USB Wifi Hotspot

[bousqi]

Hi Mwyann,

I'm reaching you as I found your work on PSAKEY.
Have you ever tried to make a simple Wifi Hotspot with your CDC_EEM Usb Key (based on a RPI Zero) ?
Such hotspot would allow to easily connect a computer to SMEG+ telnet shell.

I'm currently playing a little bit with my SMEG+ unit in my car, trying to understand how it works.
You can find my actual work in my SMEG_PLUS repo.
My work is based on a Bluetooth link and replacing it by a wifi link would be better. I won't have to sit in the car to test few things.

I'm even thinking of a RPI Zero W that would feed last ZAR over wifi and replace EEM Gadget by a Mass Storage Gadget to automatically install it when available.

[Mwyann]

Hi,

I did try to hack the unit myself via telnet. My RPi0W is designed to connect to my phone's hotspot automatically, and then I simply SSH into it and then telnet into the car.

Here is some network analysis:

Starting Nmap 7.40 ( https://nmap.org ) at 2017-12-29 12:47 CET
Nmap scan report for 192.168.0.1
Host is up (0.00092s latency).
Not shown: 996 closed ports
PORT STATE SERVICE
23/tcp open telnet
111/tcp open rpcbind
3333/tcp open dec-notes
20000/tcp open dnp
MAC Address: 12:34:00:00:00:F2 (Unknown)

Port 3333 is GPS data.

Telnet commands (help command):

help Print this list
dbgHelp Print debugger help info
edrHelp Print ED&R help info
ioHelp Print I/O utilities help info
nfsHelp Print nfs help info
netHelp Print network help info
rtpHelp Print process help info
spyHelp Print task histogrammer help info
timexHelp Print execution timer help info
h [n] Print (or set) shell history
i [task] Summary of tasks' TCBs
ti task Complete info on TCB for task
sp adr,args... Spawn a task, pri=100, opt=0x19, stk=20000
taskSpawn name,pri,opt,stk,adr,args... Spawn a task
tip "dev=device1#tag=tagStr1", "dev=device2#tag=tagStr2", ...
Connect to one or multiple serial lines
td task Delete a task
ts task Suspend a task
tr task Resume a task
tw task Print pending task detailed info
w [task] Print pending task info
d [adr[,nunits[,width]]] Display memory
m adr[,width] Modify memory
mRegs [reg[,task]] Modify a task's registers interactively
pc [task] Return task's program counter
iam "user"[,"passwd"] Set user name and passwd
whoami Print user name
devs List devices
ld [syms[,noAbort][,"name"]] Load stdin, or file, into memory
(syms = add symbols to table:
-1 = none, 0 = globals, 1 = all)
lkup ["substr"] List symbols in system symbol table
lkAddr address List symbol table entries near address
checkStack [task] List task stack sizes and usage
printErrno value Print the name of a status value
period secs,adr,args... Spawn task to call function periodically
repeat n,adr,args... Spawn task to call function n times (0=forever)
version Print VxWorks version info, and boot line
shConfig ["config"] Display or set shell configuration variables
strFree [address] Free strings allocated within the shell (-1=all)

NOTE: Arguments specifying 'task' can be either task ID or name.

Testing some commands:

-> whoami

value = 1 = 0x1

-> version
VxWorks (for Freescale MPC5121E ADS (Rev 0.1)) version 6.7.
Kernel: WIND version 2.12.
Made on May 26 2017, 13:23:36.
Boot line:
usb(0,0)host:vxWorks h=192.168.10.2 e=192.168.10.1 u=5121 pw=5121 f=0x0 tn=DB600
value = 92 = 0x5c = ''

-> ioHelp

cd "path" Set current working path
pwd Print working path
ls ["wpat"[,long]] List contents of directory
ll ["wpat"] List contents of directory - long format
lsr ["wpat"[,long]] Recursive list of directory contents
llr ["wpat"] Recursive detailed list of directory
rename "old","new" Change name of file
copy ["in"][,"out"] Copy in file to out file (0 = std in/out)
cp "wpat","dst" Copy many files to another dir
xcopy "wpat","dst" Recursively copy files
mv "wpat","dst" Move files into another directory
xdelete "wpat" Delete a file, wildcard list or tree
attrib "path","attr" Modify file attributes
xattrib "wpat","attr" Recursively modify file attributes
chkdsk "device", L, V Consistency check DOS file system
dosfsDiskFormat "device" DOSFS file system format.
hrfsDiskFormat "device", N HRFS file system format.
commit "device" Commit current transaction

"attr" contains one or more of: " + - A H S R" characters
"wpat" may be name of a file, directory or wildcard pattern
in which case "dst" must be a directory name
chkdsk() params: L=0, check only, L=2, check and fix, V=0x200 verbose
hrfsDiskFormat() params: N number of files for file system, N=0 maximum
number of files

-> pwd
/SYSTEM_TMP_DATA

BTW there's a NFS transfert method provided by this telnet thing (see nfsHelp), and I tried to transfer firmware files using this method, but all I got was the equivalent content of the update USB stick, so no use :)

Thanks for letting me know about your repo, looks like interesting stuff!

Yann

[bousqi]

Interesting.
On my side I'm making a readable disassembly of vxWorks.
There are far more commands than the ones listed in help. Once my vxWorks analysis will be complete, I'll publish a complete list.

Regarding NFS mount, I guess you mounted RPI remote storage from vxWorks ?
Have you tried the opposite ?

I also used nmap to check open ports, but I stayed in a low range.
Do you have any idea about 20000 port usage ? with a netstat command (ipnet_cmd_netstat) on SMEG+ I'have seen that 20000 port range seems to be used but locally.

Last but not least, can you provide more details on the RPI0W config ?
Have you been using a specific configuration for CDC_EEM to be recognized by SMEG+ ?
Any filtering on VID/PID ? I have a long list of USB EEM device names in vxWorks, so I guess it can't be a random one.

[Mwyann]

Great, looking forward that new list :)

