Active Topics
-
Is there a section to talk about Java ME? Apps, etc. (0)
to General by Kalatti - 2 days, 18 hrs ago -
Extra softwares in Sailfish using CLI, repositories, etc (117)
to SailfishOS by nieldk - 4 days, 15 hrs ago -
Firefox with Leste (6)
to Maemo 7 / Leste by teroyk - 5 days, 12 hrs ago - more...
|
2009-12-29
, 11:47
|
|
Posts: 236 |
Thanked: 223 times |
Joined on Oct 2009
@ NE UK
|
#2
|
Just in case you hadn't seen it, there's some discussion of iptables and kernels starting around page 2 in this: http://talk.maemo.org/showthread.php?t=30916&page=2
I'd be very grateful to see an easily installable solution to this!
I'd be very grateful to see an easily installable solution to this!
 |
|
2009-12-29
, 11:58
|
|
Posts: 14 |
Thanked: 9 times |
Joined on Nov 2009
@ Torino, Italy
|
#3
|
Yes, I've seen the other discussion but I think the issue, although fundamental for tethering, is a bit more large.
What I'd like to start here is an effort to have ONE community kernel or a common toolbox with specially tuned proxies to serve most tethering needs.
What I'd like to start here is an effort to have ONE community kernel or a common toolbox with specially tuned proxies to serve most tethering needs.
| The Following User Says Thank You to micalil For This Useful Post: | ||
|
|
2009-12-31
, 00:45
|
|
Posts: 14 |
Thanked: 9 times |
Joined on Nov 2009
@ Torino, Italy
|
#4
|
well, since the amount of feedback was so heavy (maybe I posted this in the wrong section, feel free to tell me), I'll work the two ways in parallel.
I don't know if it's legit to create a garage project for an unique community kernel, so I'll host on my own space waiting for community input.
For the generalized proxing toolkit I'll first create a garage project containing these things:
* a non caching userland http / https proxy
* a userland forwarding daemon
* a cli tool to easily configure both
* a gui tool to configure both
* maybe (maybe) python bindings for the cli stuff
please, keep in mind that I'll publish stuff only when I reach a "debian polite" and "maemo polite" way to distribute it.
stay tuned, i'll be back in a week.
Last edited by micalil; 2009-12-31 at 00:49.
I don't know if it's legit to create a garage project for an unique community kernel, so I'll host on my own space waiting for community input.
For the generalized proxing toolkit I'll first create a garage project containing these things:
* a non caching userland http / https proxy
* a userland forwarding daemon
* a cli tool to easily configure both
* a gui tool to configure both
* maybe (maybe) python bindings for the cli stuff
please, keep in mind that I'll publish stuff only when I reach a "debian polite" and "maemo polite" way to distribute it.
stay tuned, i'll be back in a week.
Last edited by micalil; 2009-12-31 at 00:49.
|
|
2010-01-03
, 18:16
|
|
Posts: 236 |
Thanked: 223 times |
Joined on Oct 2009
@ NE UK
|
#5
|
You might want to take a look at what Jebba has been up to in the NAT and kernel areas:
http://wiki.maemo.org/User:Jebba/NAT
http://wiki.maemo.org/User:Jebba/Kernel
I do think getting the various kernel options together under one roof would be a great step.
http://wiki.maemo.org/User:Jebba/NAT
http://wiki.maemo.org/User:Jebba/Kernel
I do think getting the various kernel options together under one roof would be a great step.
|
|
2010-01-03
, 19:38
|
|
Posts: 14 |
Thanked: 9 times |
Joined on Nov 2009
@ Torino, Italy
|
#6
|
Originally Posted by kwotski
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.
You might want to take a look at what Jebba has been up to in the NAT and kernel areas:
http://wiki.maemo.org/User:Jebba/NAT
http://wiki.maemo.org/User:Jebba/Kernel
I do think getting the various kernel options together under one roof would be a great step.
Thank you fir the hint, even if I'm a fan of reinventing the wheel (for learning sake, poor me)!
|
|
2010-01-05
, 09:31
|
|
Posts: 13 |
Thanked: 11 times |
Joined on Jan 2010
|
#7
|
Originally Posted by micalil
On my N810 I used a slighly different userland aproach.
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 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.
| The Following 4 Users Say Thank You to wek For This Useful Post: | ||
 |
|
2010-01-05
, 09:35
|
|
Posts: 2,121 |
Thanked: 1,540 times |
Joined on Mar 2008
@ Oxford, UK
|
#8
|
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.
|
|
2010-01-06
, 08:48
|
|
Posts: 14 |
Thanked: 9 times |
Joined on Nov 2009
@ Torino, Italy
|
#9
|
Originally Posted by wek
Very, very interesting! Looks like the best approach for the userland way, I'm looking into it.
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.
|
|
2010-01-12
, 07:22
|
|
Posts: 3 |
Thanked: 0 times |
Joined on Dec 2009
|
#10
|
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.
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.
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)