I wrote a small program called ice9 that I have setup for
anonymous cvs if you need the source code to look at.
Anyways everythign works fine with the code if you are
looking at IPv4 traffic. After installing libpcap with IPv6
enabled everything for IPv4 still works fine. However,
IPv6 packets are never read. Tcpdump will read the
pcap data fine (which ensures I have valid data) but
pcap_next_ex() returns a -2 without ever reading one
packet in. Is there a bug in the code or someone else
have clairovoance that I don't and can tip the rest of us
to the secret?
Logged In: YES
user_id=541179
On what operating system does this happen?
Is this happening when you capture packets or when you're reading from a
file? Note that a return value of -2 from "pcap_next_ex()" is supposed to
mean that, when reading from a capture file (rather than when capturing),
you've gotten to the end of the file.
I don't see any "pcap_next_ex()" calls in the code under the
http://www.silenttrace.com/phd/objc/objcindex.html
page; is there another version with pcap_next_ex()?
Logged In: YES
user_id=1103437
This is happening on OSX - panther. I know the -2 is because it reaches
the end of file but that was the point, it reaches the end of file without ever
giving an error or seeing any of the IPv6 packets.
There is no other version with a pcap_next_ex() function in it. I don't
understand why I would need one? I mean the code works fine for IPv4 is
this function critical to using IPv6?
I have cleaned the code up a little and will post a new release to my site.
Any other ideas are appreciated. Thanks.
Logged In: YES
user_id=541179
You would need a version with pcap_next_ex() in it if you want to report a
bug with pcap_next_ex(). :-)
pcap_next_ex() is not critical to using IPv6 - it's irrelevant whether you use
pcap_next_ex() or not when reading IPv6 packets. It is, however, critical
to reporting a bug on pcap_next_ex().
Note, however, that the filter "ip" will not match *ANY* IPv6 packets, so if
you try to read from a file containing only IPv6 packets with a filter of "ip",
you will get an end-of-file on the first read. "ip" matches only IPv4
packets; you'd need "ip6" to match IPv6 packets, and "ip or ip6" to match
IPv4 and IPv6 packets.
I will update the tcpdump manual page to make that clearer.
Logged In: YES
user_id=1103437
AHA !!!! You solved it sort of - see i was not trying really to report an error I
was just trying to figure out why my code with no filter would simply run live
or read a pcap file and see all IPv4 packets. I wrote the code so it should
see Ip6 as well but it doesn't, however if I add the filter "ip6" like you said I
get the IP6 packets. That is what I wanted, although why does one have to
set the filter for that? can it work just like ipv4? Also like you said if you add
to the tcpdump maual that to get ip6 packets you need to set the filter to
"ip6" . Lastly thanks for the help.
Logged In: YES
user_id=541179
IPv6 does work just like IPv4, except that the filter you use to capture
packets is "ip6", not "ip". "ip" is not a filter for IP packets of all versions;
it's a filter for IPv4 packets.
I wasn't the one who added IPv6 support to libpcap; perhaps the rationale
was that "ip" always matched only IPv4 packets (by checking only for the
protocol type field for IPv4), so they made it continue to do so. That won't
change.
The tcpdump manual page now says "IPv4" rather than "IP" when
speaking of the "ip" keyword.
Administrators of the "libpcap" SourceForge project have superseded this tracker item (formerly artifact 1008667, now bug 44) with issue 46 of the "libpcap" GitHub project.