About NFS, that's right, I connected vxWorks into the RPI, did not try the opposite (I'm not even sure it's possible).

I don't know what port 20000 is for.

The RPI0W USB gadget config is located in the myusbgadget file here: https://github.com/Mwyann/psakey/blob/master/resources/myusbgadget
Those are taken from the PSA Key, maybe somoe other VID/PID will be recognized and maybe they may expose additionnal services, why not (like if some debugging tools could be plugged into the USB port).

Yann

[bousqi]

Thanks for point out these details.
I'll try this when my RPI0W will be recevied !

By any chance, do you have some spare memories (or a log) of commands to mount an NFS from vxWorks to RPI ?
That could be interesting to write it down. Some people might find a usage for that.

[bousqi]

I recieved my ZeroW and i'm following your guide to setup the key.
I understand that usb_f_eem is the only module not prebuilt in raspbian ? So we need to build it ourselves.
Have you tried to rely on other USB gadget like RNDIS/NCM/ECM (rather than EEM) ?

I just had a look to vxWorks disassembly and I can only find references of EEM support.

One question, can you argue on the need to set the filesystem in RO ? a comment indicates that the Rpi might reboot without notice. Why ?

[Mwyann]

I don't have a log for how to mount NFS from vmWorks, I just remember that I've set up an NFS server on the RPi, and then mounted it on vxWorks using the appropriate commands. When that was done, I used the cp command to copy all the available files I could into the NFS server. And when I had a look at what I gathered, I could only find files that came from the update USB stick, so that was pointless after all ;)

And yes, I tried the other USB networking gadgets and none of them worked, that's why I had to build EEM myself.

About the RO filesystem: I found that the car shuts the 5V supply on the USB socket 1m30s after the engine is stopped, but there's no notice of this happening (I tried tcpdumping to see if the car sends any sort of message to the key to initiate a proper shutdown, but I couldn't see any). Also, during my debugging sessions I may have the need to pull the RPi quickly without having to SSH into it to power it off properly. So to avoid any corruption on the root FS which could make the RPi unable to boot, I simply turned it read-only, used tmpfs for working dirs, and one RW partition to store debugging data (tcpdump files, apache logs... nothing critical to boot). I provided the "remount" command which turns the root FS read-write, if needed. Don't forget to poweroff or reboot properly after using it to avoid problems, of course.

[bousqi]

Thanks for you feedback, I'll save a lot of time not testing other Ethernet models over USB.
I guess EEM gadget source might not change so much, I wonder if it won't be possible to make a DKMS to automatically build the usb_f_eem.ko.

I'll build the module for the current kernel, and push it to your git, and try to play with DKMS.

[bousqi]

