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.
Remove the series of constructors which take a GIOChannel directly.
These weren't used.
This change also allows the construction of the PPP object and filling
in various pertinent information without starting the HDLC processing.
The client must now use g_at_ppp_open() for the client side or
g_at_ppp_listen() for the server side to start the true PPP session.
The previous owner of the GAtIO object must be suspended beforehand.
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.
Right now it is very hard to figure out whether we should be calling the
connect callback or the disconnect callback. So refactor as follows:
- Connect callback is only called once the net is actually up
- Disconnect callback is called once ppp is down, with a reason
for why it is so.
Marcel: recording right now only works for PPP, so we'd need some sort
of multi-protocol support.
So for now expose set_recording to be used through the main PPP object.
HDLC object recording support needs to be extended.
The connect callback was not giving enough information and the
information it was providing was not in a convenient form.
- Provide the ppp interface name (e.g. tun0)
- Provide ip, dns1 & dns2 as strings
- Do not send the ppp structure in the callback, it is most likely
present in the user data anyway