-
Есть железка cubieboard3/cubietruck, но проблема вряд-ли специфична. На неё месте мог бы быть любой Raspberry. На ней есть распаянная флешка, там стоит какой-то неведомый линукс - он не важен. Важно, что этот распаянный линукс после загрузки умеет посылать запросы по BOOTP/DHCP в etnerhet-сеть и успешно получать себе IP-адрес. Дальше на распаянный линукс можно прийти по ssh и успешно получить официальный отлуп (паролей я не знаю). В общем, сеть работает в две стороны. Кроме распаянной флешки, железка умеет грузиться с SD-карты, если таковая воткнута.
-
У других людей была такая же железка, которую долго грузили с SD-карты, причём readonly (ну не важно). На SD-карте была свежая Armbian - ну считай Debian/Ubuntu, скомпилённая под этот Allwinner A20 ARM cortex-A7. Я взял у людей эту флешку и тупо скопировал себе корень. Как файлики. Тупо через tar -czvf весь корень. (да-да, я просто мог скачать образ Armbian и официально накатить, но были нужны накопившиеся изменения и оптимизации в системе, сделанные этими людьми; да-да, можно было скопировать флешку как образ, но это была бы другая история наверное). Далее взял вторую флешку, создал там таблицу разделов и 1 раздел ext4 (поставил ещё на нём галку BOOT, возможно это ни на что не влияет), распаковал в этот новый ext4 свой архив. Далее ещё немного страданий: скомпилил U-Boot, накатил на флешку U-Boot, пофиксил в /boot конфиге UUID корневой ext4 на правильный. В общем, успешно удаляя зубы через ноздри, заставил железку грузиться с моей франкенштейн-флешки.
-
Втыкаю свою новую флешку в свою железку. Косвенно по миганиям лампочек я вижу, что теперь загружается не что-то с распаянной флешки, ибо мигания совсем не характерны, а кое что и вообще не мигает! Грузится именно система с моей SD. Причём успехово загружается, видимо даже доходит до исполнения /etc/network/interfaces и начинает посылать BOOTP/DHCP запросы. Ну и по логам на DHCP-сервере я вижу, что запросы приходят, но немного другие… И тут-то самый цимес!
-
ВОПРОС-ПРИКОЛ. Прикол в том, что у системы с флешки сеть как будто односторонняя! С распаянной флешки приходит один MAC, а система с SD-карты говорит другой MAC (это не самое страшное, подумаешь разные MAC). Но системе с распаянной флешки IP-адрес выдают - она проходит успешно все 4 этапа: DHCPDISCOVER, DHCPOFFER, DHCPREQUEST, DHCPACK. Но система с SD-карты как будто физически не видит пакетов от DHCP-сервера. От SD-карты приходит DHCPDISCOVER, DHCP-сервер отвечает обратно DHCPOFFER и на этом конец до следующего повтора цикла. Как будто у системы на флешке этот MAC где-то забит, который конфликтует с физическим: как будто на исходящие пакеты проставляется какой-то левый, а входящие отбрасывает сама сетевуха физически, т.к. думает, что это пришло не для неё. Но нет! Замена MAC на SD-карте (написанием hwaddress ether 00:11:22:33:44:55 в /etc/network/interfaces где следует) не меняет ситуацию - точнее на DHCP-сервер SD-карта теперь приходит с тем же MAC, с каким приходила распаянная флешка, но толку нет. Свитчей между устройствами нет: клиент прямо кабелем UTP воткнут в сервер. Покопаться в системе в распаянной флешке возможности нет, чтобы что-то позучать, да и неинтересно. Грепание MAC-адреса, с которым в DHCP-сервер приходила SD-карта на этой SD-карте успехов не принесло, видимо это таки настоящий MAC, а на распаянной флешке забит левый, но это тоже не важно. Пробовал поставить статический адрес на SD-карту: эффект ещё интереснее: когда SD-карту пингуешь с хоста A, то SD-карта начинает вещать в сеть ARP-запросы: «а кто из вас тут A?», на что A отправляет ответы в сеть, но их как будто никто не видит. Скорее всего ARP-запросы от железки с пингом не связаны, а связаны с тем, что адрес A был случайно забит на SD-карту как default gateway, а с пингом просто по времени совпало. В общем, чудесный прикол: как будто слепая на приём сеть на cubieboard-3/cubietruck при загрузке с этой странной флешки. Я бы понял, если бы на флешке побились модули ядра про сеть, но в одну сторону-то сеть работает!
Кто что думает хорошего про всё это - поделитесь! Спасибо.
Немного дампа трафика с запросами DHCPDISCOVER и уходящими вникуда DHCPOFFER:
03:25:23.646663 02:0b:04:02:22:20 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 342: 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 02:0b:04:02:22:20, length 300
03:25:23.646814 28:d2:44:bd:f8:8a > 02:0b:04:02:22:20, ethertype IPv4 (0x0800), length 342: 192.168.30.1.67 > 192.168.30.16.68: BOOTP/DHCP, Reply, length 300
03:25:39.412397 02:0b:04:02:22:20 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 342: 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 02:0b:04:02:22:20, length 300
03:25:39.412829 28:d2:44:bd:f8:8a > 02:0b:04:02:22:20, ethertype IPv4 (0x0800), length 342: 192.168.30.1.67 > 192.168.30.16.68: BOOTP/DHCP, Reply, length 300
SOLVED Решено. Но вопросов осталось ещё больше: надо было пересобрать U-Boot с конфигом не для Cubieboard3, а для Cubieboard2, потому что тот конфиг взводит какие-то не те GPIO-пины, в результате чего из-за особенностей разводки платы сетевуха впадает в полуглухой режим работы. Это жепь-ебрилло и понять без бутылки это невозможно, но это работает.
