I have a TSW202 that I am trying to run in pure DHCP mode - i.e. not static IP address that will eventually conflict with something.
My setup is a RUTX11 acting as the LAN DHCP server, with a static DHCP entry for the TSW202. The TSW202 has the DHCP Interface enabled and Static Interface disabled.
If I simply unplug the ethernet link between the RUTX11 and the TSW202 and plug it back in, then I can no longer access the device with ping / web ui / ssh cli, and it never recovers.
If I leave the static interface enabled and do the same test, it does continue to be accessible at the DHCP IP.
The only workaround I’ve come up with is enabling the ping reboot, but at default settings that means it remain inaccessible for 10 minutes because I moved a cable.
This seems like a bug, but is there a workaround that could be done with scripting? Maybe something in /etc/hotplug.d/iface?
It appears that with only a DHCP interface enabled, the br0/br0.1 network devices get deleted when all links are down, and this causes the dhcp client process (udhcpc) to exit. Upon network reconnection, the br0/br0.1 devices are recreated, but nothing restarts the udhcpc and I can’t seem to find a suitable startup script to poke from hotplug that is supposed to kick this off.
So the workaround is that you NEED a static interface defined and enabled for DHCP to continue working after a network disconnect / reconnect. For my case where I want to avoid leaving a rogue static IP laying around that may conflict with some network the switch is plugged into, I will be changing the static interface to use a link-local 169.254.x.x/32 address | 0.0.0.0 gateway.
Hopefully the need for this kind of workaround can be fixed in a future firmware release -
or at least a stern warning in the UI about disabling the static IP.
I’ve tested this on 1.05 and 1.06 firmware versions and both ended up working correctly. If you aren’t running the latest firmware, just for testing purposes, could you upgrade and test again to see if the issue persists?
I was running 1.05 when this was posted, but haven’t tested 1.06.
How specifically did you test? I disabled the static interface and only had a dhcp interface, which on boot up obtained a dhcp lease. I then unplugged all network cables and then plugged them back in, at this point the device is not accessible and as far as I could tell, never becomes accessible.
For testing purposes, could you set up a management VLAN on one of the ports on the switch so you have permanent access to the device? You’ll have to set a static IP on your PC to access the switch, though, so make sure you do that.
What I need you to do, is do the same configuration steps as you did previously, but have the command tcpdump -i any port 67 or port 68 -n running on your RUTX11 to see if your switch is sending DHCP requests to it, you may also run logread -f as I did on your switch to see if anything is being leased at all.
Once you do that, please provide the outputs here, just make sure to blur out any sensitive information such as MAC addresses, Public IP addresses, and such.
Have you tried replicating my experiment to see it fail? I’ll test my way again with 1.06 when I get back to my bench. I figure having a link active for management purposes will avoid the issue.
So to be clear, the setup is a RUTX11 acting as the DHCP server with a connection to the TSW202 and the TSW202 has no other cables connected.
The test is to simply unplug this single connection to the TSW202 and plug it back in.
With a both the dhcp interface and a static interface enabled, tcpdump on the RUTX11 shows DHCP activity (not sure why 3 in a row, but that’s what it did):
Repeating the test with the static interface disabled results in no DHCP activity shown by tcpdump.
This is a very simple test. The TSW202 requires a power cycle if it only has a dhcp interface and all ports go down for any reason. See my 2nd post as to why.
I’ve sent you a form to fill out so we can continue our conversation in private, to avoid accidentally leaking any sensitive information. In the Ticket ID field, simply enter the thread’s number, which is 13556.
