Re: Brainstorm: MMS Support
 

OK, I have policy routing working. Although I use Linux kernel 2.6.31 on x86-64 and am using policy routing on 2 interfaces: 1 WLAN (to DSL) 1 PPP (to Bluetooth DUN to GPRS).

secret_ip is the box I'm connecting to (could be the MMSC), and secret_host is its hostname (irrelevant though).

All thanks to this great howto!

I'll use this with OpenVPN and will then play with -m owner. I'll try to get rid of using eth0 (because N900 doesn't have). This setup is on Linux 2.6.31 x86-64.

Re: Brainstorm: MMS Support
 

I've done a lot of reading and testing and have come to the conclusion you're right. This means the removal of ipt_ROUTE was wrong.

Also found another alternative: RAW?NAT (xt_RAWDNAT & xt_RAWSNAT). It is also ugly though. Here is an example:

Using -t rawpost and -A POSTROUTING instead of -t raw -A OUTPUT did not make any difference for me.

This works even if you use your ppp0 IPv4 endpoint (but if IPv4 address exists local then it will not work if local IPv4 address already exists. Then you must use ip to add the route because route will give error SIOCADDRT: No such process maybe this can be overriden. If IPv4 address is added to local afterwards it won't matter.).

The only conflict is when ppp0's local IPv4 conflicts with something. If this is something local it won't matter. If its something remote it won't matter either (for us, that is) except it won't be reachable anymore. We could apply the same trick above (or -j ROUTE) as fix, but then on ppp0 and with an ISNOT statement on -m owner.

You provided an example (about tunnel endpoint) but tunnel endpoint is never reachable on PPP; you cannot ping it or access it.

You also forgot to specify -A, you put a space between -- and gw. Hence, what you intended to state was:

However you don't know for sure intended gw is default_gw. Given ppp0 and ppp1 is from same provider its more likely to conflict with wlan0 which may or may not be connected to Internet.

I don't think this rule would match tho. Remember PPP is tunnel between 2 addresses. Example:

If the source is not ppp_local_IPv4 then it won't fly over ppp0, and given only owner of MMS service will be routed and _nothing_ else it will work

All that said I don't see any advantage from -j RAW?NAT solution over -j ROUTE except that RAW?NAT is not experimental and is part of xtables.

Personally, I prefer your solution, and I'm sad -j ROUTE is deprecated because its clear it has its use.

xtables are target extensions.

I'm doing exact opposite as you do: hitting after routing (output), and before routing (input).

BTW,

Although PPP script knows the $my_local_mms_ip if --to-source is dynamic hence one should use -j MASQUERADE so it'd become

Re: [Under consideration] Brainstorm: MMS Support
 

I'm disappointed iproute doesn't do it.. its so powerful.. close, but not cigar!

It turns out you could almost do it with policy routing if you moved the ppp / wlan interface definitions from table 255 (local) or inserted a rule with priority -1.. either way it just won't let you do it.. and frankly what we'd like to achieve is a bit counter-intuitive.. so I can't really blame it :)

As for the ipt_route code, it is actually really very simple. It wasn't dropped for reliability problems, it was dropped because iproute2 should be used instead.. and I agree.. however, what we want is REALLY out of the ordinary..

What I propose is porting ipt_ROUTE to xtables module. I think this is trivial and should take an afternoon.

Plus side
no kernel changes
iptables will work with the new module without a recomile (I think)
it is a single, small module

down sides:
It *is* a module
It *IS* a unsupported kernel module!
It *IS* an unsupported kernel module that is unlikely to make it back into the kernel as namespaces would probably be the way forward :P

If I can clean up the code and get a copy running on my N810 some time today (ARM testing first) there is one more thing to think about..

When ppp0 is brought up, it can either obtain local peer IPs automatically, OR they can be set manually.. what would be great is if they could be set manually.. but.. report what the remote end wanted them to be set too..

This means we can use that information to create/customise NAT rules.. and we can hard code our interface to non-clashing addresses. I'll look at that too..

You've raised some great points.. and its the weekend and I enjoy a good challenge! :)

I'm going to throw about some VMs and see if I can make something work..


MMSC --- RTR --- [PPP0 DEV WLAN0] --- WIFI --- HOST

Each is an IP and I'm hoping I can make any on the left match with any on the right and it'll all keep working.. I'll get to work

Re: [Under consideration] Brainstorm: MMS Support
 

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

Re: [Under consideration] Brainstorm: MMS Support
 

There should be a way to override this ;)

I wonder, PPP0 lies inbetween PPP1 and lo/wlan0/etc. So the tunnel PPP1 is isolated inbetween MMS APN and PPP0. If you stop the stuff at PPP0 already, it should work. Maybe it is possible to make PPP1's local endpoint non-local. This is something which one can do on VLANs (making them actually global, giving them ethernet address, etc).

This is normal/correct behaviour. This would happen too on other interfaces like eth0 and wlan0.

Here is where you put your ISNOT -m mms-service -j ROUTE wlan0, or use RAWSNAT/RAWDNAT. If -j ROUTE works when there is local IPv4 on wlan0 which is required to be used somewhere on ppp0 then why would it not work the other way around?

Even if ROUTE not work, for UDP or IMCP this would make no problem (assuming RAW*NAT works). For TCP, a timeout should not immediately occur, but probably the state is lost if using RAW*NAT, because the packets need a new source IPv4 which is routed to default_gw on wlan0. This triggered local on the fly.

PS: Have you taken a look at /usr/src/linux/Documentation/networking/ip-sysctl.txt ? I find ip_nonlocal_bind and ip_dynaddr interesting options.

Re: [Under consideration] Brainstorm: MMS Support
 

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 :)

Re: [Under consideration] Brainstorm: MMS Support
 

Hmmm.. pppd not open in fremantle? That sucks (wish it was GPL rather than BSD).. but I suppose that's to allow it to operate with phonet or some such.. Ok, might need to think a bit harder about this..

mind you.. maybe they'd be willing to produce a one-off pppd binary with a patch applied.. especially if the patch was hard coded to disable address setting, rather than making it configurable..

sigh..

Re: [Under consideration] Brainstorm: MMS Support
 

WAP Push message handling is handled by a daemon, to take control of this one is required to register itself via a D-BUS API - this API is not final yet but if you want to play with it, I have the alpha version and can send it to you. :)

Re: [Under consideration] Brainstorm: MMS Support
 

I'd be interested (particularly after I got my hands on an N900 today.. hmm.. nice.. pitty there is no ALS/line-2 support.. booo Nokia!!!)

I have a working ppp patch that meets my requirements, and a working iptables module.. All this to allow a PPP interface to overlap with another interface.. grrr

The WAP push stuff isn't actually that important from my perspective.. the most important bit for is to allow a connection to be made to the MMS APN with compromising any existing connections (be they PPP or WiFi) it works in a lab situation with a special iptables module AND a patch to pppd.. but the pppd in maemo looks like it is closed source.. so there is a SLIM chance it would clash and cause a service disruption.. slim chance, but a real chance.. and that imho is unacceptable .. If you're going to use a nasty hack, it has to at least work properly :)

Re: [Under consideration] Brainstorm: MMS Support
 

Yeah then we work with something akin to CNAME.

Good point, then it should just care about the routes. It won't change to ppp1 btw. ppp0 is always the 3G connection because of /etc/udev/rules.d/70-persistent-net.rules but its much more cleaner to solve problem in PPPd IMO...

Perhaps you can ask Nokia to provide a binary with your patch included? If it is a simple patch, a binary patch may be suitable.