>> Right now I analyze the first 2 bytes to check if it's equal to 0x0002
> That's somewhat of a weak check
Indeed, and moreover, it's a wrong check since I discovered a packet
starting with 0x0001 for the first time after a hundred packets ^^
In fact, there is an udp broadcast from enddevices in which they tell
the switch to which port the switch can establish a TCP connection.
What I may do, is I can automatically add that port to the ports to
listen to for the energywise heuristic dissector.
> However, if that's the best heuristic you can use, a port preference might be better, given that it has predefined ports.
In fact I will do that because in some cases, you don't have that UDP
broadcast beforehand and it TCP connects directly to a management
port.
> So I assume your dissector is being developed by reverse-engineering the protocol (which I'm guessing is
> http://www.cisco.com/en/US/prod/switches/ps5718/ps10195/white_paper_c11-514539.html
This is the one :)
> No, if it were to immediately return TRUE, Wireshark would (incorrectly) assume your dissector had dissected the packet.
ok
> No - DISSECTOR_ASSERT_NOT_REACHED() is intended to be used when it should *never ever* be possible to reach that location, even when the dissector is completely implemented.
ok thx for all those precisions.
