More working.. pppd doesn't as it stands offer a way of obtaining the allocated local and peer IP address without setting the ppp interface. This means ppp0 could be set to a clashing IP addresss the moment a link is established between the device and the apn..

Even if pppX is down, the fact the local address has been defined could screw up a wlan connection. For example.. if wlan0 is talking to 192.168.1.200, then ppp0 is started and receives a local address 192.168.1.200, even if ppp0 is never brought "up", the clash still takes effect and the established connection to 192.168.1.200 will fail.

This creates a race condition..

Also, the TEE module is a pain. 2 problems.

First, it insists on directing the duplicate to a gateway. This is unnecessary with PPP. The packet only needs to be sent to the ppp interface, there is no gateway involved. ip route add default dev ppp0 is completely valid. Second, it is not possible to drop the duplicate packet reliably. This is something the ipt_ROUTE module does do..

So.. where am I now..

I'm trying to create an xtable version of IPT_ROUTE.. that's coming on nicely

I've created a couple of scripts that will tie into PPPD. First is /etc/ppp/ip-pre-up . This script is run when pppX is configured, but before it is brought up. The problem is, it has its local and remote IP address defined, things would be great if ppp0 was left unconfigured.. but there you go.. I can work on that..

It uses the ipparam option to PPPD to pass the MMSC IP address into the script.. ipparam "mmsapn-1.2.3.4" for example.

It then brings up some policy routing and the IP tables rules to do the mangling..

Without a patch to pppd, I'm not sure it is possible to leave ppp0 unconfigured whilst still using ipcp to negotiate what they should be. This could be tricky..

Preliminary work is available at http://mms.fixitfixitfixit.com/mms-20091025.tar.bz2