A780-Routing guide by Mack

thanks to yantz for this guide.

this is excerpt from my discussion with mack. or should i say it, mack's wonderful guide/tools for me. all credits goes to mack.

the first words

ok, here's the idea. Instead of doing the ugly hijacking of the fake gprsv0 (which is just a dummy interface that does nothing), we'll use a tun/tap interface (see netlink in the kernel source). We'll have two interfaces, with a simple usermode program that passes data between them. The new fake gprsv0 won't need an ipt_ROUTE rule. Instead, the usermode program will pass gprsv0's outgoing packets to gprsv0b, as incoming packets. This way, the packets will be fed into the kernel's standard routing mechanism (via gprsv0b), and regular routing rules will apply, just as they would in a normal linux machine. With that, a simple catch-all MASQUERADE rule on ppp0 will handle the whole thing, and opera will also be able to connect a local server like you wanted, because the system will see it as an incoming connection on gprsv0b.

Sounds complicated ? It isn't. In fact, there's a trivial way to do it without netlink knowledge, by using the obsolete ethertap.o module. However, doing it the netlink way has a benefit of being compatible with future 2.6.x-based kernels.

If you want to take the easy way anyway, just compile netlink_dev.c of the kernel, and compile ethertap.c twice, once with the interface name being gprsv%d and once with the name being gprsvb%d or something like that. insmod the first one as it is, and the second one with the param “unit=1”. Don't forget to rmmod gprsv before you insmod the fake ones. Smile

At this point, ifconfig -a will show you gprsv0 and gprsvb0. Use ifconfig to give them addresses.

Now, create the ethertap devices: mknod /tmp/tap0 c 36 16 mknod /tmp/tap1 c 36 17

and write a simple program that select()s on both files, and writes everything it reads from each one of them to the other. If you want, I can give you one.

run this program and you have a working link between the two interfaces. use iptables to create a POSTROUTING SNAT rule for gprsv0, to snat everything to appear as coming from an unused IP which is not currently routable, and a PREROUTING DNAT rule that does the opposite. add a route to this non-existent address to gprsvb0 (the bridge interface). The reason we do this weird step is for returning packets. If we were to use our addresses as we assigned them to the interfaces, the returning packets would go directly to the corresponding interfaces, and will be dropped because the connection came from a different interface. By duing the above trick, we make the system think these are two real separate hosts. Trust me - this trick works. Smile

Now, just make sure the default route goes to ppp0, and add a MASQUERADE rule to ppp0 on the host side, just like I did in my scripts.

Also use fake_dsm, to make the system believe there's a live gprs connection.

At this point, opera should be able to connect external hosts, as well as the phone itself. To connect to the phone, you'll just have to go to the address of one of the non-gprs interfaces, such as ppp0, or the bridge interface (gprsvb0). Note that 127.0.0.1 won't work because we emulate an external host with this trick.

If you write everything but run into problems with the iptables rules, just ask me and I'll try to help. They are quite simple.

Now, if you want to do it the right way rather than by the obsolete ethertap, read the kernel's netlink documentation and learn how to use the universal tun interface. If you do that, you won't need to insmod so many modules.

he was so very kind to compile a few modules for me: modules and libs.

I'm back home now. Compiled the files for you. See 4yantz.tar.gz in my ftp. Try the following:

copy ethertap_gprsv.o and netlink_dev.o to your phone. on the phone, make another copy of ethertap_gprsv.o, called ethertap_gprsv2.o (since you need to load the module twice). make sure your gprs connection is off. lsmod, see the gprs module, rmmod it. lsmod to make sure its not there. insmod nelink_dev.o insmod ethertap_gprsv.o insmod ethertap_gprsv2.o unit=1 ifconfig -a you should see two new interfaces, gprsv0 and gprsv1.

if you see these two interfaces, create devices for them: mknod /tmp/tap0 c 36 16 mknod /tmp/tap1 c 36 17

