From: lwip-users
On Behalf Of Patrick Klos
Sent: Thursday, 04 August 2016 10:16
To: Mailing list for lwIP users <address@hidden>
Subject: Re: [lwip-users] Force PPP TermReq (Lwip 2.0.0 RC2)
On 8/4/2016 9:54 AM, Greg Smith wrote:
Hello.
I'm looking for a way to let a PPP peer know that the connection is dropped and needs to reestablish in 2.0.0rc2. In my case, one particular usage of this is if one peer unexpectedly resets (for example, via power loss) and then comes
back up and wants to reconnect. At this point, it's lost its IP address, etc. and needs to reconnect to the peer. But for some reason, the peer (not Lwip) is ignoring all LCP packets. (I'm not sure if that's good protocol or not, but I have to deal with
it.)
If the peer just came up, why isn't it simply starting PPP on it's side? Or is the LwIP host the peer that got reset in this case?
It is the the Lwip peer that reset. And it does, of course, restart PPP.
Does the serial link have any means to tell that the link went down? (i.e. modem control signal? carrier detect?) Or is this a simple 3-wire serial connection between 2 devices (GND, RX, TX)?
Sadly, it does not have a hardware means to tell link state. We are using a 4-wire, full-duplex RS485 link (TX+, TX-, RX+, and RX-; or Y, Z, A, and B). Drive and receive enables on the transceiver are active
100% of the time, so I can't use that, either.
Can you get a trace of the serial line to show the exact bytes that are going back and forth? That usually has all the clues you need to find and fix a problem (unless the non-LwIP peer has a broken PPP).
I have been struggling to find a good tool to get serial traces. Both systems are embedded, so the best I've come up with so far is an oscilloscope that can decode asynchronous serial packets (RS232/RS485). But it only gets
me a few bytes of one transmission -- and doesn't decode the packet, so I just get raw bytes, which is tedious to analyze. Do you (or anyone) have any suggestions for a good tool?
So I was thinking that if I could explicitly tell the peer to terminate (TermReq), then perhaps we could restart normally.
Based on what you said, your non-LwIP peer would ignore that packet as well since it is an LCP packet.
You are probably right. However, I wanted a way to see if that would bring the other peer back to life or not for debugging. I'm really not sure what is going on between the two peers. On the Lwip side, I can see in my debugger
that everything appears to be OK -- no RAM or buffer overflows/overruns, stack pointers are OK, PPP states look correct, IP address appears fine. Debugging output from PPP (and TCP and ICMP) also appear correct. I can also see traffic going both directions
on an oscilloscope. But I have almost no visibility into the other side. It shows PPP is connected, but, for example, shows 100% ping packet loss (even though my debugger shows receiving a ping and sending back out some kind of information.)
Unfortunately, if I just try a ppp_close() (on the peer that reset), Lwip is smart enough to realize it's in the DEAD state and does not try to send a TermReq. Is there a way to force it to send a TermReq? Or is there some other way to
let the peer know that the connection needs to be reestablished?
Again, the TermReq packet is an LCP packet. If your peer is ignoring all LCP packets (as you stated earlier), it's just ignore that packet as well. I'm sure you could find a way to get LwIP to send the packet - just not sure if it'll help given your symptoms.
While trying to do some research, I did come across the PPP Echo function. It is appears to be similar to the TCP keepalive function. I will try that out on both ends and see if that helps the situation.
Describe the exact link setup between the peers and get a packet trace. :o)
See above answers.
-- G