I am generating a UDP packet. The data payload is interpreted by Wireshark as a ADwin_config message. What determines an ADwin_config message?

asked 2024-05-23 18:25:03 +0000

CAH
1 ●1 ●1 ●1

updated 2024-05-23 20:15:17 +0000

cmaynard

11115 ●11 ●317 ●165 https://www.igt.com/

I am attaching a screen capture of the Wireshark packet:

+---------+---------------+----------+
14:16:19,784,777   ETHER
|0   |ff|ff|ff|ff|ff|ff|00|5d|03|01|02|03|08|00|45|00
     |00|32|00|00|00|00|7f|11|e1|ea|a9|fe|af|d2|ff|ff
     |ff|ff|c3|5c|c3|5c|00|1e|00|00|00|16|00|00|00|00
     |00|03|00|00|02|07|00|04|00|dd|18|b9|00|dd|18|b9|

edit retag flag offensive close merge delete

Comments

Formatted for Wireshark "Import from Hex Dump...":

00000000  ff ff ff ff ff ff 00 5d 03 01 02 03 08 00 45 00
00000010  00 32 00 00 00 00 7f 11 e1 ea a9 fe af d2 ff ff
00000020  ff ff c3 5c c3 5c 00 1e 00 00 00 16 00 00 00 00
00000030  00 03 00 00 02 07 00 04 00 dd 18 b9 00 dd 18 b9

Chuckc ( 2024-05-26 13:40:50 +0000 )edit

add a comment

2 Answers

Sort by » oldest newest most voted

answered 2024-05-28 06:49:32 +0000

TBoehne
1

I am the original author of this dissector (very long time ago). The ADWIN Config protocol is hard coded to port 7000, both for TCP and UDP.

I suggest checking for port 7000 in both TCP _and_ UDP to work around the problem reported by the thread creator.

Note: this is not the case for the regular ADwin communication protocol (packet-adwin.c as opposed to packet-adwin-config.c), which uses port 6543 by default but can be changed to arbitrary port numbers.

edit flag offensive delete link

Comments

Can you provide a specification document for the protocol?

5324: New dissector for adwin protocols

1. Checking for UDP port 7000 would not work for frames 2 and 3 in the sample capture attached to issue 5324.
2. If UDP trafffic is not on port 7000 then is at least one of the MAC addresses always in the "Jäger Computergesteuerte Meßtechnik GmbH." (adwin) ranges?

Should the heuristic look for UDP port 7000 "or" MAC address in specified range?

Chuckc ( 2024-05-28 12:28:16 +0000 )edit

I cannot provide a spec for the protocol, but you are correct that checking only for port 7000 would not work for frames 2 and 3 in the sample capture file. Actually, that was a firmware bug where older systems opened a new socket send replies, resulting in numerous problems (firewalls blocking the responses because the src port of the remote end was incorrect).

Newer firmwares should properly answer requests to port 7000 with that socket, and should not cause problems. I guess the buggy old firmwares were the reason why UDP was not restricted to port 7000.

The ideal solution would be record outgoing packets to port 7000 with their old source port and the also use the heuristic dissector to include packets to the old source port.

Hard to tell if it is worth the additional work for older, buggy firmwares.

For me, just restricting to 7000 on ...(more)

TBoehne ( 2024-05-28 12:43:50 +0000 )edit

"newer sample captures" :-)
Yes please.

Would you also supply a patch for the UDP dissector?

Chuckc ( 2024-05-28 12:50:05 +0000 )edit

yes and yes.

Just working on it, needed to create account first.

TBoehne ( 2024-05-28 13:06:47 +0000 )edit

Thank you!

Chuckc ( 2024-05-28 13:07:33 +0000 )edit

add a comment

answered 2024-05-24 11:47:44 +0000

johnthacker
201 ●37 ●5

Looks like TCP or UDP packets sent to port 7000 with MAC address that are either ADwin's OUI or broadcast are interpreted as ADwin config. UDP does additional length checks, but TCP doesn't because of desegmentation. You might want to disable that dissector

edit flag offensive delete link

Comments

It only checks the port for TCP:
dissect_adwin_config_tcp():

    if(!(pinfo->srcport == ADWIN_CONFIGURATION_PORT
        || pinfo->destport == ADWIN_CONFIGURATION_PORT))
        return 0;

This check seems to allow any UDP packet of a correct length and a broadcast address to pass?
dissect_adwin_config_udp():

if (! (is_adwin_mac_or_broadcast(pinfo->dl_src) || is_adwin_mac_or_broadcast(pinfo->dl_dst)))
        return 0;

Philosophical beer/coffee discussion question:
"Should niche protocol dissectors be disabled by default or is it better to search for every possible protocol 'just in case'?"
proto_reg_handoff_adwin_config() :

heur_dissector_add("udp", dissect_adwin_config_udp, "ADwin-Config over UDP", "adwin_config_udp", proto_adwin_config, HEURISTIC_ENABLE);
heur_dissector_add("tcp", dissect_adwin_config_tcp, "ADwin-Config over TCP", "adwin_config_tcp", proto_adwin_config, HEURISTIC_ENABLE);

Chuckc ( 2024-05-26 13:48:22 +0000 )edit

We see both type of questions:

Why isn't my protocol dissected?
Why is my traffic dissected as some other protocol?

With the answers being:

The dissector is disabled (or the traffic is on another port).
Because the traffic is using a port claimed by another dissector.

I'm inclined to be more inclusive and enable all dissectors, possibly disabling those with known poor heuristics and handling.

grahamb ( 2024-05-28 08:38:48 +0000 )edit

The UDP dissector is "greedy". If the discussion above provides more data to tighten it up then leaving enabled ok. Otherwise I would propose to make the default setting HEURISTIC_DISABLE for UDP.

Chuckc ( 2024-05-28 12:47:04 +0000 )edit

Sometimes the answer is "because your packets don't match the protocol spec, possibly because you generated them yourself, possibly because whatever gear you are using is non compliant." Which leads into the argument of whether dissectors should dissect the buggy data anyway.

johnthacker ( 2024-05-28 14:26:47 +0000 )edit

In this case it was a free "fuzz test". :-)

Chuckc ( 2024-05-28 14:31:22 +0000 )edit

add a comment