Re: [tcpdump-workers] decode MPLS-contained packets?
--- Begin Message --- On 07/05/2020 15:39, Francois-Xavier Le Bail wrote: > On 07/05/2020 09:39, Francois-Xavier Le Bail via tcpdump-workers wrote: >>> In this *particular* case, that test is done only if the uppermost nibble >>> of the uppermost octet is 0, so that would only be the case for the source >>> address, which is less likely to be a group address than the destination >>> address. There may be other places where that heuristic dissector is used, >>> however. >> Ok. >> What if the first nibble is <> de 4, 6, 1, 0, e.g. 'f' like the first f of >> ff:ff:ff:ff:ff:ff ? > > Currently tshark don't decode if first nibble is <> de 4, 6, 1, 0: > (ARP request not seen, just "Data") > --- > MultiProtocol Label Switching Header, Label: 262145, Exp: 0, S: 1, TTL: 253 > 0100 0001 = MPLS Label: 262145 > 000. = MPLS Experimental Bits: 0 > ...1 = MPLS Bottom Of Label Stack: 1 > 1101 = MPLS TTL: 253 > Data (64 bytes) > > ff ff ff ff ff ff 00 50 79 66 68 01 08 06 00 01 ...Pyfh. > 0010 08 00 06 04 00 01 00 50 79 66 68 01 0a 48 01 42 ...Pyfh..H.B > 0020 ff ff ff ff ff ff 0a 48 01 43 00 00 00 00 00 00 ...H.C.. > 0030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 > Data: > 005079666801080600010800060400010050796668010a480142 > <80> > [Length: 64] > --- > 1 16:26:10.061638 ca:04:2c:7e:00:08 > 00:b5:df:d1:63:02, ethertype MPLS > unicast (0x8847), > length 82: MPLS (label 262145, exp 0, [S], ttl 253) > 00:50:79:66:68:01 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length > 64: Ethernet (len 6), > IPv4 (len 4), Request who-has 10.72.1.67 (ff:ff:ff:ff:ff:ff) tell 10.72.1.66, > length 50 > --- Already reported issue. Currently no fix. (https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=13306) -- Francois-Xavier --- End Message --- ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] decode MPLS-contained packets?
--- Begin Message ---
On 07/05/2020 09:39, Francois-Xavier Le Bail via tcpdump-workers wrote:
>> In this *particular* case, that test is done only if the uppermost nibble of
>> the uppermost octet is 0, so that would only be the case for the source
>> address, which is less likely to be a group address than the destination
>> address. There may be other places where that heuristic dissector is used,
>> however.
> Ok.
> What if the first nibble is <> de 4, 6, 1, 0, e.g. 'f' like the first f of
> ff:ff:ff:ff:ff:ff ?
Currently tshark don't decode if first nibble is <> de 4, 6, 1, 0:
(ARP request not seen, just "Data")
---
MultiProtocol Label Switching Header, Label: 262145, Exp: 0, S: 1, TTL: 253
0100 0001 = MPLS Label: 262145
000. = MPLS Experimental Bits: 0
...1 = MPLS Bottom Of Label Stack: 1
1101 = MPLS TTL: 253
Data (64 bytes)
ff ff ff ff ff ff 00 50 79 66 68 01 08 06 00 01 ...Pyfh.
0010 08 00 06 04 00 01 00 50 79 66 68 01 0a 48 01 42 ...Pyfh..H.B
0020 ff ff ff ff ff ff 0a 48 01 43 00 00 00 00 00 00 ...H.C..
0030 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00 00
Data:
005079666801080600010800060400010050796668010a480142
<80>
[Length: 64]
---
1 16:26:10.061638 ca:04:2c:7e:00:08 > 00:b5:df:d1:63:02, ethertype MPLS
unicast (0x8847),
length 82: MPLS (label 262145, exp 0, [S], ttl 253)
00:50:79:66:68:01 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length
64: Ethernet (len 6),
IPv4 (len 4), Request who-has 10.72.1.67 (ff:ff:ff:ff:ff:ff) tell 10.72.1.66,
length 50
---
--
Francois-Xavier
--- End Message ---
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] decode MPLS-contained packets?
--- Begin Message ---
Hi,
On Thu, May 07, 2020 at 01:05:19AM -0700, Guy Harris wrote:
> A mechanism where you could do something such as "-T tcp:1073:{protocol}"
> to force traffic to TCP port 1073 to be dissected as the specified
> protocol might be useful; in this case, we'd do something such as
> "-T mpls:{protocol}" to force *all* MPLS packets to be dissected
> as the specified protocol, and "-T mpls:{label}:{protocol}", to
> force packets with a particular label to be dissected as the specified
> protocol (which might mean you'd have to run tcpdump twice - once
> to see what the label is, and once to decode the label.
I find this to be a fairly complex solution, at least for my use case.
I know what I'm looking at ("tcpdump -s0 'label 12003'"), it's just
tcpdump not knowing what these packets are - so for these simple cases, a
"-T mplsnocweth"
"-T mplscweth"
(or whatever it's called in the end) would be sufficient. The documentation
would need updating to make clear what happens behind the scenes ("this
forces some of the dissectors to decode the packet in a particular way",
and then possibly explain for each -T value to what sort of packets it applies)
OTOH, as a long-term road map, why not :-)
gert
--
"If was one thing all people took for granted, was conviction that if you
feed honest figures into a computer, honest figures come out. Never doubted
it myself till I met a computer with a sense of humor."
Robert A. Heinlein, The Moon is a Harsh Mistress
Gert Doering - Munich, Germany g...@greenie.muc.de
--- End Message ---
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] decode MPLS-contained packets?
--- Begin Message ---
On May 5, 2020, at 1:01 PM, Francois-Xavier Le Bail via tcpdump-workers
wrote:
> Wireshark MPLS heuristic is not perfect and has been criticized but is still
> there :-) hopefully
> correctly parsing your data as well.
*No* heuristic will be perfect here.
> For tcpdump maybe a -T based approach is better?
>
> -T mpls (+ 1st nibble logic for IPv4/IPv6)
> -T ethpw
> -T ethpwnocw
That's a thought, but -T should probably get a bunch of work done on it.
It's documented as
-T type
Force packets selected by "expression" to be interpreted the
specified type.
but it has nothing to do with the filter expression - that really means "force
all packets to be interpreted [as] the specified type", because "expression"
controls which packets tcpdump sees. It doesn't *entirely* work that way, but
the places where it's checked - for example, the TCP and UDP dissectors - just
do "if somebody specified a -T flag, dissect *everything* as that protocol".
A mechanism where you could do something such as "-T tcp:1073:{protocol}" to
force traffic to TCP port 1073 to be dissected as the specified protocol might
be useful; in this case, we'd do something such as "-T mpls:{protocol}" to
force *all* MPLS packets to be dissected as the specified protocol, and "-T
mpls:{label}:{protocol}", to force packets with a particular label to be
dissected as the specified protocol (which might mean you'd have to run tcpdump
twice - once to see what the label is, and once to decode the label.
That would require a mechanism similar to Wireshark's "run this script on all
dissector files to find their registration routines and call those at run time"
to build a table of the first items in the "-T" string; once we've gone there,
we might as well use it to build a table of the {protocol} values as well, and
we could then just have a mechanism similar to Wireshark's dissector table
mechanism, replacing the big switch statements (back in the very early days,
Wireshark - still called "Ethereal" at the time - used switch statements as
well; that was replaced by a dissector table mechanism) with dissector tables,
which would mean that a new "runs atop TCP" or "runs atop UDP" dissector could
just register and the switch statement wouldn't have to be changed.
We could start out by adding an explicit list of items, just as we currently
have an explicit list of {protocol} values.--- End Message ---
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] decode MPLS-contained packets?
--- Begin Message --- Hi, On Thu, May 07, 2020 at 03:39:07AM -0400, Francois-Xavier Le Bail via tcpdump-workers wrote: > What if the first nibble is <> de 4, 6, 1, 0, e.g. 'f' like the first f of > ff:ff:ff:ff:ff:ff ? This is, as far as I understand, the primary reason why control word was added. Routers misinterpretation these packets due to MAC addresses starting with "4" or "6". gert -- "If was one thing all people took for granted, was conviction that if you feed honest figures into a computer, honest figures come out. Never doubted it myself till I met a computer with a sense of humor." Robert A. Heinlein, The Moon is a Harsh Mistress Gert Doering - Munich, Germany g...@greenie.muc.de --- End Message --- ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] decode MPLS-contained packets?
--- Begin Message --- On 07/05/2020 09:17, Guy Harris wrote: >> On 07/05/2020 08:53, Guy Harris via tcpdump-workers wrote: >> >>> "Looks like a valid Ethernet address" is defined as "the first three octets >>> appear in Wireshark's file giving manufacturer names for OUIs". >> What if the destination address is ff:ff:ff:ff:ff:ff (broadcast) for e.g. >> ARP request ? >> Or some multicast address ? > In this *particular* case, that test is done only if the uppermost nibble of > the uppermost octet is 0, so that would only be the case for the source > address, which is less likely to be a group address than the destination > address. There may be other places where that heuristic dissector is used, > however. Ok. What if the first nibble is <> de 4, 6, 1, 0, e.g. 'f' like the first f of ff:ff:ff:ff:ff:ff ? -- Francois-Xavier --- End Message --- ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] decode MPLS-contained packets?
--- Begin Message ---
On 07/05/2020 09:13, Gert Doering wrote:
> Due to missing {}, the "p += 4" will always be executed, skipping the
> control word twice if "-v" is set.
Yes, already corrected, not the good patch ...
--
Francois-Xavier
--- End Message ---
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] decode MPLS-contained packets?
--- Begin Message --- On May 7, 2020, at 12:04 AM, Francois-Xavier Le Bail via tcpdump-workers wrote: > On 07/05/2020 08:53, Guy Harris via tcpdump-workers wrote: > >> "Looks like a valid Ethernet address" is defined as "the first three octets >> appear in Wireshark's file giving manufacturer names for OUIs". > What if the destination address is ff:ff:ff:ff:ff:ff (broadcast) for e.g. ARP > request ? > Or some multicast address ? In this *particular* case, that test is done only if the uppermost nibble of the uppermost octet is 0, so that would only be the case for the source address, which is less likely to be a group address than the destination address. There may be other places where that heuristic dissector is used, however.--- End Message --- ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] decode MPLS-contained packets?
--- Begin Message --- Hi, On Wed, May 06, 2020 at 11:54:55PM -0700, Guy Harris wrote: > OK, so what *shark's MPLS dissector does is: [..] > "Looks like a valid Ethernet address" is defined as "the first three octets > appear in Wireshark's file giving manufacturer names for OUIs". Tcpdump > *currently* doesn't have such a file. So, how do we/you want to handle this in tcpdump then? "-T mplsnocw" for "mpls, ethernet, no control word" and "0 means control word", as proposed by Francois-Xavier? (Of course this would need a man page patch as well :) ) gert -- "If was one thing all people took for granted, was conviction that if you feed honest figures into a computer, honest figures come out. Never doubted it myself till I met a computer with a sense of humor." Robert A. Heinlein, The Moon is a Harsh Mistress Gert Doering - Munich, Germany g...@greenie.muc.de --- End Message --- ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] decode MPLS-contained packets?
--- Begin Message ---
Hi,
On Thu, May 07, 2020 at 08:20:40AM +0200, Francois-Xavier Le Bail wrote:
> Proposed patch attached.
>
> With new '-T mplsethnocw' option to force 'Ethernet without Control Word'
> decode.
> (from Francesco Fondelli comment)
There's one bug here:
> + case 0x00: /* RFC 4448 PW Ethernet Control Word */
> + if (ndo->ndo_vflag) {
> + ND_PRINT("\n\tPW Ethernet Control
> Word");
> + p += 2;
> + ND_PRINT(", Sequence Number %u",
> GET_BE_U_2(p));
> + p += 2;
> + } else
> + ND_PRINT(" PWETHCW");
> + p += 4;
> + length -= 4;
Due to missing {}, the "p += 4" will always be executed, skipping the
control word twice if "-v" is set.
I'd totally leave off printing the "PWETHCW", though. If it's decoding the
payload, that is all information I need - if I want more, I can always
do "-v".
So the code would become:
+ case 0x00: /* RFC 4448 PW Ethernet Control Word */
+ if (ndo->ndo_vflag) {
+ ND_PRINT("\n\tPW Ethernet Control
Word");
+ ND_PRINT(", Sequence Number %u",
GET_BE_U_2(p+2));
+ }
+ p += 4;
+ length -= 4;
+ pt = PT_ETHER;
+ break;
There's something else:
+ case PT_ETHER:
+ ether_print(ndo, p, length, ND_BYTES_AVAILABLE_AFTER(bp), NULL,
NULL);
This might actually be a bug in my original patch, ND_BYTES_AVAILABLE_AFTER()
should possibly call "(p)", not "(bp)". Copy-pasted that line from
print-gre.c, and only changed the first "bp" to "p.
gert
--
"If was one thing all people took for granted, was conviction that if you
feed honest figures into a computer, honest figures come out. Never doubted
it myself till I met a computer with a sense of humor."
Robert A. Heinlein, The Moon is a Harsh Mistress
Gert Doering - Munich, Germany g...@greenie.muc.de
--- End Message ---
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] decode MPLS-contained packets?
--- Begin Message --- On May 5, 2020, at 11:36 AM, Gert Doering via tcpdump-workers wrote: > So, given that the first 16 bits are "4 bit always 0, and 12 bits > reserved-must-be-set-to-0", using these as heuristics for "if two 0-bytes > are following the MPLS headers, it's a control word, so we skip 4 bytes > and the rest is a regular Ethernet packet" should work. Wireshark looks only at the uppermost nibble, as per my earlier mail, probably to make it "future-proof" against the reserved bits being used later. However, it also has the "do the upper three octets, and the three octets thee octets after that, look like OUIs" test. (Note that 00:00:0C is Cisco, so "two 0 bytes following the MPLS headers" isn't *guaranteed* to work as a way of identifying control words. Wireshark's manuf file also shows 00:00:17 as being Oracle, 00:00:0F as being NeXT so that may now be used by Apple if NeXT didn't use it up, and 00:00:F0 is Samsung Electronics, so there might be others in that range.)--- End Message --- ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] decode MPLS-contained packets?
--- Begin Message --- On 07/05/2020 08:53, Guy Harris via tcpdump-workers wrote: > "Looks like a valid Ethernet address" is defined as "the first three octets > appear in Wireshark's file giving manufacturer names for OUIs". What if the destination address is ff:ff:ff:ff:ff:ff (broadcast) for e.g. ARP request ? Or some multicast address ? -- Francois-Xavier --- End Message --- ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] decode MPLS-contained packets?
--- Begin Message --- On May 5, 2020, at 3:15 AM, Gert Doering via tcpdump-workers wrote: > tcpdump's print-mpls.c already does "if I know what upper-layer protocol > is in here, I call the appropriate printer". But there is no well-defined > type field, so it fails for my packets, and and falls back to "hexdump" > (good enough). OK, so what *shark's MPLS dissector does is: 1) see whether the label indicates the next protocol - but very few label values are registered in the dissector table for that, so that's *not* what's being used for your dissector (most dissectors just register for the "decode as" feature, so the user can say "decode this label as..."); 2) if that fails, "use the 1st nibble logic (see BCP 4928, RFC 4385 and 5586)". The "1st nibble logic" is: if the upper nibble of the first octet is 4, it's IPv4'; if the upper nibble of the first octet is 6, it's IPv6; if the upper nibble of the first octet is 1, dissect it as "PW Associated Channel Header Management Communication Network (MCN) dissection as per RFC 5718" (with a comment that "this could be from an Ethernet pseudo-wire without a control word, with the MAC address's first nibble being 1."; if the upper nibble of the first octet is 0, then "If this is an Ethernet pseudo-wire, this could either be Ethernet without a control word and with the first nibble of the destination MAC address being 0 or it could be Ethernet with a control word. Let the "pw_eth_heuristic" dissector try to figure it out.". The heuristics that dissector does are if the first 12 bytes in the payload look like two valid ethernet addresses", treat it as Ethernet with no control word; otherwise, if the first octet is 0, treat it as Ethernet *with* a control word; otherwise, treat it as Ethernet without a control word. "Looks like a valid Ethernet address" is defined as "the first three octets appear in Wireshark's file giving manufacturer names for OUIs". Tcpdump *currently* doesn't have such a file.--- End Message --- ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] decode MPLS-contained packets?
--- Begin Message ---
On 05/05/2020 21:44, Gert Doering wrote:
> Hi,
>
> On Tue, May 05, 2020 at 08:47:04PM +0200, Francois-Xavier Le Bail wrote:
>>> So, given that the first 16 bits are "4 bit always 0, and 12 bits
>>> reserved-must-be-set-to-0", using these as heuristics for "if two 0-bytes
>>> are following the MPLS headers, it's a control word, so we skip 4 bytes
>>> and the rest is a regular Ethernet packet" should work.
>>
>> We should print "PW Ethernet Control Word" and the "Sequence Number", 2 last
>> 2 octets of the 4.
>> Like:
>> PW Ethernet Control Word, Sequence Number xxx
>
> I think we should only print this if "-v" is given. Most of the time,
> both control word and sequence number are of little interest.
>
> I really like tcpdump's very compact "only the most relevant info" output
> format (by default).
Proposed patch attached.
With new '-T mplsethnocw' option to force 'Ethernet without Control Word'
decode.
(from Francesco Fondelli comment)
--
Francois-Xavier
diff --git a/netdissect.h b/netdissect.h
index 65a0d987..cd76d654 100644
--- a/netdissect.h
+++ b/netdissect.h
@@ -294,6 +294,7 @@ extern void nd_pop_all_packet_info(netdissect_options *);
#define PT_PTP 18 /* PTP */
#define PT_SOMEIP 19 /* Autosar SOME/IP Protocol */
#define PT_DOMAIN 20 /* Domain Name System (DNS) */
+#define PT_MPLSETHNOCW 21 /* MPLS PW Ethernet without Control Word */
#ifndef min
#define min(a,b) ((a)>(b)?(b):(a))
diff --git a/print-mpls.c b/print-mpls.c
index 62b79957..0c0ab974 100644
--- a/print-mpls.c
+++ b/print-mpls.c
@@ -50,7 +50,8 @@ enum mpls_packet_type {
PT_UNKNOWN,
PT_IPV4,
PT_IPV6,
- PT_OSI
+ PT_OSI,
+ PT_ETHER
};
/*
@@ -133,52 +134,68 @@ mpls_print(netdissect_options *ndo, const u_char *bp,
u_int length)
/* nothing to print */
return;
}
- switch(GET_U_1(p)) {
-
- case 0x45:
- case 0x46:
- case 0x47:
- case 0x48:
- case 0x49:
- case 0x4a:
- case 0x4b:
- case 0x4c:
- case 0x4d:
- case 0x4e:
- case 0x4f:
- pt = PT_IPV4;
- break;
-
- case 0x60:
- case 0x61:
- case 0x62:
- case 0x63:
- case 0x64:
- case 0x65:
- case 0x66:
- case 0x67:
- case 0x68:
- case 0x69:
- case 0x6a:
- case 0x6b:
- case 0x6c:
- case 0x6d:
- case 0x6e:
- case 0x6f:
- pt = PT_IPV6;
- break;
-
- case 0x81:
- case 0x82:
- case 0x83:
- pt = PT_OSI;
- break;
-
- default:
- /* ok bail out - we did not figure out what it is*/
- break;
+ if (ndo->ndo_packettype == PT_MPLSETHNOCW)
+ pt = PT_ETHER;
+ else
+ switch(GET_U_1(p)) {
+
+ case 0x45:
+ case 0x46:
+ case 0x47:
+ case 0x48:
+ case 0x49:
+ case 0x4a:
+ case 0x4b:
+ case 0x4c:
+ case 0x4d:
+ case 0x4e:
+ case 0x4f:
+ pt = PT_IPV4;
+ break;
+
+ case 0x60:
+ case 0x61:
+ case 0x62:
+ case 0x63:
+ case 0x64:
+ case 0x65:
+ case 0x66:
+ case 0x67:
+ case 0x68:
+ case 0x69:
+ case 0x6a:
+ case 0x6b:
+ case 0x6c:
+ case 0x6d:
+ case 0x6e:
+ case 0x6f:
+ pt = PT_IPV6;
+ break;
+
+ case 0x81:
+ case 0x82:
+ case 0x83:
+ pt = PT_OSI;
+ break;
+
+ case 0x00: /* RFC 4448 PW Ethernet Control Word */
+ if (ndo->ndo_vflag) {
+ ND_PRINT("\n\tPW Ethernet Control
Word");
+ p += 2;
+ ND_PRINT(", Sequence Number %u",
GET_BE_U_2(p));
+
Re: [tcpdump-workers] decode MPLS-contained packets?
--- Begin Message --- On 05/05/2020 21:44, Gert Doering wrote: >> We should print "PW Ethernet Control Word" and the "Sequence Number", 2 last >> 2 octets of the 4. >> Like: >> PW Ethernet Control Word, Sequence Number xxx > I think we should only print this if "-v" is given. Most of the time, > both control word and sequence number are of little interest. > > I really like tcpdump's very compact "only the most relevant info" output > format (by default). OK for "-v" only print. Other information from Francesco Fondelli: --- it is a bit more complicated than that, look for /* * No, there isn't, so use the 1st nibble logic (see BCP 4928, * RFC 4385 and 5586). */ in https://code.wireshark.org/review/gitweb?p=wireshark.git;a=blob;f=epan/dissectors/packet-mpls.c;h=4ecb10d1216077b92e6d4ca2520340cf053414f4;hb=HEAD and also the PW ETH heuristic in looks_like_plain_eth https://code.wireshark.org/review/gitweb?p=wireshark.git;a=blob;f=epan/dissectors/packet-pw-eth.c;h=aec7b662d38ddb36514ed3c213df47ad53ad610b;hb=HEAD Wireshark MPLS heuristic is not perfect and has been criticized but is still there :-) hopefully correctly parsing your data as well. For tcpdump maybe a -T based approach is better? -T mpls (+ 1st nibble logic for IPv4/IPv6) -T ethpw -T ethpwnocw ... --- Probably some more work to do... And probably linked to https://tools.ietf.org/html/rfc8469. -- Francois-Xavier --- End Message --- ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] decode MPLS-contained packets?
--- Begin Message --- Hi, On Tue, May 05, 2020 at 08:47:04PM +0200, Francois-Xavier Le Bail wrote: > > So, given that the first 16 bits are "4 bit always 0, and 12 bits > > reserved-must-be-set-to-0", using these as heuristics for "if two 0-bytes > > are following the MPLS headers, it's a control word, so we skip 4 bytes > > and the rest is a regular Ethernet packet" should work. > > We should print "PW Ethernet Control Word" and the "Sequence Number", 2 last > 2 octets of the 4. > Like: > PW Ethernet Control Word, Sequence Number xxx I think we should only print this if "-v" is given. Most of the time, both control word and sequence number are of little interest. I really like tcpdump's very compact "only the most relevant info" output format (by default). gert -- "If was one thing all people took for granted, was conviction that if you feed honest figures into a computer, honest figures come out. Never doubted it myself till I met a computer with a sense of humor." Robert A. Heinlein, The Moon is a Harsh Mistress Gert Doering - Munich, Germany g...@greenie.muc.de --- End Message --- ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] decode MPLS-contained packets?
--- Begin Message ---
On 05/05/2020 20:45, Francois-Xavier Le Bail via tcpdump-workers wrote:
> We should print "PW Ethernet Control Word" and the "Sequence Number", 2 last
> 2 octets of the 4.
> Like:
> PW Ethernet Control Word, Sequence Number xxx
Attached patch based on yours.
--
Francois-Xavier
diff --git a/print-mpls.c b/print-mpls.c
index 62b79957..e375c84a 100644
--- a/print-mpls.c
+++ b/print-mpls.c
@@ -50,7 +50,8 @@ enum mpls_packet_type {
PT_UNKNOWN,
PT_IPV4,
PT_IPV6,
- PT_OSI
+ PT_OSI,
+ PT_ETHER
};
/*
@@ -174,6 +175,15 @@ mpls_print(netdissect_options *ndo, const u_char *bp,
u_int length)
pt = PT_OSI;
break;
+ case 0x00: /* RFC 4448 PW Ethernet Control Word */
+ ND_PRINT("\n\tPW Ethernet Control Word");
+ p += 2;
+ ND_PRINT(", Sequence Number %u", GET_BE_U_2(p));
+ p += 2;
+ length -= 4;
+ pt = PT_ETHER;
+ break;
+
default:
/* ok bail out - we did not figure out what it is*/
break;
@@ -203,6 +213,10 @@ mpls_print(netdissect_options *ndo, const u_char *bp,
u_int length)
isoclns_print(ndo, p, length);
break;
+ case PT_ETHER:
+ ether_print(ndo, p, length, ND_BYTES_AVAILABLE_AFTER(bp), NULL,
NULL);
+ break;
+
default:
break;
}
--- End Message ---
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] decode MPLS-contained packets?
--- Begin Message ---
On 05/05/2020 20:37, Gert Doering wrote:
> Hi,
>
> On Tue, May 05, 2020 at 07:28:28PM +0200, Francois-Xavier Le Bail wrote:
>> On 05/05/2020 12:15, Gert Doering via tcpdump-workers wrote:
>>> In my case, there is an MPLS control word before the ethernet header
>>> (" "), and if I skip that and just clear "ethernet in here", I
>>> get nicely printed packets...
>>
>> It seems it is like:
>> https://tools.ietf.org/html/rfc4448#section-4.6
>>
>> Can you confirm?
>
> This very much looks like it, indeed.
>
> So, given that the first 16 bits are "4 bit always 0, and 12 bits
> reserved-must-be-set-to-0", using these as heuristics for "if two 0-bytes
> are following the MPLS headers, it's a control word, so we skip 4 bytes
> and the rest is a regular Ethernet packet" should work.
We should print "PW Ethernet Control Word" and the "Sequence Number", 2 last 2
octets of the 4.
Like:
PW Ethernet Control Word, Sequence Number xxx
[...]
18:31:01.221109 00:22:55:93:74:80 > a8:0c:0d:56:50:3b, ethertype MPLS unicast
(0x8847), length 140:
MPLS (label 24002, exp 0, [S], ttl 253)
PW Ethernet Control Word, Sequence Number 0
00:c1:64:65:92:0f > 3c:fd:fe:bd:78:35, ethertype IPv4 (0x0800)
[...]
--
Francois-Xavier
--- End Message ---
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] decode MPLS-contained packets?
--- Begin Message ---
Hi,
On Tue, May 05, 2020 at 07:28:28PM +0200, Francois-Xavier Le Bail wrote:
> On 05/05/2020 12:15, Gert Doering via tcpdump-workers wrote:
> > In my case, there is an MPLS control word before the ethernet header
> > (" "), and if I skip that and just clear "ethernet in here", I
> > get nicely printed packets...
>
> It seems it is like:
> https://tools.ietf.org/html/rfc4448#section-4.6
>
> Can you confirm?
This very much looks like it, indeed.
So, given that the first 16 bits are "4 bit always 0, and 12 bits
reserved-must-be-set-to-0", using these as heuristics for "if two 0-bytes
are following the MPLS headers, it's a control word, so we skip 4 bytes
and the rest is a regular Ethernet packet" should work.
Thanks for digging up that reference :)
gert
--
"If was one thing all people took for granted, was conviction that if you
feed honest figures into a computer, honest figures come out. Never doubted
it myself till I met a computer with a sense of humor."
Robert A. Heinlein, The Moon is a Harsh Mistress
Gert Doering - Munich, Germany g...@greenie.muc.de
--- End Message ---
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] decode MPLS-contained packets?
--- Begin Message --- Hi, On Tue, May 05, 2020 at 07:24:37PM +0200, Francois-Xavier Le Bail wrote: > Ok, it had DOS line ending format ... Not when I sent it, but who knows which mailer mangled it in surprising and fascinating ways on the path... gert -- "If was one thing all people took for granted, was conviction that if you feed honest figures into a computer, honest figures come out. Never doubted it myself till I met a computer with a sense of humor." Robert A. Heinlein, The Moon is a Harsh Mistress Gert Doering - Munich, Germany g...@greenie.muc.de --- End Message --- ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] decode MPLS-contained packets?
--- Begin Message ---
On 05/05/2020 12:15, Gert Doering via tcpdump-workers wrote:
> In my case, there is an MPLS control word before the ethernet header
> (" "), and if I skip that and just clear "ethernet in here", I
> get nicely printed packets...
It seems it is like:
https://tools.ietf.org/html/rfc4448#section-4.6
Can you confirm?
--
Francois-Xavier
--- End Message ---
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] decode MPLS-contained packets?
--- Begin Message --- On 05/05/2020 19:17, Gert Doering wrote: > Hi, > > On Tue, May 05, 2020 at 06:45:27PM +0200, Francois-Xavier Le Bail wrote: >>> Attached as well. Not very smart yet, just does "what I need". >> >> Thanks, >> >> Patch for which tcpdump version? > > github checkout, it identifies itself as > > tcpdump version 4.10.0-PRE-GIT > > (git clone https://github.com/the-tcpdump-group/tcpdump.git) Ok, it had DOS line ending format ... --- End Message --- ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] decode MPLS-contained packets?
--- Begin Message --- Hi, On Tue, May 05, 2020 at 06:45:27PM +0200, Francois-Xavier Le Bail wrote: > > Attached as well. Not very smart yet, just does "what I need". > > Thanks, > > Patch for which tcpdump version? github checkout, it identifies itself as tcpdump version 4.10.0-PRE-GIT (git clone https://github.com/the-tcpdump-group/tcpdump.git) gert -- "If was one thing all people took for granted, was conviction that if you feed honest figures into a computer, honest figures come out. Never doubted it myself till I met a computer with a sense of humor." Robert A. Heinlein, The Moon is a Harsh Mistress Gert Doering - Munich, Germany g...@greenie.muc.de --- End Message --- ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] decode MPLS-contained packets?
--- Begin Message --- On 05/05/2020 18:34, Gert Doering wrote: > Hi, > > On Tue, May 05, 2020 at 04:45:04PM +0200, Francois-Xavier Le Bail wrote: >> On 05/05/2020 12:15, Gert Doering via tcpdump-workers wrote: >>> 12:11:46.116238 MPLS (label 105, exp 0, ttl 254) (label 24003, exp 0, [S], >>> ttl 254) IP 10.27.99.2 > 10.27.99.34: ICMP echo request, id 49866, seq >>> 5160, length 84 >>> 12:11:46.117107 MPLS (label 24002, exp 0, [S], ttl 253) IP 10.27.99.34 > >>> 10.27.99.2: ICMP echo reply, id 49866, seq 5160, length 84 >>> >>> >>> So, for my debugging purposes, I have what I need now. >> >> [...] > >> And the patch you apply ? > > Attached as well. Not very smart yet, just does "what I need". Thanks, Patch for which tcpdump version? -- Francois-Xavier --- End Message --- ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] decode MPLS-contained packets?
--- Begin Message --- Hi, On Tue, May 05, 2020 at 04:45:04PM +0200, Francois-Xavier Le Bail wrote: > On 05/05/2020 12:15, Gert Doering via tcpdump-workers wrote: > > 12:11:46.116238 MPLS (label 105, exp 0, ttl 254) (label 24003, exp 0, [S], > > ttl 254) IP 10.27.99.2 > 10.27.99.34: ICMP echo request, id 49866, seq > > 5160, length 84 > > 12:11:46.117107 MPLS (label 24002, exp 0, [S], ttl 253) IP 10.27.99.34 > > > 10.27.99.2: ICMP echo reply, id 49866, seq 5160, length 84 > > > > > > So, for my debugging purposes, I have what I need now. > > Could you send a pcap file with the ICMP echo request/reply test ? Of course. Attached. This is EVPN/MPLS between two Cisco ASRs (in case it makes a difference). One direction has only a single label because the final router is on the link I'm sniffing, the other direction has two labels. Inside are a few machines pinging around plus one or two ARPs. (The .cap file is very small, just 4 kbyte, so I dare send it to the list as well) > And the patch you apply ? Attached as well. Not very smart yet, just does "what I need". gert -- "If was one thing all people took for granted, was conviction that if you feed honest figures into a computer, honest figures come out. Never doubted it myself till I met a computer with a sense of humor." Robert A. Heinlein, The Moon is a Harsh Mistress Gert Doering - Munich, Germany g...@greenie.muc.de --- End Message --- ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] decode MPLS-contained packets?
--- Begin Message --- On 05/05/2020 12:15, Gert Doering via tcpdump-workers wrote: > 12:11:46.116238 MPLS (label 105, exp 0, ttl 254) (label 24003, exp 0, [S], > ttl 254) IP 10.27.99.2 > 10.27.99.34: ICMP echo request, id 49866, seq 5160, > length 84 > 12:11:46.117107 MPLS (label 24002, exp 0, [S], ttl 253) IP 10.27.99.34 > > 10.27.99.2: ICMP echo reply, id 49866, seq 5160, length 84 > > > So, for my debugging purposes, I have what I need now. Could you send a pcap file with the ICMP echo request/reply test ? And the patch you apply ? -- Francois-Xavier --- End Message --- ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] decode MPLS-contained packets?
--- Begin Message ---
Hi,
On Tue, May 05, 2020 at 05:50:40AM -0400, Gert Doering via tcpdump-workers
wrote:
> Now, the two questions:
>
> - is there a switch I'm missing to decode packets-in-MPLS?
> (like, "packets in GRE" get decoded already)
> - if not, is someone already working on it? I might just hack
>it in, if not...
O-kay. That turned out to be easier and harder than I thought, at the
same time.
tcpdump's print-mpls.c already does "if I know what upper-layer protocol
is in here, I call the appropriate printer". But there is no well-defined
type field, so it fails for my packets, and and falls back to "hexdump"
(good enough).
In my case, there is an MPLS control word before the ethernet header
(" "), and if I skip that and just clear "ethernet in here", I
get nicely printed packets...
12:11:46.116238 MPLS (label 105, exp 0, ttl 254) (label 24003, exp 0, [S], ttl
254) IP 10.27.99.2 > 10.27.99.34: ICMP echo request, id 49866, seq 5160, length
84
12:11:46.117107 MPLS (label 24002, exp 0, [S], ttl 253) IP 10.27.99.34 >
10.27.99.2: ICMP echo reply, id 49866, seq 5160, length 84
So, for my debugging purposes, I have what I need now.
For "contribute back to tcpdump", this is unsatisfactory, as I'm just
guessing what is in there - we already have guesswork, but that isn't
covering "0" (and being a control word, it could be anything).
How does wireshark/tshark approach this?
Would it make sense to add a flag option "hey, MPLS dissector, this is
ethernet + control-world, always"?
gert
--
"If was one thing all people took for granted, was conviction that if you
feed honest figures into a computer, honest figures come out. Never doubted
it myself till I met a computer with a sense of humor."
Robert A. Heinlein, The Moon is a Harsh Mistress
Gert Doering - Munich, Germany g...@greenie.muc.de
--- End Message ---
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
