Bug 301

Summary:	Bogus IP header length generated using second.cc example script
Product:	ns-3	Reporter:	Thierry Turletti <turletti>
Component:	samples	Assignee:	ns-bugs <ns-bugs>
Status:	RESOLVED INVALID
Severity:	normal
Priority:	P3
Version:	pre-release
Hardware:	Mac Intel
OS:	Mac OS
URL:	http://planete.inria.fr/turletti/test/second-1-1.pcap

Description Thierry Turletti 2008-08-29 05:25:36 UTC

Wireshark complains about 2 packets with bogus IP header length (size 0) in the example script "second.cc" .

The corresponding pcap file can be found at http://planete.inria.fr/turletti/test/second-1-1.pcap

Comment 1 Thierry Turletti 2008-08-29 05:35:45 UTC

Note that tcpdump can decode without problem this pcap file. wireshark pb only?

Comment 2 Tom Henderson 2008-08-30 17:25:38 UTC

I cannot reproduce this.  Perhaps you mean that the IP checksum (rather than length) is zero?

Can you try this:
./waf --shell
build/debug/scratch/second --ns3::Ipv4L3Protocol::CalcChecksum=true

and look at the trace in wireshark again?  Does that clear up the problem?

Comment 3 Thierry Turletti 2008-09-01 04:20:25 UTC

No, actually wireshark 1.0.2 (on my MAC OSX 10.5.4) seems to identify the following protocols on IP frames: [ppp:ip:udp:redbackli:ip] and complains on the second IP header (Bogus IP header length)... 

I put a snapshot of the wireshark at http://planete.inria.fr/turletti/test/wireshark-0-0.png


Cheers

Thierry

Comment 4 Tom Henderson 2008-09-01 18:26:29 UTC

(In reply to comment #1)
> Note that tcpdump can decode without problem this pcap file. wireshark pb only?
> 

I looked at the octal dump of the trace and it looked OK to me.  And on my version of wireshark, I could not reproduce.

Googling on "Redback Lawful Intercept" suggests to me that it might be a Wireshark bug:
https://bugs.wireshark.org/bugzilla/﷒0﷓

I will mark it as invalid (Wireshark bug) if I am not able to reproduce on other machines and if there are no further comments this week.