Thread: [In development] Brainstorm: MMS Support
View Single Post
allnameswereout's Avatar
allnameswereout is offline allnameswereout
2009-10-26 , 17:59
Posts: 3,397 | Thanked: 1,212 times | Joined on Jul 2008 @ Netherlands
#85
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
At startup time the kernel configures the default RPDB consisting of three rules:

1. Priority: 0, Selector: match anything, Action: lookup routing table local (ID 255). The local table is a special routing table containing
high priority control routes for local and broadcast addresses.

Rule 0 is special. It cannot be deleted or overridden.

2. Priority: 32766, Selector: match anything, Action: lookup routing table main (ID 254). The main table is the normal routing table contain‐
ing all non-policy routes. This rule may be deleted and/or overridden with other ones by the administrator.

3. Priority: 32767, Selector: match anything, Action: lookup routing table default (ID 253). The default table is empty. It is reserved for
some post-processing if no previous default rules selected the packet. This rule may also be deleted.
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).

Originally Posted by cpitchford View Post
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 is normal/correct behaviour. This would happen too on other interfaces like eth0 and wlan0.

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.
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.
__________________
Goosfraba! All text written by allnameswereout is public domain unless stated otherwise. Thank you for sharing your output!
Last edited by allnameswereout; 2009-10-26 at 19:24.