Anyone using WiFi Module 5B – ODROID on their N2+? It is working well?
Please use forum search function:
2 Likes
I did, I guess I didn’t do a good job with the search though. Thanks!
Edit: So I just received my Odroid N2+ with the 5B adapter and I can’t seem to get it working, I can’t see any wireless settings in CE.
I’m running the latest nightly from 20211005 and I did a clean install.
Do I need to do something to get it working?
Here’s a log.
Did you use usb_modeswitch program to put device from usb storage mode to wifi adapter mode?
Not sure what that means, so no 
How do I do that?
Edit: Never mind, I solved it, it’s working now.
Added the autostart.sh script above and installed system tools.
What @vpeter mean is your answer is found by using the search function:
Your log shows:
New USB device found, idVendor=0bda, idProduct=1a2b
Hello, I have simillar issue with wifi ( dont care about bluetooth) and fix it by autostart.sh.
But, I use coreelec 19.3, so my first question is why this improvement wasnt added to this release?
And second issue, which I have, is, that when I shutdown tv and power on it back, after that there is again no wifi. After restart everyrhing is ok, but it is very unpleasant behaviour, restart take few minutes:(
Thanks for the answer
1 Like
Hi,
Also using CE 19.3 with an ODROID USB wifi module 5B (RTL8821CU).
WIFI and bluetooth are fine after using usb_modeswitch in autostart.sh, however, it still has two issues:
- longer boot (90-120 seconds), compared to <30 seconds when module is unplugged.
- suspend/resume breaks the wifi (tried to play with sleep.d script to raise the dongle, but without much success).
Is it technically possible to have this dongle natively supported (without requiring usb_modeswitch) ?
If yes, how likely it will happen, and any tip how I could help/contribute ?
Thanks.
I doubt that because it just works as storage device by default. And needs to be put in wifi mode with usb_modeswitch.
Why the operation takes so long is beyond my knowledge (I never tested such stick). I just guess it should proceed much faster.
It seems the “Looking for active drivers” step is the one consuming all the wait, and it is not consistent between multiple attempts.
Not sure if I can manage to skip it somehow…
Access device 003 on bus 001
Get the current device configuration ...
Current configuration number is 1
Use interface number 0
with class 8
Use endpoints 0x0b (out) and 0x8a (in)
USB description data (for identification)
-------------------------
Manufacturer: Realtek
Product: DISK
Serial No.: not provided
-------------------------
Sending standard EJECT sequence
Looking for active drivers ... <======= This step can wait up to 60 seconds
OK, driver detached
Set up interface 0
Use endpoint 0x0b for message sending ...
Trying to send message 1 to endpoint 0x0b ...
Sending the message returned error -7. Try to continue
Read the response to message 1 (CSW) ...
Response successfully read (13 bytes), status 0
Trying to send message 2 to endpoint 0x0b ...
OK, message successfully sent
Read the response to message 2 (CSW) ...
Response successfully read (13 bytes), status 1
Trying to send message 3 to endpoint 0x0b ...
OK, message successfully sent
Read the response to message 3 (CSW) ...
Response successfully read (13 bytes), status 0
Trying to send message 4 to endpoint 0x0b ...
Sending the message returned error -1. Try to continue
Read the response to message 4 (CSW) ...
Response reading failed (error -1)
Device is gone, skip any further commands
-> Run lsusb to note any changes. Bye!
Can you do me one test if possible? But you would need cable connection.
Boot with ethernet cable and without wifi adapter. Run command
lsmod | paste
Then attach adapter and do command
lsusb -vv | paste
lsmod | paste
dmesg | paste
then run usb_modeswitch command to put adapter in wifi mode. And again run
lsusb -vv | paste
lsmod | paste
dmesg | paste
And post all the links you get.
1/ without adapter
lsmod
2/ attached adapter
lsusb -vv
lsmod
dmesg
3/ after usb_modeswitch
lsusb -vv
lsmod
dmesg
This seems to work:
CoreELEC:~/.config/udev.rules.d # cat 90-rtl8188gu_cdrom_mode.rules
SUBSYSTEM==“usb”, ACTION==“add”, ATTR{idVendor}==“0bda”, ATTR{idProduct}==“1a2b”, RUN+=“/storage/.kodi/addons/virtual.system-tools/bin/usb_modeswitch -KW -v 0bda -p 1a2b”
for some reason if the modeswitch is run asap when plugged, it seems to be faster.
1 Like
This is almost immediate:
[ 224.476519@2] usb 1-1.4: new high-speed USB device number 7 using xhci-hcd
[ 224.600748@2] usb 1-1.4: New USB device found, idVendor=0bda, idProduct=1a2b
[ 224.600750@2] usb 1-1.4: New USB device strings: Mfr=1, Product=2, SerialNumber=0
[ 224.600751@2] usb 1-1.4: Product: DISK
[ 224.600753@2] usb 1-1.4: Manufacturer: Realtek
[ 224.601087@2] usb-storage 1-1.4:1.0: USB Mass Storage device detected
[ 224.604119@2] scsi host0: usb-storage 1-1.4:1.0
[ 224.742477@2] usb 1-1.4: USB disconnect, device number 7
[ 224.988542@2] usb 1-1.4: new high-speed USB device number 8 using xhci-hcd
[ 225.112837@2] usb 1-1.4: New USB device found, idVendor=0bda, idProduct=c820
[ 225.112842@2] usb 1-1.4: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 225.112844@2] usb 1-1.4: Product: 802.11ac NIC
[ 225.112845@2] usb 1-1.4: Manufacturer: Realtek
[ 225.112847@2] usb 1-1.4: SerialNumber: 123456
[ 225.227001@0] Bluetooth: hci0: rtl: examining hci_ver=08 hci_rev=000c lmp_ver=08 lmp_subver=8821
[ 225.227008@0] Bluetooth: hci0: rtl: loading rtl_bt/rtl8821c_config.bin
[ 225.227142@0] Bluetooth: hci0: rtl: loading rtl_bt/rtl8821c_fw.bin
[ 225.227982@0] Bluetooth: hci0: rom_version status=0 version=1
[ 225.228037@0] Bluetooth: cfg_sz 10, total size 31990
[ 226.129091@1] start_addr=(0x8000), end_addr=(0x10000), buffer_size=(0x8000), smp_number_max=(4096)
[ 226.156351@0] IPv6: ADDRCONF(NETDEV_UP): wlan0: link is not ready
[ 226.156379@0] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
Problem solved then? The solution is to run usb_modeswitch from udev rule?
YES Thanks for the help.
Might worth the addition in the standard configuration for other users…
1 Like
Can you please try this rule?
# SPDX-License-Identifier: GPL-2.0-or-later
# Copyright (C) 2018-present Team CoreELEC (https://coreelec.org)
# put wifi module from storage to wifi mode
SUBSYSTEM=="usb", ACTION=="add", ATTR{idVendor}=="0bda", ATTR{idProduct}=="1a2b", \
RUN+="/bin/sh -c 'export usb_modeswitch=/storage/.kodi/addons/virtual.system-tools/bin/usb_modeswitch; [ -x ${usb_modeswitch} ] && ${usb_modeswitch} -KW -v ${ID_VENDOR_ID} -p ${ID_MODEL_ID} || echo usb_modeswitch: please install system-tools addon >/dev/kmsg'"
If will work then this rule will be added to the image itself. And user just need to install system-tools addon without adding extra rule.
Yes it works fine (although I only tested it with the system tools addon installed).
tbh, I still don’t understand why udev behaves differently from autostart.sh, when comparing dmesg logs, the only different trace displayed is “usb 1-1.4: reset high-speed USB device number 3 using xhci-hcd” (when it is stuck).
I suspect something is locking/attempting to mount the cdrom and delays usb_modeswitch (and that would explain why the delay is random).
With udev, the modeswitch happens immediatly and this shaddy “reset high-speed” thing has no opportunity to trigger before.
Thank you.
Maybe there is some difference when the storage is mounted it must be unmounted first before it can be switched to wifi mode.
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.