UDP problem

I have an R6k application that uses UDP broadcast messaging. And it seems to work fine. On our R3000 products we also use UDP, and we also use Scott Henion's UDPDownload feature which also uses a UDP socket. I am trying add Scott's method of device identification to my R6k app. But I've been unable to get it to work.

I'm using 3 UDP sockets, on port 2100, for our system communication. The ID socket is on port 2000.
I have these defines.

#define UDP_BUF_SIZE 256
#define UDP_SOCKETS 3
#define MAX_UDP_SOCKET_BUFFERS 8

I open the ID socket the same way as the other sockets, it opens with no errors:

if ( !udp_extopen( &udp_dl_sock, IF_DEFAULT, 2000, -1, -1, NULL, 0, 0) ) {
printf("UDPDL-udp_open socket failed!\r\n");
return 1;
}
....
Then I check the socket for broadcast packets.

len = udp_recvfrom( &udp_dl_sock, buff, sizeof(buff), &ip, &port );
if ( len < 0 ) return;

I never get any packets.

Using Wireshark I see the broadcast UDP datagram being sent by the host. The datagram contains 8-bytes of data per Scott's format. All other devices see the datagram and respond accordingly. But not the R6k device.

I then added #defines UDP_DEBUG and UDP_VERBOSE, and set debug_on to 5, which generates lots of output. Running the same test, the UDP library prints out that it got the broadcast packet, and that's it. I never get it via udp_recvfrom(). Here is paste of the relevant printout showing that the packet was received. You can see the received packet near the middle at port 2000. Notice that it doesn't say "no applicable socket". So it did associate the datagram with the open socket.

UDP: got pkt 0AFA056B:137 -> 0AFA05FF:137 payloadP i/f=0
UDP: no applicable socket
UDP: got pkt 0AFA0568:137 -> 0AFA05FF:137 payloadP i/f=0
UDP: no applicable socket
UDP: got pkt 0AFA0535:59454 -> FFFFFFFF:1947 payload@ i/f=0
UDP: no applicable socket
UDP: got pkt 0AFA0553:137 -> 0AFA05FF:137 payloadP i/f=0
UDP: no applicable socket
UDP: got pkt 0AFA053E:58143 -> FFFFFFFF:2000 payload=8 i/f=0
UDP: got pkt 0AFA055E:137 -> 0AFA05FF:137 payloadP i/f=0
UDP: no applicable socket
UDP: got pkt 0AFA056B:137 -> 0AFA05FF:137 payloadP i/f=0
UDP: no applicable socket
UDP: got pkt 0AFA0568:137 -> 0AFA05FF:137 payloadP i/f=0
UDP: no applicable socket
UDP: got pkt 0AFA0553:137 -> 0AFA05FF:137 payloadP i/f=0

I'm at a loss as to how to proceed. Any suggestions?

Steve Start a New Thread

Do you need:

#define UDP_SOCKETS 4

3 for your stuff and 1 for the other?