run the attached bridge_taps program, which just bridges between them (a tiny prog I wrote for that purpose, just opens the two devs and relays between them). at this point, ifconfig gprsv0 and another ip for gprsv1. If all goes well, packets you route through gprsv0 should appear as though coming from an external host on gprsv1 and vice versa.

Make sure all the above works, and we'll take it from there.

very very detail instructions, thx a lot mack!!!

Sure, I promised I'll help with the iptables part, and I will. I just wanted to make sure everything else works as expected. Do you have the fake gprsv0 and gprsv1, and my bridge prog running and not exiting ? If you've got all that, we can proceed to the iptables part.

Re iptables, first some theory (so you'll understand what you're doing). In order to make the fake link appear like a real one, the packets coming from it must appear as though coming from some IP that doesn't belong to a local interface. Otherwise, the replying packets will try to route through 'lo', and will be dropped by the IP stack before reaching the application binding gprsv0. In order to create such fake packets, we do the following:

0. Get to the state I described in my last PM, with the bridge running. Also insmod the relevant iptables modules as seen in my scripts.

1. ifconfig gprsv0 10.1.1.1 netmask 255.255.255.252 (fake gprs interface supported by fake_dsm which should be running).

2. ifconfig gprsv1 10.2.1.1 netmask 255.255.255.252 (the other side of the bridge).

3. ip route add 10.4.1.1 dev gprsv0 (10.4.1.1 is a fake IP which appears as a remote host on the fake network).

4. ip route add 10.3.1.1 dev gprsv1 (10.3.1.1 is the other fake IP which appears on the fake network of gprsv1).

5. iptables -t nat -I POSTROUTING -o gprsv0 -j SNAT –to-source 10.3.1.1 (all packets outgoing from gprsv0 will appear to come from 10.3.1.1).

6. iptables -t nat -I POSTROUTING -o gprsv1 -j SNAT –to-source 10.4.1.1 (all packets outgoing from gprsv1 will appear to come from 10.4.1.1).

7. iptables -t nat -I PREROUTING -i gprsv0 -j DNAT –to-destination 10.1.1.1 (hijack all incoming gprsv0 packets to appear destined to it).

8. iptables -t nat -I PREROUTING -i gprsv1 -j DNAT –to-destination 10.2.1.1 (hijack all incoming gprsv1 packets to appear destined to it).

9. ping 10.3.1.1 and 10.4.1.1. Both pings should work (hopefully). If it doesn't work, some arp games may be required. Let me know.

10. If it works, add the default route, 'ip route add default dev ppp0'

11. Start opera and see if you can reach websites like you did with my old InetBT script.

12. If everything works, try to have Opera go to 10.3.1.1 or 10.4.1.1 and see if it connects the server you have running on the phone itself.

Note that I'm writing the above without actually checking so typos may occur.

Good luck Smile

routing works perfect from this point!!!!!! so excited!!!!, but opera gives problem

accessing frpm pc browser to phone's web server gives no problem: log shows “request ”/” OK” and fetch index.html. good. accessing from phone's opera gives a problem: log shows “request “http://10.3.1.1/” illegal request”

again, mack gives a very good suggestion

Yeah, this is the problem. It is indeed an illegal request. I wonder why Opera makes it that way. It should've stripped it to '/' and move the '10.3.1.1' to the 'Host:' field.

If you really need boa working on the phone (btw, what for?) you can solve it in 3 ways:

1. Patch boa to support this illegal request by stripping the 'http://'. (Probably the easiest way). 2. Modify my bridging prog to modify the request in-transit. If you do that, pad the shortened packet with nulls so its length won't change, and don't forget to recalculate its checksum. 3. Use one of the iptables targets from patch-o-matic to modify the request in-transit from the mangle table's POSTROUTING on gprsv0.

Unless you know what you're doing, or wish to learn more about networking, I suggest you do 1

i did just that, method 1. patched boa to strip the “http://10.3.1.1” from the http request and behold, it worked!!!!!!!!!

to whoever who's gonna try this, good luck!! and remember, all credits goes to mack!!