goligo
goligo
> please read the requirements, especially that devices without mesh support won't be merged without the BROKEN flag. https://github.com/freifunk-gluon/gluon/wiki/Device-Integration I tend do disagree in this case, BROKEN implies there is...
Added BROKEN flag and removed it from supported devices list.
> which can lead to two devices ending up with the same MAC address Yes, we experienced that painfully with early firmware on the R2S in FFMUC. I know we...
> i wonder why we set up rules and now we tend to discuss the applicability on each occasion? Rules are great and have a purpose, but as the world...
> Can you check if using the device with OpenWrt generates random MAC addresses on subsequent boots? Yes exactly this is the case - WAN and LAN MAC addresses change...
@blocktrron That would be a patch for OpenWrt, right? Like you recently did for the R4S?
As discovered by @AiyionPrime , when trying to make progress with the stable MAC, there are more severe issues with NanoPi R1 introduced with OpenWrt 22.03 / Kernel 5.10. MMC...
I have experienced the same issue with 21.02-rc1, but using wpad-mesh-openssl, not wolfssl. In the log first I get a new peer notification, then five times MESH-SAE-AUTH-FAILURE, followed by MESH-SAE-AUTH-BLOCKED...
Shouldn't it also be possible for an AP to terminate the Wifi connection, to force the client to reconnect and send a new DHCP request? As far I understand there...
For v4, why do you want to make NAT and DHCP on the node? Why not keep it on the gateway?