[tcpdump-workers] verbose decoding without assigned port number
Hello, list. There are network protocols that have an assigned port number, and there are other that don't or are commonly used on non-assigned ports, such as HTTP on port 8080. Looking at function tcp_print() in file print-tcp.c, it is clear how the former are handled, but is there any assumed way to handle the latter? I am considering adding a ZeroMQ decoder to tcpdump, to be particular. -- Denis Ovsienko ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] verbose decoding without assigned port number
> "Denis" == Denis Ovsienko writes: Denis> There are network protocols that have an assigned port Denis> number, and there are other that don't or are commonly used Denis> on non-assigned ports, such as HTTP on port 8080. Looking at Denis> function tcp_print() in file print-tcp.c, it is clear how the Denis> former are handled, but is there any assumed way to handle Denis> the latter? I am considering adding a ZeroMQ decoder to Denis> tcpdump, to be particular. Currently the -T option is the only resort at the IP layer and UDP layer. It could apply to TCP too, perhaps. It would be nice to have a way for each ULP decoders to register their name so that it's not so switch() stmt based, and then to have a file which can be provided to map multiple ports at the same time. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works| network architect [ ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[ ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] verbose decoding without assigned port number
> Currently the -T option is the only resort at the IP layer and UDP layer. > It could apply to TCP too, perhaps. Thanks, that seems to be OK to start with. > > It would be nice to have a way for each ULP decoders to register their > name so that it's not so switch() stmt based, and then to have a file > which can be provided to map multiple ports at the same time. I'll look if that can be done quickly. -- Denis Ovsienko ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
[tcpdump-workers] "not vlan" filter expression broken catastrophically!
hello folks :
As you guys have been aware, I am hacking libpcap for a while. Me and
Bill noticed something seriously broken for any filter expression that
has a "not vlan" in it. For example, take a look at the filter code
generated by libpcap with an expression like "not vlan and tcp port
80" :
BpfExpression '(not vlan and tcp port 80)'
{ 0x28, 0, 0, 0x000c }, //(000) ldh [12]
{ 0x15, 19, 0, 0x8100 }, //(001) jeq #0x8100 jt 21 jf 2
{ 0x28, 0, 0, 0x0010 }, //(002) ldh [16]
{ 0x15, 0, 6, 0x86dd }, //(003) jeq #0x86dd jt 4 jf 10
{ 0x30, 0, 0, 0x0018 }, //(004) ldb [24]
{ 0x15, 0, 15, 0x0006 }, //(005) jeq #0x6jt 6 jf 21
{ 0x28, 0, 0, 0x003a }, //(006) ldh [58]
{ 0x15, 12, 0, 0x0050 }, //(007) jeq #0x50 jt 20 jf 8
{ 0x28, 0, 0, 0x003c }, //(008) ldh [60]
{ 0x15, 10, 11, 0x0050 }, //(009) jeq #0x50 jt 20 jf 21
{ 0x15, 0, 10, 0x0800 }, //(010) jeq #0x800 jt 11 jf 21
{ 0x30, 0, 0, 0x001b }, //(011) ldb [27]
{ 0x15, 0, 8, 0x0006 }, //(012) jeq #0x6jt 13 jf 21
{ 0x28, 0, 0, 0x0018 }, //(013) ldh [24]
{ 0x45, 6, 0, 0x1fff }, //(014) jset #0x1fff jt 21 jf 15
{ 0xb1, 0, 0, 0x0012 }, //(015) ldxb 4*([18]&0xf)
{ 0x48, 0, 0, 0x0012 }, //(016) ldh [x + 18]
{ 0x15, 2, 0, 0x0050 }, //(017) jeq #0x50 jt 20 jf 18
{ 0x48, 0, 0, 0x0014 }, //(018) ldh [x + 20]
{ 0x15, 0, 1, 0x0050 }, //(019) jeq #0x50 jt 20 jf 21
{ 0x6, 0, 0, 0x }, //(020) ret #65535
{ 0x6, 0, 0, 0x }, //(021) ret #0
As you can see, it loads offset 12 (ethertype). For vlan packets, it
jumps to #21 and returns false right away. However, for packets that
are not vlan tagged, it goes to #2 which loads offset 16 in the
packet. Notice that this is wrong! The offsets should be incremented
by 4 only for vlan tagged packets and not for non-vlan packets. The
problem is that in gencode.c, the off_linktype increments by 4
unconditionally whether or not the packet actually contains a vlan
tag. We do not want to increment this offset if "not vlan" is true. So
the above filter code is generated wrong.
I just wanted to point this out to folks who wishes to dig in and fix
it. I do not have time right now to think of a proper solution. It
would seem using unconditional increments of offsets like off_linktype
below the parser is not going to work. How do you know if the parser
is going to take your code generated from the "vlan" expression and
just negate it? Or may be we can hack another rule in grammar.y. I
don't know.
cheers,
ani
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] "not vlan" filter expression broken catastrophically!
To be totally honest, I think the whole way in which vlans are managed in the
filters is quite nonsense. The underlying problem is that normally a BPF filter
is an "or" or "and" combination of disjoint filters, so if I write "filterA" or
"filterB" I assume that the two filters are disjoints, so
"filterA or filterB" should be equivalent to "filterB or filterA"
This is not true when using the "vlan" keyword. Vlan sticks globally and
increments the offset of the L3 header unconditionally of two bytes, no turning
back.
For example "ip or vlan 14" is different than "vlan 14 or ip"
Have a nice day
GV
-Original Message-
From: tcpdump-workers-boun...@lists.tcpdump.org
[mailto:tcpdump-workers-boun...@lists.tcpdump.org] On Behalf Of Ani Sinha
Sent: Thursday, January 31, 2013 3:42 PM
To: tcpdump-workers@lists.tcpdump.org
Cc: Bill Fenner; Michael Richardson; Francesco Ruggeri
Subject: [tcpdump-workers] "not vlan" filter expression broken catastrophically!
hello folks :
As you guys have been aware, I am hacking libpcap for a while. Me and Bill
noticed something seriously broken for any filter expression that has a "not
vlan" in it. For example, take a look at the filter code generated by libpcap
with an expression like "not vlan and tcp port 80" :
BpfExpression '(not vlan and tcp port 80)'
{ 0x28, 0, 0, 0x000c }, //(000) ldh [12]
{ 0x15, 19, 0, 0x8100 }, //(001) jeq #0x8100 jt 21 jf 2
{ 0x28, 0, 0, 0x0010 }, //(002) ldh [16]
{ 0x15, 0, 6, 0x86dd }, //(003) jeq #0x86dd jt 4 jf 10
{ 0x30, 0, 0, 0x0018 }, //(004) ldb [24]
{ 0x15, 0, 15, 0x0006 }, //(005) jeq #0x6jt 6 jf 21
{ 0x28, 0, 0, 0x003a }, //(006) ldh [58]
{ 0x15, 12, 0, 0x0050 }, //(007) jeq #0x50 jt 20 jf 8
{ 0x28, 0, 0, 0x003c }, //(008) ldh [60]
{ 0x15, 10, 11, 0x0050 }, //(009) jeq #0x50 jt 20 jf 21
{ 0x15, 0, 10, 0x0800 }, //(010) jeq #0x800 jt 11 jf 21
{ 0x30, 0, 0, 0x001b }, //(011) ldb [27]
{ 0x15, 0, 8, 0x0006 }, //(012) jeq #0x6jt 13 jf 21
{ 0x28, 0, 0, 0x0018 }, //(013) ldh [24]
{ 0x45, 6, 0, 0x1fff }, //(014) jset #0x1fff jt 21 jf 15
{ 0xb1, 0, 0, 0x0012 }, //(015) ldxb 4*([18]&0xf)
{ 0x48, 0, 0, 0x0012 }, //(016) ldh [x + 18]
{ 0x15, 2, 0, 0x0050 }, //(017) jeq #0x50 jt 20 jf 18
{ 0x48, 0, 0, 0x0014 }, //(018) ldh [x + 20]
{ 0x15, 0, 1, 0x0050 }, //(019) jeq #0x50 jt 20 jf 21
{ 0x6, 0, 0, 0x }, //(020) ret #65535
{ 0x6, 0, 0, 0x }, //(021) ret #0
As you can see, it loads offset 12 (ethertype). For vlan packets, it jumps to
#21 and returns false right away. However, for packets that are not vlan
tagged, it goes to #2 which loads offset 16 in the packet. Notice that this is
wrong! The offsets should be incremented by 4 only for vlan tagged packets and
not for non-vlan packets. The problem is that in gencode.c, the off_linktype
increments by 4 unconditionally whether or not the packet actually contains a
vlan tag. We do not want to increment this offset if "not vlan" is true. So the
above filter code is generated wrong.
I just wanted to point this out to folks who wishes to dig in and fix it. I do
not have time right now to think of a proper solution. It would seem using
unconditional increments of offsets like off_linktype below the parser is not
going to work. How do you know if the parser is going to take your code
generated from the "vlan" expression and just negate it? Or may be we can hack
another rule in grammar.y. I don't know.
cheers,
ani
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
