Active Topics
-
Camera phone competition March 2023 "Endless" (35)
to General by Maemish - 8 hrs, 40 mins ago -
TLS 1.2 for N9 is ready (28)
to MeeGo / Harmattan by smartblu9 - 9 hrs, 54 mins ago -
Maemo repository (3)
to Community by torsen - 1 day, 1 hr ago -
Error after installing Leste on sdcard (11)
to Maemo 7 / Leste by Maemish - 1 day, 23 hrs ago -
Introducing ubiboot N9 (multiboot OS loader) (1,393)
to Alternatives by smatkovi - 3 days, 5 hrs ago - more...
| The Following User Says Thank You to allnameswereout For This Useful Post: | ||
 |
|
2009-10-24
, 02:38
|
|
Posts: 3,397 |
Thanked: 1,212 times |
Joined on Jul 2008
@ Netherlands
|
#82
|
Originally Posted by cpitchford
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.
I must admit, there were two minor api changes in the module.. however.. and this is a big difference
eth0 1.2.3.4
ppp0 192.168.1.1 <-> 192.168.1.254
If the MMSC ip address is 1.2.3.4 you cannot (afaik) use iproute2 to instruct the system to route via 192.168.1 254 as it is treated locally. With the ipt_route module, you can.
Also found another alternative: RAW?NAT (xt_RAWDNAT & xt_RAWSNAT). It is also ugly though. Here is an example:
Code:
$ host -t a talk.maemo.org
talk.maemo.org is an alias for forums.internettablettalk.com.
forums.internettablettalk.com has address 74.86.202.247
$ ip route get 74.86.202.247
74.86.202.247 via 192.168.178.1 dev wlan3 src 192.168.178.33
cache mtu 1500 advmss 1460 hoplimit 64
$ sudo ping -c 3 74.86.202.247
PING 74.86.202.247 (74.86.202.247) 56(84) bytes of data.
64 bytes from 74.86.202.247: icmp_seq=1 ttl=53 time=141 ms
64 bytes from 74.86.202.247: icmp_seq=2 ttl=53 time=138 ms
64 bytes from 74.86.202.247: icmp_seq=3 ttl=53 time=134 ms
$ sudo ifconfig wlan3:0 74.86.202.247 netmask 255.255.255.255
$ ip route get 74.86.202.247
local 74.86.202.247 dev lo src 74.86.202.247
cache <local> mtu 16436 advmss 16396 hoplimit 64
$ sudo ping -c 3 74.86.202.247
PING 74.86.202.247 (74.86.202.247) 56(84) bytes of data.
64 bytes from 74.86.202.247: icmp_seq=1 ttl=64 time=0.093 ms
64 bytes from 74.86.202.247: icmp_seq=2 ttl=64 time=0.073 ms
64 bytes from 74.86.202.247: icmp_seq=3 ttl=64 time=0.073 ms
$ ip addr ls ppp0
7: ppp0: <POINTOPOINT,MULTICAST,NOARP,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 3
link/ppp
inet 10.67.147.187 peer 10.6.6.6/32 scope global ppp0
$ sudo route add -host 10.67.147.188 gw 10.6.6.6
$ ip route ls dev ppp0
10.67.147.188 via 10.6.6.6
10.6.6.6 proto kernel scope link src 10.67.147.187
$ sudo iptables -F -t raw ; sudo iptables -F -t rawpost ; sudo iptables -F -t nat ; sudo iptables -F -t mangle ; sudo iptables -F
$ sudo iptables -t raw -A PREROUTING -i ppp0 -s 74.86.202.247 -j RAWSNAT --to-source 10.67.147.188
$ sudo iptables -t raw -A OUTPUT -d 10.67.147.188 -j RAWDNAT --to-destination 74.86.202.247
$ ip route get 74.86.202.247
local 74.86.202.247 dev lo src 74.86.202.247
cache <local> mtu 16436 advmss 16396 hoplimit 64
$ sudo ping -c 3 74.86.202.247
PING 74.86.202.247 (74.86.202.247) 56(84) bytes of data.
64 bytes from 74.86.202.247: icmp_seq=1 ttl=64 time=0.090 ms
64 bytes from 74.86.202.247: icmp_seq=2 ttl=64 time=0.070 ms
64 bytes from 74.86.202.247: icmp_seq=3 ttl=64 time=0.077 ms
$ ip route get 10.67.147.188
10.67.147.188 via 10.6.6.6 dev ppp0 src 10.67.147.187
cache mtu 1500 advmss 1460 hoplimit 64
$ sudo ping -c 3 10.67.147.188
PING 10.67.147.188 (10.67.147.188) 56(84) bytes of data.
64 bytes from 10.67.147.188: icmp_seq=1 ttl=42 time=403 ms
64 bytes from 10.67.147.188: icmp_seq=2 ttl=42 time=452 ms
64 bytes from 10.67.147.188: icmp_seq=3 ttl=42 time=431 ms
$ sudo -s
# echo 10.67.147.188 talk.maemo.org >> /etc/hosts
# exit
$ grep hosts /etc/nsswitch.conf
hosts: files mdns4_minimal [NOTFOUND=return] dns mdns4
$ lynx -source talk.maemo.org | grep "meta name"
<meta name="generator" content="vBulletin 3.8.2" />
<meta name="keywords" content="internet tablet, nokia 770, nokia, 770, n800, n810, n900, maemo, maemo.org, linux, wifi, bluetooth" />
<meta name="description" content="talk.maemo.org" />
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:
iptables -t mangle -A OUTPUT \
-m owner ! --uid-owner mms-service \
-j ROUTE --gw $my_default_gw --oif $my_internet_if
I don't think this rule would match tho. Remember PPP is tunnel between 2 addresses. Example:
$ ip route ls dev ppp0
10.6.6.6 proto kernel scope link src 10.66.15.69
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.
[...]
Doing it through userspace as you mentioned could be a viable alternative.. netfilter lets you attack a packet *almost* prior to routing which means you can hit things that would resolve locally without serious routing.. iproute2 is pretty focused on the routing layer..
I'm doing exact opposite as you do: hitting after routing (output), and before routing (input).
BTW,
iptables -t nat -A POSTROUTING -d $remote_mmsc \
-m owner --uid-owner mms-service \
-j SNAT --to-source $my_local_mms_ip
iptables -t nat -A POSTROUTING -d $remote_mmsc \
-m owner --uid-owner mms-service \
-j MASQUERADE
__________________
Goosfraba! All text written by allnameswereout is public domain unless stated otherwise. Thank you for sharing your output!
Goosfraba! All text written by allnameswereout is public domain unless stated otherwise. Thank you for sharing your output!
| The Following User Says Thank You to allnameswereout For This Useful Post: | ||
|
|
2009-10-24
, 10:41
|
|
Posts: 303 |
Thanked: 175 times |
Joined on Oct 2009
@ London UK
|
#83
|
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
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
| The Following 3 Users Say Thank You to cpitchford For This Useful Post: | ||
|
|
2009-10-25
, 14:30
|
|
Posts: 303 |
Thanked: 175 times |
Joined on Oct 2009
@ London UK
|
#84
|
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
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
| The Following User Says Thank You to cpitchford For This Useful Post: | ||
|
|
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.
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
This is normal/correct behaviour. This would happen too on other interfaces like eth0 and wlan0.
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.
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.
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!
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.
|
|
2009-10-26
, 23:29
|
|
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
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: | ||
|
|
2009-10-27
, 00:10
|
|
Posts: 303 |
Thanked: 175 times |
Joined on Oct 2009
@ London UK
|
#87
|
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..
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..
|
|
2009-11-05
, 16:04
|
|
Posts: 547 |
Thanked: 1,383 times |
Joined on Sep 2009
@ Stockholm, Sweden
|
#88
|
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.
__________________
Problem with fMMS? Run in x-terminal: cp /tmp/fmms.log /home/user/MyDocs/
After that you'll see fmms.log in filemanager or when you connect the device to your desktop as a mass storage device.
E-mail the log to me, if you don't have the email address, drop me a PM. Thanks!
fMMS - MMS for your N900
fAPN - GUI for adding a new GPRS APN
If you like this post, don't be shy to thank me -->
Problem with fMMS? Run in x-terminal: cp /tmp/fmms.log /home/user/MyDocs/
After that you'll see fmms.log in filemanager or when you connect the device to your desktop as a mass storage device.
E-mail the log to me, if you don't have the email address, drop me a PM. Thanks!
fMMS - MMS for your N900
fAPN - GUI for adding a new GPRS APN
If you like this post, don't be shy to thank me -->
| The Following User Says Thank You to frals For This Useful Post: | ||
|
|
2009-11-05
, 17:51
|
|
Posts: 303 |
Thanked: 175 times |
Joined on Oct 2009
@ London UK
|
#89
|
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
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
|
|
2009-11-07
, 21:05
|
|
Posts: 3,397 |
Thanked: 1,212 times |
Joined on Jul 2008
@ Netherlands
|
#90
|
Originally Posted by cpitchford
Yeah then we work with something akin to CNAME.
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..
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
2) pppd from the maemo source, patch to negotiate IP but apply hard coded values
__________________
Goosfraba! All text written by allnameswereout is public domain unless stated otherwise. Thank you for sharing your output!
Goosfraba! All text written by allnameswereout is public domain unless stated otherwise. Thank you for sharing your output!
secret_ip is the box I'm connecting to (could be the MMSC), and secret_host is its hostname (irrelevant though).
$ sudo vconfig add lo Added VLAN with VID == 0 to IF -:lo:- $ sudo ip addr ls dev vlan0 17: vlan0@lo: <LOOPBACK> mtu 16436 qdisc noop state DOWN link/ether 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 10.0.0.1/32 scope global vlan0 $ sudo ip route ls 10.6.6.6 dev ppp0 proto kernel scope link src 10.15.96.83 192.168.178.0/24 dev wlan3 proto kernel scope link src 192.168.178.33 169.254.0.0/16 dev wlan3 scope link metric 1000 default via 192.168.178.1 dev wlan3 proto static $ grep voda /etc/iproute2/rt_tables 200 voda $ sudo ip rule ls 0: from all lookup local 32765: from 10.0.0.1 to secret_ip lookup voda 32766: from all lookup main 32767: from all lookup default $ sudo ip route ls table voda default via 10.6.6.6 dev ppp0 $ sudo iptables -L POSTROUTING -t nat -n Chain POSTROUTING (policy ACCEPT) target prot opt source destination SNAT all -- 10.0.0.1 0.0.0.0/0 to:10.15.96.83 $ sudo ip route get secret_ip from 10.0.0.1 secret_ip from 10.0.0.1 via 10.6.6.6 dev ppp0 cache mtu 1500 advmss 1460 hoplimit 64 $ sudo ip route get secret_ip from any secret_ip via 192.168.178.1 dev wlan3 src 192.168.178.33 cache mtu 1500 advmss 1460 hoplimit 64 $ sudo ping -c 8 -I 10.0.0.1 secret_ip PING secret_host (secret_ip) from 10.0.0.1 : 56(84) bytes of data. 64 bytes from secret_host (secret_ip): icmp_seq=1 ttl=47 time=2241 ms 64 bytes from secret_host (secret_ip): icmp_seq=2 ttl=47 time=1269 ms 64 bytes from secret_host (secret_ip): icmp_seq=3 ttl=47 time=270 ms 64 bytes from secret_host (secret_ip): icmp_seq=4 ttl=47 time=176 ms 64 bytes from secret_host (secret_ip): icmp_seq=5 ttl=47 time=225 ms 64 bytes from secret_host (secret_ip): icmp_seq=6 ttl=47 time=207 ms 64 bytes from secret_host (secret_ip): icmp_seq=7 ttl=47 time=212 ms 64 bytes from secret_host (secret_ip): icmp_seq=8 ttl=47 time=224 ms --- secret_host ping statistics --- 8 packets transmitted, 8 received, 0% packet loss, time 7009ms rtt min/avg/max/mdev = 176.667/603.478/2241.316/708.549 ms, pipe 3 $ sudo ping -c 8 secret_ip PING secret_host (secret_ip) 56(84) bytes of data. 64 bytes from secret_host (secret_ip): icmp_seq=1 ttl=57 time=14.0 ms 64 bytes from secret_host (secret_ip): icmp_seq=2 ttl=57 time=13.8 ms 64 bytes from secret_host (secret_ip): icmp_seq=3 ttl=57 time=13.6 ms 64 bytes from secret_host (secret_ip): icmp_seq=4 ttl=57 time=13.2 ms 64 bytes from secret_host (secret_ip): icmp_seq=5 ttl=57 time=13.7 ms 64 bytes from secret_host (secret_ip): icmp_seq=6 ttl=57 time=13.3 ms 64 bytes from secret_host (secret_ip): icmp_seq=7 ttl=57 time=14.5 ms 64 bytes from secret_host (secret_ip): icmp_seq=8 ttl=57 time=13.6 ms --- secret_host ping statistics --- 8 packets transmitted, 8 received, 0% packet loss, time 7010ms rtt min/avg/max/mdev = 13.260/13.761/14.504/0.386 ms $ ssh -b 10.0.0.1 secret_ip [..] $ ssh secret_ip [..] $ sudo ping -c 8 -I 10.0.0.1 talk.maemo.org PING forums.internettablettalk.com (74.86.202.247) from 10.0.0.1 : 56(84) bytes of data. --- forums.internettablettalk.com ping statistics --- 8 packets transmitted, 0 received, 100% packet loss, time 7008ms $ sudo ping -c 8 talk.maemo.org PING forums.internettablettalk.com (74.86.202.247) 56(84) bytes of data. 64 bytes from reggiesuplido.com (74.86.202.247): icmp_seq=1 ttl=53 time=134 ms 64 bytes from reggiesuplido.com (74.86.202.247): icmp_seq=2 ttl=53 time=133 ms 64 bytes from reggiesuplido.com (74.86.202.247): icmp_seq=3 ttl=53 time=133 ms 64 bytes from reggiesuplido.com (74.86.202.247): icmp_seq=4 ttl=53 time=133 ms 64 bytes from reggiesuplido.com (74.86.202.247): icmp_seq=5 ttl=53 time=136 ms 64 bytes from reggiesuplido.com (74.86.202.247): icmp_seq=6 ttl=53 time=133 ms 64 bytes from reggiesuplido.com (74.86.202.247): icmp_seq=7 ttl=53 time=133 ms 64 bytes from reggiesuplido.com (74.86.202.247): icmp_seq=8 ttl=53 time=133 ms --- forums.internettablettalk.com ping statistics --- 8 packets transmitted, 8 received, 0% packet loss, time 7009ms rtt min/avg/max/mdev = 133.269/133.879/136.043/0.981 ms jfdh@entheogen:~$ sudo ping -c 8 -I 10.0.0.1 talk.maemo.org PING forums.internettablettalk.com (74.86.202.247) from 10.0.0.1 : 56(84) bytes of data. --- forums.internettablettalk.com ping statistics --- 8 packets transmitted, 0 received, 100% packet loss, time 7008msI'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.Goosfraba! All text written by allnameswereout is public domain unless stated otherwise. Thank you for sharing your output!
Last edited by allnameswereout; 2009-10-21 at 22:28.