GNU bug report logs - #62990
30.0.50; UDP server closes connection upon receiving an empty packet

Previous Next

Full log

Message #41 received at 62990 <at> debbugs.gnu.org (full text, mbox):

From: Eli Zaretskii <eliz <at> gnu.org>
To: Robert Pluim <rpluim <at> gmail.com>
Cc: 62990 <at> debbugs.gnu.org, mail <at> vasilij.de
Subject: Re: bug#62990: 30.0.50; UDP server closes connection upon receiving
 an empty packet
Date: Wed, 26 Apr 2023 15:24:03 +0300

> From: Robert Pluim <rpluim <at> gmail.com>
> Cc: 62990 <at> debbugs.gnu.org,  mail <at> vasilij.de
> Date: Wed, 26 Apr 2023 13:47:49 +0200
> 
> >>>>> On Wed, 26 Apr 2023 13:38:47 +0300, Eli Zaretskii <eliz <at> gnu.org> said:
> 
>     >> From: Robert Pluim <rpluim <at> gmail.com>
>     >> Cc: 62990 <at> debbugs.gnu.org,  mail <at> vasilij.de
>     >> Date: Wed, 26 Apr 2023 12:35:21 +0200
>     >> 
>     >> >>>>> On Wed, 26 Apr 2023 13:30:32 +0300, Eli Zaretskii <eliz <at> gnu.org> said:
>     >> 
>     Eli> Do we want some variable to get back the old behavior, in case some
>     Eli> application out there depends on that?
>     >> 
>     >> For which one?
> 
>     Eli> The 2nd one.
> 
> I guess we could, but if the application asks us to send an empty
> packet we should do it.

I didn't say that the default behavior should be that, I just asked
whether it is conceivable that someone, somewhere could actually rely
on the semi-buggy behavior, whereby empty packets aren't sent?

>     >> Does it help if I say that [1] is a security fix? 😜
> 
>     Eli> No.  But it will help if you convince me that it's a bug-fix.
> 
> It transforms this:
> 
>     recvfrom(5, "hello", 4096, 0, {sa_family=AF_INET, sin_port=htons(56845), sin_addr=inet_addr("127.0.0.1")}, [16]) = 5
>     Received string (5): "hello"
>     recvfrom(5, "", 4096, 0, {sa_family=AF_INET, sin_port=htons(56845), sin_addr=inet_addr("127.0.0.1")}, [16]) = 0
>     Received event: "connection broken by remote peer
> 
> into this:
> 
>     recvfrom(5, "hello", 4096, 0, {sa_family=AF_INET, sin_port=htons(55486), sin_addr=inet_addr("127.0.0.1")}, [16]) = 5
>     Received string (5): "hello"
>     recvfrom(5, "", 4096, 0, {sa_family=AF_INET, sin_port=htons(55486), sin_addr=inet_addr("127.0.0.1")}, [16]) = 0
>     recvfrom(5, "world", 4096, 0, {sa_family=AF_INET, sin_port=htons(55486), sin_addr=inet_addr("127.0.0.1")}, [16]) = 5
>     Received string (5): "world"
> 
> ie the UDP process is still running and can still receive messages

And no one could ever expect that?  IOW, is this behavior obviously
wrong?

Previous Next

GNU bug tracking system
Copyright (C) 1999 Darren O. Benham, 1997,2003 nCipher Corporation Ltd, 1994-97 Ian Jackson.