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

[Jani Monoses]

Your're right Ed.
As said before UDP needs a 'connected' flag in the PCB otherwise it'll only talk
to the first client.But the fix is not to remove check for remote_ip in 
udp_input but
making those checks aware of connections.connecting to a remote should make UDP 
accept
packets only from that IP, connetcing to a remote of family AF_UNSPEC should 
lose the connection.


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