This is a static archive of our old Q&A Site. Please post any new questions and answers at ask.wireshark.org.

Dropped packets: not overload, but bad FCS?

0

Hi!

The short question is: How i can capture frames with bad FCS on Linux? (i read that it is almost impossible, but i really need it).

The long story: I develop open-source FPGA-based Ethernet-to-serial converter (constant-speed bit flow, not async RS232-style). It sometimes show massive packet loss. I need to debug it and search a way to analyze all incoming traffic include damaged packets. I read many places about it and find some information, but no success. I try sudo ethtool -K eth1 tx on rx off, it not changes anything. I read here also. I also try to Wireshark Ethernet protocol properties: the FCS checking, and assuming frames have CRC, both are not helpful. But, i now see damaged packets in Wireshark as dropped packets. But unfotrunately only i see is their correct quantity in status line: no order, no time, no dumps. So the question is: if Wireshark 'see' damaged packets, and shows correct q'ty of it, can Wireshark display it?

I have no network overload or other conditions which may give other reasons to drop packets.

Thank you so much!

asked 25 May '13, 01:16

jpka's gravatar image

jpka
11112
accept rate: 0%


One Answer:

1

I don't think Wireshark counts packets with bad FCS as dropped, because it will never even know about the packet in the first place. Dropped packets are packets that didn't make it into the capture file for performance reasons but had been seen by dumpcap. Packets with bad FCS will be dropped at the switch or at least on the receiving NIC, so dumpcap and Wireshark will never even know it has been there.

You can read more about it here: http://blog.packet-foo.com/2013/05/capturing-damaged-frames/

I guess you need to get capture equipment that can capture damaged frames. I'm not sure if there are any Linux based NIC drivers that can help.

answered 25 May '13, 01:59

Jasper's gravatar image

Jasper ♦♦
23.8k551284
accept rate: 18%

I don't have a switch in this setup. I double check all connections. The fact is, Wireshark sees damaged packets. When i issue 100 packets, the sum of q'ty of received and dropped packets, is always 100... I know that is uncommon, and damaged packet should be dropped in many places before it arrives to Wireshark, but the fact is it don't. So the more precise question may be, which event in system lead to displaying dropped packets in Wireshark, except they are explicitly dropped by Wireshark (due to system overload or other rule). Because this can give a (tiny) chance to see damaged packets. But if 'dropped' means just calculation of kernel/driver events like 'dropped by NIC due to RX buffer overflow or any other receive error', there is no chance to dump, i think. But still may be a chance to display such events with timestamp in capture list. Thank you!

(25 May '13, 02:54) jpka

No switch? How is the connection done, Crossover cabling or by hub? I have never seen Wireshark list dropped packets because they've been damaged. Maybe you're microbursting your receiving NIC with extreme high amounts of packets that your capturing PC cannot deal with?

(25 May '13, 10:24) Jasper ♦♦

I have two PCs and my bridge between them, no hubs or switches. The amounts of data much less than 16 kilobytes. Anyway, no errors if direct connection (without my device) so it is not NIC overload. Dropped packets shown only after i stop capture, they do not shown when capture is active. I repeat it again and again, and overall q'ty of received and dropped packets equal to issued one. I also found other topics about dropped packets here; but no one explain what exactly this value mean...

(28 May '13, 00:05) jpka

It sometimes show massive packet loss. I need to debug it and search a way to analyze all incoming traffic include damaged packets.

I suggest to use a small managed switch (Cisco, HP, or similar) to connect your FPGA to the network. Whenever you see lost packets in your application, you can read the interfaces counters of the switch to check if there is a mismatch of what you expected to get (number of packets) and if the switch reports any dropped packets.

There is no (simple) way to do the same with commodity hardware, as already mentioned by Japser in his blog.

If you don't see a mismatch or dropped packets, it's a problem within your converter (probably overloading the serial chip buffers). If there are dropped packets in the switch, you should look at the networking code of the FPGA.

I develop open-source FPGA-based Ethernet-to-serial converter

Is there a website available for this project?

Regards
Kurt

(28 May '13, 00:13) Kurt Knochner ♦

The Wireshark currently counts damaged packets (as dropped) very well (but i still don't know why; as people says, it should not). I am sorry but can't understand how manageable switch can do it better...until it can dump or fix damaged packets. Anyway, i don't have any intelligent LAN equipment here. P.S. About my converter. I don't fully publish my project now due to it not ready, but shapshots available here, Xilinx ISE project and Pcad2002 PCB. But before opening ISE project please read here about ISE bugs (project will not open correctly until you bugfix standard ISE library as described).

(28 May '13, 07:44) jpka

As @Jasper already said, the dropped packets are not those with a bad FCS, as Wireshark would never see them (the NIC driver or even the NIC hardware will drop them without notice). That's just 'good' packets that did not make it into the capture file for some reason (most likely hard disk speed). Maybe it's not a constant stream on packets (as you said) but instead there is a burst of packets for short time intervals. Try to write the capture file to RAM disk and (most certainly) you will no longer see any dropped packets in Wireshark.

I am sorry but can't understand how manageable switch can do it better...until it can dump or fix damaged packets.

it cannot dump or fix damaged packets, but it can show that there are some damaged packets. It's just an indicator for damaged packets not more and not less. But it will help to narrow down the problem.

Anyway, i don't have any intelligent LAN equipment here.

The guys at amazon will send one ;-) Really, you can't detect damaged packets with a commodity ethernet NIC on linux, so the easiest and cheapest way is to get a managed switch (80$ for a HP switch).

BTW: wouldn't it be clever to test your project with some "standard" network equipment in an early stage to detect general problems ;-))

P.S. About my converter.

Thanks for the info!

(28 May '13, 07:54) Kurt Knochner ♦
showing 5 of 6 show 1 more comments