I am monitoring USB traffic with Wireshark in the interface XHC2. However, the payload of all USB packets is all-zero. The packet's length is correct, but the packet's payload is all zero. It does not matter which device, which packet or whichever. It is always zero. Obviously, this is not the reality, since the devices work properly and lot of information is displayed via lsusb.
My guess is that the XHC interface is setting the payload to 0 before delivering to upper layers, but I do not know if it is intentionally, a bug, kernel issue, my fault or something related with Wireshark.
I also tried tcpdump -i XHC2 and the saved pcap file is the same.
Additional info:
Mac Mini M1 with Big Sur
Wireshark ARM 3.6
SIP disabled
It's unlikely to be related to Wireshark, given that it happened when you captured with tcpdump as well.
You should file an issue on Apple's Feedback Assistant.
Related
I'm having no joy in getting a replayed UDP Multicast packet to be "seen" by a client program on a different machine.
Details:
I have two machines on my local (wired) network connected through one unmanaged switch. One machine (running tcpreplay) is running Ubuntu 20.04, the other machine is running Windows 10.
On the Windows machine I have a Python program I wrote which listens for UDP multicast packets on port 5110 (this is dictated by the source of the UDP stream which is a commercial program). When I run the commercial program, my Python code correctly consumes the incoming packets and all seems to be working fine. I have a lot of work yet to do on the contents of those packets after they are received, but that isn't important for this issue.
So, moving forward, I decided it would be great to be able to work on the Python code without having the commercial program always running in the background hogging up resources. I figured if I could catch a snippet of UDP broadcasts from that program, I should be able to replay at leisure without having to run that resource hog.
So, on the Windows machine, I captured a UDP multicast packet stream using Wireshark and saved to a pcap file which I then copied to the Ubuntu machine.
I then attempted to replay that pcap file (on the Ubuntu machine) as follows:
$sudo tcpreplay -i enp5s0 single.pcap
To my disappointment, my Python program (on the Windows machine) did not receive the incoming packets.
Back on the Windows machine, I fired up Wireshark again and captured the "replayed" packet coming from the Ubuntu machine - so it appears the packet did make it out of my Ubuntu machine and into my Windows one. The contents of both the source packet (sent by tcpreplay) and the received packet (grabbed by Wireshark) appear identical - including the source and destination MAC addresses and the checksums. A diff on the byte contents of each packet yields no differences.
However, my Python program still stoically sits there waiting at:
data, address = sock.recvfrom(1024)
Here on stackoverflow, I did find this thread which seems to be an identical problem, however none of the solutions presented within helped (including changing the rp_filter parameter). I also saw mention of a Windows program, "Colasoft PacketPlayer", which I tried - running on the same machine as my Python client. This appears to have the same apparent results (i.e. no joy). I did not initially try that route as I was concerned with generating the packet on the same machine which is listening for it. (As an aside, I did also capture the replayed packet from Colasoft PacketPlayer and it too appears identical to the source packet).
At this point I'm out of ideas and am reaching out to the community for possible next steps?
I have started with an Atmel Start project:
My goal is to have a usb hub connected to this demo board:
SAM V71 Xplained Ultra Evaluation Kit
The problem is atmel doesn't supply a hub driver, and they haven't responded to our questions about this. So I have been attempting to write one based upon the msc and other drivers they do provide.
Currently I'm having an issue when I connect the USB hub. It is returning a STALL when I send a GET_DESCRIPTOR request with the type DEVICE. This seems odd to me because other USB devices such as a flash drive or USB to serial converter do not reply STALL to the same request. In fact the Flash drive goes through the entire enumeration process and msc installation so that I can successfully read and write to the drive.
I am detecting the stall via a single break point set in the STALL handling section of the pipe handler.
I have been reading the Universal Serial Bus
Specification Rev 2.0 but I can't find any differences between the way to read descriptors from hubs vs other devices. And I don't understand why a STALL would ever be sent in reply to a GET_DESCRIPTOR request.
Thanks
Just in case this is useful for anyone else. The issue I was having was apparently caused by the compiler optimization settings. Specifically I had change this setting to: "None (-O0)", after changing this back to the default I have had no problems enumerating USB devices. Picture of Optimization configuration
My colleague discovered this because of a seemingly unrelated problem which was causing Hard faults and Bus faults on the chip, these were also fixed by switching back to -O1. It seems -O0 needs to be used with a grain a salt or not at all on this chip.
After having been studying a USB Packet Sniffer based around the BeagleBoard xM (https://gitorious.org/beagleboard-usbsniffer/), I have been at a loss as to how the driver actually works in a certain area.
I now understand that the BeagleBoard acts as a one port USB hub for the USB host to see, so that it may view and log the packets going through it. The part i'm trying to currently understand is how exactly the BeagleBoard is able to be somewhat transparent, and able to mimic the USB Vendor/Product ID's of the device being sniffed.
There is nothing to mimic. If it behaves as a hub, it can see all the traffic going between the computer and the device under test because all the USB packets would go through the hub. Packets are received by the hub and transmitted along to the other device.
I am using an embedded linux kernel 2.6 onto an Intel Atom CPU. Due to the slow performance of the 2x00usb wifi driver, I decide replace it by the 5370sta. Now speed connection is up to 10 times faster but I am experimented a problem with UDP transmission that worked like a charm with the 2800usb wireless driver.
The UDP connection can receive all datagrams properly, but the transmission turn down after some minutes. It is curious because while transmitter is down, the receiver keeps receiving correctly. After some minutes, the UDP transmitter comes alive again. I have not been able to find a pattern, the failure is apparently random, but I am sure that there is a reason, maybe a buffer saturation or something like that.
I have modified the socket bind from (ip=0.0.0.0 to my CPU ip) and the broadcast (from 255.255.255.255 to 192.168.0.255) among several non successful attempts. But I thing that problem is with the new wifi driver and some configuration that I don't know.
at the moment I am using usbmon to sniff usb. for better understandability I want to use wireshark. I've used wireshark before for sniffing ethernet packets. But what to capture to sniff USB Packets ? I meant I need to start by selecting which interface to capture in wireshark. but what wold I select there for usb ?
Grab newest wireshark.
Use lsusb before and after plugin in device so You know which usb bus its plugged into.
type in terminal:
su -c "modprobe usbmon" && su -c "wireshark"
(First load kernel module that allow for usb sniffing for root, second load wireshark as root)
Than select usbmonX, where X stand for usb bus number (lsusb show those numbers).
After than you still need to filter packets for device / vendor id, or something else device specific, as wireshark will show all packets from all devices plugged into that bus. (Again lsusb before/after plugging you device will help).
Have you taken a look at the documentation for that on the Wireshark website?
In libpcap 1.0.x, the devices for capturing on USB have the name usbn, where n is the number of the bus. In libpcap 1.1.0 and later, they have the name usbmonn.
a quick notice since I just started using wireshark to sniff usb packets on linux. as I understand you need usbmon module loaded (which if you are using it should be). Additionally I seem to recall that while wireshark can be setup to let non root users sniff ethernet packets, some limitation required root access for usb packs (at least at the time of writting).
Similar to what others have said, on my system, Ubuntu 12.10, the usb interfaces have names like "usbmon1 USB bus number 1" and so forth.
(you might look at http://biot.com/blog/usb-sniffing-on-linux)
the link listed has an image showing a filter which can be used to select only traffic to from a device number (from lsusb).
I hope thats helpful
#przemo_li You want to filter by device address to see the communication from both the host and the device. The filter for that is usb.device_address ==.