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@xxxxxxxxxx> 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@xxxxxxxxxxxxxxx>
--
To unsubscribe from this list: send the line "unsubscribe linux-ppp" in
the body of a message to majordomo@xxxxxxxxxxxxxxx
More majordomo info at http://vger.kernel.org/majordomo-info.html
