Hi mikalil,

I am an Acquisition Editor with a publishing house. We're working on a book on Nokia application programming and we need a technical reviewer to review the book. I went through your posts and your knowledge on the subject looks impressive. If you're interested, please get in touch with me at taruns@packtpub.com for details.

Do you happen to have any notes online anywhere with a bit more info on how to do it ? (see this thread about related NAT discussion)

It is a bit sad that such a fascinating and tantalizing post was made by a one-post user. How do you extract the SLiRP code from qemu and "plumb it to" the wlan interface "using pcap"?

Unfortunately my spare-time for topics like these was a little limited recently. Regarding your questions the slirp-code inside qemu is
concentrated in a directory called slirp. So the idea is to simply take
this code build something like the main-loop of qemu add some
glue-code to make references happy and instead of communicating
with virtual ethernet-interfaces of virtual machines make it use
pcap instead. Under http://article.gmane.org/gmane.comp....ors.qemu/39831 you
can find a patch which brings pcap-support to qemu (not in the
official qemu because of some drawbacks which don't hurt us
here). So all code is basically there what is missing is to remove
the actual qemu and add some glue, command-line handling and
so on...

Obviously the task is even easier than I had thought. Yesterday I
finally found the time to port the patch mentioned to
qemu-0.12.2. Once I had fired up a qemu virtual machine with
one virtual ethernet interface as
userspace-networking (using slirp code) and one virtual ethernet
connected to eth0 using pcap both connected to vlan=0 (behaves
like a bridge) on my sles11-linux-box I had exactly the desired behaviour.
(user-space nat, dhcp-server, dns-forwarding)
What is running inside the virtual-machine is of course
quite irrelevant. In fact the whole virtual-machine-stuff shouldn't be there
making the approach quite bloated and unnecessarily complicated to
port to freemantle-arm-scratchbox.
The commandline for this looks something like "qemu -boot d
-cdrom /windows/D/iso/SUSE_SLES-11-0-0.001.ISO -m 512
-net nic,model=e1000,vlan=0 -net pcap,ifname=eth0,vlan=0
-net nic,model=e1000,vlan=0 -net user,vlan=0".
So if somebody is willing to help it would be helpful to compile the
qemu-tools out of the qemu-0.12.2 package for
freemantel-arm-scratchbox.
The configuration which makes this work should also be fit for
compiling a qemu stripped down to just the networking stuff. I'm
thinking of something like qemu-img just for networking instead
of blockdevices.

Hi Wek,
unfortunately I'm living a bit busy right now so I've put on hold a lot of things, even this one, but I'm posting some of my doubts regarding the silrp solution. Maybe it cuold be useful for other readers.

What we are trying to do here is bridging a tap/tun to an interface with UNSPEC link type (gprs0), is it even possible? Even if the qemu code is about untagged vlan, somebody already tried to bridge that interface with anything resembles an ethernet?

Then, let's talk about layer 3: for what I can see we add an interface beetwen the gprs0 and an ipotethical pan0 (we're still talking about tethering, right?). But at IP level what it gives us?

Even if we bridge successfully everything how could the stuff route correctly packets out of gprs0 without senting out routing errors?

Imho the whole approach as flaws so big that any resolutuin wouldn't be any smaller than rewrite lot of ip routines in userland...

I will elaborate more only if requested, since I'm living on the run

Shame on me not to think of that aproach earlier especially as I know
vde.sourceforge.net already.
This might be aproach where no codechanges at all might be needed.
VDE is the equivalent to an ethernet-switch realized as a userspace
application. There are several plugins available. Amongst these
there are a tap-plugin and a slirp plugin. Haven't checked enough
to see if there is a pcap plugin as well. If not it is probably not
complicated to write. But maybe we wouldn't even need it.
Haven't checked about bridge & tap - support in the official
freemantle-kernel. Does anybody know if these features are there?
If yes the solution would be to setup a vde-switch with a tap and
a slirp - end and to bridge the tap with the wlan0 or pan0 device.

As from what we have seen (kernel module piping data to user
space) regarding Joikuspot on N900 this guy obviously hasn't
found a way to handle the NAT in the kernel either (without building
a new kernel).
So I think my aproach will perform at least as well as this one
with the two advantages that it is free and that the userspace-nat-code
used is really well tested in the virtualization world (at least qemu, kvm
and virtualbox) and as it is open-source any application-support
missing can be added instead of being bound to the protocols supported
by a closed source product. Btw. does anybody know which protocols
are supported by the Joikuspot-NAT-code - probably no difference to
what works on the symbian version. I'm thinking of things like active FTP,
IPSec-Tunnels, telco-protocols... where e.g. the linux-kernel has
Nat-Helpers for.

Well I have it working on my PC which should be enough proof
for the principle ;-) And - as already stated - I had it running
on my unfortunately stolen N810 between wlan0 and pan0 or
alternatively an usb-plugged ethernet (unfortunately not possible
with N900 due to missing OTG as it looks).
Actually it shouldn't make any difference how the internet
connection looks like as long as a working socket-interface is
provided to userspace-applications.

Well if anyone knows how to actually use it, vde2 can be installed in the Easy Debian chroot on any of the Maemo devices. But I have no idea how to use anything in that package to build a userspace router.

Setting up a virtual-switch with one pcap-leg to pan0 and/or
wlan0 (checked seems to be
there) and one slirp-leg should do the trick...
As an alternative to the pcap-leg you can try a tap-leg for vde and
bridge it with wlan0 and/or pan0 (bridge enabled in the kernel?
bridge-utils available?).
Note regarding slirp in vde: Once inherited from qemu but dates
March 2008 which would mean that latest refactoring in qemu
didn't go in it. Maybe not ideal but for our purpose probably
sufficient.