Hotplug.d: detect interface name assigned to USB Modem cdc_ether / rndis_host

Installing and Using OpenWrt Network and Wireless Configuration
1

I have searched through the forum but couldn't find a sureshot way to detect the device name assigned to the USB dongle plugged in.

Depending on device, it is either detected as usbX or ethX. Driver is either cdc-ether or rndis-host.

I am not in control of what USB devices will be plugged-in to the device in the field.

Instead of trying to make the naming predictable, I would want to know the device name assigned to it by the kernel so that I can dynamically populate the ifname in /etc/config/network using a hotplug script.

One way is to tail the syslog using a monitor script, which will waste CPU cycles.

Is there a better way to know the interface name assigned?

2 Likes
2

Check if this could help

1 Like
3

Already tried it. None of the variables provide the ifname assigned by the kernel.

Putting this line in script:
logger -t RNDIS: "$vid $pid $DEVTYPE $TYPE $DRIVER $SUBSYSTEM $PRODUCT $DEVPATH"

Provides following output:
Fri Nov 20 13:43:57 2020 user.notice RNDIS:: 19d2 1557 usb_device 0/0/0 usb 19d2/1557/101 /devices/platform/1e1c0000.xhci/usb1/1-1

I have also went through the $PATH under /sys but no useful information available to know the interface name.

4

Are there any iface-specific events?

5

No.

Not until ifname is defined in an interface in /etc/config/network and is brought up / down by USB plug/unplug.

I want to automate this process:

  1. Plug USB device
  2. Identify by looking at logs if it is usb0 or eth2
  3. Modify configuration in /etc/config/network by setting appropriate ifname
  4. Execute ifup usbwan

It is achievable by writing a script to watch syslog messages and do the above, but is not an elegant solution.

I am looking for an actual hotplug event detection to find the ifname.

6

you'll likely need to walk /sys to to get the devpath during the appropriate hplug stage... there was a recent thread re: changing network device names in vmware via pci-devname that discussed similar principles... it is no walk in the park... some more hplug hooks might help... when I did something similar I needed... some hooks were via net and some via iface... and that made it tricky... not so sure if these things are exposed via qmi/whatever you are working with as i've never used those apologies...

there is another thread about debugging hotplug where a cool dev... the name escapes me... mentions installing udev? this may be useful also... edit: @dl12345 here glad i looked cause you never would have found it.... lol...

7

I tried to add a dummy interface and it invoked a net-specific event.

8

But the dummy interface need to have an ifname and until that is created by the kernel, the dummy interface will not come up.

Could you please elaborate more on how you had achieved it?

9

Replying to myself here:

config interface 'wan3'
        list ifname 'eth1'
        list ifname 'usb0'
        option type 'bridge'
        option proto 'dhcp'
        option metric '30'
        option peerdns '0'
        option dns '8.8.8.8 8.8.4.4'

This brings usbwan up irrespective if the ifname is usb0 or eth1 (on my test device switch is eth0 so next higher device available is eth1)

And here are the logs:

* DISCONNECTED DONGLE:
Tue Dec 15 11:40:23 2020 kern.info kernel: [639843.653015] usb 1-1: USB disconnect, device number 5
Tue Dec 15 11:40:23 2020 kern.info kernel: [639843.663456] rndis_host 1-1:1.0 eth1: unregister 'rndis_host' usb-1e1c0000.xhci-1, RNDIS device
Tue Dec 15 11:40:23 2020 kern.info kernel: [639843.684914] br-wan3: port 1(eth1) entered disabled state
Tue Dec 15 11:40:23 2020 kern.info kernel: [639843.717028] br-wan3: port 1(eth1) entered disabled state
Tue Dec 15 11:40:23 2020 daemon.notice netifd: bridge 'br-wan3' link is down
Tue Dec 15 11:40:23 2020 daemon.notice netifd: Network alias 'br-wan3' link is down
Tue Dec 15 11:40:23 2020 daemon.notice netifd: Interface 'wan3_6' has link connectivity loss
Tue Dec 15 11:40:23 2020 daemon.notice netifd: Interface 'wan3' has link connectivity loss
Tue Dec 15 11:40:23 2020 daemon.notice netifd: wan3 (21619): udhcpc: received SIGTERM
Tue Dec 15 11:40:23 2020 daemon.notice netifd: Interface 'wan3' is now down
Tue Dec 15 11:40:24 2020 daemon.notice netifd: Interface 'wan3_6' is now down
Tue Dec 15 11:40:24 2020 daemon.notice netifd: Interface 'wan3_6' is disabled
Tue Dec 15 11:40:24 2020 daemon.notice netifd: Interface 'wan3' is disabled
Tue Dec 15 11:40:24 2020 daemon.err odhcpd[1753]: Failed to send to ff02::2%wan3_6@br-wan3 (No such device)

