Slashdot Mirror
Configuring a (User-Side) Hassle-Free Network?
braek asks: "I have been approached by a few locations (Hotels/Convention centers) in regards to providing high speed Internet to clients. Now, I'm sure this has been done a million and one times with a small x86 box running some flavor of Unix or BSD, however the thing that makes this somewhat of a more difficult chore, is the fact that the hotels and convention centers want absolutely NO reconfiguration to be required on the users laptops. So for example, the router must be able to route packets for people who have DHCP, as well as someone who has a static reserved IP address of 192.168.4.8 and someone who has a static global of 206.10.3.9. Basically the router should be able to route packets for the user regardless of their IP configuration. I Have looked around the web ad-nauseum but have found very little help. I'm thinking some form of transparent bridge or proxy-arp solution may be the key. Has anyone ever been in a situation like this,
or have any ideas as to how this could be
accomplished?"
...might be that your router has to listen to every packet that comes in through the ethernet port that is connected to all those laptops, so you want a router where all packets are available to everyone (or at least to you).
Another part of the answer is probably that tcp/ip packets from these laptops have to have a return ip address, so WHATEVER the return address is, you'll be masquerading in the address of the server, and remembering who to send it back to. This is pretty much analogous to what happens already.
The DHCP part is easy. just have a dhcp server running, and it ought not to matter what it gives back.
http://www.ibiblio.org/pub/Linux/docs/HOWTO/mini/P roxy-ARP-Subnet is a link to the howto. Check it out.
Use a switch with VLAN tagging and one VLAN per port to connect to your router/host. Host will then substitute the real address if the user has static addressing or handle the DHCP request. Since each switch port is on a different VLAN you can use VLAN tags to determine whose machine sent you a packet. You can't do this at layer 3.
The Economics of Website Security
First realize that what you ask is borderline impossible - You would have to handle
* IP's out of their subnet
** The LAN side of the NAT router would have to have a subnet mask of 0.0.0.0 to catch all possible client configurations
* Colliding IP's
* Guessing where to route packages based on port numbers alone (e.g. for local DNS servers and http proxy servers)
It can't be done at the IP level, you'd have to get below that level, and you'd have to keep all machines on separate VLANs (to avoid clients detecting IP address collisions). And the problems don't stop there, I bet.
THEN realize that especially laptops will very often be configured for DHCP.
In my opinion it would be much more interesting to accept that clients will need their computers to be configured for DHCP and ask: How can I offer wireless LAN support without risking abuse from neighbours, ensuring that people are charged etc.
First of all, your box will need to be kind of switch that is
directly connected via an ethernet cable to every client (without
any intervening hubs), that listens to every packet on the network
yet does not allow the different laptops in the room to communicate
with each other. Otherwise there are potential problems with someone
stealing Google's ip addres, someone sending bogus DHCP responses,
sniffing traffic, etc..
Your box is going to respond to every packet it receives, regardless
of the information in the packet header. Your box will ALWAYS act
as the default gateway for packets from clients, regardless of what
the received packet specifies as the next hop IP address.
* Whenever your box receives a DHCP query, it responds with a
DHCP response giving the address 10.0.0.1, and giving 10.0.0.2 as the
default gateway. The specific numbers don't matter...
* Whenever your box receives any non-DHCP packet, it uses NAT to
route it to the Internet, remembering the switch port on which
the packet came in in order to send the response to the right
place.
This can't work because you can't assume what the users will tell their OS what their gateway/router is.
What happens if you assign IP 168.1.2.32 to a machine and some moron tries to use 168.1.2.32 for their gateway?
Then there are the troubles of ip conflicts, etc.
Juse use DHCP.
The Mariott Hotel in Dallas (can't remember which one exactly) already does this. Your configuration matters not a bit. Just plug it in and go.
Give them a call and find out what they are running, and who provided the solution.
If tits were wings it'd be flying around.
Some of the posters seem to assume the people in the hotel want to see each other on the network. That's probably the absolute *last* thing you want (if suits are expecting to move their laptop from the office to the hotel without any configuration, it probably means the laptop is wide open to hacks). What you want is a hardware set-up that makes each node think it's got a direct connection to the internet, not that it's on a LAN.
It should make the "what if somebody's configured with an IP address I've already assigned" easier-- if the nodes can't see each other you can translate IPs and not worry about conflicts. Assuming you can come up with a hardware configuration that allows that, of course...
Both.
Any responses here that are based on TCP/IP are incorrect (incomplete) and would result in some unusual cases NOT working and nobody would understand why. (Without have a full understanding of networking).
You would -have- to use a switch to split traffic by MAC address. You would also have to know, and keep the MAC address to know how to handle all the packets for each user. If you tracked ALL of that you would be able to deal with 2 machines using the same IP address. (pretty much the worst possible scenario).
You would have to use information from both the TCP/IP layer and the MAC layer to handle ALL packets. You would have to make certain assumptions about the current status on the network, etc. Is it possible? I have no doubt. Is it possible to do using standard utilities under any OS? No.
A properly designed OS will seperate the various layers of networking as much as possible, and in this case you actually HAVE to merge layers to make it work.
I think the requirement is almost ludicriously stupid. I understand why they would want it, but I don't think most people realize that -if- a problem occured it would be damn near impossible to narrow down and deal with. Harder than simply requiring people to use DHCP.