Can you describe little bit more your setup? Do you really have to restart switches? Or can you solve it by restarting network in end devices. This remembers me one of my problems I had few months ago. Windows machine caused me some troubles. When it doesn’t detect dhcp server it starts its own and starts giving addresses. When router was connected (with different ip range) network wasn’t reconfigured and I had two different ip ranges on my network. Couldn’t this be somewhat related? Just check if end devices are configured correctly.
Of course, here’s my setup:
Port 0 --> Empty
Port 1 --> Connects to 5 port switch, which connects to another 8 port switch
Port 2 --> Connects to 5 port switch
Port 3 --> Connects to 5 Port switch
Port 4 --> Connects to VOIP adapter (Model SPA112)
I really do have to restart my switches, even for PC’s that have statically defined IP’s (like my servers) require the 5 port switch they’re connected to, to be power cycled. Then its okay. None of my end devices are acting as DHCP servers, thats for sure!
I’m going to test it a bit morel, but i don’t feel its right to have to power cycle the end devices to restore connectivity, anymore than restarting the switch (remember, i didn’t have to do it before). End devices are a mix of DHCP reservation (IP’s still provided by DHCP, but predictable), static IP’s (DHCP reservation still created), and wireless clients (some DCHP reservations, some not).
Its worth mentioning that wireless clients (which connect directly to the turris omnia) do not have issues, its just anything thats connect via the switch (all of which are linksys switches and all of which are slightly different models, not the same).
Hope this information helps. Between now and your next reply, i’ll have more information for you.
thank you @cynerd
If you try to disable the auto negotiation on your switches for Turris connections and manually configure the speed and duplex. Does it fix the issue?
May you give the model of your 4 port switches? As other people describe problems with macbooks and other modern hardware my conclusion is it may have something to do with 802.3az aka energy efficient ethernet. If the links are in sleep state but do not get a wakeup then they will look like they are there but not work. Linksys SE 2500 would not suport it but SE 2800 would support it.
I have the same problem with my Netgear 8-port managed switch.
@white --> I am unable to disable auto-negotiation. My apologies, i didn’t mention, my switches are unmanaged dumb switches
@adminX --> Great question, I didn’t want to include too much detail so as not to dissuade someone from reading a giant wall of text. Your last sentence is very impressive as i have those models. The model of switches i have are as follows:
1 &2) Linksys SE2500, which connects to a Linksys SE2800 (that’s two switches). This has all DHCP reservation clients connected to it
3) Linksys EG005W, specifically this one https://images-na.ssl-images-amazon.com/images/I/41%2BRP2EI33L.SY450.jpg (kind of an old switch but it still works, please don’t make me turf it :P). This one has DHCP clients, no reservations on it
4) Linksys SE2800. This has one DHCP reservation client on it, which also has a static IP. I’ve also had a laptop plugged in directly (which has a DHCP reservation on it) and had to reboot the switch to get connectivity back.
Hope thats enough detail
Too bad my idea seems to be out of the game. Ground loops are out too because the SE2xxx do not have shielding at the ports.
This problem sounds liek the same problem i reported with the title:
DHCP/Network up seems to be flaky
I think you’re quite right
Can you ping or connect between your devices across your switches and across the omnia even if there is no internet?
Could you check what
swconfig dev switch0 show gives after you rebooted only one of your switches?
Next step would be
swconfig dev switch0 set reset && swconfig dev switch0 set apply but this may make it worse as 2 ethernet ports are then connected to the same switch as all ports are simply switched.
@adminX Okay, finally got around to rebooting my router tonight. Here’s what i did/what i discovered:
After rebooting the router, as I mentioned above, wireless clients re-connect just fine. So wireless clients are a non-issue
I am able to ping a device thats connected to the switch my main PC is connected to, but not a device thats connected to another switch (in the bedroom).
After a single switch reboot, the swconfig dev switch0 show command gives me:
mask: 0x0000: (0)
link: port:0 link:down
mask: 0x0000: (1)
link: port:1 link:up speed:100baseT full-duplex
mask: 0x0000: (2)
link: port:2 link:up speed:1000baseT full-duplex
mask: 0x0000: (3)
link: port:3 link:up speed:1000baseT full-duplex
mask: 0x0000: (4)
link: port:4 link:down
mask: 0x0000: (5)
link: port:5 link:up speed:1000baseT full-duplex
mask: 0x0000: (6)
link: port:6 link:up speed:1000baseT full-duplex
Hope this helps, and thank you for your help
My guess is you reset the switch connected to port 1 because it is connected with 100 Mbit but all your switches are gigabit ones. Right?
@adminX I apologize. Port 1 actually has my VOIP adapter (which is why its only connected at 100 Mbit. The switch i rebooted was in port 2.
My apologies for screwing that up.
No Problem. I also needed some ideas what could happen.
After quite some reboots and different connections i got a similar problem on another switch. It was only one port affected and i could get it working again using its admin console. The problem was a stale MAC address entry on another port and vlan. This won’t help with your problem as there should be no duplicate MAC entry as you do not move things around.
After a reboot all switch ports get isolated. swconfig will create the vlans and add the ports but I could not find a function that flushes the MAC table in the switch. Setting the VLANs to port_based it won’t have to clear the MAC table as the ports are still without VLAN.
uci set 'network.@switch_vlan.port_based=1' uci set 'network.@switch_vlan.port_based=1' uci commit
will set the VLANs in the switch to plain port based ones. You may also edit /etc/config/network and add the options there.
config switch_vlan option device 'switch0' option vlan '1' option ports '0 1 2 3 5' option port_based '1' config switch_vlan option device 'switch0' option vlan '2' option ports '4 6' option port_based '1'
To remove the settings use
uci set 'network.@switch_vlan.port_based=0' uci set 'network.@switch_vlan.port_based=0' uci commit
or edit the file again.
Okay so this is all fine and good, but seems like the problem was the actual switches for me. I replaced two of the switches (One SE2500 and one SE2800) with two Se3005’s. Now when i reboot the TO, i am not required to reboot the switches as well (well for now at least). I’ll be watching this slowly…but i think the TO team should look at this bug as i’m sure telling people to change out their switches when they get a new router is not a sustainable practice
Cheers and thank you @adminX
Replacing switches is no solution as the new ones may have the same problem. If you don’t mind could you keep your old switches?
There are some hints what happens and some people are working on this. Someone able to test this in addition to everyone else may be a good thing.
More up to date information as in
I’ll keep the old ones for sure and test the new ones some more. Thanks for your help!
It happen to me also with my HP N54L (with fixed IP address, so no DHCP involved)… the logs in the server that the adapter link is down, but nothing else… I need to reboot the N54L because of the missing link.
I’ve been battling this for several days now. As of this morning, odhcpd does not appear to do anything - no addresses assigned, no active v4 leases, no assignment of static reservations. In the last 24 hours, dhcp on my Omnia basically disappeared - worked last night before I went to bed. Gone this morning after what I’m guessing was an update reboot.
This evening I’m attempting to switch my network over to dhcp being managed on my Ubiquiti core switch rather than on the Omnia. Ubiquiti’s dhcp server is only partly working - static reservations are not being assigned, static clients that receive a wrong ip don’t seem to be able to release it for their assigned ip, and clients are unable to connect to the Omnia wireless networks bc no ip addresses are being assigned on the Omnia. At least the core servers are connected, albeit with wrong ip addresses.
Prior to today (i.e. periodically over the last few weeks) I have noticed the same issue you mentioned - had to reboot my switch after rebooting the router. My switch is managed, so I’m inferring that the problem has nothing to do with managed or unmanaged switch.