Hello,
I am looking to turn my LPC2468 into a router. It seems that the RL-ARM TCPnet doesn't have any functionality to support this. Does anyone know of either an open-source solution or a product that supports this?
Any thoughts on this would be really appreciated!
Thanks! Eric
ISTR that my Netgear WGR614 Wireless-G Router used open-source software...
Note that a router will require multiple ethernet interfaces...
In theory, you could run a Linux system on the LPC2468 (with external memory, of course.)
I'm curious: can Linux's virtual memory be directed to external RAM ? Has anybody ever tried this?
Does Linux (need to) know or care anything about the details of how the memory is physically implemented?
Isn't that the whole basis of Virtual Memory?
Note that someone seems to be trying to do exactly this on an STM32: http://bit.ly/fftceb
my.st.com/.../Flat.aspx
Running Linux on such a chip can enrich the experience of using our products (for the moment we manually draw a GUI, use TCPNet/FlashFS/RTX etc. which is nice in terms of footprint, but not functionality...) - I was actually asking a slightly irrelevant question about how to do it... Thanks for the link, I'll look into it.
See: kb.netgear.com/.../13279
"This product includes software code developed by third parties, including software code subject to the GNU General Public License ("GPL") or GNU Lesser General Public License ("LGPL"). As applicable, the terms of the GPL and LGPL, and information on obtaining access to the GPL Code and LGPL Code used in this product, are available to you at NETGEAR's Open Source Code Web page. The GPL Code and LGPL Code used in this product is distributed WITHOUT ANY WARRANTY and is subject to the copyrights of one or more authors. For details, see the GPL Code and LGPL Code for this product and the terms of the GPL and LGPL."
NETGEAR's Open Source Code Web page: kbserver.netgear.com/.../open_src.asp
Thanks everybody! I am going to check out netgear's firmware.
I also just came across the open source lwIP stack (light weight IP): savannah.nongnu.org/.../ and http://lwip.wikia.com . I see that some people have modified the code to add NAT so that it can behave as a router -- and lwIP supports PPP. What I am trying to do is have an internet connection via a GPRS modem (PPP) and then route a local area network to this internet connection.
-Eric
But where's the documentation?
http://lwip.wikia.com/wiki/PPP is just a "skeleton" containing no information at all.
then route a local area network to this internet connection.
This should be doable with lwip.
As you might have guessed, the answer to this question is 'Contributions to the project are welcome.' There are very few (maybe just one) active developers on this project, so don't be surprised if you find documentation outdated/lacking/etc.
That's great news! So is it correct that I need to add NAT to lwip in order to do this? (I apologize for how naive I am regarding TCP/IP)
Thanks!
So is it correct that I need to add NAT to lwip in order to do this?
I thought NAT was already available. It appears, I was mistaken: savannah.nongnu.org/.../
You can always implement it yourself, of course. But it will be a challenge if you are a newcomer to TCP/IP. Well, integrating lwip into your application is a challenge in itself.
NAT is _one_ way of having multiple machines share a connection.
But it is the most common method, since it is quite easy to have a router filter all traffic and replace the source IP number before sending out data on the public interface.
Remember that your modem only get one IP number and the first issue is that if a local machine tries to reach another machine out somewhere in the world, that machine somewhere far away must know where to send back any response. So a NAT:ing router replaces the source IP of the local machine with the IP it got on the public (WAN) interface before sending out data.
And when answers comes back, it has a table of ongoing NAT:ed connections, so it can figure out which of multiple local machines that should get the answer. So with the received data, the destination IP gets replaced from the public IP of the modem to the IP of the local machine.
An alternative method - at least when just trying to reach foreign web pages - is to instead have a small proxy program. The difference is that the web browser must know about the existence of the proxy. It makes a connect specifically to the IP of the proxy machine, and sends data telling which IP and what connect the proxy machine should to to talk with machines out in the world. But the proxy solution requires that your local PC machines must know about the proxy. And it only works for protocols that both the PC and the proxy have proxy support for.
A PC game that expects that it should be able to send UDP data directly to a game server somewhere will not manage to go through a proxy.
Note that most cellular subscriptions don't give you a fixed IP number that may be connected to from the outside. So local machines can (using NAT or proxy) connect to external machines and send data and get answers back. But external machines will normally not be able to connect to your modem, allowing your router to send data to a mail or web server hosted behind the router. If you need support for incomming connections (that needs to be destination-NAT:ed or similar to the relevalt local server) then you must check specifically what operator and subscription to use.
Without NAT support in the stack, it will probably be easier for a TCP/IP beginner to write a proxy. But that will limit support to specific protocols, and to PC applications that supports the use of a proxy.
A proxy is easier to implement, since it is a man-in-the-middle. A server program run in the router that accepts connections from the PC, reads info in the message what to do and then create a new, outgoing connection to some machine on the WAN. If the local machines have 5 connections to the proxy, then the proxy will have 5 connections to the outside world. So when answers arrives back, it will have a one-to-one association between local and external connection and just being able to take bytes from one connection and forward to the other connection in the local/external connection pair.
Wow, thank you, Per. This is very helpful information!
I like your idea of a proxy. I think I may do this until I can learn enough to get NAT to work.
"so don't be surprised if you find documentation outdated/lacking/etc"
My real question is: is it just the documentation that's missing, or has PPP not actually been implemented at all?
I think it was Jack Ganssle who said, "'free' software is only really free if you don't value your own time"...