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

[Ed Sutter]

Leon,
Ok, thanks for confirming that.  I wasn't sure based on earlier emails
whether you were disagreeing with my proposed fix in udp_input()
or with the fact that I thought there was a bug.
I think we're in sync now!

So, now my next question/comment...
The function udp_send() is the function that is ultimately
called to send a udp packet.  That function assumes pcb->remote_ip
is populated with the ip address of the system that is to receive
the packet.  This means that prior to calling udp_send(), udp_connect()
must be called to properly populate the pcb->remote_ip and pcb->port.

I think this is what causes all other incoming client requests to 
be rejected... As soon as pcb->remote_ip is non-zero, the 
ip_addr_isany(pcb->remote_ip) test in udp_input() fails (this is
what led me to the change I made to udp_input).

See what I mean?  
Assuming you agree...

It appears that the need to "connect" for udp_send() to transfer
the packet to the proper destination is incorrect. 

So, is there any way to send a UDP packet without having to call
udp_connect()?

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)? 

Ed

address@hidden wrote:
> 
> Hello Ed,
> 
> yes, this server should respond to every client that send to it.
> 
> The core stuff (udp.c) works OK for me (i.e. the raw interface).
> 
> It seems that you have found a bug in the lwip_*() or netcon_*() interface.
> 
> Regards,
> 
> Leon Woestenberg
> 
> ons is available on request free of charge.
> ================================================================================
> 
> =====================
> 
> |---------+------------------------------------------------------>
> |         |           Ed Sutter <address@hidden>   |
> |         |           Sent by:                                   |
> |         |           lwip-users-bounces+leon.woestenberg=axon.tv|
> |         |           @nongnu.org                                |
> |         |                                                      |
> |         |                                                      |
> |         |           20-01-2003 15:14                           |
> |         |           Please respond to esutter; Please respond  |
> |         |           to "Mailing list for users of lwIP."       |
> |         |                                                      |
> |---------+------------------------------------------------------>
>   
> >----------------------------------------------------------------------------------------------|
>   |                                                                           
>                    |
>   |       To:                                                                 
>                    |
>   |       cc:       "Mailing list for users of lwIP." <address@hidden>        
>             |
>   |       Subject:  Re: [lwip-users] bug #2240 - UDP pcb connect behaviour    
>                    |
>   
> >----------------------------------------------------------------------------------------------|
> 
> Leon (& all),
> Well, now I'm even more confused.  Here is an example of a
> simple UDP-based, connectionless server that does not work
> properly on lwIP...
> 
> void
> taskMonSrvr(void *notused)
> {
>   int msglen, sfd;
>   unsigned char rcvmsg[128];
>   struct sockaddr_in srvr_addr, from_addr;
> 
>   sfd = lwip_socket(AF_INET,SOCK_DGRAM,0);
>   bzero((char *)&srvr_addr,sizeof(struct sockaddr));
>   srvr_addr.sin_family = AF_INET;
>   srvr_addr.sin_port = htons(777);
>   srvr_addr.sin_addr.s_addr = htonl(INADDR_ANY);
> 
>   lwip_bind(sfd,(struct sockaddr *)&srvr_addr,sizeof(struct sockaddr));
> 
>   while(1) {
>     msglen = sizeof(from_addr);
>     lwip_recvfrom(sfd,rcvmsg,sizeof(rcvmsg),0,(struct sockaddr *)
> &from_addr,&msglen);
>     lwip_sendto(sfd,"hello!\n",7,0,(struct sockaddr *)
> &from_addr,sizeof(from_addr));
>   }
> }
> Do you agree that this server should respond to any client?
> 
> AFAIK, this server should simply respond with "hello!\n" to any client that
> tries to talk to it.  In my system it only communicates with the first
> client
> that attempts to talk to it.  Is there something wrong with this approach?
> I've used this with many other stacks and it works fine.
> 
> I agree that a UDP-based "connection" can be set up to only communicate
> with one other peer, but that should not the case with this server.
> The above code should respond to any peer, not just the first one.
> Agree?
> 
> Ed
> Leon Woestenberg wrote:
> >
> > Hello,
> >
> > > Yes, I beleive that's correct.  My change to udp.c for this
> > > assumes connectionless behaviour, so now I'm going to
> > > advertise my stupidity... Isn't that the way UDP should work?
> > >
> >
> > UDP is connectionless in the sense that it merely tries to send
> > datagrams to a certain address without any attempts to keep
> > a communication channel open with that address.
> >
> > An UDP protocol control block (think of a simple socket) can
> > send and receive datagrams to/from any host during operation,
> > unlike a TCP connection.
> >
> > A UDP PCB can however, assume a connected state, where
> > the remote address is used to send datagrams to, and to accept
> > only datagrams from that address.
> >
> > This kind of UDP PCB is referred to as a "connected" PCB (or
> > socket) which might introduce the confusion, as the UDP
> > communication protocol is still "connection-less".
> >
> > > Assuming there are cases where accept() and connect() are
> > > used with UDP, then maybe a real fix would be to have some
> > > kind of flag field in the pcb that allows udp_input() to
> > > determine if it is a connection or connectionless bind.
> > >
> > There is no such thing, and AFAIK nothing needs to be fixed.
> > (unless netcon_*() has a bug).
> >
> > Regards,
> >
> > Leon.
> >
> > >
> > >
> > > Leon Woestenberg wrote:
> > > >
> > > > Ed Suller submitted this bug report. (Thanks Ed.)
> > > >
> > > > >A UDP server appears to "lock on" to the IP address of
> > > > >he first client that communicates with it. After the first
> > > > >client transaction, no other client (different IP) can
> > > > >communcate with that server. Assuming that it is agreed
> > > > >by all that this is a bug, I have what I think is a
> > > > >fix for this and will submit a patch.
> > > >
> > > > This behaviour corresponds with accept() or connect(), where the
> socket
> > > > connects with the
> > > > remote IP address and remote UDP port address. Ed's fix probably
> > implements
> > > > recvfrom() behaviour,
> > > > where the socket stays unconnected to a remote address.
> > > >
> > > > None of both is wrong, but we should make both available and
> especially
> > well
> > > > documented.
> > > >
> > > > Regards, Leon.
> > > >
> > > > _______________________________________________
> > > > lwip-users mailing list
> > > > address@hidden
> > > > http://mail.nongnu.org/mailman/listinfo/lwip-users
> >
> >
> ----------------------------------------------------------------------------
> 
> > ----
> >
> > > _______________________________________________
> > > lwip-users mailing list
> > > address@hidden
> > > http://mail.nongnu.org/mailman/listinfo/lwip-users
> > >
> 
> Leon Woestenberg wrote:
> >
> > Hello,
> >
> > > Yes, I beleive that's correct.  My change to udp.c for this
> > > assumes connectionless behaviour, so now I'm going to
> > > advertise my stupidity... Isn't that the way UDP should work?
> > >
> >
> > UDP is connectionless in the sense that it merely tries to send
> > datagrams to a certain address without any attempts to keep
> > a communication channel open with that address.
> >
> > An UDP protocol control block (think of a simple socket) can
> > send and receive datagrams to/from any host during operation,
> > unlike a TCP connection.
> >
> > A UDP PCB can however, assume a connected state, where
> > the remote address is used to send datagrams to, and to accept
> > only datagrams from that address.
> >
> > This kind of UDP PCB is referred to as a "connected" PCB (or
> > socket) which might introduce the confusion, as the UDP
> > communication protocol is still "connection-less".
> >
> > > Assuming there are cases where accept() and connect() are
> > > used with UDP, then maybe a real fix would be to have some
> > > kind of flag field in the pcb that allows udp_input() to
> > > determine if it is a connection or connectionless bind.
> > >
> > There is no such thing, and AFAIK nothing needs to be fixed.
> > (unless netcon_*() has a bug).
> >
> > Regards,
> >
> > Leon.
> >
> > >
> > >
> > > Leon Woestenberg wrote:
> > > >
> > > > Ed Suller submitted this bug report. (Thanks Ed.)
> > > >
> > > > >A UDP server appears to "lock on" to the IP address of
> > > > >he first client that communicates with it. After the first
> > > > >client transaction, no other client (different IP) can
> > > > >communcate with that server. Assuming that it is agreed
> > > > >by all that this is a bug, I have what I think is a
> > > > >fix for this and will submit a patch.
> > > >
> > > > This behaviour corresponds with accept() or connect(), where the
> socket
> > > > connects with the
> > > > remote IP address and remote UDP port address. Ed's fix probably
> > implements
> > > > recvfrom() behaviour,
> > > > where the socket stays unconnected to a remote address.
> > > >
> > > > None of both is wrong, but we should make both available and
> especially
> > well
> > > > documented.
> > > >
> > > > Regards, Leon.
> > > >
> > > > _______________________________________________
> > > > lwip-users mailing list
> > > > address@hidden
> > > > http://mail.nongnu.org/mailman/listinfo/lwip-users
> >
> >
> ----------------------------------------------------------------------------
> 
> > ----
> >
> > > _______________________________________________
> > > lwip-users mailing list
> > > address@hidden
> > > http://mail.nongnu.org/mailman/listinfo/lwip-users
> > >(See attached file: els.vcf)
> _______________________________________________
> lwip-users mailing list
> address@hidden
> http://mail.nongnu.org/mailman/listinfo/lwip-users

els.vcf
Description: Card for Ed Sutter