HTTP over USB...?

[ricko_uk]

NOTE: OP UPDATED (additional files added)

Hi,
a client asked me if I could add an external device to a vending machine for vapes devices. It is an age-recognition system that would interface with the main controller via USB but apparently uses HTTP protocol?

Attached is a PDF the API (very short) and the brochure. In the brochure there are 4 devices there but the one I've been asked to use is the one on page 4 and 5. It is like a USB pen drive that you can plug directly into a PC. At the back of it there is another USB port where you plug in the web cam. There are no other connectors. That is the whole system for age recognition. On page 5 it also says "no internet required".


I wrote quite a bit of code in C/C++ through the years, but never worked with networks/internet. To the point that I barely know what HTTP is...   

So, as a newbie to that topic, I am wondering:
- if I understood correctly that is is HTTP over USB?
- what do I need to implement on the host micro in term of software... maybe some "server" software? (again no idea how HTTP even works or what it needs). Or do I just send a packet via USB like in the attached screenshot?

Any clarification is much appreciated as always!

Thank you

[ataradov]

Given that it talks about URLs and IP addresses, it is likely a USB to Ethernet adapter, which implements one of the standard protocols. The common ones are RNDIS (Microsoft specific, but widely supported) or ECM/EEM/NCM, which are a part of the CDC class (same spec that covers USB to serial converters).

And then you will need TCP/IP stack, although in this case it can be a very limited subset, which you can likely hard code. Once you implement that, HTTP is just a text-based protocol, that part is easy.

And if SSL is necessary and enabled, then you are going to suffer. SSL on embedded devices sucks.

Or it could be something entirely proprietary. The only real way to tell is to get one of those devices and plug it into the PC and see what descriptors it supplies. Or read the document more carefully, it might specify that.

[T3sl4co1l]

HTTP is quite a high-level protocol -- it's text based (7-bit ASCII), and operates within a network pipe.  A server could run via plain text on the command line, but that wouldn't be very interesting, so it's usually piped to a program, or better yet a network port.  (A pipe is a bidirectional comm channel.  Although, how that actually manifests, or works, in a *nix shell, or MS-DOS/Windows context, I'm not clear on.  Also MS has the equivalent function in name, but it's a one-way street I think?--)

HTTP is normally handled over TCP/IP, so that the text can be collected from time to time and sent as packets, and will be transmitted reliably in-order.  A web browser's most basic function is handling these requests and responses (the OS usually handles TCP drivers and below).

