hello, when capturing traffic timestamed by ixia NTO5288 i can see the trailer without any problem. however, after trimming the payload and computing a new CRC to the packet i can't see trailer in wireshark, although the packet length is 15 bytes longer and going through the HEX data i can find the trailer but it can't be displayed correctly. is there a way to pull out this information and display it? This question is marked "community wiki". asked 16 Apr '15, 07:18  Roni Pollak |
3 Answers:
If I change the Ethernet protocol preference "Fixed ethernet trailer length" to 19, this decodes for me. Otherwise the ethernet dissector doesn't see any trailer, as the IP dissector doesn't get as many bytes as its length field indicates, so never returns any bytes back to the ethernet dissector to consider as trailer... answered 17 Apr '15, 09:12  MartinM Hello, thanks all for you help. MartinM's suggestion solved my issue - thanks Martin have a nice weekend, roni (17 Apr '15, 12:52) Roni Pollak |
Hi Roni You could convert the file to text (i.e. save at K12 format) and then parse through the file to determine the timestamp with a script. This is one way that I've done exactly this in the past. Thanks, Ollie answered 17 Apr '15, 08:33  Ollie Sheridan |
It is. Ethernet packets have a field that can be used as a type field or a length field; for IP packets, it's used as a type field, so the only length field that can be used to determine whether the Ethernet packet has a trailer is the length field in the IP header, and that wasn't changed as part of the editing process. Why are you trimming the payload here? answered 17 Apr '15, 09:22  Guy Harris ♦♦ My understanding is that it is a feature of the monitoring switch to effectively set a snaplen, but maintain the ethernet trailer with the timestamp information. Is there a neater way making it work than changing the ethernet preference "Fixed ethernet trailer length" that I suggested in an answer a few minutes ago? (17 Apr '15, 09:26) MartinM I'm obligated to record all streams 24*7 so I have to get rid of the payload. MartinM,how do I set what you suggested? (17 Apr '15, 10:44) Roni Pollak 1 The cleanest way to do this would be to get a new LINKTYPE_ value from [email protected], with packets beginning with the Ixia trailer and having the Ethernet packet following it, and have the program that records the streams move the trailer to the beginning, truncate the rest of the packet and discard the FCS, and write the packets out with a length that reflects the on-the-wire packet length and a "captured length" that's the actual number of packet data bytes. (17 Apr '15, 11:04) Guy Harris ♦♦ |
Can you show a capture before and after the trimming you talk about?
There's no reliable way to detect that a packet has an Ixia trailer, so Wireshark is forced to use heuristics to try to guess whether there's a trailer or not. Editing the packet probably changed it in some way that causes the heuristics to fail; that might be a bug in the heuristics, or it might be a consequence of the editing not being done in a way that would make the heuristics work (for example, you might not have set the packet length and captured length fields for that packet in the modified capture file so that they correspond to the changed packet length).
That's why we'd need to see the capture files from before and after the trimming - to figure out what's the cause and how it would need to be fixed.
hi,
thanks for the quick responses.
i do i upload the files? it's my first post at this site and i am not familiar with it.
roni
Please upload it to google drive, dropbox or cloudshark.org and post the link here.
hi,
here are the files:
https://www.dropbox.com/sh/ym0z8be2ehxpexl/AAAwvct5X5Y75D58gKqPk-2za?dl=0
pcap files
thanks,
roni