I'm developing a high-speed USB peripheral and using Wireshark to sniff the USB traffic. In Wireshark, each line displayed corresponds to a single URB.
Because I'm developing on the device side, I don't really care about URBs, instead, I'd like to see individual packets.
For instance, during a single control transfer, this is what I see in Wireshark:
But this one control transfer consists of 9 packets in the following sequence:
{{SETUP, DATA0, ACK}, {IN, DATAx, ACK}, {OUT, ZLP, ACK}}
Can I see the exact timing and contents of each of these packets, or is that something that I would need to buy a hardware USB analyzer for?
My operating system is vanilla Ubuntu 16.04
Related
Is there an easy way to send and receive BLE raw packets on Linux, e.g. Raspberry Pi devices? Very simply, I would like to use BLE as packet radio, i.e. exchange data packets over the air among several devices. Every device knows the MAC address of all other devices. The BLE packet format is very straightforward. I would think one should be able to put user data into the PDU (2~257 bytes) then push it through a socket to be sent out through the BLE PHY, just like how one can send raw UDP packets through a NIC. But I cannot figure out a straightforward way to achieve this after quite a bit of investigation. I suppose hcitool cmd could send packets if used correctly? But its usage is very cryptic.
The node client/server functions here do exactly this: exchange raw packets via BLE over a network of Pis. See section 3.7 in the documentation for NODE connections.
https://github.com/petzval/btferret
Recently I encountered several questions on SO regarding working with sockets on a very low level. Here's an example. While looking for an answer, I realised that sockets have relatively low capabilities on OSI Level 2. On Linux, we can specify a protocol when creating a socket, but obviously not all Level 2 protocols are present in the list.
While it is possible to assemble and send an ethernet frame, it's (presumably) not possible to send a 802.11 packet - though it looks like wifi device drivers do convert ethernet frames to wifi packets and vice versa.
This made me wonder, if there are more possibilities in reading and writing directly to device files like eht0, ath0? Is it a socket implementation who usually writes to these files, or a device driver? And who's on receiving side - a NIC driver, a peripheral bus controller?
I am on debian and:
I have a USB controller hooked up to a USB port on my PC (Device 1).
I have a male to male USB cord hooked up to another port on the PC that connects to Device 2. (it is a "bridging" usb cord, and has the chip for it)
I want to make them connect to each other as if they were one cord, so neither device knows that there is a computer in the middle.
This would be called a 'Coupler', except that I am using a PC as a coupler.
Here is a (really bad) diagram I made:
What I have done:
I have been able to connect the two devices independently of each other and sniff the results for when they fail to connect. The devices don't send a large volume of data back and forth.
Maybe there is some kind of command tool that I could use, for example (psudocode):
$ couple-usb-ports PORT1 PORT2
You're trying to reinvent the wheel here.
You might consider looking at this link instead.
http://dan3lmi.blogspot.com/2012/10/sniffing-usb-traffic-different.html
Specifically this.
Windows: You cannot directly capture raw USB traffic on Windows with Wireshark/WinPcap, but it is possible to capture and debug USB traffic on a virtual Windows machine under Oracle Virtual Box.
You cannot use a simple PC as transparent USB sniffer without extra (expensive) hardware. An USB bus has always one host (and one or more devices), and the PC can only be the host. This is a hardware limitation.
But you can capture USB data in a Windows machine using Wireshark and USBPcap, eliminating the need for the middle box in most cases.
As this post is tagged Linux, I suppose the controller PC is a Linux machine. Instead of connecting USB ports with a male-male connector, which is all kinds of bad (you are connecting the 5V lines of both machine with each other!), just run Wireshark in the controller PC.
There might be a little work to be done previously, as you have to enable Wireshark for USB monitoring (Particularly in Debian, this is disabled by default), and you might have to install a small driver to enable the monitoring. Have a look at this page for more information.
Once you get it working, Wireshark is an excellent tool for this!
I've got usb cable plugged to my computer, which D+ and D- pins are connected to multimeter. I want to send some raw bytes to get some voltage.. is it possible at all?
I'm 99% sure that usb port I've plugged cable in is something like /dev/bus/usb/002
I know that there was possibility to do the same with LPT or RS232 ports.
RS232 and LPT are not bus ! USB devices need to be addressed in order to become reachable.
Maybe unloading and reloading usb driver that drive your usb host... or trying to make a reset on usb hub host...
For doing this kind of operation on usb port, you have to break usb kernel driver and whipe all addressing operation to address directly the chipset...
At all, due to USB concept, I'm not sure you may successfully hold some power state on outlet.
For playing with that kind of physical IO, two solution:
Install a low-cost RS-232 <-> USB adapter
or better
Buy an Arduino micro-controller for prototyping and development.
I'm nearly 100% sure that you can't send anything down your USB lead unless you actually have a device at the other end. If you still want to play with this, get a cheap memory stick, break the casing off it [not too roughly], and measure whilst doing a large file-transfer to the memory stick, or some such.
But I'm not sure your multimeter will show much, as they tend to be a bit slow, compared to USB rates.
USB uses pull-up / pull-down resistors on the data lines to detect whether or not a port is connected (1.5k pull-up to 3.3v on the device side, 15k pull-down on the host side IIRC). The exact connection depends on the device speed.
So if you connect an appropriate resistor, the host should attempt to start signalling. Because of the data-rate, you might not be able to see that on a multimeter; an oscilloscope would be more appropriate.
If you want to by-pass the normal USB protocol and just blindly send data, I think you'll need to get your hands dirty and write code to bypass the usual device drivers and access the USB hardware directly. Even then I'm not sure what's possible - the USB hardware is a lot smarter than good ol' LPT and RS232 ports, which might get in the way of doing this sort of low level stuff.
Is there some way to get the Frame Check Sequence (FCS) from an ethernet frame when using Wireshark to capture packets under Linux?
The FCS is generated by the sender's ethernet device and decoded by the recipients ethernet device. If the FCS is correct, the payload is passed up to higher layers. If it's not, then the potential frame is discarded.
Because it's added for the exclusive use of the ethernet layer, there's no reason to pass the data up to the operating system. There's no reason for the hardware to include additional capabilities of moving that data out of the card. All modern ethernet devices do onboard FCS processing (and often much more). The only exception would be devices intended to analyze ethernet performance and function.
The Ethernet wiki page on Wireshark states:
Most Ethernet interfaces also either don't supply the FCS to Wireshark or other applications
so I assume the answer is a no.