How do we override the underlying udp dissector?

asked 2020-08-07 21:11:15 +0000

RickC
1

updated 2020-08-08 06:21:20 +0000

Jaap

13730 ●684 ●115

I've created the minimal packet-foo dissector verbatim from code in the documentation. It compiles (VS 2017) and I can see in Wireshark that it's registered and enabled.

In debug mode I hit break points in methods proto_register_foo and proto_reg_handoff_foo. When I send a message to FOO_PORT I hit a breakpoint in dissect_udp. I never hit a breakpoint in dissect_foo.

Is there something needed to explicitly make a dissector override (is that the right term) an underlying type, in this case udp? The only thing I see in code id this:

dissector_add_uint("udp.port", FOO_PORT, foo_handle);

Getting ahead of things, would adding this line also override the tcp dissector?

dissector_add_uint("tcp.port", FOO_PORT, foo_handle);

Thx

Comments

So does your protocol run on top of UDP - in which case you should expect that dissect_udp() is called, and you should do dissector_add_uint("udp.port", FOO_PORT, foo_handle); to get the UDP dissector to call dissect_foo() for traffic to and from port FOO_PORT - or does your protocol run instead of UDP, directly atop IPv4 or IPv6?

Guy Harris ( 2020-08-07 21:58:29 +0000 )edit

FYI: He's working on the simple dissector from the developers guide.

Jaap ( 2020-08-08 06:20:38 +0000 )edit

add a comment

answered 2020-08-07 21:57:14 +0000

Jaap

13730 ●684 ●115

I think you're on the right track here, so there's some detail wrong (isn't it always).

What you call override, is something else. Think of the protocols in a stack. the Ethernet frame has a selector field (called several things based on value) indicating the rest is IPv4, the IPv4 header has a selector field (called protocol ID) indicating the rest is UDP, the UDP header has a field (called source / destination port) that can help determine the protocol in the UDP payload.

This last one is where your FOO dissector comes in. It registers itself to the UDP protocol port table, which means that once the UDP dissector has seen the source / destination port it tries to find a dissector that registered itself for that port number, so that it can hand the UDP payload to that dissector.

If your dissector is not called, first thing to verify is that the UDP dissector port table has indeed a registration for your dissector at the expected port number. You can find this in View | Internals | Dissector Tables. This dialog shows all tables, so you have to go look in the Integer tables, under the UDP port list, to see if your dissector is there under the expected port number.

Other details can be the UDP test packet, which needs the correct port number in it. The protocol need to be not disabled (obviously). Just to name a few.

edit flag offensive delete link

Comments

Thanks for the reply. This confirms that I'm not too far off. In code I have:

define FOO_PORT 1234

In the Dissector Tables I see:

Integer Tables UDP port udo.port 1234 FOO

I also see that the FOO protocol is enabled.

RickC ( 2020-08-10 15:20:12 +0000 )edit

I'm also seeing that the ASTERIX dissector isn't being invoked.

I can see in packet.register_dependent_dissector that ASTERIX and FOO are added to the list of sub-dissectors. If the parent dissector is UDP, where in the code might I find the decision point to invoke the sub-dissector?

RickC ( 2020-08-10 23:00:40 +0000 )edit

add a comment

Your Answer

Please start posting anonymously - your entry will be published after you log in or create a new account.

How do we override the underlying udp dissector?

Comments

1 Answer

Comments

Your Answer

Question Tools

Stats

Related questions

How do we override the underlying udp dissector? edit

Comments

1 Answer

Comments

Your Answer

Question Tools

Stats

Related questions

How do we override the underlying udp dissector?