TCP over a PPP serial proxy route

Steve Packwood

Hello,

I'm trying to establish a TCP connection over a PPP serial link to a cell modem attached my Tiva TM4C1294N device and a host PC.

I'm able to pass UDP traffic between my host PC and Tiva device over the cell modem link. I'm able to establish a TCP connection between the host PC and Tiva device if I use a direct Lan connection.

As a test, I was able to establish a TCP connection by adding a static route for my host PC. This seems to suggest that the problem is not with the PPP link or the modem but rather with the proxity route in the table.

The PPP proxy route to the cell modem is address 192.168.15.31. I know that a TCP connection can be made over a PPP link from the TCP echo example and my test of creating a static route but I'm not sure why it isn't working over this proxy route. What I mean by not working is I call the function accept(,,,,) and it never returns as if there was no connection attempted. I can look at the serial traffic over the PPP link and see the connection attempt get to the device but it seems to be getting discarding before making to my socket.

Does anyone have any suggestions of things I can try or any theories about why this doesn't work? Thanks.

over 9 years ago

0 Gilbert Rodriguez III over 9 years ago

TI__Intellectual 2275 points

Can you check if your packet is reaching the NIMU layer? We need to find out where the packet is being dropped.

You can set a breakpoint at the following function found it ti/ndk/stack/nimu/nimu.c:

int NIMUReceivePacket (PBM_Handle hPkt)
{
...
    /* Dispatch the Packet to the appropriate protocol layer. */
    switch( Type )
    {
        case 0x800:
        {
            /* Received packet is an IP Packet. */
            IPRxPacket( ptr_pkt ); // do you get here???
            break;
        }
...

Regards,

Gilbert

0 Steve Packwood over 9 years ago in reply to Gilbert Rodriguez III

Intellectual 450 points

Gilbert,

I'm not able to set a breakpoint here. I get a message from the Breakpoint Manager saying: " No code is associated with C:......nimu.c line 282 in any loaded symbols. I have compiled the NDK in debug mode by uncommenting out the 5 lines in ndk.bld and I have tried setting software and hardware breakpoints. Is there some other setting I have missed?

0 Gilbert Rodriguez III over 9 years ago in reply to Steve Packwood

TI__Intellectual 2275 points

Have you tried right-clicking in the Breakpoints tab to see if it will allow you to add a breakpoint at NIMUReceivePacket? If it doesn't, will it allow you to add one at NIMUPacketService?

0 Steve Packwood over 9 years ago in reply to Gilbert Rodriguez III

Intellectual 450 points

I can't put a breakpoint in any stack code currently.

0 Gilbert Rodriguez III over 9 years ago in reply to Steve Packwood

TI__Intellectual 2275 points

Can you open up the map file and see if the NIMUReceivePack and/or other NDK symbols are in there?

0 Steve Packwood over 9 years ago in reply to Gilbert Rodriguez III

Intellectual 450 points

They are in there. I think my breakpoint problem was due to the fact that I recompiled the stack into a different directory name and then renamed the directory back to the default ndk_2_25_00_09. I am able to set the breakpoint now. It doesn't hit IPRxPacket() in nimu.c but rather IPRxPacket() in nimuppp.c. I should be able to step through and see what's happening now. Thanks for pointing me in the right direction. I'll post back what I find.

0 Steve Packwood over 9 years ago in reply to Steve Packwood

Intellectual 450 points

It looks like the stack isn't using the correct route when sending back TCP packets in response to the connection request. When I put a break point at PBM_setRoute and look at the route selected, it is selecting the gateway route on the Ethernet interface rather than the proxy route in the table on If-2.

In tcpout.c

/* Indicate the preferred route */
PBM_setRoute( pPkt, SockGetRoute( pt->hSock ) );

    /* Count it */
    tcps.SndTotal++;

    /* Send the packet */
    error = IPTxPacket( pPkt,
                        SockGetOptionFlags(pt->hSock) & FLG_IPTX_SOSUPPORTED );

0 Steve Packwood over 9 years ago in reply to Steve Packwood

Intellectual 450 points

Gilbert.
I came up with a patch to temporarily solve the problem. In TCPInput() in tcpin.c there are 2 places where "hSock = SockPCBResolve()" is called. Right after these 2 calls, I added the following code:

if (hSock)
{
ps = (SOCK *) hSock;
ps->hRoute = pPkt->hRoute; /* Set the route to match what same route as the income TCP packet */
}

And then in llserial.c in the function llSerialService.c:

if (sdi[dev].cbInput)
{
/* Add a function that sets the hRoute in hPkt to the route that should be used to send back TCP traffic on.
What we set hRoute to here will then appear in pPkt->hRoute of TCPInput() which we will use to
populate the created TCP socket with */

newFunct((PBM_Pkt *) hPkt); // Walk the route table and determine our route and set hRoute with it
sdi[dev].cbInput(hPkt);
}

Ultimately, I think the IPGetRoute() function in the stack needs to be a litle smarter so it looks for proxy routes and looks on the correct interface so when a TCP connection request comes in, it will choose a route that is on the same interface as the incoming request. If you could pass this on to the stack experts, I'm sure they will know the best way to correctly fix this.

0 Steven Connell over 9 years ago in reply to Steve Packwood

TI__Mastermind 45025 points

Hi Steve,

It definitely seems like there's an issue here. I've a bug report to ensure that this is tracked and looked at:

NDK-114 IP packets recv'd when multiple IFs present may be replied to on wrong IF

Steve

Processors

Processors forum

TCP over a PPP serial proxy route