sergeyk

Попробуйте на Raspberry прописать в /etc/sysctl.conf net.ipv4.conf.all.arp_announce = 1 net.ipv4.conf.all.arp_ignore = 2 и перезагрузить его вместе с Keenetic.

Другие клиенты Wi-Fi работают с нормальной скоростью на том же диапазоне?

Вот это вообще уже очень странно. То есть просто подключение по Wi-Fi не работает?

@HeavySide [W] Jun 14 21:38:19 ndm: Hotspot::Discovery::Explorer: "Bridge0": network conflict: hosts b8:27:eb:6b:9d:60 and b8:27:eb:3e:c8:35 have the same IPv4 address 192.168.0.145. У вас в сети Raspberry с обоих интерфейсов (eth0 и wlan0) отвечает на ARP для 192.168.0.145, поэтому Keenetic не знает, на какой MAC слать ответ, предназначенный для 192.168.0.145. Локально вы на какой адрес пробовали заходить?

Да. Покажите ещё "curl --verbose ...".

Нужен ещё self-test в момент, когда нет доступа в интернет (в скрытом сообщении).

@HeavySide картинки с traceroute лучше скрыть.

Покажите ещё ifconfig со всеми адресами в системе в обоих случаях.

Запускайте тогда traceroute до 8.8.8.8 в обоих случаях, будем сравнивать.

@HeavySide два маршрута до шлюза по умолчанию (192.168.0.1) не работают в Linux, даже с разной метрикой. Два одинаковых маршрута в сеть 192.168.0.0/24 тоже.

Что у вас на Rasberry в таблице маршрутизации?

[I] Jun 8 14:14:34 kernel: hub 1-1:1.0: USB hub found [I] Jun 8 14:14:34 kernel: hub 1-1:1.0: 3 ports detected [E] Jun 8 14:14:35 kernel: usb 1-1-port2: Cannot enable. Maybe the USB cable is bad? [I] Jun 8 14:14:35 kernel: usb 1-1: USB disconnect, device number 3 [I] Jun 8 14:14:36 kernel: usb 1-1-port2: attempt power cycle Смена кабеля не помогает?

@r777ay вообще, судя по журналу, виноват minidlna: [I] Jun 8 11:11:16 transmissiond: Closing session [E] Jun 8 11:11:16 ndm: Core::FileSystem::Native: failed to unmount "/tmp/mnt/01D5FCB9BFDFC440": device or resource busy. [W] Jun 8 11:11:16 ndm: Core::Server: client disconnected. [E] Jun 8 11:11:17 ndm: Core::FileSystem::Native: failed to unmount "/tmp/mnt/01D5FCB9BFDFC440": device or resource busy. [I] Jun 8 11:11:17 minidlna: Notifier thread stopped. [I] Jun 8 11:11:18 ndm: Storage::Manager: "Media0": unregistered partition "01D5FCB9BFDFC440:". Причём с третьего раза раздел всё-таки отмонтируется: два раза busy, а затем "...unregistered partition ...".

Попробуйте для эксперимента отключить CIFS, перезагрузиться, а затем отмонтировать.

Честно говоря, ничего не понятно. Эта ошибка означает, скорее всего, что какой-то процесс до сих пор удерживает файлы открытыми на этом разделе. Возможно swap или какой-то демон из Entware.

USB host — часть SoC, так что все спецификации USB-контроллера описаны в соответствующих документах на основной чипсет.

Попробуйте заменить ip static tcp BELKA 2222 dc:a6:32:ac:16:b0 22 !LB на ip static tcp BELKA 2222 172.16.17.16 22 !LB Чтобы правило с MAC работало, в таблице ARP (show ip neighbour) должно быть соответствие IP <-> MAC. Или попробуйте добавить статическую запись ip arp 172.16.17.16 dc:a6:32:ac:16:b0

Можно попробовать без сброса.

[EMI] DRAMC calibration failed Как бы намекает, что имеет смысл начать с замены чипа RAM.

@ldmh @Gaaldex похоже на https://4pda.to/forum/index.php?showtopic=883101&st=14780#entry106789105

Нужны выводы команд "show version" и "show log" в telnet.

@McMCC Или pull-request сделать.

Лучше результат "git am ...", чтобы сохранить атрибуты коммита.

К сожалению полноценных исходников ядра нынешних прошивок Keenetic'ов у меня нет, я делал вручную экспорт всех нужных заголовочных файлов из того, что было. Часть исходников я взял из ядра linux-4.9 для Android, другую, очень старую, когда я еще работал в NDM Systems и она тогда находилась в зачаточном состоянии. Тем не менее, собранные драйвера работают до сих пор, не смотря на то, что сменилось несколько внутренних версий ядра в прошивках... Почему нет? Тут вполне актуальная версия ядра.

А в чём была сложность? По описанию достаточно выбрать нужный пункт меню: