[Top][All Lists]
[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
Re: [lwip-users] bug #2240 - UDP pcb connect behaviour
From: |
Ed Sutter |
Subject: |
Re: [lwip-users] bug #2240 - UDP pcb connect behaviour |
Date: |
Mon, 20 Jan 2003 11:59:59 -0500 |
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
- Re: [lwip-users] bug #2240 - UDP pcb connect behaviour,
Ed Sutter <=