1

Preamble: It seems that this question is being poorly received by some users and I'm not sure why. If you believe this question merits a downvote, please also consider posting a comment explaining why so that I know how to fix it. I need a solution to my problem and am more than willing to edit my question if need be.

I'm trying to use a TP-Link UE200 USB-to-Ethernet Adapter with Debian Buster (the latest stable release at the time of this writting). Under normal operation, this adapter presents itself as a USB CD-ROM drive when first plugged in and relies on its driver to switch it to Ethernet mode.

The adapter works fine when I plug it into my system when it's already running: linux detects the adaptor properly and automatically switches the device to the correct mode. However my system fails to automatically switch the correct mode when the adapter is plugged in during system boot-up.

Furthermore, when in its CD-ROM state, I'm unable to find a way to force the device to present itself as an Ethernet adapter without mechanically unplugging and replugging the device. This system is meant to run and reboot without human intervention, so having to manually intervene each time is undesirable.

My question is as follows: How can I get my adapter - that was plugged in when the system booted up - to present itself as an Ethernet adapter without having to physically unplug it?

Side notes:

  • I would like to add that I have a similar setup running on a raspberry pi 4 + Ubuntu 19.10. The Ethernet adapter gets correctly recognized even when the system boots up with it plugged in. I've only experienced this issue on Debian Buster/x86_64 so far.

  • As far as USB is concerned, the adapter behaves as two separate USB devices. Each of the device's two modes has its own USB Product ID (namely 0601 when operating as a CD-ROM drive and 0602 when operating as an Ethernet adapter).

  • Things I've tried so far:

    1. Unbinding and rebinding the device via /sys/bus/usb/drivers/usb/{unbind,bind}: the adapter just presents itself as 0601 again, and the kernel registers it as a CD-ROM device again. I think the device needs to be powered off completely before it will reinitialize itself properly.

    2. Manually unbinding the usb-storage driver from the device and binding the cdc_ether driver via /sys/bus/usb/drivers/usb-storage/unbind and /sys/bus/usb/drivers/cdc_ether/bind (after loading the module manually): Unsuprisingly this doesn't work since the device presents itself to the kernel as a usb mass-storage device.

    3. Using usb_modeswitch to manually force the device to present itself as 0602: The device simply ignores the messages or refuses to work. Ejecting the device -K and resetting it -R don't seem to have any effect.

    4. Disconnecting the device via /sys/bus/usb/devices/XXX/remove: Works perfectly, but no way to get linux to "unremove" the device without physically reinserting the device Upon further investigation, it probably doesn't since linux doesn't cut power to the device.

    5. Including the cdc_ether module in my initramfs, and preloading the module via the kernel command line parameter modules_load in a vain hope that this issue is caused by lack kernel modules during early boot: Linux still used usb-storage regardless.

Improve this question
0

2 Answers 2

Reset to default
2

Install usb-modeswitch:

sudo apt install usb-modeswitch

Get device id with lsusb. Example:

Bus 001 Device 004: ID 2357:0601 TP-Link UE300 10/100/1000 LAN (ethernet mode) [Realtek RTL8153]

Run command:

/usr/sbin/usb_modeswitch -v 2357 -p 0600 -R

And it is fixed. I created service that execute this on boot.

This also applies to TP-Link UE300

Improve this answer
1
  • While I did try using usb_modeswitch, I expect this to be correct answer. I'll gladly accept it once I have the faulty TP-link device in my hands again to confirm. That you for posting this answer.
    – Tenders McChiken
    Commented Feb 6, 2022 at 15:34
1

[Sorry for writing an answer for what would not be worth more than a comment. If some mod' could transpose, I'd be grateful.]

Could it be possible that your BIOS holds your adapter as a bootable USB device and locks the handling of the associated interrupt and io ports so that It cannot be reappropriated by the kernel ? If it's the case, simply force usb devices out of the list of bootable devices and make sure BIOS is configured for a PnP system.

Improve this answer
3
  • Thank you for trying to help. The system I'm using is indeed a BIOS-based system. I've removed all usb devices from the list of bootable devices. The BIOS doesn't seem to have configuration options for PnP, but the closest I've found was a USB controller option to prevent the BIOS from recognizing USB storage devices which I also disabled. Neither seem to have helped.
    – Tenders McChiken
    Commented Aug 4, 2020 at 3:49
  • Also, I would like to learn more about the relationship between kernel/BIOS and bootable USB devices. Do you have any specific link you would recommend?
    – Tenders McChiken
    Commented Aug 4, 2020 at 4:07
  • "Could it be possible etc.?" - how does one check whether that is the case? i.e. whether there's interrupt-handler-locking?
    – einpoklum
    Commented Jul 26 at 18:54

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .