Hikey 960 4G dongle support

Hi Loic, I’ve pushed the arm64 to the Hikey: adb push usb-modeswitch /data/local (for example) but when I try to run ./usb_modeswitch… it says permission denied. I’ve also tried with “su” and it shows the same message. The developer options are enabled but I can not manage to run it…

I dont know how to build the project with “mm” either…

All the process of usb_modeswitch is known to me because I’ve done it in a Intel Edison board… but as I can not run it in my Hilink… I can not resolve the problem…

Ty!

Could you retry with sepolicy disabled (setenforce permissive) ? I’ve personally tried from root console (via UART).
Any issue reported in dmesg when executing the command ? could you try to move binary to system partition ?

“adb push” does not bring execute permissions through when it writes the file unless you are overwriting a file that already has the permission. After you push the file, make sure you run “chmod 755” on the file, then it should execute.

I think that anywhere in the /data tree should be executable as far as selinux is concerned.

Now with chmod done, I can execute it but with -J says “invalid option -J”, in Internet says that with -H will change it automatically and -J is to change manually. (Maybe is because my usb_modeswitch version is older but I don’t know how to update it since there is not any apt-get or something like that).

If I try with “su 0 ./data/local/usb_modeswitch -H -v 0x12d1 -p 0x1f01” it executes but doesn’t finish well:

hikey960:/ $ su 0 ./data/local/usb_modeswitch -H -v 0x12d1 -p 0x1f01
Look for default devices …
Segmentation fault

Also, if I type lsusb, it does not show anything.

Any ideas?

My Bad, I forgot to update the binary on git repository, this should be fixed now. You can check usb_modeswitch version with -e option (version should be 2.5.2).

Note that concurrent USB device/host mode is not supported by Hikey960, so if you are running adb over USB you will not be able to use USB devices…

Okk I know the version of usb_modeswith is older but as I said I don’t know how to update it in the Hikey.

I didn’t know I can not use USB devices if running over USB… I’ll try another way then…

You can script this. But I would suggest you to make it work manually at least one time, you can use eserial/uart console or adb over ip:

