Activation Codes and Methods, Hardware Details, Sniffing
Post Reply
bernhard
Posts: 5
Joined: 12 May 2021, 13:16

yet another device with 0bda:1a2b not switching to c811

Post by bernhard » 12 May 2021, 14:14

I bought yet another usb wifi stick, which has 0bda:1a2b and is not switching to c811 with usb_modeswitch (see also: viewtopic.php?f=3&t=2936). It is an Inter-Tech DMG-19 and documentation says that it uses Realtek RTL-8811CU chipset
(see https://www.pollin.de/p/wlan-usb-adapte ... bps-741384 and/or https://www.inter-tech.de/products/netw ... ter/dmg-19). I tried different eject methods, but none of these changed anything under Linux and/or Raspbian Buster. In the latter I also installed the latest data packet without success. It labels 0bda:1a2b as "D-Link DWA-171 Wifi Dongle", but it uses apparently a different method to achieve the modeswitch.

The logfile with EnableLogging=1 is attached.

I am tempted to use the 33 days evaluation period for http://www.usblyzer.com/ to monitor the hot-plug communication under MS Windows, but I do not really know if I can find a solution for the problem. Does anybody have some recommendations or objections?

Additional question: Is it possible to add a second method to the 0bda:1a2b file. Paging through the different files I see only one per file.

thanks in advance for any help
Attachments
usb_modeswitch_1-1_2.txt
Log file with EnableLogging=1
(3.52 KiB) Downloaded 131 times

LOM
Posts: 1403
Joined: 11 Jul 2012, 15:14
Location: Koh Samui, TH

Re: yet another device with 0bda:1a2b not switching to c811

Post by LOM » 12 May 2021, 18:03

We can have another obda:1a2b based on the Manufacturer string which is Realtek in your dongle and is D-Link Corporation in the D-Link version, as reference see all the config files for 05c6:1000.
First you have to find out though how to switch it, I don't have any experience with Realtek devices so I have no idea on possible switch messages.
You could try to eject the virtual cd-rom on the cmd line:
sudo eject /dev/sr0 but that should be the same as sending the StandardEject switch message.

You can log the USB communication in MS Win with Wireshark + USBPcap, they are free.

bernhard
Posts: 5
Joined: 12 May 2021, 13:16

Re: yet another device with 0bda:1a2b not switching to c811

Post by bernhard » 14 May 2021, 10:52

hmm, I tried to use sudo eject on the command line already without success, see above.

I logged the communication with USBlyzer, but I have some problems in interpreting the results. Digging through the packets, my impression is that the driver does try to eject the disc with a start/stop unit command containing the following bulk data:
55 53 42 43 B0 B2 CE A2 00 00 00 00 00 00 06 1B 00 00 00 02 00 00 00 00 00 00 00 00 00 00 00
followed by a test unit ready command containing the following bulk data:
55 53 42 43 20 38 AA A5 00 00 00 00 00 00 06 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
but I am a little bit lost/overwhelmed by the information provided.

now I don't know how to use that info for additional testing.

LOM
Posts: 1403
Joined: 11 Jul 2012, 15:14
Location: Koh Samui, TH

Re: yet another device with 0bda:1a2b not switching to c811

Post by LOM » 14 May 2021, 11:41

Yes the stop/start cmd is the eject media cmd, it is usually preceded by the 06 1e cmd which is the prevent/allow media removal cmd.
usb_modeswitch StandardEject is 4 cmds, allow media removal + stop unit for SCSI LUN0 and the same sequence for SCSI LUN1, this because some dongles have 2 USB Storage devices, one is a TF/SD card and one is the virtual cd-rom which can be either on LUN0 or LUN1.

If you have filtered the capture to only log communication with this USB storage device (virtual cd-rom) then there will be no more entries in the capture when this device disappears due to it being switched, so the switch command should be one of the last cmds you see near the end of your capture. The test unit ready cmd may then be used as a check that the device has disappeared.
Please confirm that the capture stops after that.

Did you try to eject the cd-rom device from linux cmdline?

bernhard
Posts: 5
Joined: 12 May 2021, 13:16

Re: yet another device with 0bda:1a2b not switching to c811

Post by bernhard » 14 May 2021, 13:07

LOM wrote: 14 May 2021, 11:41 Did you try to eject the cd-rom device from linux cmdline?
yes I tried that several times without sucess.

After having switched successfully under windows, I ejected and unplugged the stick and moved it to the raspi, and now lsusb list it as c811. I have no idea how long it must be offline to switch back/and or if it now was successfully switched by usb_modeswitch and the udev rules. I am completely puzzled.

bernhard
Posts: 5
Joined: 12 May 2021, 13:16

Re: yet another device with 0bda:1a2b not switching to c811

Post by bernhard » 04 Jan 2022, 00:48

finally I found time to revisit this problem and alas under a recent version of EndlessOS (Debian bullseye based) I see the following in dmesg output:

Code: Select all

[ +43.654396] usb 1-3: new high-speed USB device number 6 using xhci_hcd
[  +0.148128] usb 1-3: New USB device found, idVendor=0bda, idProduct=1a2b, bcdDevice= 2.00
[  +0.000011] usb 1-3: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[  +0.000003] usb 1-3: Product: DISK
[  +0.000003] usb 1-3: Manufacturer: Realtek
[  +0.084937] usb-storage 1-3:1.0: USB Mass Storage device detected
[  +0.001620] scsi host2: usb-storage 1-3:1.0
[  +0.000160] usbcore: registered new interface driver usb-storage
[  +0.008446] usbcore: registered new interface driver uas
[Jan 3 12:08] usb 1-3: USB disconnect, device number 6
[  +0.379173] usb 1-3: new high-speed USB device number 7 using xhci_hcd
[  +0.148208] usb 1-3: New USB device found, idVendor=0bda, idProduct=c811, bcdDevice= 2.00
[  +0.000010] usb 1-3: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[  +0.000003] usb 1-3: Product: 802.11ac NIC
[  +0.000003] usb 1-3: Manufacturer: Realtek
[  +0.000002] usb 1-3: SerialNumber: 123456
[Jan 3 12:23] usb 1-3: USB disconnect, device number 7
which implies to me that usb_modeswitch works here as expected. Going back to Debian buster on another laptop (eeePC under Q4OS 3.15.2-n1) the dongle shows up as 0bda:1a2b, but doing

Code: Select all

sudo usb_modeswitch -v 0bda -p 1a2b -P c811 -K
worked like expected, i.e. switched the device to c822.

On the Raspbrry Pi, for which I had intended it, the stick was listed as 0bda:1a2b, so I copied /usr/share/usb_modeswitch/0bda:1a2b to /etc/usb_modeswitch.d/0bda:1a2b and modified its content to

Code: Select all

# InterTech DMG-19 Wifi Dongle
TargetVendor=0xbda
TargetProduct=0xc811
StandardEject=1
and after reboot the stick is recognized as 0bda:0xc811. So everything looks good.

buhtz
Posts: 4
Joined: 28 Nov 2021, 16:38

Re: yet another device with 0bda:1a2b not switching to c811

Post by buhtz » 04 Jan 2022, 11:30

Thanks a lot for keeping track on that problem.
But sorry, this was a bit to fast for me. Can you break it down a bit for me please.

So the problem is solved?

But what was the problem?

bernhard
Posts: 5
Joined: 12 May 2021, 13:16

Re: yet another device with 0bda:1a2b not switching to c811

Post by bernhard » 04 Jan 2022, 18:57

buhtz wrote: 04 Jan 2022, 11:30 So the problem is solved?
yes, I think so.
buhtz wrote: 04 Jan 2022, 11:30 But what was the problem?
no Linux did switch from 0bda:1a2b to 0bda:c811 when I first tried to use it in May 2020.

I had tried to trace the USB communication under MS Windows without success and had the stick sitting around on my shelf since then because I dared to fire up wireshark & co on windows ...

Now, I retried it yesterday with the plan to have MS Windows in a Gnu Box https://wiki.gnome.org/Apps/Boxes and wireshark directly under EndlessOS. To my own surprise, EndlessOS switched the device automagically, but since I know that EndlessOS recently made a big step to being based on Debian 11 (bullseye). So I moved the stick over to a Debian 10 (buster) based and this time I was able to use usb_modeswitch on the command line without fuzz to switch it from emulated cdrom to NIC. And I was able to configure usb_modeswitch on the Raspberry Pi to switch it there too.

I don't have any idea if usb_modeswitch has had updates or what else may be the cause of the different behavior, but I wanted to keep the forum informed about the success.

Post Reply