UDP broadcast, no response

One thing that I observed in your setup:  The IP address of your PC and the IP address of your EK are on different subnets.  Since the subnet mask for both devices is 255.255.255.0, the fact that the third address octet is different (33 vs 34) means that the packet will not go through.  This is confirmed since it works when you change the address octet on the PC from 33 to 34.

--Bobby

Hello Bobby

The UDP packet is sent from with a broadcast to all clients (independent from the subnet mask)

This data are received from the board (see dump of lwip-stack), receiving this data is working correct.

Than the board wants to return the respond data to the PC (see dump of lwip stack)

But this data are not transmitted on the Ethernet.

Regards,

Anton

Anton,

How is the EK connected to the PC.  Is it a direct connection?  Is it through a hub?  A switch?  A router?

I suspect that what might be happening is that since the EK and PC are configured on different subnets, even though the broadcast packet makes it through from the PC to the EK, the switch or router (if that is what you are connecting with) may be filtering the packet since the subnets do not match.  Or perhaps your PC filters the response packet such that even Wireshark does not capture it.

Are you enabling promiscuous mode in your Wireshark capture?

--Bobby

Bobby,

1. board connected direct to the PC
2. board connected to a switch
--> both same result, no reply from the devices

This is not a problem with different subnets!

____________________________________________
To verify the device discover, I made a test with different hardware.
(Lantronix UDS2100 (a ethernet to serial device) and Lantronix DeviceInstaller.exe)
PC : 192.168.33.254
Device: 192.168.2.22

The Lantronix discover software send a UDP broadcast 255.255.255.255 to all devices (all subnets)
The device return a UDP packet to the PC

==> This is a common practice to discover devices with unknown IP addresses on all subnets !
____________________________________________

Back to the LM3S9B92 board and the Finder.exe
PC: 192.168.33.254
board: 192.168.34.4

after the board receives the UDP broadcast from the Finder.exe,
the lwip-stack tries to send the response back to the PC.
see dump below:

+-------------------------------+
| 4 | 5 |  0x00 |       112     | (v, hl, tos, len)
+-------------------------------+
|        4      |000|       0   | (id, flags, offset)
+-------------------------------+
|  255  |   17  |    0xf625     | (ttl, proto, chksum)
+-------------------------------+
|  192  |  168  |   34  |    4  | (src)
+-------------------------------+
|  192  |  168  |   33  |  254  | (dest)
+-------------------------------+
netif->output()

==> this UDP packet in not transmitted on the ethernet, but should !

-- Anton

I've been working on reproducing your setup.  I have a question about how you are setting up you network interface.

How are you configuring the static IP for the EK?  I assume that you have simply modified the call to lwIPInit, changing the IP Address, Mask, and Gateway parameters.  If that is correct, what are the parameters you are using?  Specifically, what are you programming for the gateway address?

The reason I ask.  When I programmed my EK/PC with the addresses that you are using, I take a path through the "etharp_output" function (in lwIP/etharp.c) that will ultimately result in a check for the gateway address.  If it is zero, the function returns an error code without transmitting the packet (this is the path I take).  If it is non-zero, then it will do an arp query for the gateway, and attempt to send the packet via the gateway.

--Bobby

 
in enet_lwip.c I  set the IP address with lwIPInit()
 
...
#define MAKE_IP_ADDRESS(a0,a1,a2,a3) (((a0<<24) & 0xFF000000) | ((a1<<16) & 0x00FF0000) | ((a2<<8)  & 0x0000FF00) | (a3 & 0x000000FF) )
...
 
 
    //lwIPInit(pucMACArray, 0, 0, 0, IPADDR_USE_DHCP);
    lwIPInit(pucMACArray,
            MAKE_IP_ADDRESS(192,168,34,4),
            MAKE_IP_ADDRESS(255,255,255,0),
            MAKE_IP_ADDRESS(0,0,0,0),
            IPADDR_USE_STATIC);
 
___________________________
I debugged the code and an error was returned:
etharp.c (line 845)
 
return ERR_RTE;
 
Any Idea how to fix this problem?

The error code that is returned (ERR_RTE) indicates a routing problem.  This is happening because the destination IP address is outside the local network (etharp.c, line 836) and there is no gateway (router) address defined (etharp.c, line 842).

There are a few different ways that this issue can be addressed, but it depends on the reason why the IP address for the EK was chosen to be on a different network than your PC.  My knowledge networking/routing, etc. is limited, so the terminology I use might not be entirely correct.

The simplest solution is to ensure that both the PC and the EK are on the same network.  This means that both IP addresses must match when AND'ed with the network mask (this is the comparison that is being done in etharp.c, line 837).  In your default setup, the first three octets in the mask are all ones, so the first three octets in the IP addresses should be the same.  However, the PC has an IP address of 192.168.33.254, while the EK has an IP address of 192.168.34.4.  The "33" and "34" do not match. Since there is no gateway address programmed, the packet will not be transmitted, because the ethernet stack cannot find an address to send it to.

The next simplest solution would be to use a router with DHCP, and configure both the PC and EK to use DHCP.  The addresses provided would be on the same network, and the connection between the two devices should work.

If static IP addresses are required, and they must be on different networks, then a router could still be used, but a manual route table would need to be programmed to provide a connection between the two different IP addresses on different networks.

--Bobby

A discover tool like 'finder.exe' is required, if you don't remember the IP-address of your devices.
Finder.exe and the code in locator.c support this.
There is a bug in the lwip-1.3.2 stack.
The device try to send the UDP response to the PC (see dump) but the data are never transmitted on the ethernet.
etharp_output() return with error code ERR_RTE.
 
A lot of other discover-tools find all devices with any IP-address connected to the PC.
See this sample.

 
_________________________________________
In lwip-1.4.1  
A lot of modifications was done there in the etharp.c at function: etharp_output()
Is this bug fixed ???
Are there plans to port the lwip-1.4.1 to stellaris ?

Taking a quick look at the 1.4.1 code, it was not clear to me whether the changes would address this issue or not.  I will discuss this issue further with some of the engineers here who have better knowledge of networking/routing.  It may take a day or two to get an update to you on this.

I also did a quick look into networking address definitions (http://en.wikipedia.org/wiki/Private_network).  The 192.168 network is classified as 192.168.0.0/16.  The subnet mask that should be used with this prefix is 255.255.0.0.

In the test setup we have been discussing, changing the EK's subnet mask to match this definition would allow the packet through.  It may also be that Lantronix devices use the same subnet mask as defined for this private network address.

--Bobby

Bobby,

The IP 192.168.x.x is an address of a class C network.

Class C networks have the address range from 192.0.0.0 to 223.255.255.255 and the network mask 255.255.255.0

see http://en.wikipedia.org/wiki/IPv4_subnetting_reference

-- Anton

Often within an organization, the subnet mask may be altered a bit.  I've seen a number of organizations use 23 or 20 bit mask with 192.168.x.x to increase the number of available addresses on the local network.  I've also seen it go the other way with up to 28 bit mask.

One quick answer is to see what the local settings on the PC are, by running ipconfig (if running Windows) or ifconfig (if running Linux), and see what net mask is being used on the local network.  If a 23 bit mask is used, it will be 255.255.254.0, if a 20 bit mask is used, it will be 255.255.240.0, and of course other size masks are possible.