Re: Spontaneous LCP ConfReq after connection made

[James Cameron <james.cameron@hp.com>]

[-- Attachment #1: Type: text/plain, Size: 3014 bytes --]

James Carlson wrote:
> I'd strongly suggest finding a different service provider.  Giving
> your money to a "service" provider that won't even accept a valid bug
> report doesn't strike me as a good plan.

Unfortunately, there is no other service provider; all transmission
towers within radio range are owned by the one provider, and no
comparable service is available.  DSL is not available, and copper pairs
can only do about 24kbit/sec.  It's a 24-month contract, I'm up to the
ninth month, and the contract terms include a "supported software"
clause.  It was working reasonably well before now.

> In reading this log, it looks to me like the peer just wanted to
> renegotiate the link.
> 
> How do you know that's not what it wanted to do?  Does this behavior
> happen with other PPP implementations?  If not, then what's different
> with them?

Apart from the IP address change, there doesn't seem to be any reason
for the renegotiation.  These renegotiations happen in the middle of the
cell phone call; the cell call is not terminated.  But the provider
charges based on their PPP records, not their cell call records.  As a
result of the renegotiation, a new call record is placed in the service
provider's billing system, costing me $USD 0.385 each renegotiation.
I've had it renegotiate 30 times in a minute, before I added an if-down
script to SIGHUP it.  The service provider has reversed these charges,
admitting a fault condition exists, but they haven't been able to
progress the fault since Feb '05, so I thought to seek additional help.

You raise an excellent point with regard to other PPP implementations.
Perhaps there is something negotiated or implied that isn't being done
by Linux PPP.  (Nor should it do so, of course).

I've not tried the PPP implementation that has been provided by the
modem manufacturer, because it is Windows specific, I don't run Windows
here, and as the modem is USB connected instead of serial port connected
I don't know a way to catch the stream for analysis.  But thanks for the
idea, I'll see if I can get the manufacturer to provide information.
(So far they have been silent since I told them I am using Linux).

> Getting to the bottom of such issues is essentially debugging that
> remote peer from afar.  It's not easy at all.

Agreed.  So in addition to whinging I could try to find what innocuous
behaviour Linux PPP is doing that apparently causes the peer to
renegotiate.  Have you any suggestions for options to try blindly in
case they have an effect?

I've tried "asyncmap ffffffff" and "escape
00,01,02,03,04,05,06,07,08,09,0a,0b,0c,0d,0e,0f,10,11,12,13,14,15,16,17,
18,19,1a,1b,1c,1d,1e,1f,80,81,82,83,84,85,86,87,88,89,8a,8b,8c,8d,8e,8f,90,91,92
,93,94,95,96,97,98,99,9a,9b,9c,9d,9e,9f" so far, with no apparent
change.

Have you any suggestions for things to look for in the data sent to the
peer that seems to trigger the event?

-- 
James Cameron
http://ftp.hp.com.au/sigs/jc/

[-- Attachment #2: Digital signature --]
[-- Type: application/pgp-signature, Size: 189 bytes --]