I suppose the most basic way you could handle this, is to have any text-based comm channel between devices.  Assuming you have control of hardware on both sides.  It could be as trivial as a USB virtual COM port, and then it could run HTTP directly (no IP/port connection, no routing, no network state, just a fixed hard pipe), or via a thin interface (say, https://en.wikipedia.org/wiki/Serial_Line_Internet_Protocol and relatives).

Alternately, you can ask your, whatever software people you're working with, to de-abstract the fuck out of their interface , and just give you a sequence of commands to operate on.  I guess they're working on a server backend or client browser/app API sort of level, which means you need some kind of interface similarly accessible for them to work with, and that will depend on what's available.  I think even at the app level, there are ways to access serial ports, so you could have for example a cell phone with a USB-serial adapter plugged in and connect through that.  A simple packet encoding for commands and/or data would suffice for communication between the app and the attached device.

Serial of course is plain text over wires, so isn't exactly secure, just to make that clear.  That doesn't mean it's an automatic fail, it just means it needs to be physically inaccessible, and perhaps EMI-invisible (well enough shielded) too.

There are also higher-level versions, like serial over Bluetooth, or WiFi obviously, which need some means of identifying, connecting or attaching device(s), but which AFAIK can do this as simply -- in high-level terms.  These might already be available on a platform, and otherwise there are USB Ethernet adapters for example.

Tim

[ataradov]

They may not be able to de-abstract. The device may be just a simple USB to Wi-Fi stick that connects to their servers. So, the actual logic happens on the server. Even if they invent some binary protocol, there is still no avoiding the TCP/IP stack and may be SSL.

[ricko_uk]

Thank you @T3sl4co1l and @ataradov,

I have found the leaflet of the product if that helps in any way...? I attached it below. There are 4 devices there but the one I've been asked to sue is the one on page 4 and 5.

It is like a USB pen drive that you can plug directly into a PC. At the back of it there is another USB port where you plug in the web cam. There are no other connectors. That is the whole system for age recognition. On page 5 it also says "no internet required".

Not sure if that gives you any additional clues perhaps?

Also attached is the full API in case it gives away some additional info.

Thank you again

[ataradov]

This does not really tell much, but given that it works offline and with any web cam, I'd say it is likely to be some Linux MPU that runs a server and presents itself as a network device. It is easy to work with on a PC, but a huge pain on the MCU.

The actual USB protocol is going to be RNDIS or the CDC one. As usual with USB, standardization and interoperability is a shitshow of epic proportions.

[ricko_uk]

Thank you.

If anybody else has any additional thoughts or comments (maybe someone here has used it?) please feel free to share what you know of the system

[mr ed]

Now is a good time to study the Osi stack concept.   Http assumes a reliable transport mechanism like tcp. Usb is just serial -  best effort like udp.

[ataradov]

Usb is just serial -  best effort like udp.

Bulk endpoints guarantee delivery. And this is what is used in all Ethernet over USB classes.

The only thing that may be unreliable in USB are isochronous endpoints, which are used for audio/video type of stuff where retries make no sense and it is better to drop the data rather than retry.

[SiliconWizard]

Yes, the easiest path would be to implement a RNDIS USB device.
The MilkV duo board does just that, with the default Linux build.

[moffy]

I'm not sure if this will help but LWIP is a light weight TCP/IP stack that has been ported to a number of microcontrollers, it might provide a starting point at least for the TCP/IP part.
https://github.com/lwip-tcpip/lwip

[ricko_uk]

Thank you all!

[radiolistener]

the protocol broshure shows typical interface for REST service. So, it looks like USB-Ethernet converter which is often used to connect FPGA to PC with USB3 interface. Technically it looks like usual Ethernet PHY on FPGA side, but it is connected to PC with USB3 interface. It works like usual USB-Ethernet adapter, but there is no Ethernet medium (coax/twisted pair/fiber optic), instead it provides Ethernet PHY interface.

Regarding to biometrics identification/authentication, using it in our days is a bad choice because it becomes more and more vulnerable with today technology, AI and raising risks of biometrics data leakage. For example even child can bypass face/voice recogniton, fingerprint/eye iris also can be easily stolen and copied. So, using biometrics identification/authentication will give you much more risks than advantages, because it helps crimes to use someone identity with minimum efforts and opens up huge opportunities for black businesses trading stolen biometric data... The only way to avoid such risks is just to forbid using biometrics for identification/authentication at all. You're needs to assume that crimes already have access to anyone private and biometrics data from black-market and build your security system with take into account that crime can easily use stolen biometrics data to bypass biometrics identification/authentication.

In other words, using biometrics identification/authentication is the same as adding a big backdoor into your security system. Even usual password is more secure than biometrics.

[Doctorandus_P]

A bunch of years I bought a few BeagleBone Black's Plugged them into an USB port, started up a web browser and viewed the beaglebone web page directly from it. As my main PC is also running Linux I did not have to do anything extra. Apparently you have to install extra drivers on the PC side if you want to run Windoze or the fruit brand.

Also see:

https://en.wikipedia.org/wiki/Ethernet_over_USB

[zilp]

I guess noone has said so explicitly, so I will:

Unless you build a large number of these, I probably wouldn't bother with implementing all of the necessary complex protocol handling (both USB and TCP/IP) on a microcontroller, but rather stick in some cheap Linux system (the MilkV duo has been mentioned, that's probably the cheapest option? if you need only small numbers, I guess you could also just use old home routers that are supported by openwrt ...), as Linux implements all of that protocol machinery, and even has plenty of libraries and tools for handling HTTP(S), so it should be close to trivial to hack together something that exposes the interface of that module via a UART or something that you then can interface from your "main MCU". You could even write the glue code in Perl, Python, Ruby, whatever. Just make sure that that thing is not in any way connected to the internet, or else you'd have to worry about security updates ...

[Siwastaja]

As zilp said. Use general-purpose computer (something like Raspberry Pi or whatever). Doing this on microcontoller is possible and allows you to drop BOM cost from tens of $ to a few $ (also power consumption from a few watts to hunderds of mW), and manufacture in hundreds of thousands (single-board computers often have supply issues), but probably none of this matters. Development on microcontroller will require a much more experienced type of person who has done exactly this before, and still expect development time of months. On a generic PC running e.g. linux and its TCP/IP, USB and device driver stacks, it could be matter of days.

[ricko_uk]

Thank you all