* CONNECTED PHONE:
Tue Dec 15 11:40:27 2020 kern.info kernel: [639848.003942] usb 1-1: new high-speed USB device number 6 using xhci-mtk
Tue Dec 15 11:40:27 2020 user.notice RNDIS:: 18d1 4ee7 usb_device 0/0/0  usb 18d1/4ee7/ffff /devices/platform/1e1c0000.xhci/usb1/1-1
Tue Dec 15 11:40:39 2020 kern.info kernel: [639859.812207] usb 1-1: USB disconnect, device number 6
Tue Dec 15 11:40:39 2020 kern.info kernel: [639860.323923] usb 1-1: new high-speed USB device number 7 using xhci-mtk
Tue Dec 15 11:40:39 2020 kern.info kernel: [639860.532454] rndis_host 1-1:1.0 usb0: register 'rndis_host' at usb-1e1c0000.xhci-1, RNDIS device, d6:44:34:bb:d1:c5
Tue Dec 15 11:40:39 2020 kern.info kernel: [639860.540780] br-wan3: port 1(usb0) entered blocking state
Tue Dec 15 11:40:39 2020 kern.info kernel: [639860.564159] br-wan3: port 1(usb0) entered disabled state
Tue Dec 15 11:40:39 2020 kern.info kernel: [639860.575937] device usb0 entered promiscuous mode
Tue Dec 15 11:40:40 2020 kern.info kernel: [639860.593964] br-wan3: port 1(usb0) entered blocking state
Tue Dec 15 11:40:40 2020 kern.info kernel: [639860.604797] br-wan3: port 1(usb0) entered forwarding state
Tue Dec 15 11:40:40 2020 kern.info kernel: [639860.617419] IPv6: ADDRCONF(NETDEV_UP): br-wan3: link is not ready
Tue Dec 15 11:40:40 2020 daemon.notice netifd: Interface 'wan3' is enabled
Tue Dec 15 11:40:40 2020 daemon.notice netifd: Network device 'usb0' link is up
Tue Dec 15 11:40:40 2020 daemon.notice netifd: bridge 'br-wan3' link is up
Tue Dec 15 11:40:40 2020 daemon.notice netifd: Interface 'wan3' has link connectivity
Tue Dec 15 11:40:40 2020 daemon.notice netifd: Interface 'wan3' is setting up now
Tue Dec 15 11:40:40 2020 user.notice RNDIS:: 22b8 2e25 usb_device 0/0/0  usb 22b8/2e25/ffff /devices/platform/1e1c0000.xhci/usb1/1-1
Tue Dec 15 11:40:40 2020 daemon.notice netifd: wan3 (27978): udhcpc: started, v1.30.1
Tue Dec 15 11:40:40 2020 daemon.notice netifd: wan3 (27978): udhcpc: sending discover
Tue Dec 15 11:40:40 2020 daemon.notice netifd: wan3 (27978): udhcpc: performing DHCP renew
Tue Dec 15 11:40:40 2020 daemon.notice netifd: wan3 (27978): udhcpc: sending discover
Tue Dec 15 11:40:40 2020 kern.info kernel: [639861.553916] IPv6: ADDRCONF(NETDEV_CHANGE): br-wan3: link becomes ready
Tue Dec 15 11:40:42 2020 daemon.notice netifd: wan3 (27978): udhcpc: sending select for 192.168.42.162
Tue Dec 15 11:40:43 2020 daemon.notice netifd: wan3 (27978): udhcpc: lease of 192.168.42.162 obtained, lease time 3600
Tue Dec 15 11:40:43 2020 daemon.notice netifd: Interface 'wan3_6' is enabled
10

But this solution won't work if there are 2 USB devices which are detected as usb0 and eth1 together.

So, still looking for an elegant solution which let's us identify the ifname as assigned by kernel which can be then dynamically updated on the network file using uci .

11 
cat << "EOF" > /etc/hotplug.d/net/00-logger
logger -t hotplug $(env)
EOF
opkg update
opkg install kmod-dummy
rmmod dummy
modprobe dummy
logread -e hotplug
1 Like
12

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.