+TCP multi static and ARP issues

Libraries
21

Also adding, mDNS needs to explicitly set the endpoint somewhere, weighting the prvFillSockAddress to choose up interfaces results yields an empty endpoint, requiring adding

        if( pxEndPoint != NULL )
        {
            xDNSSocket->pxEndPoint = pxEndPoint;

in prvGetHostByNameOp

22

@htibosch Do you have any suggestion here?

23

@aggarg

Earlier I wrote:

~~~

     #if ipconfigIS_ENABLED( ipconfigUSE_IPv4 )
+        /* __HT__ Should be done only if all network interfaces are down. */
         vIPSetARPTimerEnableState( pdFALSE );
     #endif

~~~

Actually this is the only place where the timer can be disabled. So if one out of two interfaces goes down, the other will not have timer-driven services. vARPAgeCache() and vARPSendGratuitous() won’t be called any more.

Shall I write a PR for this?

24

If you think this is the right change, please go ahead.

25

@htibosch I’m not sure this is enough, but its fine with me.

I really believe this is more of an architecture issue. +TCP is also a free offering, so I really can’t require FreeRTOS to fix this, or fix it the way I see the problem. Also, htibosch obviously has other irons in the fire, and that is understandable, so hopefully FreeRTOS adds some other experienced network architects to the project.

The core issue , at least the way I understand, is that the routing and selection layer needs to be more context aware. The way it is now, its really chance and the order the interfaces were added to FreeRTOS TCP that decides which interface the outbound packet goes out on, rather than proper metrics like, is this interface active, etc.

So to make this work in a reasonable fashion and get this shipped, I modified this to work for me, and I’ve attached the diff file based on 4.3.3 to what I ended up at.

tcp-4.3.3.patch (13.9 KB)

26

Thanks for the patch, but could you send the sources files as C files? The easiest if you just ZIP the source files and attach them to your post?

Your post mentions several problems:

  • vARPAgeCache() is not being called
  • And therefore, gratuitous ARP packets won’t be sent

Earlier you wrote:

I don’t think vARPAgeCache() is ever called by the stack. If I breakpoint at

That is solved: it occurred when you have to interfaces: one being up and the other one going down. That would disable the ARP timer for ever:

vIPSetARPTimerEnableState( pdFALSE );

And also:

Well, I can’t find anywhere it is enabled in code once disabled. Shouldn’t this happen on network up?

When an interface goes up, it will call:

void vIPNetworkUpCalls( struct xNetworkEndPoint * pxEndPoint )

which will set the ARP timer and get it running:

static void prvIPTimerStart( IPTimer_t * pxTimer, TickType_t xTime )

As I wrote earlier, the ARP timer doesn’t have to be switched off.

First I would like to have this solved: have vARPAgeCache() and vARPSendGratuitous() called regularly.

In the next step we can look at the end-point issues.

Hein