I updated the binary version on git (https://github.com/loicpoulain/armbin/blob/master/android/aarch64/usb_modeswitch) you can download it and push it.

Okk finally I got it accesin with adb IP instead of ssh.

IF I run with -J (with the version of my dongle vx12d1 px14c3) it doesn’t create the eth0 connection, first it returns:

hikey960:/data/local # ./usb_modeswitch -J -v 0x12d1 -p 0x14c3
Look for default devices …
Found devices in default mode (1)
Access device 007 on bus 001
Get the current device configuration …
Current configuration number is 1
Use interface number 0
with class 8
Use endpoints 0x01 (out) and 0x81 (in)
Using standard Huawei switching message
Looking for active drivers …
OK, driver detached
OK, driver detached
Set up interface 0
Use endpoint 0x01 for message sending …
Trying to send message 1 to endpoint 0x01 …
OK, message successfully sent
Read the response to message 1 (CSW) …
Response reading failed (error -9)
Device is gone, skip any further commands
→ Run lsusb to note any changes. Bye!

And this is what dmesg shows dmesg

And lsusb returns

e[0mhikey960:/data/local # lsusb
Bus 001 Device 004: ID 0424:2740
Bus 001 Device 001: ID 1d6b:0002
Bus 001 Device 008: ID 12d1:14c8
Bus 001 Device 002: ID 0424:2734
Bus 002 Device 001: ID 1d6b:0003
Bus 001 Device 003: ID 046d:c05a

So maybe I have to change the command of usb_modeswitch?

From your log usb switch has been working correclty. However your device seems to have switched into legacy mode since I can see CDC ACM is enumerated (with ttyUSBx created). That means your device (probably a Huaweu E398 from USB ids) does not support Hilink mode, your device operates with ‘legacy’ stick mode. The ttyUSB1 needs to be used to send AT command and create network context, which is more complicated…

There are some existing resources for this:
https://www.thefanclub.co.za/how-to/how-setup-usb-3g-modem-raspberry-pi-using-usbmodeswitch-and-wvdial
https://forum.odroid.com/viewtopic.php?f=113&t=16489

Hi guys ,

first of all thank you Loic for your solution it really helped me. but every time I use my dongle 4g I need to do the same steps so if you have a solution that every time my hikey960 detect that i’m using a dongle 4g than will execute your command

./usb_modeswitch -J -v 0x12d1 -p 0x1f01

please share it
thanks for help :slight_smile:

The solution on Linux is simple because you can add udev rules and simply execute usb_modeswitch. AFAIK there is no such solution with Android. Android has a ueventd daemon but it seems very limited to basic actions like creating symlink or changing access rights…

I found and updated one of my old tools to execute commands on USB device detection (which is today pretty useless on Linux) but it could be interesting to test it on Android. I’ve just pushed it to https://github.com/loicpoulain/usb-trigger. feel free to try… you will have to run this program at device boot, this requets a new service in init.rc. I assume you will also have to deal with sepolicy. If I have some time I’ll test it on my side as well.

(usb-trigger android aarch64 binary https://github.com/loicpoulain/armbin/blob/master/android/aarch64/usb-trigger)

hey loic,
thank you for replying . i will give it a try and i hope it work.

There is a better/easier way.
Android’s init has this capability.

on <trigger>
    do something

A couple of pertinent triggers are these;
device-added-<path>
device-removed-<path>

So you might use a trigger like this;

on device-added-/dev/ttyUSB2
    exec <blah blah blah>

This looks a good way indeed, but AFAIK, even if these triggers are described in some README, they actually have never been implemented…

Intel was using it in 2014… https://github.com/01org/android-bluez-device-intel-mixins/blob/master/sensors/hid_sensorhub_bytm/init.rc

hey everyone,

sory to be late , right now I am working on 3 project in the same time dongle 4g , websocket and Lendspiker.
sorry @Loic I found that doitright’ solution is much easier so I spended all my time to make it work .
@doitright : sorry to bother you but i need some information that i didn’t find it on google .
in fact, there is two file init.rc :
_1/ …/…/bootable/recovery/etc/init.rc _
2/ …/…/system/core/rootdir
ther is also :
…/…/device/linaro/hikey/init.common.rc
…/…/device/linaro/hikey/init.common.usb.rc

I add for all those file :

on device-added-/dev/usb_accessory
usb_modeswitch -J -v 0x12d1 -p 0x1f01

but it didn’t work i even changed usb_accessory many times but nothing change :
those are all the information that i had when i connect my dongle

[ 1484.193980] logd: logdr: UID=2000 GID=2000 PID=8657 b tail=0 logMask=19 pid=0 start=0ns timeout=0ns
[ 1485.742106] usb 1-1.2: USB disconnect, device number 11
[ 1500.304727] usb 1-1.2: new high-speed USB device number 12 using xhci-hcd
[ 1500.414427] usb 1-1.2: New USB device found, idVendor=12d1, idProduct=1f01
[ 1500.422739] usb 1-1.2: New USB device strings: Mfr=1, Product=2, SerialNumber=3
[ 1500.431729] usb 1-1.2: Product: HUAWEI_MOBILE
[ 1500.436635] usb 1-1.2: Manufacturer: HUAWEI_MOBILE
[ 1500.442153] usb 1-1.2: SerialNumber: 0123456789ABCDEF
[ 1500.482915] usb-storage 1-1.2:1.0: USB Mass Storage device detected
[ 1500.494555] scsi host1: usb-storage 1-1.2:1.0
[ 1501.530641] scsi 1:0:0:0: CD-ROM            HUAWEI   Mass Storage     2.31 PQ: 0 ANSI: 2
[ 1501.549945] scsi 1:0:0:1: Direct-Access     HUAWEI   TF CARD Storage  2.31 PQ: 0 ANSI: 2
[ 1501.580109] sd 1:0:0:1: [sde] Attached SCSI removable disk

and this is the result of “ls /dev” :

gpiochip26 ptyp6 tty3 ttyAMA3
ashmem gpiochip27 ptyp7 tty30 ttyFIQ0
autofs gpiochip28 ptyp8 tty31 ttyS0
binder gpiochip3 ptyp9 tty32 ttyS1
block gpiochip4 ptypa tty33 ttyS2
bus gpiochip5 ptypb tty34 ttyS3
cg2_bpf gpiochip6 ptypc tty35 ttyp0
console gpiochip7 ptypd tty36 ttyp1
cpu_dma_latency gpiochip8 ptype tty37 ttyp2
cpuctl gpiochip9 ptypf tty38 ttyp3
cpuset graphics random tty39 ttyp4
cuse hidraw0 rfkill tty4 ttyp5
device-mapper hidraw1 rtc0 tty40 ttyp6
dri hidraw2 rtc1 tty41 ttyp7
ec033000.etr hifi_misc snd tty42 ttyp8
ec036000.etf hwbinder socket tty43 ttyp9
ec802000.etf i2c-0 stune tty44 ttypa
ed002000.etf i2c-1 tty tty45 ttypb
fd i2c-2 tty0 tty46 ttypc
fscklogs input tty1 tty47 ttypd
full ion tty10 tty48 ttype
fuse kmsg tty11 tty49 ttypf
gpiochip0 kmsg_debug tty12 tty5 tun
gpiochip1 loop-control tty13 tty50 uhid
gpiochip10 mali0 tty14 tty51 uinput
gpiochip11 memcg tty15 tty52 urandom
gpiochip12 memory_bandwidth tty16 tty53 usb-ffs
gpiochip13 network_latency tty17 tty54 usb_accessory
gpiochip14 network_throughput tty18 tty55 vcs
gpiochip15 null tty19 tty56 vcs1
gpiochip16 port tty2 tty57 vcsa
gpiochip17 ppp tty20 tty58 vcsa1
gpiochip18 psaux tty21 tty59 vga_arbiter
gpiochip19 ptmx tty22 tty6 vndbinder
gpiochip2 pts tty23 tty60 watchdog
gpiochip20 ptyp0 tty24 tty61 watchdog0
gpiochip21 ptyp1 tty25 tty62 watchdog1
gpiochip22 ptyp2 tty26 tty63 xt_qtaguid
gpiochip23 ptyp3 tty27 tty7 zero
gpiochip24 ptyp4 tty28 tty8
gpiochip25 ptyp5 tty29 tty9

when i remove it :

[ 1593.518561] usb 1-1.2: USB disconnect, device number 12

soo help please :smile:

@REKIK: @loic could very well be right and there may not be any actual code in AOSP to support that function. Just because Intel was using it doesn’t mean that it is part of AOSP (it may only exist in some Intel fork of AOSP’s init), or just because it was part of AOSP at one point (in this case, 2014), does not mean that it is still. It could very easily have been removed or lost.

HOWEVER, on first glance, your addition won’t work for a different reason, because “usb_modeswitch” is NOT an init command. You’ll need to use something like “exec – usb_modeswitch …”

If it doesn’t work, then another approach that may work similarly, is to use a property trigger. Property triggers definitely work. Android userspace can monitor for usb insertions. You just need to register a broadcast receiver for ACTION_USB_DEVICE_ATTACHED, check if its the device you’re looking for, and then set a property. The init property trigger will see the property being set, and run your command.

thank you @doitright for your response

check if its the device you’re looking for

how i could do it when the only information i have about my dongle is : idVendor=12d1, idProduct=1f01

I couldn’t find any thing about the dongle in /dev

This should help for working on the Android side of things;

And for the Linux side, you could read my lights HAL, which manipulates a display’s backlight (USB) using raw hid;

This may also provide valuable ideas;
http://processors.wiki.ti.com/index.php/Android-USB-3G-Modem-Integration#Add_USB_Mode_switch_as_a_Service