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.
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.