Some modems such as Quectel EC200T do not honor the default value for
the Async-Control-Character-Map (ACCM) configuration option defined in
RFC 1548 6.2 as 0xffffffff. This patch suggests to use RX ACCM = 0 for
Ofono by default as pppd does for instance. This will reduce PPP data
overhead as well.
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.
Using my Huawei EM770W modem, if set ACCM as 0x00000000, RXJ-
event breaks PPP link, after IP package transmit for a while.
Using default ACCM, the issue can be fixed.
I tested it at China Unicom networks.
According to RFC1662 Section 7.1, ACCM Configuration Option is
used to inform the peer which control characters MUST remain
mapped when the peer sends them.
This patch was generated by the following semantic patch
(http://coccinelle.lip6.fr/)
// <smpl>
@fix disable is_null,isnt_null1@
expression *E;
@@
- !E
+ E == NULL
// </smpl>
We use IPCP NAK response to stall the progress of acquiring the client
IP address from DHCP server. So we need to increase the max failure of
NAKs in IPCP handshaking.
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.
Huawei E160G hardware seems to NAK our configure request and suggest
that it will never send packets bigger than 1440 bytes. Since we don't
particularly care (our receive ring buffer is 4K, so it can handle 2048
byte packets), we just re-send the Configure Request with the preferred
value.
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.
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.
This removes the need for the layer_started functions in lcp and ipcp.
For LCP the link is always up unless the socket has been closed, and for
IPCP the link should be opened as soon as LCP is ready anyway.
option_process was declared with two gpointer arguments for the sole
reason of being used as a GFunc. Casting to a GFunc or re-writing the
foreach as a loop is preferable.
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.
Sergei Golubtsov
Giacinto Cifelli
Philip Paeps
Marcel Holtmann
Denis Kenzior
Guillaume Zajac
Martin Xu
Lucas De Marchi
Zhenhua Zhang
Kristen Carlson Accardi