DHCP requests are continuously sent to turned off network interface

[X512]

This is hrev55465.

Steps to reproduce:

1. Run PC with USB Ethernet adapter that is not connected to Ethernet cable.

2. Turn off usb_ecm interface with ifconfig /dev/net/usb_ecm/0 down or Network settings.

3. syslog shows that DHCP requests are still continuously sent:

   DAEMON 'DHCP': /dev/net/usb_ecm/0: Send DHCP_DISCOVER to 255.255.255.255:67
   DAEMON 'DHCP': /dev/net/usb_ecm/0: Timeout shift: 0 msecs (try 24)
   DAEMON 'DHCP': /dev/net/usb_ecm/0: Send DHCP_DISCOVER to 255.255.255.255:67
   DAEMON 'DHCP': /dev/net/usb_ecm/0: Send DHCP_REQUEST to 255.255.255.255:67
   DAEMON 'DHCP': /dev/net/usb_ecm/0: Send DHCP_DISCOVER to 255.255.255.255:67
   DAEMON 'DHCP': /dev/net/usb_ecm/0: Timeout shift: 500 msecs (try 1)
   DAEMON 'DHCP': /dev/net/usb_ecm/0: Send DHCP_DISCOVER to 255.255.255.255:67
   DAEMON 'DHCP': /dev/net/usb_ecm/0: Timeout shift: 1000 msecs (try 2)
   DAEMON 'DHCP': /dev/net/usb_ecm/0: Send DHCP_DISCOVER to 255.255.255.255:67
   DAEMON 'DHCP': /dev/net/usb_ecm/0: Timeout shift: 2000 msecs (try 3)
   DAEMON 'DHCP': /dev/net/usb_ecm/0: Send DHCP_DISCOVER to 255.255.255.255:67
   DAEMON 'DHCP': /dev/net/usb_ecm/0: Timeout shift: 4000 msecs (try 4)
   DAEMON 'DHCP': /dev/net/usb_ecm/0: Send DHCP_DISCOVER to 255.255.255.255:67
   DAEMON 'DHCP': /dev/net/usb_ecm/0: Timeout shift: 8000 msecs (try 5)
   DAEMON 'DHCP': /dev/net/usb_ecm/0: Send DHCP_DISCOVER to 255.255.255.255:67
   DAEMON 'DHCP': /dev/net/usb_ecm/0: Timeout shift: 24124 msecs (try 6)
   DAEMON 'DHCP': /dev/net/usb_ecm/0: Send DHCP_DISCOVER to 255.255.255.255:67
   

[kallisti5]

I have a physical usb_ecm adapter and noticed something related. Unplugging the usb_ecm device results in it remaining in ifconfig indefinitely.

Probably something wrong in teardown.

Then again, I can't get an ip address through my usb_ecm adapter either.

[pulkomandy]

Unplugging the usb_ecm device results in it remaining in ifconfig indefinitely.

This is actually intentional!

Our USB ethernet drivers support unplugging and replugging the USB side of the adapter, and restoring the connection, just as happens when you unplug the ethernet side. To do this, the drivers keep the ethernet device published and put it in "down" mode. When the device is reconnected, a function in the driver compares the MAC address, and if it's the same, it reattaches the USB device to the already existing ethernet one, instead of creating a new one.

​https://git.haiku-os.org/haiku/tree/src/add-ons/kernel/drivers/network/ether/usb_ecm/ECMDevice.cpp#n323

[kallisti5]

This is actually intentional!

Why though? No other driver does this. It's inconsistent and doesn't provide any real value.

I even saw my system hanging at one point trying to access the /dev/net/usb_ecm/0 device while it was unplugged.

Just because you can do something doesn't mean you should

[pulkomandy]

No other driver does this.

PCI drivers don't, because you rarely disconnect an ethernet card from the PCI bus while your machine is running.

But we should do this more for USB. It will also be useful when we implement powersaving (put your computer in sleep mode and cut power to USB port, wake it up, the network interface is still there and resumes normally). Or maybe you need to untangle your cables, so you unplug the USB interface and replug it in another port. It's nice to be able to do this without losing your connection and network settings (dhcp lease or static setup done manually, but also ongoing TCP connections, routes, ...).

It could show more explicitly in the UI that the interface is missing (a different state than just "link down"?), and maybe delete it after a timeout if it is not connected back?

[kallisti5]

But we should do this more for USB. It will also be useful when we implement powersaving (put your computer in sleep mode and cut power to USB port, wake it up, the network interface is still there and resumes normally).

Hm, that story is compelling.

It could show more explicitly in the UI that the interface is missing (a different state than just "link down"?), and maybe delete it after a timeout if it is not connected back?

I feel like for this to be reliable we need a few flags:

• Virtual Interface (VPN, multiple ips assigned to a physical interface), bridge
• Hot-plug Interface (Could be "detached", lower routing priority)

We probably need a bigger project to evaluate our network stack for improvements. I guess this is getting off-topic here.