PPP connection stuck at bad configuration-ack

PPP connection stuck at bad configuration-ack

[Kristian R. Evensen]

Hello,

I am having some troubles establing a PPP connection to my ISP,
Network Norway, using the Huawei E173 modem. Sometimes it works,
however, most of the time the connection never receives a valid
configuration-ack. This usually happens right after boot, which is
critical as I want the connection to come up automatically. As ppp is
initiated, the chatscript is successful. I also spoke to the
technicians at the ISP, and they cant find any errors in the script or
configuration, and can also see in their systems that a connection is
established. However, the connection is torn down after around 30
seconds, which is the time it takes before pppd terminates.

I am not sure where the error lays, so I wonder if anyone else has
seen something similar or has any tips on how to proceed with figuring
this out? Output from pppd, as well as the chatscript and pppd options
can be found here: http://pastebin.com/z8crcxR6

Thanks in advance for the help,
Kristian

Re: PPP connection stuck at bad configuration-ack

[James Carlson]

Kristian R. Evensen wrote:
> I am not sure where the error lays, so I wonder if anyone else has
> seen something similar or has any tips on how to proceed with figuring
> this out? Output from pppd, as well as the chatscript and pppd options
> can be found here: http://pastebin.com/z8crcxR6

The reason pppd considers the Configure-Nak to be "bad" is that the
negotiation is not converging due to a bug or misconfiguration on the
peer's side.  We say this:

May 21 12:17:50 nne5 pppd[2658]: sent [IPCP ConfReq id=0x1 <addr 0.0.0.0>]

The peer tells us (using the backwards and proprietary Microsoft
extensions) that we should be asking for DNS addresses:

May 21 12:17:51 nne5 pppd[2658]: rcvd [IPCP ConfNak id=0x1 <ms-dns1
10.11.12.13> <ms-dns2 10.11.12.14> <ms-wins 10.11.12.13> <ms-wins
10.11.12.14>]

We modify our request exactly as the peer says and ask again:

May 21 12:17:51 nne5 pppd[2658]: sent [IPCP ConfReq id=0x2 <addr
0.0.0.0> <ms-dns1 10.11.12.13> <ms-dns2 10.11.12.14> <ms-wins
10.11.12.13> <ms-wins 10.11.12.14>]

This is where it runs off the rails.  The peer idiotically repeats the
same response:

May 21 12:17:52 nne5 pppd[2658]: rcvd [IPCP ConfNak id=0x2 <ms-dns1
10.11.12.13> <ms-dns2 10.11.12.14> <ms-wins 10.11.12.13> <ms-wins
10.11.12.14>]

We try again and again, only to get the same broken answer.

Note just how terribly invalid that reply from the peer really is.  He's
sending us a Configure-Nak, but every single "hint" value exactly
matches what we sent in our Configure-Request.  That's just beyond the
pale; if what you're "negatively acknowledging" exactly matches what the
peer is asking, you really should have just acknowledged it, right?

However, the key here (besides understanding that the peer is very
poorly designed and should be avoided) is noticing that we also politely
asked for an IP address, and the peer failed to supply one.

