gen_udp behaviour

Steve Davis steven.charles.davis@REDACTED
Tue Dec 29 09:13:46 CET 2009


Frankly, I'm not clear on what the solution to the following situation 
should be from the OTP side, *if any*, but I thought I should at least 
report this edge-case behaviour.

I'm communicating with a badly behaved UDP server that is unpredictably 
appending additional bytes to sent udp packets beyond the declared 
payload length.

Example capture from WireShark:
---
Frame 1203 (60 bytes on wire, 60 bytes captured)
User Datagram Protocol, Src Port: 12035 (12035), Dst Port: oc-lm (1448)
     Source port: 12035 (12035)
     Destination port: oc-lm (1448)
     Length: 23
     Checksum: 0xb2a0 [correct]
Data (15 bytes)
     Data: 000000000100FFFFFFFB0101000000

0000  00 c0 9f 7f 26 c2 00 c0 49 db ac d0 08 00 45 00   ....&...I.....E.
0010  00 2b 00 00 40 00 38 11 2c 4b d8 52 02 16 c0 a8   .+..@REDACTED,K.R....
0020  7b 66 2f 03 05 a8 00 17 b2 a0 00 00 00 00 01 00   {f/.............
0030  ff ff ff fb 01 01 00 00 00 00 00 00               ............
---

As you can see, the actual payload length is correctly set for the 
message, but the server has chosen (in this case) to append three 
additional zero bytes.

Rather than just the 15 bytes of data, gen_udp is returning the data 
plus the erroneous extra bytes - i.e. a total of 18 bytes that were 
actually sent over the wire.

The reason this has caused me a development issue is that without 
knowing the length specified in the UDP packet header it's makes it 
tough to parse some messages from this incorrectly-implemented server 
reliably.

What the solution to this should be -- I'm not entirely sure.

Regards,
Steve



More information about the erlang-bugs mailing list