Age | Commit message (Collapse) | Author | Files | Lines |
|
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.
|
|
If we are sent a Config-Request for an auth proto other than
CHAP with MD5, send a NAK.
|
|
We will not support pfc or acfc
|
|
We will not support loopback detection.
|
|
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.
|
|
|
|
So we can re-negotiate the options if the layer is opened again.
|
|
No real need to wrap them behind lcp_ functions
|
|
|
|
Using wireshark is much easier
|
|
|
|
|
|
When the other side acks our options, then let us apply these options
locally and start using them
|
|
Use pppcp_send_reject_protocol
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
|
We already have a set_valid_codes function, let us use it
|
|
|
|
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.
|
|
Using these functions makes the code much cleaner than trying to pass
the priv pointer everywhere
|
|
|
|
|
|
|
|
|
|
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.
|
|
|
|
Prevents too early transition to PPP_DEAD
|
|
|
|
|
|
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.
|