My guess (and it's just a guess at this point) is that this "huawei"
thing is one of those horrible 3G access devices that mangles PPP.  The
3G "standard" specifies that the access server must lie to the client
and return success during the authentication phase, even if the user
name and/or password are completely wrong, or if the named user does not
have the requested network service authorization.  The only way you find
out that something is wrong under this "standard" is when you ask for an
IP address and the peer is unable to supply one.

Most likely, your PAP user name "nne5" or password is incorrect or you
don't have the right configuration set up in the chat script.

Better still, stay as far as you can manage to get from badly-designed
"standards."

-- 
James Carlson         42.703N 71.076W         <carlsonj@workingcode.com>

Re: PPP connection stuck at bad configuration-ack

[Kristian R. Evensen]

Thank you very much for a detailed reply.

On 22 May 2012 20:24, James Carlson <carlsonj@workingcode.com> wrote:
>
> Note just how terribly invalid that reply from the peer really is.  He's
> sending us a Configure-Nak, but every single "hint" value exactly
> matches what we sent in our Configure-Request.  That's just beyond the
> pale; if what you're "negatively acknowledging" exactly matches what the
> peer is asking, you really should have just acknowledged it, right?

Yes, I agree, I also thought this was very strange behavior.

>
> My guess (and it's just a guess at this point) is that this "huawei"
> thing is one of those horrible 3G access devices that mangles PPP.  The
> 3G "standard" specifies that the access server must lie to the client
> and return success during the authentication phase, even if the user
> name and/or password are completely wrong, or if the named user does not
> have the requested network service authorization.  The only way you find
> out that something is wrong under this "standard" is when you ask for an
> IP address and the peer is unable to supply one.

Yes, it is a 3g modem and its exact behavior is of course company
secret and undocumented. However, I dont think the configuration of
the modem is the problem, as I have tried the same type of modem with
other ISPs and it works.

> Most likely, your PAP user name "nne5" or password is incorrect or you
> don't have the right configuration set up in the chat script.

I suspect authentication, as the same modem works for other ISPs with
the same chatscript. Thank you very much for pointing me in this
direction.

-Kristian

Re: PPP connection stuck at bad configuration-ack

[James Cameron]

I've seen this symptom also in the time between power up of the modem
and successful network attachment.

What fixed it for me was to add to the chatscript:

# cease if modem is not attached to network yet
ABORT '+CGATT: 0'
'' AT+CGATT?

-- 
James Cameron
http://quozl.linux.org.au/

Re: PPP connection stuck at bad configuration-ack

[Kristian Evensen]

On 23. mai 2012, at 00:47, James Cameron <quozl@laptop.org> wrote:

> I've seen this symptom also in the time between power up of the modem
> and successful network attachment.
> 
> What fixed it for me was to add to the chatscript:
> 
> # cease if modem is not attached to network yet
> ABORT '+CGATT: 0'
> '' AT+CGATT?
> 

Thanks, I will try that tomorrow. I just spoke to somebody at the Isp as well, and their theory is that the ppp client is confused by the 127.0.0.1 ms-wins. They will update their ggsn config tomorrow so we can check if that is the case.

Thanks again for the help!
Kristian

Re: PPP connection stuck at bad configuration-ack

[James Cameron]

On Wed, May 23, 2012 at 12:55:12AM +0200, Kristian Evensen wrote:
> On 23. mai 2012, at 00:47, James Cameron <quozl@laptop.org> wrote:
> 
> > I've seen this symptom also in the time between power up of the modem
> > and successful network attachment.
> > 
> > What fixed it for me was to add to the chatscript:
> > 
> > # cease if modem is not attached to network yet
> > ABORT '+CGATT: 0'
> > '' AT+CGATT?
> > 
> 
> Thanks, I will try that tomorrow. I just spoke to somebody at the
> Isp as well, and their theory is that the ppp client is confused by
> the 127.0.0.1 ms-wins. They will update their ggsn config tomorrow
> so we can check if that is the case.

That will be interesting to try.  Line 150 or so of your paste shows
that the peer and the host are in agreement over ms-wins values
(10.11.12.{13,14}), then suddenly the peer changes it's mind at line
196 and proposes 127.0.0.1.  Presumably the change is due to the modem
reaching the back end servers.

The lies beforehand occur for me with a modem in a faraday cage, with
a latency consistent with being locally generated by the CPU in the
device.

> Thanks again for the help!

p.s. my name looks like James Carlson, but I'm James Cameron.  I've
started to think I should mention that when I join in on a thread
involving James.  ;-)

-- 
James Cameron
http://quozl.linux.org.au/

Re: PPP connection stuck at bad configuration-ack

[Kristian R. Evensen]

On 23 May 2012 01:11, James Cameron <quozl@laptop.org> wrote:
> On Wed, May 23, 2012 at 12:55:12AM +0200, Kristian Evensen wrote:
>> On 23. mai 2012, at 00:47, James Cameron <quozl@laptop.org> wrote:
>>
>> > I've seen this symptom also in the time between power up of the modem
>> > and successful network attachment.
>> >
>> > What fixed it for me was to add to the chatscript:
>> >
>> > # cease if modem is not attached to network yet
>> > ABORT '+CGATT: 0'
>> > '' AT+CGATT?

Thanks, I will add this to my chatscript. Since it doesnt make sense
to try to connect without network attachment, then it wont hurt to
have it there anyway.

>
> That will be interesting to try.  Line 150 or so of your paste shows
> that the peer and the host are in agreement over ms-wins values
> (10.11.12.{13,14}), then suddenly the peer changes it's mind at line
> 196 and proposes 127.0.0.1.  Presumably the change is due to the modem
> reaching the back end servers.

This seems to have been the case. After the ISP update their config, I
am not able to recreate the behavior. Now, the peer does not report
any ms-wins.
>
> p.s. my name looks like James Carlson, but I'm James Cameron.  I've
> started to think I should mention that when I join in on a thread
> involving James.  ;-)
>

