So I’m observing some strange behaviour and I believe this behaviour still exists also on older firmwares of the flint.
So a little flow chart how my network is made:
now my issue is that I’m noticing some concerning logs saying that interfaces go up and down I have no idea why…
from what I experience with vlan is that the DHCP connection gets lost, I managed to fix this by selecting the checkbox ‘Force DHCP’ in luci on this vlan interface, however for some reason I think this should not be intended can someone explain why this needs to be checked in order to not lose connection?, I think it might be related to authorative dhcp setting which needs to be off?
Note for vlan I removed one ethernet port from the lan interface, and I use the whole port perhaps I shouldn’t call it vlan, the same scenario for the print server so eth1, and eth2 are used for other interfaces while eth3 and eth4 is for normal lan.
now my other issue are the random wifi drops I’m experience once per 6 hours (I think its part of the dhcp renew or maybe related to dhcp authorative issues aswell?).
First I thought it might has todo with my Poco x3 nfc phone which tried to save power, but it seems my ax6s router doesn’t disconnect only difference is the network setup (which is default nothing changed) and soc.
my firmware is: 3.213
and the compile time of it was: 2022-03-18 17:19:52
it might be a different version than release because I can remember checking the hashes did not match and neither I remember if I did update it again.
log.zip (9.0 KB)
if I need to sent configuration files to share my setup please feel free to ask, it might not even be the firmware since for wifi I also had this on a EA 6350 with wifi dropping and im out of clues only besides that it is qualcomm related maybe.
Could you point out which part of log?
I think ‘Force DHCP’ is needed if a broadcast domain has more than one dhcp server.
For wifi drop issue, I guess you can try disable repeater - auto connect function, and stop gl_monitor
These two program more likely misfuction in complicated configuration scenarios.
Thanks about gl_monitor I will try this asap and see if its more stable for me.
about the log section its on the end for example:
Fri Apr 1 17:10:47 2022 daemon.notice netifd: Network device 'eth1' link is up
Fri Apr 1 17:10:47 2022 daemon.notice netifd: Bridge 'br-VLAN_TV' link is up
Fri Apr 1 17:10:47 2022 daemon.notice netifd: Interface 'VLAN_TV' has link connectivity
Fri Apr 1 17:10:47 2022 kern.info kernel: [44973.964059] eth1: PHY Link up speed: 100
Fri Apr 1 17:10:47 2022 kern.info kernel: [44973.964254] br-VLAN_TV: port 1(eth1) entered forwarding state
Fri Apr 1 17:10:47 2022 kern.info kernel: [44973.967103] br-VLAN_TV: port 1(eth1) entered forwarding state
Fri Apr 1 17:10:49 2022 kern.info kernel: [44975.963763] br-VLAN_TV: port 1(eth1) entered forwarding state
Fri Apr 1 19:06:12 2022 daemon.notice netifd: Network device 'eth1' link is down
Fri Apr 1 19:06:12 2022 kern.info kernel: [51898.898228] eth1: PHY Link is down
Fri Apr 1 19:06:12 2022 kern.info kernel: [51898.898789] br-VLAN_TV: port 1(eth1) entered disabled state
Fri Apr 1 19:06:13 2022 daemon.notice netifd: Bridge 'br-VLAN_TV' link is down
Fri Apr 1 19:06:13 2022 daemon.notice netifd: Interface 'VLAN_TV' has link connectivity loss
and this is with DHCP forcing checked, perhaps I’m overseeing something in where a ethernet port could be in sleep because the device is in standby?
I read the log in more detail, it’s eth1 link down twice, and eth4 link down twice.
eth4 link down then link up very quickly in 2 seconds.
but eth1 down the keep down state for more than 2 hours, then up again.
More likely eth1 is a physical reason, you can try to change a cable.
While eth4 is maybe a little driver issue, becase it recovery very soon.
This could happen, I don’t if the driver has this standby mode.