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

lua script for mpls frames with AND without cw

0

we have a mix of different mpls frames with and without cw.

if a cw is present, then its value is always 0 - in our implementation we have no cw's with a value different from 0.

so our question is how we might be able to write a small lua script to accomplish, that:

in the case, that the first four bytes of the encapsulated ethernet frame are not all zero, then we assume that they contain the start of the destination mac address ... and hence just simply continue with the dissection.

if on the other hand the first four bytes of the encapsulated ethernet frame are all zero then we assume to have a control-word and would like to strip it away before we may continue with the dissection of the frame.

would that be possible ? any hints ?

asked 04 Jan '17, 05:59

x42's gravatar image

x42
6●2●2●4
accept rate: 0%

edited 04 Jan '17, 09:28

Ugh, MPLS control words are just a pain to get right. Heuristically it's almost impossible to determine definitively (I experimenting with a Wireshark change, not done yet).

Anyway, your case should be possible, if you can insert yourself as MPLS ethertype dissector, then examine the first octets of the TVB and decide which dissector to call.

(04 Jan '17, 06:27) Jaap ♦

we have only a dirty and tedious workaround for the present case, that the cw's can only take on the value 0:

1) open the mixed trace (mpls packets with and without cw) and apply the lua-script

local success, dis_eth = pcall(Dissector.get, "eth_withoutfcs")
if not success or not dis_eth then
  dis_eth = Dissector.get("eth")
end

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

2) apply the display filter eth.dst[0:4]==00:00:00:00 and save the displayed frames as capture-with-cw.pcap

3) apply the complementary display filter !(eth.dst[0:4]==00:00:00:00)

4) open the previously saved capture-with-cw.pcap in a second instance of wireshark (it must be 1.x because the pw_eth_cw dissector is not present in wireshark 2.x https://ask.wireshark.org/questions/58532/missing-dissector-pw_eth_cw )

and apply the lua-script

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

5) analyze the original trace in the two wireshark instances …

so yes … we are hoping very much that your modifications/changes to the mpls-heuristic may be successfull :-)

(06 Jan ‘17, 10:21) x42

One Answer:

0

now, that the missing dissectors pw_eth_cw and pw_eth_nocw have found their way back into the wireshark source-code, we may use the following script to switch between appropriate dissectors as needed:

info("MPLS script loaded ...")

local tap_mpls = Listener.new("eth")
local mpls_table = DissectorTable.get("mpls.label")


dis_eth_cw = Dissector.get("pw_eth_cw")
dis_eth_nocw = Dissector.get("pw_eth_nocw")


eth_dst_f = Field.new("eth.dst")
mpls_label_f = Field.new("mpls.label")


function tap_mpls.packet(pinfo, tvb, eth)


– as we may or may not have multiple vlan encapsulations
– we would like to avoid using an explicit offset like e.g.
– local cw = tvb(22,4):uint()


local eth_dst = tostring(eth_dst_f())
local mpls_label = tostring(mpls_label_f())


– in our case only cw's = 0 might be present
– this makes the heuristic relatively easy


local dst = tostring(eth.dst)
if string.find(dst, "00:00:00_00")==1 or string.find(dst, "00:00:00:00")==1 then
debug("cw==0 found in packet " .. pinfo.number .. " label " .. mpls_label)
debug("changing dissector for label " .. mpls_label)


mpls_table:remove(mpls_label,dis_eth_nocw)
mpls_table:add(mpls_label,dis_eth_cw)



end
end


function tap_mpls.reset()
debug("reset … assuming we have no cw's")
mpls_table:remove_all(dis_eth_nocw)
mpls_table:remove_all(dis_eth_cw)
for label=0,1048575 do
mpls_table:add(label,dis_eth_nocw)
end
end


function tap_mpls.draw()
debug("————————————–")
end

it would be even better if we knew how to “insert ourself into the mpls ethertype dissector” as suggested, but it’s ok … the script works satisfactory in our network.

we are now able to analyze different cases in the (very buggy) mpls-implementation of a well-known hardware vendor ;-)

thanks a lot to you all for your friendly, swift and very competent support and insight into mpls-related problems !

answered 08 Jan ‘17, 13:59

x42's gravatar image

x42
6●2●2●4
accept rate: 0%

edited 08 Jan ‘17, 14:01