Re: netifd issue
Felix Fietkau kirjoitti 10.11.2023 klo 16.38: On 10.11.23 15:21, e9hack wrote: Too fast. I did reboot with the old version again. The patched version does work. Fix pushed, thanks for testing! - Felix Thanks, I tested the current netifd with the fix, and it seems to work ok, again. Please remember to backport the fixed netifd to 23.05, as currently 23.05 has the faulty version. Hannu ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: netifd issue
On 10.11.23 15:21, e9hack wrote: Too fast. I did reboot with the old version again. The patched version does work. Fix pushed, thanks for testing! - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: netifd issue
Too fast. I did reboot with the old version again. The patched version does work. Sorry! Regards, Hartmut Am 10.11.2023 um 15:09 schrieb e9hack: Sorry, but it doesn't solve the issue. Regards, Hartmut Am 10.11.2023 um 14:13 schrieb Felix Fietkau: I think I found the cause of this regression while looking at the code again. It seems that the hotplug-added devices are removed too early based on DEV_EVENT_REMOVE events. Please try this fix: https://nbd.name/p/2791d8d4 Sorry, the last patch was incomplete. Here is the correct version: https://nbd.name/p/8a6bc06b Thanks, - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: netifd issue
Sorry, but it doesn't solve the issue. Regards, Hartmut Am 10.11.2023 um 14:13 schrieb Felix Fietkau: I think I found the cause of this regression while looking at the code again. It seems that the hotplug-added devices are removed too early based on DEV_EVENT_REMOVE events. Please try this fix: https://nbd.name/p/2791d8d4 Sorry, the last patch was incomplete. Here is the correct version: https://nbd.name/p/8a6bc06b Thanks, - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: netifd issue
On 10.11.23 13:59, Felix Fietkau wrote: On 09.11.23 22:31, Hannu Nyman wrote: e9hack kirjoitti 9.11.2023 klo 17.32: I face a strange behaviour since commit 516ab774cc16d4b04b3b17a067cbf2649f1adaeb (system-linux: fix race condition on bringing up wireless devices). After a reboot or a full restart of hostapd via 'wifi down; sleep 30; killall hostapd; sleep 5; wifi', only the first of 3 5G AP's is join to the configured bridge. The two faulty AP's are up and connecting is possible, but there is no real network connection. If I change one parameter of the faulty AP's in the config file and do a 'wifi reload', than the 2 AP's are join to the bridges. ... If I change the sequence of the 5G AP's in the config file, the behaviour after reboot doesn't change. Only phy1-ap0 does join to the bridge, either to br-lan or to br-tor. The previous netifd commit 40ed7363caf2b22b6e29ed9d9948189c2bc4c8f3 (device: fix build error on 32 bit systems) doesn't have this issue. I see the same error. Some APs do not initially join the bridge, but after making a small pointless edit to the AP's config in /etc/config/wireless and reloading wifi, the AP then joins the bridge. OpenWrt SNAPSHOT, r24331-168beef1dd - root@router4:~# brctl show bridge name bridge id STP enabled interfaces br-lan 7fff.c4411ef8a51f no lan4 lan2 hn5wpa3 lan3 lan1 root@router4:~# nano /etc/config/wireless root@router4:~# wifi reload root@router4:~# brctl show bridge name bridge id STP enabled interfaces br-lan 7fff.c4411ef8a51f no lan4 hn5wpa2r lan2 hn5wpa3 lan3 lan1 I think I found the cause of this regression while looking at the code again. It seems that the hotplug-added devices are removed too early based on DEV_EVENT_REMOVE events. Please try this fix: https://nbd.name/p/2791d8d4 Sorry, the last patch was incomplete. Here is the correct version: https://nbd.name/p/8a6bc06b Thanks, - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: netifd issue
On 09.11.23 22:31, Hannu Nyman wrote: e9hack kirjoitti 9.11.2023 klo 17.32: I face a strange behaviour since commit 516ab774cc16d4b04b3b17a067cbf2649f1adaeb (system-linux: fix race condition on bringing up wireless devices). After a reboot or a full restart of hostapd via 'wifi down; sleep 30; killall hostapd; sleep 5; wifi', only the first of 3 5G AP's is join to the configured bridge. The two faulty AP's are up and connecting is possible, but there is no real network connection. If I change one parameter of the faulty AP's in the config file and do a 'wifi reload', than the 2 AP's are join to the bridges. ... If I change the sequence of the 5G AP's in the config file, the behaviour after reboot doesn't change. Only phy1-ap0 does join to the bridge, either to br-lan or to br-tor. The previous netifd commit 40ed7363caf2b22b6e29ed9d9948189c2bc4c8f3 (device: fix build error on 32 bit systems) doesn't have this issue. I see the same error. Some APs do not initially join the bridge, but after making a small pointless edit to the AP's config in /etc/config/wireless and reloading wifi, the AP then joins the bridge. OpenWrt SNAPSHOT, r24331-168beef1dd - root@router4:~# brctl show bridge name bridge id STP enabled interfaces br-lan 7fff.c4411ef8a51f no lan4 lan2 hn5wpa3 lan3 lan1 root@router4:~# nano /etc/config/wireless root@router4:~# wifi reload root@router4:~# brctl show bridge name bridge id STP enabled interfaces br-lan 7fff.c4411ef8a51f no lan4 hn5wpa2r lan2 hn5wpa3 lan3 lan1 I think I found the cause of this regression while looking at the code again. It seems that the hotplug-added devices are removed too early based on DEV_EVENT_REMOVE events. Please try this fix: https://nbd.name/p/2791d8d4 Thanks, - Felix ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
Re: netifd issue
e9hack kirjoitti 9.11.2023 klo 17.32: I face a strange behaviour since commit 516ab774cc16d4b04b3b17a067cbf2649f1adaeb (system-linux: fix race condition on bringing up wireless devices). After a reboot or a full restart of hostapd via 'wifi down; sleep 30; killall hostapd; sleep 5; wifi', only the first of 3 5G AP's is join to the configured bridge. The two faulty AP's are up and connecting is possible, but there is no real network connection. If I change one parameter of the faulty AP's in the config file and do a 'wifi reload', than the 2 AP's are join to the bridges. ... If I change the sequence of the 5G AP's in the config file, the behaviour after reboot doesn't change. Only phy1-ap0 does join to the bridge, either to br-lan or to br-tor. The previous netifd commit 40ed7363caf2b22b6e29ed9d9948189c2bc4c8f3 (device: fix build error on 32 bit systems) doesn't have this issue. I see the same error. Some APs do not initially join the bridge, but after making a small pointless edit to the AP's config in /etc/config/wireless and reloading wifi, the AP then joins the bridge. OpenWrt SNAPSHOT, r24331-168beef1dd - root@router4:~# brctl show bridge name bridge id STP enabled interfaces br-lan 7fff.c4411ef8a51f no lan4 lan2 hn5wpa3 lan3 lan1 root@router4:~# nano /etc/config/wireless root@router4:~# wifi reload root@router4:~# brctl show bridge name bridge id STP enabled interfaces br-lan 7fff.c4411ef8a51f no lan4 hn5wpa2r lan2 hn5wpa3 lan3 lan1 ___ openwrt-devel mailing list openwrt-devel@lists.openwrt.org https://lists.openwrt.org/mailman/listinfo/openwrt-devel
