headers
Tyler Sutherland | 1 Apr 22:57
Picon

LCP Renegotiates After IP Connection

Hi There,

I have a situation where I'm trying to maintain a PPP connection from my
Linux PC to an embedded Linux device.

I am able to get the PPP connection working such that each end has an IP
address and I can ping the other end for twenty seconds, but then I
receive an [LCP ConfReq] packet and the PPP connection sets itself up
again.  This interrupts the IP connection and breaks my ability to ping.

I'm trying to figure out why this is happening, because I want to have a
stable PPP connection.  If someone can help me I'd appreciate it very
much.

The embedded device seems to want to restart the connection every 20
seconds.  This is what the pppd debug log looks like from my end:

~ #  pppd nodetach file /etc/ppp/options.pppUSB1 
pppd options in effect:
nodetach        # (from command line)
debug           # (from /etc/ppp/options.pppUSB1)
dump            # (from /etc/ppp/options.pppUSB1)
noauth          # (from /etc/ppp/options.pppUSB1)
/dev/ttyUSB1    # (from /etc/ppp/options.pppUSB1)
57600           # (from /etc/ppp/options.pppUSB1)
lock            # (from /etc/ppp/options.pppUSB1)
noaccomp                # (from /etc/ppp/options.pppUSB1)
asyncmap ffffffff               # (from /etc/ppp/options.pppUSB1)
nopcomp         # (from /etc/ppp/options.pppUSB1)
10.2.10.5:10.2.10.20            # (from /etc/ppp/options.pppUSB1)
(Continue reading)

Permalink | Reply | 9 comments |
headers
Bill Unruh | 1 Apr 23:44
Picon
Picon
Favicon

Re: LCP Renegotiates After IP Connection

On Tue, 1 Apr 2008, Tyler Sutherland wrote:

> Hi There,
>
> I have a situation where I'm trying to maintain a PPP connection from my
> Linux PC to an embedded Linux device.
>
> I am able to get the PPP connection working such that each end has an IP
> address and I can ping the other end for twenty seconds, but then I
> receive an [LCP ConfReq] packet and the PPP connection sets itself up