Hehehe, sorry about that.

-Kristian

Re: PPP connection stuck at bad configuration-ack

[James Carlson]

James Cameron wrote:
> On Wed, May 23, 2012 at 12:55:12AM +0200, Kristian Evensen wrote:
>> On 23. mai 2012, at 00:47, James Cameron <quozl@laptop.org> wrote:
>>
>>> I've seen this symptom also in the time between power up of the modem
>>> and successful network attachment.
>>>
>>> What fixed it for me was to add to the chatscript:
>>>
>>> # cease if modem is not attached to network yet
>>> ABORT '+CGATT: 0'
>>> '' AT+CGATT?
>>>
>> Thanks, I will try that tomorrow. I just spoke to somebody at the
>> Isp as well, and their theory is that the ppp client is confused by
>> the 127.0.0.1 ms-wins. They will update their ggsn config tomorrow
>> so we can check if that is the case.
> 
> That will be interesting to try.  Line 150 or so of your paste shows
> that the peer and the host are in agreement over ms-wins values
> (10.11.12.{13,14}), then suddenly the peer changes it's mind at line
> 196 and proposes 127.0.0.1.  Presumably the change is due to the modem
> reaching the back end servers.

For what it's worth, I don't buy the ISP's theory.  pppd just doesn't
care much about the MS-WINS addresses, and the peer can change them
arbitrarily without causing "confusion."  They're really not used for
anything other than stuffing into environment variables for Someone Else
to play with.

(These are Microsoft proprietary extensions for a reason ...)

If you check ipcp_nakci() and the NAKCIDNS() macro and the
CI_MS_WINS[12] cases, you'll see that the only thing we do is make sure
that the entry is well-formed (i.e., 4 bytes of address).  We don't care
what actual value is used.

The reason we end up in that "bad nak" state has nothing to do with the
Windows "WINS" server options.  It has to do with the treat_as_reject
flag passed into ipcp_nakci() from the state machine.  This flag is set
when we see "too many" Configure-Nak messages from the peer without
having ever seen a Configure-Ack.  See fsm_rconfnakrej() in fsm.c.

Too many Configure-Nak messages means that negotiation is not converging
and needs to be shut down.

The normal default for this is 5 consecutive Configure-Nak messages.
You can tune it with the "ipcp-max-failure".  Note that in the most
recent ipcp.c code, this value has been hacked to 100 (!) for everyone
just to deal with lame 3G "modems."

(The rationale for the change is to make the utility more tolerant of
this known bad behavior by default.  I'm not sure I agree with the
change.  The limit is important; it makes sure that we don't spend too
long on a link that is misconfigured, and it means we don't spend too
much time trying to hint at something the peer won't use.  With this
change in place, we'll hint until the cows come home rather than just
dropping a non-conforming option.  That seems undesirable.)

> The lies beforehand occur for me with a modem in a faraday cage, with
> a latency consistent with being locally generated by the CPU in the
> device.

Good to hear confirmation that this is "expected" behavior.

-- 
James Carlson         42.703N 71.076W         <carlsonj@workingcode.com>

Re: PPP connection stuck at bad configuration-ack

[terry white]

... ciao:

: on "5-22-2012" "Kristian R. Evensen" writ:
: I am having some troubles establing a PPP connection to my ISP

: can be found here: http://pastebin.com/z8crcxR6
  
    that did not work for me.  traceroute also hungup.
 
    i would suggest, you include the data your reference in your email.  if 
nothing else, it guarantees delivery ...


-- 
... it's not what you see ,
    but in stead , notice ...