UDP listen for connection on port 12344

[GregEigsti]

Sorry the code is on my laptop which I may or may not be able to revive - it needs to go into the shop to have its bogus NVidia graphics "chip/card/whatever" replaced. i386 is a description which means "Intel processor" - so running on an actual 386 - no; running on an Intel chip - yes.

If I can revive the machine I'll get the code off of it; otherwise its going in for its free fix (motherboard replacement I think).
Greg

[Renasis]

Greg,

Thanks for giving it a go. Sorry about your computer, hopefully you will be able to revive it. I will try tweaking my files and see it I can get it to work. At least I know that it is possible.

Thanks,

-ren

[rryan]

Renasis:

What you are experiencing is either a bug in the uIP stack or a bug in the WiShield fork of the uIP stack. I also experienced your confusion that varying source ports seem to 'lock' the listening port to receiving only from that source port.

After reading the uIP source provided by AsyncLabs, I found this problem:

In uip.c, around line 1150 (I've modified my version of uIP)

Code: Select all

udp_found:
    if (uip_udp_conn->rport == 0) {
        uip_udp_conn->rport = UDPBUF->srcport;
    }


The udp_found label is called whenever an incoming UDP datagram is found that matches the listening connection. If the rport (the source port) is 0, it sets it to the current incoming source port.

Now, let's look at an earlier check that decides whether or not to jump to udp_found. This check is performed on every listening port, and it decides if the incoming UDP datagram is destined for this listener (starting at line 1130):

Code: Select all

        /* If the local UDP port is non-zero, the connection is considered
           to be used. If so, the local port number is checked against the
           destination port number in the received packet. If the two port
           numbers match, the remote port number is checked if the
           connection is bound to a remote port. Finally, if the
           connection is bound to a remote IP address, the source IP
           address of the packet is checked. */
        if(uip_udp_conn->lport != 0 &&
           UDPBUF->destport == uip_udp_conn->lport &&
                  (uip_udp_conn->rport == 0 ||
                   UDPBUF->srcport == uip_udp_conn->rport) &&
           (uip_ipaddr_cmp(uip_udp_conn->ripaddr, all_zeroes_addr) ||
            uip_ipaddr_cmp(uip_udp_conn->ripaddr, all_ones_addr) ||
            uip_ipaddr_cmp(BUF->srcipaddr, uip_udp_conn->ripaddr))) {
            goto udp_found;


Let's focus on these two lines of that conditional:

Code: Select all

  (uip_udp_conn->rport == 0 ||
       UDPBUF->srcport == uip_udp_conn->rport) &&


Basically, the packet is a valid packet for the current UDP connection if the source port is 0, or if the incoming source port matches the previously set source port.

So this confirms the behavior that you are seeing. After the first incoming UDP datagram, the listening port is 'locked' to the source port that was originally sent. Any subsequent UDP datagrams coming from your application will not likely have the same source port so they will be ignored.

I checked the latest version of uIP and in uip.c the bug is not present. In the latest version they do not set the source port to the current source port if it is zero.

If you would like for the TCP/IP stack to do what it is supposed to when binding to a UDP port, then simply remove these 3 lines from uip.c:

Code: Select all

    if (uip_udp_conn->rport == 0) {
        uip_udp_conn->rport = UDPBUF->srcport;
    }


Regards,
RJ Ryan

[GregEigsti]

Nice! Thanks for sharing this!

I need to take a look at the code and fully understand what is happening but I wonder if a better fix is to set rport (so that the app has access to it) but loosen the check around line 1130? Since UDP is connectionless one of these fixes seem like the right thing to do - I'm just worried that by not setting rport we lose data. Dunno, need to study that code.

This may also solve the UDP reliability problem which I can repro; but I'd need to take a look to be sure.

Thanks!
Greg

[rryan]

Hi Greg,

I actually originally did what you are suggesting until I noticed that the conditional remains in uIP 1.0, but the setting of rport is not done in uIP 1.0. I decided to go with the "official" uIP bugfix.

Out of curiosity, which version of uIP did you base the WiShield driver on?
Cheers,
RJ Ryan

[GregEigsti]

I claim complete ignorance and innocence I am not the author nor an employee of AsyncLabs - just someone who finds their stuff compelling. I do maintain the user contrib branch however and your post has got me thinking of maybe inserting the latest uIP stack into that branch - I thought uIP was "dead" and no longer maintained - glad to know I was wrong!

Check out the user contrib branch - we have DHCP, DNS, AP scanning, bug fixes, etc.

Thanks for that fix and post - I'll definitely take a look - probly not till the weekend though.

Greg

[karmakazi]

I have been lurking around these boards for a couple of weeks ever since I got my wishield. For every question I searched there seems to be one person who is always there with the answer...Greg... so a big THANKS to you! You may not be a employee of Async Labs but if it were not for you I would have tossed this board in a drawer and given up completely.

Anyway I'm just here to say "me too". I have been banging my head against a wall because the wishield seemed to lock to a port and I need it to accept data even if the port changed. It's good to hear that my assumptions were right. I am going to try this fix tonight but I was wondering, has this been updated in the user contrib branch?

Thanks for finding the bug rryan.

[GregEigsti]

I would have tossed this board in a drawer

Don't do that! Send it to me!

It has not been fixed in the user contrib branch because I am not sure what the correct fix is (rryan's or my suggested variant) and I have not had time to look myself to figure it out. Truth be told there has not been any "traffic" on this issue for a while and I forgot about it

Though hats off to rryan for nailing this one down - it may be the same issue that I have hunted for hours upon hours (thats why I think I can repro it pretty quickly/easily).

I am feeling green and may just stay home sick tomorrow - should be an easy repro - if I can get it to repro and have some time to mess with it I'll update the user contrib branch. There are a few other changes I have thinking of making (namely percolating more "common" stack settings to apps-conf.h...

Flattery will get you everywhere
Thanks!
Greg

[GregEigsti]

BTW - meant to say - if you apply rryan's fix please let us know how it works for you!

Greg

[karmakazi]

It works... but there seems to be a delay at the beginning and I think some data is being lost. For my purposes this isn't a problem.

So yes Ryyan's tip stops the wishield's UDP connection from getting stuck on one port. I'll write it up in more detail tonight.