Notices

Put my patches to SVN, right now waiting form my SB VM to build a clean clean kernel directory patched with the hotspotize.sh script (and when it's done we'll see if I missed something I did by hand earlier)

Edit: dpkg-buildpackage builds the scrip-patched source cleanly, tomorrow after real work(tm) I can test flashing the kernel.

*bonk* forgot to set EXTRAVERSION in rules so of course I get conflict in module directory and cannot install modules deb (I want to be able to have stock modules longside so I only need to flash kernel back and forth and not worry about the modules)

When I flash the zImage to the device it won't boot properly, probably need to enable rd mode on the device and compile the kernel with framebuffer (so I can see the kernel boot messages) to debug this.

My weekend is already booked though, on sunday I might have an hour or so but I'll probably spend that on the Python/DBus side of things (since the kernel compile alone takes some 25-35min)

So if *you* have a scatchbox and some spare time: Use the patches linked above and see if you can figure it out.

I've built a kernel with NAT support (with at least the same modifications as rambo's patches).
It works, but the N900 reboots as soon as there is more than light traffic through the NAT: I can download a small web page from a computer behind the NAT, but reloading many pages at once kills the n900 every time.
It happens with any interface (wlan or phone).

I've also tried Jebba kernel (version 2.6.28-omap1-jebba9-g649dffc) which have exactly the same problem.

So is there anybody really using NAT on the N900 (not just loading the modules) ?


Here is an easy way to reproduce the problem:

Put the n900 (with iptables & a nat kernel) on a wifi network, and then type:
Then on a PC on the same network:
Then browse some web pages from the PC, N900 should reboot after a few seconds.


Tell me your results and we'll know if i've done something stupid with my n900 or if there is a real problem

that sounds pretty fatal, I've never heard of a linux crash like that before, so I wonder what is going wrong!

if you send a little bit of traffic so as not to crash it, and do "dmesg | tail -20" or similar, do you see any relevant kernel errors?

I only tested my kernel but I was able to surf fine without any resets. I have only done this once (when I first set it up) and didn't push any huge volume through it, but it seemed stable enough.

The only time I've been able to consistently reset the n900 is when I play with jackd.

Nothing at all. Last kernel message is caused by module loading:

(just did the test again with Jebba's kernel)

Loading a web page at a time may not reboot the device, but a "Reload all tabs" in a firefox with 20 tabs opened and routed through the n900 immediately reboots it

I tried to reduce the number of conntrack slots (/proc/sys/net/netfilter/nf_conntrack_max) but it doesn't solve the problem.


Could someone run my little test to make sure this is not a problem on my side ?

I was seeing this with the previous kernel version (and my patches) as well (the current one I build will reboot straight away...), it's probably the device watchdog timer that gets tripped... Enabling RD mode and disabling wathdog would be one way to verify, then it's the "just" a question of figuring out why kernel won't reset the timer if conntrack is loaded and there is more than light traffic...

I wonder if there are some options that could be passed on with insmod, but quick search turned out nothing (I guess reading the module source is the next place to look for them).

Perhaps the watchdog timer can just be made a bit less sensitive...

Was too lazy to read through this whole thread, but my n800 works fine in wlan ad-hoc mode while being connected to internet via bluetooth/mobile phone. All I needed was the missing iptables module which i was able to build against the installed kernel and some iptables user space libraries to get the nat working. With that setup I can provide several people with network (slow but existing) anywhere while they connect to the n800 in ad-hoc mode. I would expect this to also work without much problems, when I got time I'll give it a shot.