• State Resolved
  • Locked Locked
  • Replies 2 replies
  • Subscribers 31 subscribers
  • Views 133 views
  • Users 0 members are here
Support feedback
Options
Options
Related

This thread has been locked.

If you have a related question, please click the "Ask a related question" button in the top right corner. The newly created question will be automatically linked to this question.

MSP432E401Y: Establishing connections using Ethernet and PPP

Robert Macklin
Intellectual 565 points

Part Number: MSP432E401Y

I have a project using the Ethernet interface on the MSP432E401Y.  Now I am trying to add support for a PPP connection over a modem.  I have done a lot of reading online and have most of it working.

I have ported the code from the TM4C129 example.  I wrote routines to handle initializing the modem and establishing the connection.  Then I pass the handle into the task that receives data and pushes packets into the stack.  This starts the PPP negotiation, which is successful, and an IP address is assigned.  Then the netIPAddrHook function is called with the IP address of the connection, just like the Ethernet interface.  In the hook function, I initialize SlNet, and add the PPP interface using:

status = SlNetIf_add(SLNETIF_ID_3, "ppp0",(const SlNetIf_Config_t *)&SlNetIfConfigNDKSec,8);

At this point I see the stack periodically sending a small packet, the serial receive task receives and validates a valid packet and pushes it into the stack.  I think this is an LCP status message that runs about once a second.

When I try to open a socket the stack uses the Ethernet interface because it is a higher priority.  When I unplug the Ethernet cable, the sockets fail, the stack doesn't switch to the modem connection.  I have also tried disabling the Ethernet interface using SlNetIf_setState, and swapped the priorities of the two interfaces.  None of these changes causes any additional activity on the modem connection, I still see the LCP status messages moving periodically.

I found some information about sending a LINKUP message using STKEVENT_signal and implemented that in the receive task.  It signals LINKUP after it sees a bunch of valid packets have been decoded.

I have noticed that a call to SlNetIf_getConnectionStatus never returns a connected status for the modem connection.  I followed this into the code and found that the PPP driver doesn't implement an IOCTL function.  SlNetIf_getConnectionStatus uses this to get the connection status of the interface, so it never gets reported as connected through this function.  Does the stack use this function?  Could this be the reason it doesn't switch?

I have also tried making a build that includes only the PPP interface and I get the same basic response.  The PPP connection is established and the IP address is assigned, but I am unable to create any socket connections.

What am I missing? 

 

  • 0
    TI__Intellectual 1970 points

    Hi Robert,

    Have you tried to mimic the functionality implemented in the SlNetIf_getConnectionStatus with the IOCTL added to check this? That would be my next step,

    Thanks,

    -Eric Rentschler

  • 0 in reply to Eric Rentschler
    Intellectual 565 points

    My next step was to implement the IOCTL function needed. I implemented something crude and was able to get the stack to begin using the PPP interface. With some additional work, I was able to implement a better solution that uses the PPP state flags to determine the status. This is very portable and only requires a small change to NIMUPPP.C.

    During more testing, I found the STKEVENT_signal can be used to send LINKUP, but that only causes the stack to trigger the NetUpHook callback defined when the network initializes. It does not inform the stack that the interface is ready to be used.

    There was one additional problem to solve. After everything worked properly under JTAG debug, the release build didn't complete the PPP negotiation. I used the Display_printf() functions a lot in my code to debug the connection problem. The Display functions do not execute in release builds, so the timing changes slightly. I found there is a race condition in the handling of the transition between two states of the PPP negotiation. I was unable to find the root problem, but it causes the stack to never start the CHAP negotiation with the PPP server. I was able to patch this by adding some delays during the PPP negotiation. This works around, but does not solve the race condition.

    I am still having some trouble getting SlNet to switch between the Ethernet and PPP interfaces based on what is currently connected to implement a fallback feature, but the stack is up and running on the PPP interface.