zephyr: PPP interface LCP negotiation failure
I tried raising this issue in the networking sub-group for zephyr on Discord but did not get a response, hence raising it here instead.
This is with an nRF5340DK board using nRFConnect SDK (2.5.0)/Zephyr 3.4.99ncs: we are tied to the nRFConnect Zephyr versions but I think this should be OK, PPP-wise, as the only change in the PPP code since Zephyr 3.4.99ncs is to remove the “experimental” flag.
To be clear, this issue is with PPP, not with the modem stuff; we are not using that, we are JUST using PPP to a UART, on the other side of which a peer PPP entity is running.
THE PROBLEM
PPP will not pass LCP negotiation with a PPP-peer that I know to be well behaved (a production device that passes LCP negotiation v LWIP’s PPP interface).
I’ve attached a full log with the debug output from Zephyr PPP but, in summary, the Zephyr-side PPP sends an LCP Configure-Request (c0 21 01 01 00 04) and the debug prints shows that the Zephyr-side PPP receives back an LCP Configure-Acknowledge for this from the device (ff 03 c0 21 02 01 00 04 1c 90), which looks well formed to me (given the Configure-Request), but this response is ignored and Zephyr-side PPP repeats the LCP Configure-Request. I know that Zephyr-side PPP really is receiving/processing packets (i.e. it is not some weird data-routing or FCS issue) because the device sends its LCP Configure-Request a little while later and Zephyr-side PPP responds to that with a correctly-formatted Configure-Reject.
I am building with the following KConfig flags:
CONFIG_NETWORKING=y
CONFIG_NET_DRIVERS=y
CONFIG_PPP_NET_IF_NO_AUTO_START=y
CONFIG_NET_PPP=y
CONFIG_NET_L2_PPP=y
CONFIG_NET_PPP_ASYNC_UART=y
CONFIG_UART_ASYNC_API=y
CONFIG_NET_PPP_UART_BUF_LEN=512
CONFIG_NET_PPP_ASYNC_UART_TX_BUF_LEN=512
…and my code is currently not much more than:
pNetIf = net_if_get_first_by_type(&NET_L2_GET_NAME(PPP));
if (pNetIf != NULL) {
net_if_carrier_on(pNetIf);
if (net_if_up(pNetIf) == 0) {
...
…after which I just wait for a long time (no events hooked in or the like),
About this issue
- Original URL
- State: closed
- Created 7 months ago
- Comments: 41 (19 by maintainers)
Yes, you could wait
NET_EVENT_IF_UPevent if you want to know when the interface is up. The reason why this is not tied to the function return value is that the operation might take time and we do not want the function to block.I managed to test the pap with Linux pppd and everything was working fine with upstream zephyr. Changes compared to my earlier instructions somewhere above:
and then adding the secret to
/etc/ppp/pap-secretsThe Linux pppd then tells this:
If you are able to fix this PAP handshaking issue and submit it to upstream, then the fix will propagate itself to NCS too, I would not be too worried about it.
No, there is no expectation like that. By default there should be 3sec timeout but for some reason the timeout happens almost immediately.
I think that is already in the attachment? https://github.com/zephyrproject-rtos/zephyr/files/13564324/lcp_ppp_l2.txt
It might be that we are not in the proper state
PPP_ACK_RECEIVEDwhen we receive the ACK.In my test Zephyr sends the first packet too, the log is from the Linux (modem) side in this case and there pppd just waits data and the first packet is from zephyr LCP ConfReq
@RobMeades sorry for the delay, I have been busy with other stuff. The PPP worked in my setup, but next I need to figure out what I need to change to test your use case.
For IPCP to work you indeed need to enable IPv4. The LCP happens before IPCP so missing IPCP is not affecting the issue you are seeing.