UDP initialization

[emblem]

I've been fiddling with the UDPApp example. It works, but I have to run the PC UDP code three times before it will respond after booting the arduino. I added some debug code to uip.c and stack.c to try to figure out what was going on. It looks like network_read() is returning <= 0 until the third UDP packet is sent from the PC. Has anyone else seen similar problems?

Stuart

[GregEigsti]

Are you waiting for the WiShield's "I'm ready to go" red LED comes on before hitting it from the PC? Have not played with the UDP sample myself.

[emblem]

Yes. The red light is on, and I can ping the device. I can even see the pings show up at 104 byte returns from network_read, but it still takes 3 UDP packets before anything shows up.

Stuart

[GregEigsti]

How much have you modified the UDP app sample code? What are you using from the PC to tx/rx UDP packets? Mind posting your code so that others can take a look (assuming it is not just the stock sample app)?

Greg

[emblem]

I am able to reproduce the issue using only modified network parameters (WEP, 64 bit key, local ip = .1.20) and changing the remote IP in udpapp.c (to .1.4).

This is interesting: sometimes it takes 4 tries, and gives weird behavior on the 4th (replies with "Hello Hellome?"):
The client code is copied directly from the wiki, the only change is to the IP address we talk to.

Code: Select all

soa@flit:~$ ./upe
Hello
^C
soa@flit:~$ ./upe
Hello
^C
soa@flit:~$ ./upe
Hello
^C
soa@flit:~$ ./upe
Hello
Hello Hellome?
^C
soa@flit:~$ ./upe
Hello
Hello. What is your name?
dfs
Hello dfs


[GregEigsti]

I was reviewing the WiShield UDP sample app and the uIP documentation to understand what was going on in the sample sketch. The sample UDP sample sketch's use of uip_udp_new() looked weird to me as its rport param was set to HTON(0) (port 0). My only thought was that this might be for broadcast UDP but then that does not really fit in with the sample app for the PC on WiShield's wiki. If you look at the sample code from the uIP docs it you will see that the second param to uip_udp_new() is HTONS(12345) which makes a heck of a lot more sense to me given the context. What happens if you change your call to uip_udp_new() to match what is in the uIP docs? It certainly matches the sample PC code... A typo in the WiShield UDP sample?

WiShield UDP Sample

Code: Select all

c = uip_udp_new(&addr, HTONS(0));
if(c != NULL) {
   uip_udp_bind(c, HTONS(12344));
}

uIP doc sample code

Code: Select all

c = uip_udp_new(&addr, HTONS(12345));
if(c != NULL) {
   uip_udp_bind(c, HTONS(12344));
}

Link to uIP docs - which the WiShield uses as its TCP/IP implementation
http://www.sics.se/~adam/download/uip-1.0-refman.pdf

Greg

[emblem]

Thanks, good thought. If you look at the uip docs you'll note that they say the port can be changed when the connection is bound later on. It's implemented as just an assignment to the rport field. I just tried your suggestion anyway, just to be sure, and it had no effect. I'm going to poke at it with wireshark for a bit and see if I can learn anything that way.

Stuart

[GregEigsti]

WireShark - love it! Good idea.

I still think that the uIP docs are "more correct" (or at least more clear); uip_udp_new() sets rport, or the remote port to connect to and uip_udp_bind() sets lport, or the local port that can be connected to. I have not played with UDP alot, and mostly with broadcast, but I'm pretty sure to achieve a two way conversation with UDP there must two "channels" or two sets of ports and each device connects to a remote port (rport). So two unidirectional socket connections are used rather than a bidirectional socket connection (as with TCP). The uip_udp_new() code actually does play around with lport but the values that it uses are all "cached" values and I have not taken the time to understand the code.

If I can manage to stay awake after I get home I can try this stuff out. But I aint gonna reconfigure the home wireless net to be 64 bit wep
There is another thread here that talks about smaller WEP keys (40 bit maybe?) and that requires a change or two to the WiShield/uIP code to get that support. Dunno, worth looking for.

Greg

[emblem]

I have the same errors using no WEP and 128bit WEP. Wireshark shows nothing unexpected, just UDP going from my PC to the WiShield, and then no replies until the 3rd or 4th packet.

[GregEigsti]

Hmmm, k. I use 128 WEP here and will give it a try. The kids are in bed, the wife upstairs reading and I am downstairs with the TV on and my laptop

Update - same problem here; except mine never works.