I'm porting the FreeRTOS+UDP simulation to the LPCXpresso environment. It's mostly there but I have a suspicion there's something strange going on with the Address Resolution Protocol.

Watching packets with Wireshark, I see that the echo clients send out echo request messages that appear to be properly formatted, but never get a reply. I know the echo server is working because I connected to it from my virtual Linux machine.

Both network ports are broadcasting ARP requests to find out who 192.168.1.2 is (that's my FreeRTOS simulation), but apparently aren't getting a response. Also I can't get to the CLI from YAT, again probably because address resolution hasn't completed properly.

Any hints? Clues? Has anyone else seen similar behavior?

TIA

I'm porting the FreeRTOS+UDP simulation

Is this the FreeRTOS Win32 simulator version?

I see that the echo clients send out echo request messages that appear to be properly formatted, but never get a reply

Are the echo clients on the FreeRTOS side? So the FreeRTOS client sends a message to the server. What is the server running on?

Both network ports are broadcasting ARP requests to find out who 192.168.1.2 is (that's my FreeRTOS simulation)

Sorry, I'm confused. If 192.168.1.2 is the FreeRTOS node, which are the other two network ports...and I thought FreeRTOS was now running on an LPCXpresso?

As I recall in the simulator there is both a client and a server running at the same time - on the same node. So the simulator effectively talks to itself. Is that what your LPCXpresso project is attempting to do too? If so I don't think that would work on real hardware, with a real network MAC and PHY because it won't see its own traffic - whereas the simulator does see its own traffic.

Regards.

Yes, it is the FreeRTOS Win32 simulator. I'm using the LPCXpresso Eclipse IDE to build and run the program.

The client/server pair works fine. Then there are two clients (one zero-copy, the other not) that talk to a standard echo server. The server is running on my Windows 7 workstation. As I said previously, I know the server is working because I can telnet to it either from a Windows shell or my virtual Linux machine.

The workstation itself has two network ports: Ethernet at 192.168.1.191 and WiFi at 192.168.1.192. I'm connecting FreeRTOS to the Ethernet port with address 192.168.1.2. The echo clients attempt to access the server at 192.168.1.191. It just occurred to me that maybe the problem is trying to talk to another node using the same interface, so I tried changing the server location to 192.168.1.192 and got the same thing.

In either case FreeRTOS appears to correctly resolve the MAC address for the server. The reverse does not seem to be true. Both 192.168.1.191 and 192 are continually broadcasting ARP requests inquiring about 192.168.1.2, but apparently getting no response.

Hi Doug,

It can be confusing to have two NIC's with an address in the same range.

What you could try is, e.g. assign:

- 192.168.2.192 to Wifi
- 192.168.1.191 to Ethernet / LAN

both with a netmask of 255.255.255.0.

I'm not sure about your W32, but Linux might receive a packet on the ETH and send a reply through WiFi, because they belong logically to the same network.

If the networks are different (192.168.1.x versus 192.168.2.x), the routing becomes very predictable.

Regards.

Turns out the header structures weren't being packed properly. packstructend.h for GCC looks like this: attribute( (packed) )

So as a shot in the dark I added a space after attribute and lo and behold the structures are now properly packed. There's still something funny going on with the Sender and Target addresses that I have to sort out, but I'm making progress.

I just checked the file and found it to contain the following:

__attribute__( (packed) );

That looks valid, and I'm not sure that changing it to:

__attribute__ ( (packed) );

makes any difference?

Regards.

Oops, the double underscores got deleted from my post. They really are there.

Indeed, adding a space after __attribute__ didn't do anything. I was fooled by looking at an ARP transaction of the simulator talking to itself.

So fundamentally, __attribute__( (packed) ) doesn't seem to be working. Fortunately, GCC also supports the MS compiler #pragma mechanism. So I substituted packstructstart.h and packstructend.h from the MSVC directory and it works!

Hey Richard,

Question: Why did you use this construct #include "packstructstart.h", #include "packstructend.h" rather than just define macros?

Thanks, Doug

So fundamentally, attribute( (packed) ) doesn't seem to be working

That is very interesting. I have been hit by that GCC bug myself, but never on an ARM architecture. Which GCC version are you using.

In code I wrote for another project I added an assert() into the code that took the sizeof() a structure and compared it to the expected value as a sanity check that the structure packing was working.

Why did you use this construct #include "packstructstart.h",

include "packstructend.h" rather than just define macros

Indeed, for a very good reason, I just can't remember exactly what the reason was. Macros were used originally, but we got into a situation where they couldn't cope with something, I just remember what that something was.

Regards.

This is MinGW generating x86 code with gcc version 4.8.1.

Right - that is the same compiler bug I have experienced then, on x86.

Regards.