Make the authentication method configurable, CHAP or PAP, defaulting to
CHAP (i.e.: previous behaviour).
Implementation details:
o If PAP is configured, we NAK the CHAP authentication protocol option
in LCP configuration requests and suggest PAP instead. This works
around the amusing requirement of 3GPP TS 29.061 that modems must
send a forced positive acknowledgement of the authentication method
tried (i.e.: the modem will successfully accept any CHAP handshake,
but if the network only supports PAP, the modem will hang up
when it tries and fails to activate the PDP context)
o The PAP Authenticate-Request is resent a hard-coded three times at
ten-second intervals. This may be a bit too persistent. Chances
are if it doesn't work the first time, it'll never work, but the
RFC insists that we MUST retry.
The biggest update here is that the server needs to be in dormant mode
by default, so as not to send a Configure-Req to the peer until the peer
is ready. This requires adding special constructor for LCP to
initialize it to Stopped state instead of initial state.
Along with this, we pass the server local IP directly to the ppp server
constructor.
This function simply didn't have the context of why the phase was being
entered. Instead have each protocol notify GAtPPP as to what is
happening. We already had this more or less for IPCP and AUTH events,
this just now formalizes it for LCP as well.
If the peer requests a MRU option, set the mtu for the network
phase. When we are in link establishment phase, we should
continue to behave as if no option has been set and the peer
should use the default MRU.
This option is required for the Huawei E160G modem.
These really serve no purpose right now as we use only CHAP. So they
only take up space and make the code harder to read. If we implement
1-3 auth protocols, then they're easier handled inside gatppp.c. If we
have more, then a proper auth driver framework is required.
This function will be notified whenever authentication has succeeded /
failed. This can happen in the authentication phase or during the
network phase. If auth fails, then we should proceed to the terminate
phase.
Use of the generate event function, while more 'pure' with regard to how
the spec views transitions, actually makes code more difficult to read.
Instead use phase transitions directly inside gatppp. This still bleeds
through a little into lcp code, and probably should be fixed in a better
way eventually.
There are only about 4 protocols that the current ppp code handles and
it is doubtful that it will grow much more. There's no point in having
an extensive packet handler registration framework.
change ppp_decode to store the length of the decoded frame, so that
if we have a packet with a protocol we don't understand, we can send
Protocol-Reject packets. Modify ppp_cp code to add support for sending
Protocol-Reject packet.