I intend to dissect last 12 bytes of my protocol packet and for that i am using eth.trailer subdissector list of standard ethernet dissector. And we know that in IP header we have a field of 2 bytes which denotes total length of IP packet.Also i assume IP dissector must have done its dissection before my dissector will get called. So is there any way to retrieve that value from *pinfo ?? I hope i am clear.
asked 14 Jun '12, 00:51
You have set a real hard target for yourself trying to keep all Wireshark functionality while dissecting such a violating protocol. What kind of HW or SW is used that overwrites these 12 bytes and the ethernet addresses?
I think the way forward (warning: uncharted territory!!!) would be:
I'm not sure what you mean, as you are mixing ethernet trailer with last 12 bytes of IP payload in your question. If the 12 bytes you want to dissect are part of the IP payload, then you need to follow the normal path and let the protocol that has your 12 bytes as its payload call your dissector.
If your 12 bytes come after the IP payload, then it will indeed be handled as ethernet trailer and you will need to add your dissector to the ethernet trailer dissector list. Your dissector will then be called with a TVB pointing to the first byte after the IP payload, so that should be the first byte of your 12 bytes.
You have to be aware though, that there might or might not be a FCS in the trailer as well.
It would help if you could upload a tracefile with a few of the packets you want to dissect to www.cloudshark.org and post the link to it here.
answered 14 Jun '12, 10:24
yogeshg, you are asking a lot of questions about how to write a dissector during the last weeks, which is absolutely fine.
You say, you need to filter on a specific dst mac address. Then you show a sample (Frame 385) that looks like a somehow "crippled" HTTP request. BTW: There are other, "crippled" HTTP requests to that dst mac. Why is that?
So, what are you excatly trying to do with your dissector? I'm not sure you really need a dissector. Can you show a binary packet you want to dissect and the logical structure of the data in that packet? You need that information anyway if you want to dissect the packet.
BTW: Why do you want to filter on the dst mac address? Your sample is TCP on port 80. So, why not just add a heuristic TCP/HTTP dissector?
Are you interested in the structure of the payload or just the fact that there are packets with that dst mac address?