Wireshark mailing list archives
Re: Extending PCLI payload decoding
From: mmann78 () netscape net
Date: Tue, 26 May 2015 20:48:52 -0400
Someone can correct me, but I believe Decode As works off of the numeric value passed into dissector_try_uint and associates it with a dissector (function). UDP/TCP/IP/Ethernet (and others) have a "unique" numeric value (port/protocol) to pass into dissector_try_uint, while PCLI (and a few others that used to be preference based) are stuck with just 0 (constant). In the current patch set (3), I set all PCLI "flavors" to use 0 (constant), but you may get your desired functionality by giving each flavor a different constant (an idea I thought of post submittal). Not exactly sure how the constants would be clear to the user (or if they need to even be exposed). The sample captures provided in the bug reports didn't provide enough data, so I'll leave that to you. I don't like the idea of using the UDP port number as the dissector_try_uint value for PCLI as I think it breaks "layering" (like what if PCLI came over TCP?). It seems much better to have the "current" dissector determine how its subdissector will be called. At worst, you can just break the a large capture up by port to do analysis. Michael -----Original Message----- From: Luke Mewburn <luke () mewburn net> To: Developer support list for Wireshark <wireshark-dev () wireshark org> Sent: Tue, May 26, 2015 10:55 am Subject: Re: [Wireshark-dev] Extending PCLI payload decoding On Tue, May 26, 2015 at 10:32:06AM -0400, mmann78 () netscape net wrote: | Do you want to post your current progress to the existing review and I | can take a look at it from there? That's probably the easiest way to | look at the "rough edges". You definitely want a dissector table with | type FT_UINT32 (not a string) Done! With what's in changeset 2, I can at least use the decode as in Wireshark (with the aforementioned Qt issues on my Mac), as well as in tshark if I specific pcli.payload==0. E.g. the pcap in bug 9266 can be decoded with: ./tshark -V -d udp.port==5001,pcli -d pcli.payload==0,eth -r bug9266.pcapng As an aside, is it possible/sensible to match/couple the 'PCLI payload' decode choice with the udp.port that selected PCLI? I.e. use the udp.(dst)port as the pcli.payload choice in dissector_try_uint(), so allowing different UDP ports be decoded as different PCLI payloads. If a file has PCLI-as-Ethernet on port 3000 and PCLI-as-IP on port 4000; ./tshark \ -d udp.port==3000,pcli -d pcli.payload==3000,eth \ -d udp.port==4000,pcli -d pcli.payload==4000,ip ... Or is that a silly idea? thanks, Luke. ___________________________________________________________________________ Sent via: Wireshark-dev mailing list <wireshark-dev () wireshark org> Archives: https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-request () wireshark org?subject=unsubscribe
___________________________________________________________________________ Sent via: Wireshark-dev mailing list <wireshark-dev () wireshark org> Archives: https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-request () wireshark org?subject=unsubscribe
Current thread:
- Extending PCLI payload decoding Luke Mewburn (May 24)
- Re: Extending PCLI payload decoding mmann78 (May 24)
- Re: Extending PCLI payload decoding Luke Mewburn (May 26)
- Re: Extending PCLI payload decoding mmann78 (May 26)
- Re: Extending PCLI payload decoding Luke Mewburn (May 26)
- Re: Extending PCLI payload decoding mmann78 (May 26)
- Re: Extending PCLI payload decoding Luke Mewburn (May 26)
- Re: Extending PCLI payload decoding mmann78 (May 24)