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