Re: [lwip-users] bug #2240 - UDP pcb connect behaviour

[Ed Sutter]

Leon (& all),

Leon, you're probably getting this twice.  On my first reply I omitted
the lwip-users list, so I'm resending...

> > So, is there any way to send a UDP packet without having to call
> > udp_connect()?
> >
> That would be a sendto() call. It does this:
> 1) remember the current remote address of the UDP socket.
> 2) sets the remote address to the recipient specified in sendto()
> 3) sends the UDP datagram
> 4) resets the remote address of the UDP socket to the address saved in 1.

Are you referring to lwip_sendto() here?  Assuming you are, it
wraps lwip_send() with two calls to netconn_connect() (steps 2 & 4) and
that results in 2 calls to udp_connect().  
The logic applied in the lwip_sendto() function is necessary because of
udp_send()'s need for udp_connect() to be called prior. 

Plus, if this sendto() call was preceded by a recvfrom() (very likely
in the case of a server), then step 4 doesn't clear the pcb properly,
and all future incoming packets (from other clients) are dropped. 
I've gotten around this problem (partially) by forcing addr to
zero in the second call to netconn_connect() (within
lwip_sendto()).  This atleast restores the pcb so that the ip_addr_isany()
test in udp_input() will pass for future incoming packets.
There is a window of time however during which arbitrary
clients' packets will be dropped (see below), so this is not a perfect
fix.

 
> > You say that the core stuff (udp.c) works ok, but have you ever
> > used it to set up a server that would interface to multiple
> > clients (as the one that I sent should)?
> >
> Yes. Please note that the 'core' stuff does not use the netcon* and
> lwip* wrapper calls.
> 
> See the doc's on raw_arch (core) vs. sys_arch (core + wrapper).

I may be totally off track here (I apologize if I am!), but I don't think
I am...
I've gone through those docs.  The udp_send() call (which I believe you
consider to be part of the core code) depends on udp_connect() being
called prior.  The call to udp_connect() establishes the remote_ip and port
values used in the pcb however, that affects incoming packets as well.
That's the part that I have a problem with...
To send a packet (using the core code) udp_connect() modifies the pcb
so that udp_send() can transfer the packet to the remote system; however,
that same portion of the pcb is used by udp_input() to filter incoming
packets, so unless incoming packets are disallowed between the time
the pcb is modified for udp_send() and then restored, the incoming
packets (from arbitrary clients) will be lost because udp_input() will
be filtering out all remote_ip addresses except the address of the
packet that was just sent by udp_send().
See what I mean?

The problem that I see is that the send and recieve code depend on the
same remote_ip member of the pcb, but during a packet send the remote_ip
is set to the address of one specific client.  If during that send,
another client's packet comes in, it is lost.
Ed

els.vcf
Description: Card for Ed Sutter