I have been able to compile my code (initially developed for an NXP device) using the POSIX port and run it on my Linux devices. I’m using the network interface for Linux provided in the repository (at
portable/NetworkInterface/linux/NetworkInterface.c). It successfully runs on a Pi, opens a listening socket and accepts incoming connections. However, I can’t get it to work with a loopback type of interface.
I set the interface number (using
configNETWORK_INTERFACE_TO_USE) to the number that represents my
lo interface. I set the IP address to
127.0.0.2 and disabled DHCP. Am I missing something in the configuration?
I have a guess that this has something to do with the NetworkInterface.c implementation and that it might need to work with loopback devices through libpcap a bit differently. Any thoughts on that?
Hi @vala ,
Thanks for posting in our forum.
I understand that you are using FreeRTOS+TCP stack and using the Linux portable layer (portable/NetworkInterface/linux).
Are you referring to the local loopback device, that the linux systems use to communicate with itself
Hi @Shub, thanks for your reply!
That’s correct. I’m using the FreeRTOS+TCP stack and the Linux portable network interface.
I want to communicate with the software on the same machine. So I tried configuring
configNETWORK_INTERFACE_TO_USE to my
lo interface, but couldn’t get it to work.
lo, yes, I’m referring to the loopback interface exposed by the Linux OS and used for communications on the same machine (it is printed by
ip a for example). But that aside, is there any way I can establish TCP connections with my FreeRTOS-based software on the same machine (not a local network)? The software is compile for Linux using FreeRTOS-simulator-for-Linux.
I’d strongly suggest use a separate machine on the local network.
But, if you really want to try, then modify your
configNET_MASK[0-3] in FreeRTOSConfig.h to match the loopback’s netmask and then give your code a try.
If it still does not work, try modifying the code here like so:
- sprintf( pcap_filter, "broadcast or multicast or ether host %x:%x:%x:%x:%x:%x",
+ sprintf( pcap_filter, "broadcast or multicast or ether proto loopback or ether host %x:%x:%x:%x:%x:%x",
I have not tested/tried the above and so it might not work at all since the we are relying on pcap here and if it doesn’t give the packets to the +TCP driver, we don’t have a way to snoop in on the loopback interface.
Let us know if that works for you or not.
Hi @vala ,
Thanks for clarifying.
Usually Linux and other systems support bridging. And this bridging layer will have a pre-bridge hook which taps the packets just before they reach the bridge to loopback the packets sent on “lo” interface.
However, we do not support “bridging” in FreeRTOS-plus-TCP as of now.
Some code can be added to achieve this but a good alternative, in my opinion, to this would be to use the “MAC Level Loopback” or “PHY level Loopback”.
All the MAC and PHYs will have a bit to be set which will enable this.
What is this software that you want to communicate with? Is it running in the same application using FreeRTOS+TCP or is it some other software which runs on the same PC. If later, you should be able to use the PC’s IP address to communication with it.
For example, lets say the PC has IP address
192.168.1.10 and the +TCP stack is assigned the address
192.168.1.11, then +Tcp, should be able to talk to PC using the IP address
I am curious now how this would even be possible, because I never thought that you would be able to use loopback to communicate between FreeRTOS and the linux host in such a setup. (see e.g. Create and bridge virtual network interfaces in Linux - Server Fault )
I would expect Loopback to never leave the FreeRTOS “machine”, but loop back into FreeRTOS only, which would make it very weird (actually wrong) to me if you could speak to the linux machine using the loopback address.
In fact if FreeRTOS+TCP is implementing loopback the way it is defined in the RFC’s I would expect the packets to never even go to the pcap interface, they should just be passed back up the stack and if there are no FreeRTOS tasks listening for the packets they should be dropped.
At least on loopback that is the behavior I expect.