This is our old Q&A Site. Please post any new questions and answers at ask.wireshark.org.

in wireshark version 1.x the following script works without problems:

dis_eth_pw = Dissector.get("pw_eth_cw")
local mpls_table = DissectorTable.get("mpls.label")
for label=0,1048575 do
  mpls_table:add(label,dis_eth_pw)
end

how should we modify the call to Dissector.get("pw_eth_cw") in order to be able to use it with wireshark 2.x ?

Lua: Error during loading: (Dissector_get: No such dissector)

asked 05 Jan '17, 02:13

x42's gravatar image

x42
6224
accept rate: 0%


I think you have to try your luck with pw_eth_heuristic instead.

permanent link

answered 05 Jan '17, 09:52

Jaap's gravatar image

Jaap ♦
11.7k16101
accept rate: 14%

pw_eth_heuristic does not help us in our case, sorry ...

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 pw_eth_cw and pw_eth_nocw dissectors ?

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...
(05 Jan '17, 14:51) x42

to extend the heuristic to include cases where the mpls payload consists of ipv6-frames ...

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

register_dissector("pw_eth_cw", ...);
register_dissector("pw_eth_nocw", ...);

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 register_dissector() code-lines given in

https://code.wireshark.org/review/gitweb?p=wireshark.git;a=commitdiff;h=7ca04728c35560530304e7f2266bc9f01e020267

namely:

Just use Decode As directly.
Also replace "registered" dissectors which just the creation of a handle 
since the dissectors really don't need to be "found" outside of themselves.

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 register_dissector() calls should be inserted back into the source code again ...

(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. "pw_eth_cw" or "pw_eth_nocw" etc. ought to be available and callable from lua:

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 (pw_eth_cw, pw_eth_nocw, etc.) have now been merged back into the wireshark source-code :-)

permanent link

answered 08 Jan '17, 06:26

x42's gravatar image

x42
6224
accept rate: 0%

edited 08 Jan '17, 09:19

Your answer
toggle preview

Follow this question

By Email:

Once you sign in you will be able to subscribe for any updates here

By RSS:

Answers

Answers and Comments

Markdown Basics

  • *italic* or _italic_
  • **bold** or __bold__
  • link:[text](http://url.com/ "title")
  • image?![alt text](/path/img.jpg "title")
  • numbered list: 1. Foo 2. Bar
  • to add a line break simply add two spaces to where you would like the new line to be.
  • basic HTML tags are also supported

Question tags:

×637
×431
×25

question asked: 05 Jan '17, 02:13

question was seen: 1,312 times

last updated: 08 Jan '17, 09:19

p​o​w​e​r​e​d by O​S​Q​A