Erlang Mailing Lists

Author Message

<  Erlang bugs mailing list  ~  gen_udp behaviour

steved
Posted: Tue Dec 29, 2009 8:13 am Reply with quote
User Joined: 29 Apr 2008 Posts: 78
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 .+..@.8.,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


________________________________________________________________
erlang-bugs mailing list. See http://www.erlang.org/faq.html
erlang-bugs (at) erlang.org

Post received from mailinglist
View user's profile Send private message
axel
Posted: Tue Dec 29, 2009 9:49 am Reply with quote
User Joined: 03 Mar 2005 Posts: 271
Greetings,

I would suggest that gen_udp only sends the number of bytes specified in
the UDP packet header.

If backwards compatibility mandates that the current behaviour is
maintained for existing applications, then a flag could turn on the new
(correct) behaviour. Add to open/2 options something like this:
{receive_correct_length, true}


bengt

On Tue, 2009-12-29 at 02:13 -0600, Steve Davis wrote:
> 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 .+..@.8.,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
>
>
> ________________________________________________________________
> erlang-bugs mailing list. See http://www.erlang.org/faq.html
> erlang-bugs (at) erlang.org
>


________________________________________________________________
erlang-bugs mailing list. See http://www.erlang.org/faq.html
erlang-bugs (at) erlang.org

Post received from mailinglist
View user's profile Send private message

Display posts from previous:  

All times are GMT
Page 1 of 1
This forum is locked: you cannot post, reply to, or edit topics.

Jump to:  

You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
You cannot attach files in this forum
You cannot download files in this forum