Hi all.
After two days of pajama hacking I'm now sure that stock 2009.42-11 kernel cannot support NAT modules in a proper way, because the netfilter core is compiled in without CONFIG_NF_CONNTRACK or CONFIG_NF_CONNTRACK_MODULE (see line 214 of net/netfilter/core.c).
So, no matter how hard we try to get a "debian-polite" way to add needed modules to this kernel, they will simply not work.
I'm posting this to see how other people involved in tethering projects would think about what we are in front of, specifically:
* Build a new, more modulable, kernel without getting too far from the rx51_defconfig and go with it.
* Go completely userland via proxies of any sort, even heavily tweaked for low resource usage.
Both ways have a lot of bad points, but I'd like to know which one people would choose.
(btw, I think I found an almost elegant way to package "internal" kernel modules, ask freely if interested)
I do think getting the various kernel options together under one roof would be a great step.
I admit I've stumbled on Jebba's pages just a pair of day ago, and there's a lot of things down there... I'll study his stuff more deeply in next days.
Thank you fir the hint, even if I'm a fan of reinventing the wheel (for learning sake, poor me)!
Hi all.
After two days of pajama hacking I'm now sure that stock 2009.42-11 kernel cannot support NAT modules in a proper way, because the netfilter core is compiled in without CONFIG_NF_CONNTRACK or CONFIG_NF_CONNTRACK_MODULE (see line 214 of net/netfilter/core.c).
So, no matter how hard we try to get a "debian-polite" way to add needed modules to this kernel, they will simply not work.
I'm posting this to see how other people involved in tethering projects would think about what we are in front of, specifically:
* Build a new, more modulable, kernel without getting too far from the rx51_defconfig and go with it.
* Go completely userland via proxies of any sort, even heavily tweaked for low resource usage.
Both ways have a lot of bad points, but I'd like to know which one people would choose.
(btw, I think I found an almost elegant way to package "internal" kernel modules, ask freely if interested)
On my N810 I used a slighly different userland aproach.
I took the userland-network (slirp) code from qemu and
plumbed it to the interface the to be natted clients were behind
using pcap.
This gives you a completely userland-based NAT solution
with even a dhcp-server and dns-forwarding incorporated.
Of course it also has all non functional disadvantages of a
userland solution like additional delay and cpu-utilization but
apart from that from a functional perspective it behaves like
NAT. I even used to use VoIP and proprietary tunnel-clients
behind it.
Although it's more work, I think both approaches (new community kernel, and userland stuff) are worth pursuing. The userland solution would be useful for people who just want to install a normal app and don't want to tinker too much with their device. A community kernel, on the other hand, would be of interest to those who don't mind hacking a bit. I would prefer to see only one or two community kernels, though, so that the community doesn't get too divided like the Zaurus community rather did.
On my N810 I used a slighly different userland aproach.
I took the userland-network (slirp) code from qemu and
plumbed it to the interface the to be natted clients were behind
using pcap.
This gives you a completely userland-based NAT solution
with even a dhcp-server and dns-forwarding incorporated.
Of course it also has all non functional disadvantages of a
userland solution like additional delay and cpu-utilization but
apart from that from a functional perspective it behaves like
NAT. I even used to use VoIP and proprietary tunnel-clients
behind it.
Very, very interesting! Looks like the best approach for the userland way, I'm looking into it.
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.
