FreeRTOS+TCP routing from interface to interface

Libraries
1

Hi,
I was wandering if the current multi-interface version of FreeRTOS+TCP is designed to route between interfaces OR is it designed to simply be a multi-homed stack. I don’t think it is designed for routing, but I wanted to find out what the design goal was instead of drawing conclusions from bits and pieces of the code.
For the sake of the argument, let’s just assume the following scenario ( all netmasks are 255.255.255.0 )

    [PC-A 192.168.0.7]----[(192.168.0.1) FreeRTOS+TCP (10.0.0.1)]----[PC-B 10.0.0.5]
[Misconfiged 10.0.0.9]-/

PC-A’s gateway is 192.168.0.1
PC-B’s gateway is 10.0.0.1
Misconfigured PC’s gateway is 10.0.0.1

  • If PC-A tried to ping PC-B, is it supposed to succeed?
  • If PC-A tried to ping 10.0.0.1, is it supposed to succeed?
  • If the misconfigured PC tried to ping the FreeRTOS+TCP host, is it supposed to succeed?
  • If the FreeRTOS+TCP host tried to ping 10.0.0.9, is it supposed to succeed?

Please don’t read to much into why I’m asking these. I’m not trying to make a router, I just want how what the code was planned for. I fully expect all the answer above to be a “No”.

Thanks in advance

2

@epopov Multiple endpoint support was added to FreeRTOS+TCP primarily to allow concurrent IPv6/IPv4 addresses. Multiple interface support came along with this. Routing packets between interfaces is not currently supported and the stack is primarily client-focused.

That said, we’re always open to contributions if you would like to implement routing.

3

Thanks for the clarification @PaulB-AWS
I don’t have any interest in the routing part. I just have a few possible changes that I will be proposing and wanted to make sure that I understand the original intent of the team.
I can see it being “cool” to support routing between interfaces, but it’s probably outside the scope of what most FreeRTOS+TCP projects need. I feel that making a router will be much better handled by an embedded Linux device, so I don’t think we should burden the code with this feature.

Have a nice day, and thanks again for the insight

4

Hi @epopov ,
Let me share the thoughts behind the existing design:

  1. FreeRTOS-plus-TCP stack to allow concurrent IPv6 and IPv4 traffic and hence support multiple endpoints on the same physical interface
  2. FreeRTOS-plus-TCP stack is presently designed to work on end devices, whose job is to just receive the packet on the destined interface and accept/drop
  3. Being an end-device FreeRTOS-plus-TCP not to support bridging, hence the endpoints will act an parallel tunnels with no traffic flow across tunnels.

However, I understand that you have some changes. Please share the same and we will be happy to discuss and understand more on the same.

5

Thanks for your thoughts @Shub

All the changes that I have been thinking of are just small bug fixes and currently, all of them are in the issues or PR sections on github. I posted this question here before creating PR #1094.
If FreeRTOS+TCP was designed for routing, then it would make sense to allow reception of a packet on one interface if the packet was destined for another interface. That is wat routers do. Once I got my answer, it was apparent that what I had found was a bug so I created PR #1094. That’s all.

Again, thanks a lot!

1 Like