10
edits
Category:L2TP Handover: Difference between revisions
Further comments on authentication, delivering IP addresses and setting up routing on the remote device
No edit summary |
(Further comments on authentication, delivering IP addresses and setting up routing on the remote device) |
||
|
peer_ipaddr=90.155.53.8 \
peer_port=1701 \
peer profile create profile_name=careless
peer profile modify profile_name=careless \
The proxy authentication username that the LAC presents is a UK 07xxx phone number. It also presents a CHAP authentication ID, challenge and response. These are ignored unless you enable allow_ppp_proxy.
I gather that there is an option to pass the username and password that were supplied to the modem all the way through to the LNS, this would replace the phone number and 'password'. Haven't tried this yet.
The 'calling number' and 'called number' in the incoming call request are the SIM's ICCID.
=Things to do=
I've got this working, in as much as it allows entries in the LNS's chap-secrets to contain IP addresses and the correct one is passed to the modem. However (at least on pppd 2.4.5 with openl2tp 1.8) I haven't found a way to set the IP address on the LNS's end of the link. If you use the '-- local:remote' syntax in chap-secrets it picks up the remote IP but not the local one.
Another bit of fun is that at the moment the IP address on the LNS's end of the PPP link doesn't get communicated to the other end. It goes out to the LAC okay, which accepts it, but never passes it on. (I think I once saw it work with a data SIM that was connecting directly to A&A, but that doesn't seem to happen any more either.) To be honest, this in itself isn't that great a problem. However ...
Windows 7, and the Vodafone Mobile Broadband software (the Mac version works nicely with non-Vodafone SIMs, the Windows one doesn't, go figure) treat suitably capable 3G devices essentially as if they were Ethernet interfaces, rather than PPP devices. There's lots of interesting magic going on in there that I haven't figured out, but what they try to do is figure out a netmask and default gateway based on the IP address they're given. If you supply the second or third IP in a /30 for instance, they pick the other one as the default gateway. I want to see if and how this behaviour changes if the server end's IP address gets passed through correctly.
The Huawei K4505, if it doesn't get a (from its perspective) remote address passed in, picks 10.64.64.64. A Nokia E51 picks 10.6.6.6.
=PPP mutterings=
If you set the default route over the PPP interface, then none of this next bit matters except if you're picky like me. If you don't set the default route it does get important.
Microsoft's PPP implementations up to and including Vista still believe in classful addressing. If you don't want the PPP interface to be the default route, then if they are given a 'class A' address they assume a netmask of 255.0.0.0 and set a corresponding network route, similarly for class B and C addresses. Windows 7 has the option to disable this automatic classful route if you don't set the default route. Nice one Microsoft :-)
The Linux pppd understands the concept of point-to-point, non-broadcast links and gets it right.
Mac OS X, despite using the same pppd, manages to muck things up, however this can be fixed with suitable runes in /etc/ppp/ip-up:
# Remove the network route that pppd 'helpfully' sets up for us, which we don't need, and which just gets in the way.
O1=$(echo $IPLOCAL | sed 's/\..*//')
if [ "$O1" -le 127 ] ; then
# Class A -- netmask 255.0.0.0
/sbin/route delete -interface -net $O1.0.0.0 $IFNAME 255.0.0.0 >> /var/log/ppp-ip-updown.log
elif [ "$O1" -le 191 ] ; then
# Class B -- netmask 255.255.0.0
O12=$(echo $IPLOCAL | sed 's/\.[0-9]*\.[0-9]*$//')
/sbin/route delete -interface -net $O12.0.0 $IFNAME 255.255.0.0 >> /var/log/ppp-ip-updown.log
else
# Class C -- netmask 255.255.255.0
# (This will also pick up class D and E, which I doubt we'll be given!)
O123=$(echo $IPLOCAL | sed 's/\.[0-9]*$//')
/sbin/route delete -interface -net $O123.0 $IFNAME 255.255.255.0 >> /var/log/ppp-ip-updown.log
fi
Yes, it's hacky!
| |||