Funny thing, not so funny.
I realized that Mass Storage gadget is not working if the VID/PID of the PSAKey is used.
vxWorks must associate this usb token ids to EEM only and refuses to mount MassStorage.

[Mwyann]

You're right :) You cannot use both Mass Storage and EEM (even in composite mode it doesn't work). So if you want to switch between the two, you have to reset the USB gadget config.

[bousqi]

I did try to use Mass Storage only with this config :

echo 0x243a > idVendor  # Peugeot
echo 0x0001 > idProduct # Connect Apps
echo 0x0226 > bcdDevice # v2.26
echo 0x0200 > bcdUSB    # USB 2.0

echo "CAFEDECA"                  > strings/0x409/serialnumber
echo "Aperture Science"          > strings/0x409/manufacturer
echo "PSAKey"                    > strings/0x409/product

But SMEG+ refuses to scan it for storage.
Thus I had to duplicate a USB Key VID/PID and strings

[vidarrt9]

I realized that Mass Storage gadget is not working if the VID/PID of the PSAKey is used.
vxWorks must associate this usb token ids to EEM only and refuses to mount MassStorage.

This may work if you use dummy_hcd. Basically when you pose as CDC_EEM you offer only a single interface (in USB terminology). If you use dummy_hcd you pose as a USB hub which can then in turn provide a pathway to additional interfaces.

You may want to investigate the Facedancer project also.

[Mwyann]

I realized that Mass Storage gadget is not working if the VID/PID of the PSAKey is used.
vxWorks must associate this usb token ids to EEM only and refuses to mount MassStorage.

This may work if you use dummy_hcd. Basically when you pose as CDC_EEM you offer only a single interface (in USB terminology). If you use dummy_hcd you pose as a USB hub which can then in turn provide a pathway to additional interfaces.

You may want to investigate the Facedancer project also.

If I understand correctly, dummy_hcd isn't a USB function for gadgets, but it allows to set up a fake USB host so you can try USB gadgets locally without having compatible hardware (i.e. a proper USB OTG interface). This is different from a fake USB hub gadget function that you can use to attach more than one (virtual) device to it. And I couldn't find that too.

Also, when the original USB key was still working, I tried using a real USB hub with the PSA key and some flash stick, to see if I could use both, but it didn't work, even when powered externally (from the lighter socket). Maybe my hub was faulty, or the power supply I was using was not good enough (the PSA key needed some proper voltages to work), but I concluded that the car doesn't react if the "root device" is not what it's waiting for.

[bousqi]

SMEG Unit USB controller is very sensitive. You should not try to draw power from it.
My RPI zerow make the units reboot.

I'll definitely give a try to dummy_hcd. That sounds promising. I'm always pleased to realized how far we can go in linux kernel to simulate USB devices. Developping USB devices could be such a nightmare ! And when I did it, it was only about USB2 :)

[vidarrt9]

If I understand correctly, dummy_hcd isn't a USB function for gadgets, but it allows to set up a fake USB host so you can try USB gadgets locally without having compatible hardware (i.e. a proper USB OTG interface). This is different from a fake USB hub gadget function that you can use to attach more than one (virtual) device to it. And I couldn't find that too.

I see. Perhaps I misinterpreted it. I'll see it when I get to try.

Also, when the original USB key was still working, I tried using a real USB hub with the PSA key and some flash stick, to see if I could use both, but it didn't work, even when powered externally (from the lighter socket). Maybe my hub was faulty, or the power supply I was using was not good enough (the PSA key needed some proper voltages to work), but I concluded that the car doesn't react if the "root device" is not what it's waiting for.

That's well possible. Which exact hardware version do you have? As far as I read only the version with two USB ports may be able to do that.

@bousqi Facedancer with the appropriate hardware is your best bet to get started quickly.

[Mwyann]

SMEG Unit USB controller is very sensitive. You should not try to draw power from it.
My RPI zerow make the units reboot.

Really? Mine has only one USB port, but the PSA key advertised a MaxPower of 500 mA on the USB bus, and I used a RPI0w and also an OrangePi (which I currently use) without any problem at all. My OrangePi even have an extra USB Wifi dongle (because the integrated Wifi controller is garbage) and a USB BT dongle for the OBD2 communication ;-)

[Mwyann]

That's well possible. Which exact hardware version do you have? As far as I read only the version with two USB ports may be able to do that.

I don't know exactly which version I have. The upgrade screen tells me my hardware ID is 155. And I have only one USB port.