Discussion:
Scanning IP6 packets
Steve
11 years ago
Permalink
Hello Dev Team,



Firstly, I apologise if this mail is going to the wrong place, but I
couldn't find anywhere else to send it to.



I've been using TCPDump for some time as a way of tracking and extracting
the domain names of http request for IPv4. As IPv6 becomes more prolific,
I've missing more and more data.



I note that on some documentation that the use of 'tcp' filter on Ipv6 isn't
supported because of the possibility of additional headers in IPv6 packets,
but I was wondering if there is some kind of work-around in order to seek
out the required information.



This was the string that I was using for Ipv4:

tcpdump -i eth0 -nn -s 0 -A port 80 and '(tcp[((tcp[12:1] & 0xf0) >> 2):4] =
0x47455420 or tcp[((tcp[12:1] & 0xf0) >> 2):4] = 0x504f5354)'





I've tried several different versions of converting these filters to 'ip6'
references but no packets are returned.



How can I get a working filter to capture the data I need?



Thanks

Steve.
Guy Harris
11 years ago
Permalink
Post by Steve
How can I get a working filter to capture the data I need?
Modify the code in libpcap's gencode.c so that the comment in gen_load():

/*
* The offset is relative to the beginning of
* the transport-layer header.
*
* Load the X register with the length of the IPv4 header
* (plus the offset of the link-layer header, if it's
* a variable-length header), in bytes.
*
* XXX - are there any cases where we want
* off_nl_nosnap?
* XXX - we should, if we're built with
* IPv6 support, generate code to load either
* IPv4, IPv6, or both, as appropriate.
*/

(in particular, the last XXX part) no longer applies.

Or write your own filter expression that looks at the link-layer header to detect IPv6 packets, skips past the IPv6 header (you won't be able to handle extension headers, as that involves looping, and the libpcap filter language doesn't support that), and then loads the appropriate value from the TCP header based on that.

There is no easy solution. Sorry.
Steve
11 years ago
Permalink
Hi Guy,

Thanks for the reply.

I tried using the below filter which did pick up some request packets, but
(likely as a result of the added header extensions) it was missing some.

(ip6[((ip6 [32:1] & 0xf0) >> 2):4] = 0x47455420 or ip6 [((ip6 [32:1] & 0xf0)
Post by Steve
Post by Steve
2):4] = 0x504f5354)
As a result, I've just modified my scripts to simply pick up all port-80
data on ipv6 and scan the packet for what I'm looking for. Takes a bit more
CPU but gives me the result I was looking for.

Thanks very much for your help.
Steve.



-----Original Message-----
From: Guy Harris [mailto:***@alum.mit.edu]
Sent: Wednesday, 13 November 2013 7:15 PM
To: Steve
Cc: tcpdump-***@lists.tcpdump.org
Subject: SPAM-LOW: Re: [tcpdump-workers] Scanning IP6 packets
Post by Steve
How can I get a working filter to capture the data I need?
Modify the code in libpcap's gencode.c so that the comment in gen_load():

/*
* The offset is relative to the beginning of
* the transport-layer header.
*
* Load the X register with the length of the IPv4 header
* (plus the offset of the link-layer header, if it's
* a variable-length header), in bytes.
*
* XXX - are there any cases where we want
* off_nl_nosnap?
* XXX - we should, if we're built with
* IPv6 support, generate code to load either
* IPv4, IPv6, or both, as appropriate.
*/

(in particular, the last XXX part) no longer applies.

Or write your own filter expression that looks at the link-layer header to
detect IPv6 packets, skips past the IPv6 header (you won't be able to handle
extension headers, as that involves looping, and the libpcap filter language
doesn't support that), and then loads the appropriate value from the TCP
header based on that.

There is no easy solution. Sorry.
Darren Reed
11 years ago
Permalink
Post by Guy Harris
...
Or write your own filter expression that looks at the link-layer header to detect IPv6 packets, skips past the IPv6 header (you won't be able to handle extension headers, as that involves looping, and the libpcap filter language doesn't support that), and then loads the appropriate value from the TCP header based on that.
There is no easy solution.
Something that I'm working on is a design & implementation of BPF (v2) that
incorporates instructions that are specifically designed to deal with headers
that are chained together in this fashion. In its current form, BPF (v1) is
not that IPv6 friendly. Give me a week or two to back up a design with some
code that works (the parser and compiler bit are the tricky pieces.)

Darren
.
Michael Richardson
11 years ago
Permalink
...
That's cool...
Post by Guy Harris
that are chained together in this fashion. In its current form, BPF (v1) is
not that IPv6 friendly. Give me a week or two to back up a design with some
code that works (the parser and compiler bit are the tricky pieces.)
True. I assume you are adding kind of limited loop capability. Could it be
unrolled to some depth to work with BPFv1?

--
] Never tell me the odds! | ipv6 mesh networks [
] Michael Richardson, Sandelman Software Works | network architect [
] ***@sandelman.ca http://www.sandelman.ca/ | ruby on rails [
Darren Reed
11 years ago
Permalink
...
No. For analysing IPv6 you don't need loops, rather you need some
much more complex instructions than BPF's RISC design has at present.
Key to that are "find header number X" or "what is the last header"
as network analysis functions. Once those two operations become
explicit instructions for BPF, there isn't really any need to
support loops for analysing IPv6 packets.

Darren
Michael Richardson
11 years ago
Permalink
...
okay, I would call these "limited loops", in that they can only iterate
through the packet under specific conditions :-)

Thank you for working on this.
Getting new BPF code widely deployed won't be easy.

--
] Never tell me the odds! | ipv6 mesh networks [
] Michael Richardson, Sandelman Software Works | network architect [
] ***@sandelman.ca http://www.sandelman.ca/ | ruby on rails [
Continue reading on narkive:
Loading...