View Single Post
Posts: 303 | Thanked: 175 times | Joined on Oct 2009 @ London UK
#86
Fixed link to snapshot.. DNS error.. :
http://mms-maemo.fixitfixitfixit.com...091025.tar.bz2

Back to the point..

The problem with negative routing (if NOT mms, then route wlan0) is what happens if wlan0 is missing or wlan0 goes down and comes back up as pppX..

The script I've tested (vmware x86) which plugs into pppd's ip-pre-up doesn't touch any current config. By this, I mean it doesn't redirect stuff to the current internet connection, because that connection may not be there yet, or worse still.. may change!

All the ip policy rules/routes only apply to MMS traffic.. If you remove them, you're left with the default system.. This means an internet connection can be started and changed whilst connection to the APN is active.. I don't think it is safe to have a rule like "redirect non mms traffic to wlan0" because that might change to ppp1, or maybe wlan0 again.. or it might disappear

That is a key thing here.. if we never have to add a rule (ip or iptables) that says "if not-mms do the default action" then we don't need to worry if the default connection comes up, changes or goes down.. otherwise we'd have to add new / different rules if the internet connection changes..

To solve the local down interface clash (where ppp0 has an IP address that clashes with a remote connection) was a simple patch to PPPD.

PPPD allows you to set the local and remote IP address. It also allows you to use ipcp to negotiate a local and/or remote address with the remote system. An option exists to allow the specified local/remote address to be used if one can't be negotiated.. What we want is a hybrid. We want to negotiate a local and remote IP addresses BUT apply local-127 addresses to ppp0. This patch should be dead simple. An alternative pppd binary could be used just for MMS connections to keep it separate, but it is a possibility..

This way, we get to know the local and remote pppd addresses BUT they will absolutely never clash with a local or remote address!

With this patch in place, the script should work quite well. It also won't interfere OR reference any other internet connection (wlan0 or other pppX interface or default route) it is totally separate.

This is a super mega cludge.. but the foot print is remarkably small for what we're trying to do.. an alternative pppd (may only be used for mms), an almost custom kernel module to force local address routing to an interface (which is the only thing iproute2 can't really do) and a script to initialise the firewall and ip policy routing..

I think we're getting close to something work-able.. but this type of thing is really bending the rules..

So, things I would like to get finished:

1) xt_route.. test, test, document and test.. I'd like to submit upstream stating that it could be used to redirect local addresses
2) pppd from the maemo source, patch to negotiate IP but apply hard coded values

I think, with those two items sorted, this might work..

I'll have a look at the ip sysctl stuff too, there is always neat stuff in there! The ip_nonlocal_bind is very neat! though it comes with a warning

Last edited by cpitchford; 2009-10-26 at 23:39. Reason: Fixed link
 

The Following User Says Thank You to cpitchford For This Useful Post: