in wireshark version 1.x the following script works without problems:
how should we modify the call to
|
I think you have to try your luck with pw_eth_heuristic instead.
the reason why we are forced to write own lua-scripts to begin with is that the heuristic for mpls is probably limited to the case of ipv4 frames and does not recognize all our embedded ipv6-frames correctly. so currently we would be limited to use wireshark 1.x together with lua-scripts that explicitely use the otherwise we would humbly ask you - the wireshark-gurus - to extend the heuristic to include cases where the mpls payload consists of ipv6-frames ...
(05 Jan '17, 11:12)
x42
x42, Open a bug with your pcap file
(05 Jan '17, 12:27)
Alexis La Go...
thanks ... bug has been reported https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=13295
(05 Jan '17, 14:51)
x42
It already does take IPv6 into consideration, according to BCP 4928, RFC 4385 and RFC 4448. I'll go and have a look at the sample capture to see what it does do.
(05 Jan '17, 23:39)
Jaap ♦
you are absolutely right in this point :-) please also note the following bug which shows another case of mpls misinterpretation: https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=13301 seemingly mpls heuristic is very tricky indeed ...
(06 Jan '17, 08:48)
x42
sometime along the way lines like
were removed from epan/dissectors/packet-pw-eth.c any strong reasons for doing so ? maybe we could simply get them back again ?
(06 Jan '17, 15:02)
x42
it would seem that the reason for removing many namely:
could be arguable. the important and regrettable side-effect thereof is that we loose the ability to use these dissectors in user-defined lua-scripts and implement or experiment with different mpls-heuristics ? i would therefore suggest, that all mpls-related
(07 Jan '17, 05:12)
x42
Can't look ut up at the moment but do we have a function find protocol by filter name? Or somthing similar.
(07 Jan '17, 07:44)
Anders ♦
please also consider the following argument as to why the mpls-dissectors like e.g. " the reason why mpls-heuristics in wireshark (or other sniffers) has fundamental problems decoding the mpls-payload correctly, come from the simple fact that - as you probably all know very well - the mpls-header does not caontain any "type-field" which would define what kind of "protocol-over-mpls" will follow in the payload. "protocol" might be "ethernet" (pw with or without cw) but also "ipv4" or "ipv6" or maybe even something completely different like e.g. "fabricpath" ;-) wireshark could attempt to analyze different length-fields, checksums or god knows which other parameters and fields from all potential "protocols" in order to perform a successful identification. when, however, some of these length-fields, checksums etc are corrupt or errornous, then the poor heuristic would have no earthly possibility to determine which "protocol" is being transported over mpls ... so probably the only practical solution to be able to perform a successful dissection of a "protocol" in the presence of corrupt and/or errournous protocol-fields would be to have the knowledge of the "protocol" beforehand - for instance throgh the gui-function 'decode as ...' or through a lua-script. in cases, where the number of mpls-labels is large, it is surely more user-friendly to use a lua-script (or possibly other global mpls dissection-settings) instead of manually define a large number of 'decode as ...' rules. this is the reason, why it might be a good idea to be able to access all different dissectors via lua in addition of having a strong heuristic ...
(07 Jan '17, 12:40)
x42
showing 5 of 9
show 4 more comments
|
thanks to michael mann and anders broman the missing mpls-dissectors ( |