Quality RTOS & Embedded Software

 Real time embedded FreeRTOS RSS feed 
Quick Start Supported MCUs PDF Books Trace Tools Ecosystem TCP & FAT




Loading

ARP in FreeRTOS+UDP

Posted by digitalwiz on November 5, 2014

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


ARP in FreeRTOS+UDP

Posted by rtel on November 5, 2014

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.


ARP in FreeRTOS+UDP

Posted by digitalwiz on November 5, 2014

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.


ARP in FreeRTOS+UDP

Posted by heinbali01 on November 6, 2014

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.


ARP in FreeRTOS+UDP

Posted by digitalwiz on November 11, 2014

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.


ARP in FreeRTOS+UDP

Posted by rtel on November 12, 2014

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.


ARP in FreeRTOS+UDP

Posted by digitalwiz on November 12, 2014

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


ARP in FreeRTOS+UDP

Posted by digitalwiz on November 13, 2014

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!


ARP in FreeRTOS+UDP

Posted by digitalwiz on November 13, 2014

Hey Richard,

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

Thanks, Doug


ARP in FreeRTOS+UDP

Posted by rtel on November 14, 2014

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.


ARP in FreeRTOS+UDP

Posted by digitalwiz on November 15, 2014

This is MinGW generating x86 code with gcc version 4.8.1.


ARP in FreeRTOS+UDP

Posted by rtel on November 15, 2014

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

Regards.


[ Back to the top ]    [ About FreeRTOS ]    [ Sitemap ]    [ ]




Copyright (C) Amazon Web Services, Inc. or its affiliates. All rights reserved.

Latest News

FreeRTOS kernel V10 is available for immediate download. Now MIT licensed.


FreeRTOS Partners

ARM Connected RTOS partner for all ARM microcontroller cores

IAR Partner

Microchip Premier RTOS Partner

RTOS partner of NXP for all NXP ARM microcontrollers

STMicro RTOS partner supporting ARM7, ARM Cortex-M3, ARM Cortex-M4 and ARM Cortex-M0

Texas Instruments MCU Developer Network RTOS partner for ARM and MSP430 microcontrollers

OpenRTOS and SafeRTOS