On Aug 17, 2010, at 2:21 AM, Ambika Prasad Tripathy wrote:
> I am searching a way how to filter GTP packets and hence mobile IP data over
> GTP-U. I can do that by applying index based filter for BPF. But can when I
> see struct bpf_insn structure I think, if I modify the gencode.c/h and
> grammer.y to extend the GTP based filter it can work.
The bpf_insn structure doesn't matter - if, by "I can do that by applying index
based filter for BPF", you mean that you could, for example, do a whole bunch
of "udp[N:M] = XXXX" tests, then that gets compiled into BPF, so that alone
would demonstrate that you can generate BPF code. (BPF can do pretty much
anything that does *NOT* involve looping. If you have to do a loop, you would
only be able to do it in userland; no kernel implementation of BPF allows
backwards branching, to prevent user-mode code from loading code that loops
infinitely.)
> But not sure whether it is possible or not. Please let me know is the idea
> works to extend existing bpf syntax for GTP-C and what are the things I
> should modify for it. Below is my idea.
>
> e.g.
> proto gtp -> will filter all GTP-U data packets
There is no keyword "proto" that stands by itself; you have to specify a link
layer (e.g., "ether proto XXX") or a network layer (e.g., "ip proto XXX").
GTP-U runs over UDP; there is no support for "proto" in pcap filter format
referring to a transport-layer protocol field. If it's using the standard
port, you could do "udp port 2152"; at least on some systems, "udp port
gtp-user" would also work.
If you want to add explicit support for GTP filters, you should just have the
filter for GTP-U be "gtp" or, perhaps "gtp-u" (people might also want to filter
for GTP-C packets).
> mip <value> -> will filter all mobile IP address based comparing on value
> field.
> Src mip <value>-> will filter only those packet whose mobile src ip is as
> value
> dst mip <value>-> will filter only those packet whose mobile dst ip is as
> value
So this is intended to look at the IP address of the encapsulated IP packet,
rather than the IP address of the GTP-U packet, right?
> Mproto <tcp/udp/ip/icmp> -> will compare the protocol layer above GTP-U
> layer and filters
>
> Mport <value> => will filter mobile transport ports
>
> Src mport <value> -> will filter only those packets whose src port is as
> value
>
> dst mport <value> -> will filter only those packets whose dst port is as
> value
And, again, those are intended to look at the IP protocol value and the TCP or
UDP port values of the encapsulated IP packet, right?
If so, I think that's doable fairly straightforwardly, given that the GTP-U
header for a T-PDU is fixed length.
An alternative, however, would be to make "gtp-u" work similarly to, for
example, "vlan", "mpls", and "pppoed", and modify the offsets used in the code
generator to generate test, so that you could, for example, do
host XXX.XXX.XXX.XXX and gtp-u and host YYY.YYY.YYY.YYY
which would generate code to:
test for an IP source or destination host, in the IP header above the
link layer, of XXX.XXX.XXX.XXX;
if that test succeeds, test for an IP protocol number, in that IP
header, of 17 (UDP);
if that test succeeds, test for a UDP source or destination port, in
the UDP header above that IP header, of 2152;
if that test succeeds, test for a message type, in the GTP-U header
above that UDP header, of 0xFF (and possibly also check the version and
protocol type fields in the GTP-U header);
if that test succeeds, test for the first byte of the payload of the
GTP-U header being between 0x45 and 0x4E - the reason for that test to identify
IPv4-over-GTP-U is, to quote a comment in the Wireshark dissector for GTP:
/* this is most likely an IPv4 packet
* we can exclude 0x40 - 0x44 because the minimum header size is 20
octets
* 0x4f is excluded because PPP protocol type "IPv6 header
compression"
* with protocol field compression is more likely than a plain IPv4
packet with 60 octet header size */
if that test succeeds, test for an IP source or destination host, in
the IP header above the GTP-U header, of YYY.YYY.YYY.YYY.
> teid <value> -> only filter those gtp-u packets whose TEID is as value.
I might be tempted to implement that similarly to the way the "vlan" keyword
works - a filter of just "gtp-u" would just test for GTP-U, and a filter of
"gtp-u {teid}" would filter for a GTP-U packet with a TEID of {teid}, so that,
for example, the filter
host XXX.XXX.XXX.XXX and gtp-u 0x01010101 and host YYY.YYY.YYY.YYY
which would generate code to:
test for an IP source or destination host, in the IP header above the
link layer, of XXX.XXX.XXX.XXX;
if that test succeeds, test for an IP protocol number, in that IP
header, of 17 (UDP);
if that test succeeds, test for a UDP source or destination port, in
the UDP header above that IP header, of 2152;
if that test succeeds, test for a message type, in the GTP-U header
above that UDP header, of 0xFF (and possibly also check the version and
protocol type fields in the GTP-U header);
if that test succeeds, test for a TEID, in that GTP-U header, of
0x01010101;
if that test succeeds, test for the first byte of the payload of the
GTP-U header being between 0x45 and 0x4E;
if that test succeeds, test for an IP source or destination host, in
the IP header above the GTP-U header, of YYY.YYY.YYY.YYY.
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.