On 7/11/2014 1:50 PM, s...@yahoo.com [rabbit-semi] wrote:
>
> I have an R6k application that uses UDP broadcast messaging. And it
> seems to work fine. On our R3000 products we also use UDP, and we also
> use Scott Henion's UDPDownload feature which also uses a UDP socket. I
> am trying add Scott's method of device identification to my R6k
> app. But I've been unable to get it to work.
> I'm using 3 UDP sockets, on port 2100, for our system communication.
> The ID socket is on port 2000.
>
> I have these defines.
> #define UDP_BUF_SIZE 256
> #define UDP_SOCKETS 3
> #define MAX_UDP_SOCKET_BUFFERS 8
>
> I open the ID socket the same way as the other sockets, it opens with
> no errors:
> if( !udp_extopen( &udp_dl_sock, IF_DEFAULT, 2000, -1, -1, NULL, 0, 0) ) {
>
> printf("UDPDL-udp_open socket failed!\r\n");
>
> return1;
>
> }
>
> ....
>
> Then I check the socket for broadcast packets.
> len=udp_recvfrom( &udp_dl_sock, buff, sizeof(buff), &ip, &port);
>
> if( len< 0) return;
> I never get any packets.
> Using Wireshark I see the broadcast UDP datagram being sent by the
> host. The datagram contains 8-bytes of data per Scott's format. All
> other devices see the datagram and respond accordingly. But not the
> R6k device.
> I then added #defines UDP_DEBUG and UDP_VERBOSE, and set debug_on to
> 5, which generates lots of output. Running the same test, the UDP
> library prints out that it got the broadcast packet, and that's it. I
> never get it via udp_recvfrom(). Here is paste of the relevant
> printout showing that the packet was received. You can see the
> received packet near the middle at port 2000. Notice that it doesn't
> say "no applicable socket". So it did associate the datagram with the
> open socket.
> UDP: got pkt 0AFA056B:137 -> 0AFA05FF:137 payloadP i/f=0
> UDP: no applicable socket
> UDP: got pkt 0AFA0568:137 -> 0AFA05FF:137 payloadP i/f=0
> UDP: no applicable socket
> UDP: got pkt 0AFA0535:59454 -> FFFFFFFF:1947 payload@ i/f=0
> UDP: no applicable socket
> UDP: got pkt 0AFA0553:137 -> 0AFA05FF:137 payloadP i/f=0
> UDP: no applicable socket
> UDP: got pkt 0AFA053E:58143 -> FFFFFFFF:2000 payload=8 i/f=0
> UDP: got pkt 0AFA055E:137 -> 0AFA05FF:137 payloadP i/f=0
> UDP: no applicable socket
> UDP: got pkt 0AFA056B:137 -> 0AFA05FF:137 payloadP i/f=0
> UDP: no applicable socket
> UDP: got pkt 0AFA0568:137 -> 0AFA05FF:137 payloadP i/f=0
> UDP: no applicable socket
> UDP: got pkt 0AFA0553:137 -> 0AFA05FF:137 payloadP i/f=0
> I'm at a loss as to how to proceed. Any suggestions?
> Steve
> Start a New Thread

I thought of that, but it doesn't matter. That particular define is not used by DC. It's only used by my application to define the number of system communication sockets to open. I even removed opening any UDP sockets except for the one for ID on port 2000, and it didn't make a difference.

Here's another data point I just received. If I use Scott Henion's Ethernet Downloader utility and do a search, the R6k device responds as it should. But if use our internal utility the R6k never gets the packet. So I used Wireshark and captured both UDP broadcast packets, the one from Scott's utility and the one from ours. I'm looking at them side-by-side, and they are identical except for two differences. The first is the Source Port is different for each application. I don't think that should matter. And I think that's the way Ethernet works. Each application gets its own source port number. The second difference is that the 8-bytes of data that Scott's utility sends are a 1 and seven zeros, while our utility has some scattered bits set. Again, I don't see how or why the value of the 8-data bytes would affect the packet being received or not. I could see my application getting the packet and after parsing the 8-data bytes decide to throw it away because it had an error. But my app never even gets the packet.

And one more data point. Both utilities, Scott's and ours, work with the R3000 devices. It's only the R6000 that has the problem.

Steve Start a New Thread

So now I've delved into stepping through the DC UDP library. Maybe one you DC network experts can help me understand this. I've removed all other UDP sockets except for this ID socket for this test.

When a broadcast datagram arrives, it makes it all the through udp_handler(). The last statement in udp_handler() before returning is this:

// Is there enough space? If not, then just drop it
if ((len + sizeof(_udp_datagram_info)) <= _tbuf_remain(&s->rd)) {
_tbuf_append(&s->rd, (char __far *)&udp_datagram_info, sizeof(_udp_datagram_info));
_tbuf_bappend(&s->rd, LL, dp, len);
}

It appears that at this point the handler has determined that the packet is for "us", and the 'if' statement determines if there is enough room for the data. At the 'if' the result is TRUE so it appends the data to the socket buffer. The value of "len" is 8, which matches the data in the packet. Then the function returns.

I have breakpoint at udp_peek() and step into it right after leaving udp_handler().

int udp_peek(udp_Socket* s, _udp_datagram_info __far * udi)
{
auto int rc;

LOCK_GLOBAL(TCPGlobalLock);
LOCK_SOCK(s);

if (s->rd.len < sizeof(_udp_datagram_info)) {
UNLOCK_SOCK(s);
UNLOCK_GLOBAL(TCPGlobalLock);
return 0;
}
rc = 1;
...
}

The 'if' statement fails so the function returns false, no packet. And when I look at s->rd.len it is 0. What happened to all the data that was copied to the buffer back in udp_handler()?

Steve Start a New Thread