Вопрос или проблема
в настоящее время мы разрабатываем плату на базе embedded linux с интегрированным коммутатором KSZ8775. Ядро Linux: v5.15
Настройка коммутатора следующая:
Порт 1: Пользователь 1
Порт 2: Пользователь 2
Порт 3: Пользователь 3
Порт 4: Внешний PHY - Пользователь 4
Порт 5: Интерфейс CPU-Хост (Linux-система)
Интерфейс процессора настроен как RMII, а для управления используется SPI. Я включил драйверы ядра и добавил устройство в свое дерево устройств. Я также настроил драйвер ksz8795 для принятия ksz8775.
Все хорошо, при загрузке я получаю все пользовательские интерфейсы коммутатора (lan1, lan2, lan3, lan4, как указано в дереве устройства). Затем я создаю интерфейс моста и добавляю к нему lan1, lan2 и т.д. Как описано здесь: https://www.kernel.org/doc/html/v5.15/networking/dsa/configuration.html
С этой конфигурацией пользовательские порты могут пинговать друг друга, например, пользователь 2 может пинговать пользователя 1 и наоборот. К сожалению, главный интерфейс (хост-процессор) не может пинговать ни одного пользователя, и ни один пользователь не может пинговать главный интерфейс.
Когда я пытаюсь пинговать главный интерфейс с пользовательского порта, я вижу входящие пакеты ARP и также вижу, что они отвечают. Например, здесь я использую tcpdump, чтобы увидеть весь трафик на eth0 (подключенном к порту 5 коммутатора):
root@picocoremx6ull100-de-dp-eval:~/tools# ./tcpdump -i eth0
tcpdump: подробный вывод подавлен, используйте -v[v]... для полного декодирования протокола
прослушивание на eth0, тип связи NULL (BSD loopback), длина снимка 262144 байт
23:21:38.691465 AF Неизвестный (4294967295), длина 61:
0x0000: ffff 0005 5107 5584 0806 0001 0800 0604 ....Q.U.........
0x0010: 0001 0005 5107 5584 c0a8 0214 0000 0000 ....Q.U.........
0x0020: 0000 c0a8 0201 0000 0000 0000 0000 0000 ................
0x0030: 0000 0000 0000 0000 02 .........
23:21:38.691786 AF Неизвестный (348423), длина 61:
0x0000: 5584 46e2 4a3e 7493 0806 0001 0800 0604 U.F.J>t.........
0x0010: 0002 46e2 4a3e 7493 c0a8 0201 0005 5107 ..F.J>t.......Q.
0x0020: 5584 c0a8 0214 0000 0000 0000 0000 0000 U...............
0x0030: 0000 0000 0000 0000 04 .........
23:21:39.709613 AF Неизвестный (4294967295), длина 61:
0x0000: ffff 0005 5107 5584 0806 0001 0800 0604 ....Q.U.........
0x0010: 0001 0005 5107 5584 c0a8 0214 0000 0000 ....Q.U.........
0x0020: 0000 c0a8 0201 0000 0000 0000 0000 0000 ................
0x0030: 0000 0000 0000 0000 02 .........
23:21:39.709862 AF Неизвестный (348423), длина 61:
0x0000: 5584 46e2 4a3e 7493 0806 0001 0800 0604 U.F.J>t.........
0x0010: 0002 46e2 4a3e 7493 c0a8 0201 0005 5107 ..F.J>t.......Q.
0x0020: 5584 c0a8 0214 0000 0000 0000 0000 0000 U...............
0x0030: 0000 0000 0000 0000 04 .........
Я вижу ARP-запрос “кто имеет 192.168.2.1”, поступающий от 192.168.2.20, подключенного к пользовательскому порту 3. Сразу после запроса приходит ARP-ответ “192.168.2.1 имеет адрес 46:e2:4a:3e:74:93”.
Также метки в пакетах кажутся корректными. “02” для пакетов от коммутатора к процессору и “04” для пакетов от процессора к коммутатору. Это точно так, как описано в драйвере ядра в tag_ksz.c.
Вот дополнительная информация:
root@picocoremx6ull100-de-dp-eval:~/tools# bridge vlan show
порт vlan-id
lan1 1 PVID Egress Untagged
lan2 1 PVID Egress Untagged
lan3 1 PVID Egress Untagged
br0 1 PVID Egress Untagged
root@picocoremx6ull100-de-dp-eval:~/tools# ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1501 qdisc pfifo_fast state UP group default qlen 1000
link/ether 46:e2:4a:3e:74:93 brd ff:ff:ff:ff:ff:ff
inet6 fe80::44e2:4aff:fe3e:7493/64 scope link
valid_lft forever preferred_lft forever
3: sit0@NONE: <NOARP> mtu 1480 qdisc noop state DOWN group default qlen 1000
link/sit 0.0.0.0 brd 0.0.0.0
4: lan1@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br0 state UP group default qlen 1000
link/ether 46:e2:4a:3e:74:93 brd ff:ff:ff:ff:ff:ff
inet6 fe80::44e2:4aff:fe3e:7493/64 scope link
valid_lft forever preferred_lft forever
5: lan2@eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue master br0 state LOWERLAYERDOWN group default qlen 1000
link/ether 46:e2:4a:3e:74:93 brd ff:ff:ff:ff:ff:ff
inet6 fe80::44e2:4aff:fe3e:7493/64 scope link
valid_lft forever preferred_lft forever
6: lan3@eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue master br0 state LOWERLAYERDOWN group default qlen 1000
link/ether 46:e2:4a:3e:74:93 brd ff:ff:ff:ff:ff:ff
inet6 fe80::44e2:4aff:fe3e:7493/64 scope link
valid_lft forever preferred_lft forever
7: spe@eth0: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
link/ether 46:e2:4a:3e:74:93 brd ff:ff:ff:ff:ff:ff
8: br0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP group default qlen 1000
link/ether 46:e2:4a:3e:74:93 brd ff:ff:ff:ff:ff:ff
inet 192.168.2.1/24 scope global br0
valid_lft forever preferred_lft forever
inet6 fe80::44e2:4aff:fe3e:7493/64 scope link
valid_lft forever preferred_lft forever
root@picocoremx6ull100-de-dp-eval:~/tools#
то же самое tcpdump входящего пинга, но на интерфейсе моста br0:
root@picocoremx6ull100-de-dp-eval:~/tools# ./tcpdump -i br0
устройство br0 перешло в промискуитетный режим
tcpdump: подробный вывод подавлен, используйте -v[v]... для полного декодирования протокола
прослушивание на br0, тип связи EN10MB (Ethernet), длина снимка 262144 байт
23:58:05.658830 IP 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Запрос от 00:05:51:07:55:84 (oui Неизвестный), длина 300
23:58:08.482775 ARP, Запрос who-has 192.168.2.1 tell 192.168.2.20, длина 46
23:58:08.482877 ARP, Ответ 192.168.2.1 is-at 46:e2:4a:3e:74:93 (oui Неизвестный), длина 28
23:58:09.558810 ARP, Запрос who-has 192.168.2.1 tell 192.168.2.20, длина 46
23:58:09.558910 ARP, Ответ 192.168.2.1 is-at 46:e2:4a:3e:74:93 (oui Неизвестный), длина 28
23:58:10.598784 ARP, Запрос who-has 192.168.2.1 tell 192.168.2.20, длина 46
23:58:10.598886 ARP, Ответ 192.168.2.1 is-at 46:e2:4a:3e:74:93 (oui Неизвестный), длина 28
Но кажется, что коммутатор не передает ответ обратно к пользовательскому порту, который отправил запрос. Есть ли что-то, что я упускаю в настройке моста? В принципе, я хочу, чтобы каждый порт (пользовательский и процессорный) мог общаться друг с другом. Мне нужно добавить отдельный интерфейс в мост для связи с пользовательскими портами, или эта настройка должна работать?
К сожалению, я не очень хорошо разбираюсь в сетях… Дайте знать, если вам нужна дополнительная информация.
Надеюсь, это подходящее место, чтобы попросить помощь по этому вопросу.
Спасибо!
Ответ или решение
Когда речь идет о встраиваемых системах Linux с использованием коммутатора, возникает множество сложностей с конфигурацией сети. В описанном вами сценарии, главная задача состоит в том, чтобы наладить корректное взаимодействие между портами коммутатора и главным интерфейсом CPU через мостовую конфигурацию. Давайте разберем, что может пойти не так и какие шаги можно предпринять для решения проблемы.
Теория
Как вы описали, вы используете коммутатор KSZ8775 с драйвером KSZ8795 в Linux kernel версии 5.15. Коммутатор интегрируется в систему, и каждый его порт является отдельной сетевой интерфейсной точкой. Конфигурация предполагает, что все порты (включая главный интерфейс для CPU) должны быть добавлены в сетевой мост, чтобы обеспечить их взаимодействие. Когда моста строится, каждый пакет, включая ARP-запросы, должен корректно маршрутизироваться между интерфейсами, чтобы обеспечить связь. В случае ARP-запросов, пакеты должны дойти до целевого устройства, и ответы должны вернуться обратно.
Пример
Ваша проблема заключается в том, что, несмотря на видимые ARP-запросы и ответы на них, главный интерфейс CPU не может обмениваться данными с «пользовательскими» портами или быть доступным для них. Вы упоминаете видимые ARP-пакеты через tcpdump, включая запросы и ответы, но сообщения не доходят обратно до интерфейсов через коммутатор.
Применение
-
Проверьте тэгирование и обработку тэйл-тэгов: В драйвере KSZ8795 предусмотрена система тэгирования трафика с использованием последних байтов пакета для определения направления (пакет от коммутатора к CPU или в обратном направлении). Убедитесь, что тэги правильно интерпретируются драйвером, и соответствующие пакеты не отбрасываются из-за некорректной обработки.
-
Диагностика сетевой конфигурации:
- Изучите таблицу MAC-адресов (например, с помощью
bridge fdb show), чтобы убедиться, что адреса корректно изучены мостом и ядром системы. Если MAC-адреса главного интерфейса или пользовательских интерфейсов отсутствуют, это может означать проблемы в их обучении коммутатором. - Проверьте маршрутизацию и флагирование пакетов, чтобы убедиться, что они направлены в нужные интерфейсы.
- Изучите таблицу MAC-адресов (например, с помощью
-
Конфигурация моста:
- Убедитесь, что каждый интерфейс моста, включающий CPU и пользовательские порты, корректно настроен и активен в составе моста (проверьте это с помощью
brctl showилиbridge link). - Проверьте, есть ли на CPU интерфейсе правильная IP-конфигурация, и удалите IP с физических интерфейсов (
lanX), кроме самого моста (br0), если они установлены.
- Убедитесь, что каждый интерфейс моста, включающий CPU и пользовательские порты, корректно настроен и активен в составе моста (проверьте это с помощью
-
Исследование логов karusela: В дополнение к видимости пакетов через
tcpdump, попробуйте исследовать системные логи (dmesgили/var/log/syslog) для диагностирования аномалий или ошибок, связанных с драйвером коммутатора. -
Настройка драйвера: Иногда специфические исправления драйверов или обновления могут содержать исправления для специфичной ситуации или аппаратной конфигурации. Проверьте последний статус драйвера и убедитесь, что у вас установлена самая новая версия или патч, адаптированный для KSZ8775.
-
Конфигурация VLAN (если применимо): Поскольку ваш мост не настроен на использование VLAN, убедитесь, что ни один из интерфейсов не ждет тегированных кадров, если это не было явно запланировано.
Если все эти меры не привели к желаемому результату, и проблема остается, возможно потребуется провести глубокий аудит драйвера на предмет несовместимости или ошибок в коде обработки. Важность обращения к сообществу разработчиков, поддержке дистрибутива или, если есть доступ, к сотрудникам производителя аппаратного обеспечения остается важным шагом в поиске решения. В некоторых случаях может потребоваться разработка кастомного решения или патча, чтобы проблемы были решены.