What packet do you receive? And from where--- the embedded device? 
Show us the output ( put debug into /etc/ppp/options, and 
daemon.*;local2.*     /var/log/daemonlog
into /etc/syslog.conf
and then do 
killall -1 syslogd

> again.  This interrupts the IP connection and breaks my ability to ping.
>
> I'm trying to figure out why this is happening, because I want to have a
> stable PPP connection.  If someone can help me I'd appreciate it very
> much.
>
> The embedded device seems to want to restart the connection every 20
> seconds.  This is what the pppd debug log looks like from my end:
>
> ~ #  pppd nodetach file /etc/ppp/options.pppUSB1
> pppd options in effect:
> nodetach        # (from command line)
(Continue reading)

Permalink | Reply | 0 comments |
headers
James Cameron | 1 Apr 23:53
Picon
Favicon

Re: LCP Renegotiates After IP Connection

G'day Tyler,

I've had that situation on a Maxon MM-5100 USB CDMA modem.  An LCP
ConfReq packet appears out of the blue.  My prior postings on that in
early 2005 here ... determined that pppd is reacting properly, and that
you have to find a way to prevent the packet from appearing.

(In my case the triggering condition was to send a packet out the
interface that had a source IP address different to that negotiated.
Once I added iptables rules to block such packets, the trigger was
removed.)

So for a wild guess, use tcpdump to ensure that nothing unexpected is
being sent out your new network interface.

Now, looking at your log in more detail ... I'm surprised that you get
an LCP ConfReq and ConfAck sequence up front consisting of 10 pairs of
packets, each with the same id and magic number.  It is as if the
embedded device is echoing the packets back to your host.  But I thought
pppd had code to detect that, and there's no sign of that detection
triggering.

I suggest you use the record option and use pppdump or wireshark on the
result, so as to find out what is happening.

Other than that ... sounds like the embedded device wants something
different.  If it works in a stable fashion with something else, a dump
of that data stream may be handy for comparison.

--

--
(Continue reading)

Permalink | Reply | 7 comments |
headers
James Carlson | 2 Apr 00:05

Re: LCP Renegotiates After IP Connection

James Cameron writes:
> Now, looking at your log in more detail ... I'm surprised that you get
> an LCP ConfReq and ConfAck sequence up front consisting of 10 pairs of
> packets, each with the same id and magic number.  It is as if the

That's not a pppd problem.  We're sending Configure-Request (over and
over on the normal restart timer), and the peer is sending
Configure-Ack each time, but isn't bothering to send
Configure-Request.

The peer is either confused or broken.  Based on the combination of
symptoms, that's not too surprising.

> embedded device is echoing the packets back to your host.

No, it's not.  It's sending Configure-Ack in response.  I don't see
anything wrong here, other than the fact that we're stuck in AckRcvd
state because the peer won't send Configure-Request.

>  But I thought
> pppd had code to detect that, and there's no sign of that detection
> triggering.

There's no loopback here, so nothing to detect.

> I suggest you use the record option and use pppdump or wireshark on the
> result, so as to find out what is happening.
> 
> Other than that ... sounds like the embedded device wants something
> different.  If it works in a stable fashion with something else, a dump
(Continue reading)

Permalink | Reply | 6 comments |
headers
Bill Unruh | 2 Apr 01:18
Picon
Picon
Favicon

Re: LCP Renegotiates After IP Connection

On Tue, 1 Apr 2008, James Carlson wrote:

> James Cameron writes:
>> Now, looking at your log in more detail ... I'm surprised that you get
>> an LCP ConfReq and ConfAck sequence up front consisting of 10 pairs of
>> packets, each with the same id and magic number.  It is as if the
>
> That's not a pppd problem.  We're sending Configure-Request (over and

Who is we? Are you part of this or is this a sort of royal we?

> over on the normal restart timer), and the peer is sending
> Configure-Ack each time, but isn't bothering to send
> Configure-Request.

Sould not your side start to send a ConfReq with something other than
magic?

>
> The peer is either confused or broken.  Based on the combination of
> symptoms, that's not too surprising.
>
>> embedded device is echoing the packets back to your host.
>
> No, it's not.  It's sending Configure-Ack in response.  I don't see
> anything wrong here, other than the fact that we're stuck in AckRcvd
> state because the peer won't send Configure-Request.
>
>>  But I thought
>> pppd had code to detect that, and there's no sign of that detection
(Continue reading)

Permalink | Reply | 5 comments |
headers
James Carlson | 2 Apr 13:09

Re: LCP Renegotiates After IP Connection

Bill Unruh writes:
> On Tue, 1 Apr 2008, James Carlson wrote:
> 
> > James Cameron writes:
> >> Now, looking at your log in more detail ... I'm surprised that you get
> >> an LCP ConfReq and ConfAck sequence up front consisting of 10 pairs of
> >> packets, each with the same id and magic number.  It is as if the
> >
> > That's not a pppd problem.  We're sending Configure-Request (over and
> 
> Who is we? Are you part of this or is this a sort of royal we?

"We" are the local node for which the original poster supplied logs.
"They" are the other node -- the one that doesn't speak PPP so well
and for which we have no logs.

I can certainly use other words if those two offend you in some way.

> > over on the normal restart timer), and the peer is sending
> > Configure-Ack each time, but isn't bothering to send
> > Configure-Request.
> 
> Sould not your side start to send a ConfReq with something other than
> magic?

No.

When "we" send the very first Configure-Request, we're in Req-Sent
state.  We then get Configure-Ack from the peer, and we enter Ack-Rcvd
state.  The peer does nothing, and time passes.  Eventually, after 3
(Continue reading)

Permalink | Reply | 4 comments |
headers
Bill Unruh | 2 Apr 17:38
Picon
Picon
Favicon

Re: LCP Renegotiates After IP Connection

On Wed, 2 Apr 2008, James Carlson wrote:

> Bill Unruh writes:
>> On Tue, 1 Apr 2008, James Carlson wrote:
>>
>>> James Cameron writes:
>>>> Now, looking at your log in more detail ... I'm surprised that you get
>>>> an LCP ConfReq and ConfAck sequence up front consisting of 10 pairs of
>>>> packets, each with the same id and magic number.  It is as if the
>>>
>>> That's not a pppd problem.  We're sending Configure-Request (over and
>>
>> Who is we? Are you part of this or is this a sort of royal we?
>
> "We" are the local node for which the original poster supplied logs.
> "They" are the other node -- the one that doesn't speak PPP so well
> and for which we have no logs.

Since "James Cameron" was not the original poster, your suddenly using "we"
was confusing. It was not at all clear that you were in any way related to
the original poster, and it was not clear whether your descriptions were
hypothetical or based on some facts.

>
> I can certainly use other words if those two offend you in some way.

Nope, clarification is sufficient. So when you make statements as to what
happens in the negotiation attempts, we are to take them as having some
basis in fact and personal experience.
(Continue reading)

Permalink | Reply | 3 comments |
headers
James Carlson | 2 Apr 18:09

Re: LCP Renegotiates After IP Connection

Bill Unruh writes:
> > I can certainly use other words if those two offend you in some way.
> 
> Nope, clarification is sufficient. So when you make statements as to what
> happens in the negotiation attempts, we are to take them as having some
> basis in fact and personal experience.

Or perhaps with reference to the original poster's message ... ?

> > If you read section 5.1 ("Configure-Request") of RFC 1661, it
> > discusses how the Identifier is chosen, and explains that
> > implementations are permitted to leave the ID field unchanged.
> > Retransmit can be exactly that: retransmit, don't generate a new one
> > from scratch.  That's how pppd does it.
> 
> Can be. But why make it so.

Because that's how pppd works.  See fsm_timeout(), and the
REQSENT/ACKRCVD/ACKSENT states.  These call fsm_sconfreq(f, 1), which
then tells fsm_sconfreq() to avoid generating a new ID.

The FSM also invokes the `retransmit' callback when it processes the
TO+ event, so it's possible for xCP implementations to alter the
packet before resending.  In lcp_callbacks, though, this function
pointer is NULL, meaning that LCP does nothing to alter the packet on
retransmit.

I checked the CVS repository, and this logic dates back to at least
1993 when the code was first imported to CVS.  I suspect it dates back
much further, probably to the mid-80's original Carnegie-Mellon
(Continue reading)

Permalink | Reply | 1 comment |
headers
James Cameron | 2 Apr 23:30
Picon
Favicon

Re: LCP Renegotiates After IP Connection

On Wed, Apr 02, 2008 at 12:09:46PM -0400, James Carlson wrote:
> Bill Unruh writes:
> [...]

Chuckle.  But I understand better now, thanks.

I'd love to know what this embedded device is so that I can add it to my
list of "don't buy, sounds dodgy".  ;-)

--

-- 
James Cameron
http://ftp.hp.com.au/sigs/jc/
--
To unsubscribe from this list: send the line "unsubscribe linux-ppp" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 0 comments |
headers
Paul Mackerras | 3 Apr 06:13
Picon

Re: LCP Renegotiates After IP Connection

Bill Unruh writes:

> > If you read section 5.1 ("Configure-Request") of RFC 1661, it
> > discusses how the Identifier is chosen, and explains that
> > implementations are permitted to leave the ID field unchanged.
> > Retransmit can be exactly that: retransmit, don't generate a new one
> > from scratch.  That's how pppd does it.
> 
> Can be. But why make it so.

The main reason I made it like this is that this way, it has some
chance of working on a link where the round-trip latency is more than
the retransmit interval.

> Then I would follow that. Agreed. But it could have been "We just purchased
> 5000 of those things at a really cheap non-returnable deal. You better make
> them work."

Then you hack pppd for that particular situation (you have the source,
after all), but you don't pretend that your hack is necessarily a good
thing for everyone to use.

Paul.
--
To unsubscribe from this list: send the line "unsubscribe linux-ppp" in
the body of a message to majordomo <at> vger.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html
Permalink | Reply | 0 comments |

Gmane