Re: Stock kernel and NAT support
 

wek: can you post the commands to set that up?

According to ifconfig, we have "wlan0" which is the wireless network, and "gprs0" which is the data connection we'd want to share.

Re: Stock kernel and NAT support
 

The binary-packet I just downloaded unfortunately doesn't have
the vde_pcapplug so I can't check if it works like that but you
can try something like this as a minimal setup (everything in an
extra console till it works afterwards all modules offer daemonization):

vde_switch -s /var/run/vde_sock
slirpplug -s /var/run/vde_sock -D
vde_pcapplug -s /var/run/vde_sock wlan0

We don't care for gprs0 as this is gonna be done by the
IP-stack.
I found a couple of hours time in the train so I'm quite far
with stripping down qemu to what we need here. So I will
try to go for that to have everything in a single binary and
to avoid the socket-communication.

Re: Stock kernel and NAT support
 

wek:

Ok, so the first command runs OK (I needed to be root to have permissions to /var/run/vde2/vde_sock)
The second command doesn't exist, but there's one that seems to do the same thing, "slirpvde", and it returns, "IP address of your DNS(s): 0.0.0.0"
The third command fails, with the error message, "vde_pcapplug: Open wlan0: wlan0: That device is not up"

I think the problem here is that I have to manually bring up the wlan0 connection in ad-hoc mode (Maemo only allows one network interface to be active at a time, so I have the gprs0 connection open).

How do I bring up wlan0 in ad-hoc mode without disconnecting gprs0?

Also, is slirpvde the same as slirpplug? "man slirpvde" says that it is "a slirp interface for a VDE network".

Re: Stock kernel and NAT support
 

i did not try vde yet as i don't have debian-chroot installed atm. Setting the wlan0 to ad-hoc however basically works like this:

iwconfig wlan0 mode ad-hoc
ifconfig wlan0 [ip adress]
iwconfig wlan0 essid [name]

for testing this should do, have not yet tried to connect with another machine though.

misses encryption and dhcp server, so connecting hosts need to have a fitting manual ip setup

Re: Stock kernel and NAT support
 

Good news! And bad news.

Combining greygoo's instructions with wek's instructions (with my "slirpvde" modification) sets up a joikuspot-style router with a stock kernel... for a second, until my N900 rebooted.

0. Install Easy Debian and apt-get install vde2

1. make sure the N900 is on the GPRS data network (not wifi)

2. run the three commands from greygoo as root (I don't have iwconfig in Maemo, so I also ran these in a root Debian terminal):

3. run the three vde2 commands in three Easy Debian root terminals (sudo debian):
4. Find the "N900" hotspot with your N800 (or laptop if you aren't cool enough to own an N800) and connect.

5. Get the IP address (yes, you get one!)

6. Try to load a web page... see the web browser show the title of the web page at the title bar... :D then watch the N900 reboot... :( ...or watch the web page load at a snail's pace, or stall, or not load at all...

Re: Stock kernel and NAT support
 

As you said good and bad news...

Your IP-Address should be 0.0.0.0 instead of 10.0.0.1 to keep
the IP-Stack out of the game.
But I'm afraid this is not our problem with stability.
I would expect that libpcap is not properly built against
freemantle but this is just a guess.
Something else which came to my mind is the following:
Per default, the device is probably opened promiscuous, which
might not work properly with wlan0 and as I remember from my gone n810 pan0.
Don't know if slirpvde (sorry for my mistake here
with the naming) has an option to do that.
I remember that I had changed that in my implementation on
the N810. Of course if the interface is not opened
promiscuous then slirp has to be forced to use the mac-address
of your wlan0 or whatever device you are connecting to.
Also remember to have built a mac-selection-option into
slirp. Can't remember if that went into the current slirp (the one
in current qemu) but it is for shure not in the old implementation
coming with vde2.
Looks as if I should try to dig out my old implementation (last
version is for shure gone but there might be something left
somewhere) and give it a try to see if the n900 behaves
differently in comparison to the n810...

Re: Stock kernel and NAT support
 

Tried a few more times. N900 didn't reboot, but the whole thing was terribly, terribly slow and not very stable-feeling.

Corrected my instructions; I had the order of 1 and 3 wrong. First you set up wlan0, then you set up the router.

wek: How do I run the VDE apps as daemons?

Re: Stock kernel and NAT support
 

In case of slirpvde use -d for a daemon (surprise ;-) ). The
others are probably similar.
With -p you can create a pidfile which you should use in
your up/down-script to clean up properly.
The reliability-problem could be due to various reasons.
Have you set the wlan0-ip to 0.0.0.0?
If you use wireshark (tcpdump or any other sniffer) on the
box connected via our hotspot which mac for 10.0.2.2 do
you see? The same you get when you do ifconfig wlan0
on the N900?
Try with pan as an alternative to see if it has to to with
ad-hoc on N900 in principle. v(Would probably anyway
more suitable because of power-consumption on the
long - aeh more short ;-) - run.)

Re: Stock kernel and NAT support
 

Reboot might be caused by a bug in the minstrel wifi driver, you can try recompiling the module with this patch.

Re: Stock kernel and NAT support
 

Finally found some time to invest into the stripped-down qemu approach.
Now I have a 200K (probably can be made smaller but for a test this
should suffice) binary running on my SLES machine basically doing
what qole achieved with the 3 vde daemons.
I observed a thruput-issue as well: Limitation to 570KBytes/s per
TCP-stream. As pcap doesn't have any knowledge of TCP-streams
and I don't think it is a delay/windowsize issue it probably
originates somewhere inside slirp. Though with a 100KBytes/s
shaping per TCP-stream of many servers and the bandwidth offered
by the providers I have been using till now this is kind of academic.
CPU-Load isn't dramatic as well.
Now the bad news: Last time I used scratchbox was chinook ;-)