Please create an account to participate in the Slashdot moderation system

 


Forgot your password?
Close
typodupeerror
×
The Internet

Configuring a (User-Side) Hassle-Free Network? 87

Posted by Cliff from the now-that-is-truly-plug-and-play dept.
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?"
This discussion has been archived. No new comments can be posted.

Configuring a (User-Side) Hassle-Free Network? More

Configuring a (User-Side) Hassle-Free Network?

Comments Filter:

  • part of the answer (Score:3, Informative)

    by repoleved ( 569427 ) on Thursday May 02, 2002 @03:39PM (#3452818)
    ...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.
  • That would be awesome. Supporting static IPs seems tricky. The router could try to ping everything in 192.168 until it gets a response, right? Do Windows boxers respond to ping?

    But, isn't it possible by just looking at all packets coming in on the interface? Oh, but the gateway needs to be configured, client side. That's the kicker...the gateway could be anything, IINM. Or not...the gateway must be encoded somehow in the packets.

    Hey, maybe I should read something about how TCP/IP works before posting. I'll leave this here as an anchor point for those who wish to respond to the article, that way it will be simpler for everyone. :)

  • Pray tell . . . (Score:5, Insightful)

    by cjpez ( 148000 ) on Thursday May 02, 2002 @03:45PM (#3452858) Homepage Journal
    . . . what range of IPs would you assign when doing DHCP for someone, then? Someone's configuration is going to give you problems. If you assign someone a DHCP address in the 10.x.x.x block and then someone comes in with a static 10.x.x.x for some reason, you're screwed . . . I suppose in that scenario you could tell the DHCP server to not use that one IP address. But then what happens if the DHCP server assigns somone 10.0.10.10 and then someone comes in with that static IP? You've got a mess on your hands, that's what.

    Not to mention if someone comes in with a laptop that has a publicly-accessible IP; it's possible, anyway. How will you know to route that properly? I suppose that's pretty farfetched, actually, because the person with a publicly-available static IP on a laptop wouldn't expect it to work outside the network it usually sits in. But still, if that's one of your requirements, what then? Where does traffic to that IP route? Out to the world the way it's supposed to, or inside your hotel network? If you allow global IPs and do some funky route hacking, it would be trivial for someone to boot up their laptop with an IP of 216.239.39.101 and suddenly nobody in the hotel can get to Google. Bad idea.

    Someone's toes are going to have to be stepped on somewhere along the line. Someone else can come around and prove me wrong, though, if they can. :)

    • Re:Pray tell . . . (Score:4, Funny)

      by tps12 ( 105590 ) on Thursday May 02, 2002 @03:48PM (#3452892) Homepage Journal
      But then what happens if the DHCP server assigns somone 10.0.10.10 and then someone comes in with that static IP?

      Could you possibly keep track of MAC addresses and check every N packets whether there has been a change?

      If you allow global IPs and do some funky route hacking, it would be trivial for someone to boot up their laptop with an IP of 216.239.39.101 and suddenly nobody in the hotel can get to Google.

      Known as a "man-in-the-lobby" attack. ;)

      • Could you possibly keep track of MAC addresses and check every N packets whether there has been a change?

        I suppose . . . Seems to me you'll still have interruption of service, though. Plus that might be an awful lot of overhead for the DHCP server.

        Known as a "man-in-the-lobby" attack.

        That's brilliant. :)

        • Re:Pray tell . . . (Score:1, Offtopic)

          by tps12 ( 105590 )
          :)

          Sir, I strongly approve of your noseless smiley. Keep up the good work.

          • If we allow noseless smileys, then the teen pregnancy rate will increase! In addition, the CBDTPA will become law if we don't do anything about the scourge of noseless smileys!

            I am forming the coalition to kill noseless smileys! Smiley genocide!

            • Re:Pray tell . . . (Score:1, Offtopic)

              by tps12 ( 105590 )
              You are overreacting dude. Instead of

              s/[:;][()]//g

              you should be thinking

              s/([:;])-([()])/$1$2/g .

              Trust me, no nose is necessary, or even recommended. ;(
    • But what about subnet masks? and then there is a small issue of security. I would think that it would be easier to have a program that the users would run when at the hotel (provided by the hotel) that would make the configuration changes for the user and when the program was stoped it would revert the setting to the original...

      Since allot of people run windows creating a windows program to save and set the tcp/ip settings shouldn't be that hard. And quiting the program would put the info back...

      I think that would be a much easier solution since it would not harm the users machine and still allow them to use the internet with little to no hassles.
      • I suppose some people might be all right with that, but I know that I certainly wouldn't trust some program a hotel gives me. Then you've got the support nightmare. "Your program destroyed my hard drive which had all my mp3s on it!" You'd probably want to have a Mac version, too, because while MS machines are probably more prevalent, you'd likely have a rather upset Apple user base to deal with otherwise. And that probably means doing an OSX version and a pre-OSX version.

        You'd also have to worry about various Windozes, too. I'd wager that WinXP's networking code would have to be done differently from Win98. I'd say you're best off trying to find a solution that doesn't involve installing programs on the people's laptops. Or just saying, "If you want to use our network, use DHCP." I don't think that's too much to ask . . .

    • You'd need to reserve a proper routable address range and use that - no-one else should be using that; those with static assigned addresses will either be from their own routable range or one of the non-routables. Or they are configured very badly.

  • Tough Part. (Score:3, Insightful)

    by MindStalker ( 22827 ) <mindstalker@[ ]il.com ['gma' in gap]> on Thursday May 02, 2002 @03:45PM (#3452860) Journal
    There are two tough parts to this, one, people may have identical ip addresses, and would upset eachother, two computers trying to reference ip addresses that exist out on the internet could accidently hit other computers on the network if they are ipd wrong. So the only way I could see this working, is to have a small device on each ethernet port that on the network side, has a preconfigured ip address assigned by the hotel. And on the laptop side, reads whatever ip address the laptop that gets plugged into it has, and just accepts it, and then just translates one to the other. I don't know if this device exist, but if its a large enough hotel chain, I bet they could find a company willing to make it, should be simple enough of a device.
    • Yeah yeah, like a router sans hub. That would be pretty cool, and should retail at $10-15 (it is basically two NICs and a little logic, so figure 2 x $4 + $5, give or take). Wouldn't that make network administration easy? Each computer could have (according to its own knowledge) the same static IP, and you just use a little dongle to set the "real" external address.
    • That's what I was thinking too. Those translators have to be able to do DHCP as well though, don't forget.

      mark
      • Those translators have to be able to do DHCP as well though, don't forget.

        Yeah, that's true . . . I suppose you could have it allow all DHCP traffic through, which should be easy enough, and then have your DHCP operate on a different subnet than the IPs assigned to the devices themselves. Or would the routing tables be too weird for that? I suppose it wouldn't be too difficult to just have those devices support a mini-DHCP protocol that just always spits out some IP. You'd probably want to limit it to one IP per device . . . Or not. Hm.

        • I suppose you could have it allow all DHCP traffic through, which should be easy enough, and then have your DHCP operate on a different subnet than the IPs assigned to the devices themselves. Or would the routing tables be too weird for that?

          I don't know. Seems like a good approach, but I really don't know if it's possible.

          You'd probably want to limit it to one IP per device . . . Or not. Hm.

          Yeah, it's gotta be one IP per device. Because once you have even two people on the same one, you have the chance that they will have the same static IP. Seems like a remote chance, but I could see two people with the IP of, say, 192.168.1.5 or something.

          mark
          • Yeah, it's gotta be one IP per device.

            Oh, I wasn't terribly clear there . . . I meant that the device would only give out a total of one IP address with DHCP. Which would prevent someone from plugging a hub into their jack and having three computers share the network connection. But maybe you wouldn't mind doind that. The little device would still do the NATting regardless, so it's just an issue of how complicated you want this device to be. Will it just support one connection, or will it do more?

            • That's true. Since we're talking about a hotel, whatever people do is only going to last the during of their stay. I don't think there's anything inherently wrong with it, unless it bogs down the network.

              mark
      • Each one of them could be a DHCP relay agent as well, and keep the DHCP server on the common hotel network.
    • Well, I suppose that would be cool . . . That would probably take care of most of the problems. I dig. Good show!

    • Very good idea.

  • Switch w/VLAN tagging to Host (Score:3, Informative)

    by regen ( 124808 ) on Thursday May 02, 2002 @03:45PM (#3452864) Homepage Journal
    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.
    • ok, that solves how to have different ips, but how do other routers know that i part of a subnet is not with the rest. this means routers would have to advertise individual hosts in their routing tables. can you imagine the overhead to do this?

      also vlans divide broadcast domains at layer 2 (mac addresses) layer 3 addressing usually follows the vlan but doesnt have to. think of each vlan as a hub. you can run 2 different subnets on a hub ie 192.168.1.xxx (and 10.15.3.xxx) but machines wont be able to communicate at layer 3 (ip) without a router (or vlan trunk)

      clear as mud?

      • Re:Switch w/VLAN tagging to Host (Score:5, Insightful)

        by regen ( 124808 ) on Thursday May 02, 2002 @04:41PM (#3453339) Homepage Journal

        In my haste to reply quickly, I left out details that I thought would be clearly seen once I said use a switch with vlan tagging.

        The upload to the host/router is via trunk port on the switch which is a member of all vlans. Since it is a trunk port the switch will forward the frame which the 802.1q tags on the frames.

        The host/router is configured with virtual interfaces on each vlan. Since the tags are present it can determine which packets belong to which ports on the switch.

        The host/router will use NAT/PAT to map the entire 0/0 address space to a single IP. Thus it will not matter what address is statically assigned to the laptop.

        Since the ARP request will be confined to the VLAN only the host/router will see them and can respond with it's MAC address, thus it will become the gateway router for that port. Likewise you can map services that you would like to provide locally such as DNS this way (or just let DNS pass)

        Of course, if they send a DHCP request you don't need to do all this work.

        You should be able to do this with of the shelf components. A Cisco 3700 series router could handle a small setup and a Cisco Catalyst 5500/6500 with RSM could handle much larger setups. Any CCIE with much VLAN experience should be able to set this up.

        If you want to go Open Source, you could use a Catalyst 5500/6500 with an OpenBSD/Linux/FreeBSD box instead of the RSM. You could even throw a bunch of quad nic into a box instead of using a switch but that would be a mess to manage.

        • Another issue with doing this is the utilization on the router for NATing so many addresses will shoot throught the roof. Make sure you're using some beefy equipment.

  • Cant Be Done (Score:3, Insightful)

    by linuxbert ( 78156 ) on Thursday May 02, 2002 @03:48PM (#3452891) Homepage Journal
    It Cant Be done. dhcp is easy, but there is now way to route an ip packet to a laptop that is not part of an contiguous network, ie the 205.211.44.xxx subnet exists in ottawa, but my laptop which is a member of that subnet is currently in washington, is not gonna be able to have packets routed to it.

    i suppose it could be done if you wrote a gateway that useses a netbios like layer 2 protocol (using mac addresses) and proxying requests and responces from layer 3 (ip) to layer 2 (MAC)
    Hope that makes sence.
    • Not entirely true. If he used some sort of NAT soloution to rewrite the incomming/outgoing packets header with the server/routers IP address, there would no problems. His biggest problem would be preventing his DDHCP server from allocating IP addresses that someoen else has set staticaly. If he was able to sniff all the packets on the network, he could scan for people using IP addresses from the DHCP pool that the DHCP server didn't allocate itself. If it sees one, it would remove that IP address from the DHCP pool (i.e. pretend it was allocated by the DHCP server). If he was able to set relatively short lease times on DHCPed IP addresses, he could minimize the potential imact. The best he can hope for is to minimze the likelyhood of a collision.

      • His biggest problem would be preventing his DDHCP server from allocating IP addresses that someoen else has set staticaly.

        This isn't a problem at all. A compliant DHCP server must arp an address 3 times before it issues a lease. Likewise, a proper DHCP client will arp the address before accepting a lease. If anyone answers these arp requests then it is known that the address is in use.

        The place where you can get into trouble is if the DHCP server has already issued a lease on a particular address and then someone plugs in a device which is statically configured with that address. Usually when this happens one of the devices is smart enough to shutdown its ethernet port or go back to the DHCP server asking for a new lease.

      • NAT Could be done but NAT breaks things.

        -- Tim
    • Just post host routes for every IP that is detected.
    • It Cant Be done.

      It Can Be Done. 1 VLAN per laptop and NAT at the router. It'd be messy as all shit, but it's doable. It would even work if every laptop had the same static-IP.

      • You better hope that your router has support for more VLAN's than you have users then.. if your device can only support 64 vlans, that you can only have 63 users on the network (you'll need one vlan to get to your gateway). Not to mention that you'll have to write all sorts of code to guess the subnet masq and the gateway the person is trying to use. What happens when there DNS server is on a private network and you have no idea how to route to it?

        You'll have just about as much luck trying to do this as randomly crimping your cat5 cables. Any vegetable can configure DHCP -- this is an unreasonable request.

        • You better hope that your router has support for more VLAN's than you have users then.. if your device can only support 64 vlans, that you can only have 63 users on the network (you'll need one vlan to get to your gateway).

          Yup.

          Not to mention that you'll have to write all sorts of code to guess the subnet masq and the gateway the person is trying to use.

          Nope, just have the router respond to all addresses on the /0 network. That way no matter what gateway the laptop tries to talk to, your router will claim to be that gateway.

          What happens when there DNS server is on a private network and you have no idea how to route to it?

          Your router is sending back ARP replies for all addresses, including whatever address their DNS is set to. You then NAT the DNS packets to a local DNS server.

          I'm imagining significant problems if their laptop configuration uses DNS names for various services (eg, http_proxy, mailhost) because your local DNS wouldn't resolve them. I wonder if you could write an "intelligent" bind8 that would wildcard match for records that don't resolve!?

          Any vegetable can configure DHCP -- this is an unreasonable request.

          I agree it's nuts. The hotel probably just wants DHCP but they've worded it in a bad way. The cost of providing true "anything will work" is wasteful: 99% of the hotel guests will have DHCP configured anyway, so the complexity would only be catering for a tiny fraction of guests.

          It would be more sensible to build a plain reliable DHCP environment and provide printed instructions for guests to enable DHCP on their laptops, only to be used if they have trouble.

  • Interesting. Might be "sorta" doable (Score:3, Insightful)

    by dschuetz ( 10924 ) <.gro.tensad. .ta. .divad.> on Thursday May 02, 2002 @03:52PM (#3452915)
    This is an interesting problem. At first blush, it seems that it should be possible. Consider a web request at a packet level:
    • the laptop spits out a packet for, say, 10.3.5.1, and it contains a DNS request for www.slashdot.org
    • some network device configured to receive all packets snarfs that up
    • The device looks at the packet, sees it's a DNS lookup, does the lookup, and then spits out a response packet
    • the laptop now sends out an HTTP packet for 64.28.67.150
    • the magic box sees that packet, recognizes it for what it is, and forwards/NATs it on to /.
    • ... etc ...

    So far, so good.

    Of course, if your laptop sends out a DHCP request, then all the pertinent information (router, DNS, etc.) can be returned that way -- but then again, the laptop has to be configured to accept, for example, the DNS server via DHCP and not be hard-coded.

    So, yes, sure, conceptually it might be possible. And it might even be "easy" to implement. But I can think of a few problems, offhand:
    • First, what I described above -- where some data (IP and subnet, for example) come via DHCP, but router and DNS are hard-coded. The system will have to be able to work in both "transparent magic box mode" and "sensible DHCP mode" at the same time, for the same client.
    • Cases where the laptop's "home network" is comprised of routable addresses, and they want to access something on that network. Er, wait, this might actually work -- but the system would have to keep track of "internal" IP addresses (used by the guests' laptops), so that if, say, two folks from the same company want to file share between their laptops, the system won't forward those packets onto the internet, but'll just let them sit there on the local net.
    • ...I can't think of any other issues right now. I'm sure there are plenty.

    As I said, interesting idea, and I'm really curious if it actually is possible, or if I'm missing something significant here.

    If you implement a cool solution, document it somewhere on the web and send it back to /. again!

    • and a whole bunch of other stuff too. (E.g. client domain, WINS [yech], Samba node type, time servers etc.)
      Go read some DHCP docs...
      • and a whole bunch of other stuff too. (E.g. client domain, WINS [yech], Samba node type, time servers etc.)
        Go read some DHCP docs...

        Er, yeah, I know that. What I meant (and maybe I didn't say it clearly) is that the *client* has to be configured to accept that information from DHCP.

        That is, it's simple to configure a machine with a hard-coded DNS server, while still letting it get its IP address from DHCP.
  • Short answer: No.

    Don't you love it when people say: I don't care how [Insert Your Favorite Standard Here] works, can't you make it work this way instead?

    Long (read: expensive) answer:

    Off the top of my head, I can't think of any COTS solutions to do what you need.

    However, you could put some sort of NAT box with DHCP on every ethernet jack. Assign the "outside" jack of the NAT box to a static IP and NAT that again at a central place to get it out of the building.

    Of course, just providing a computer in every room would be as simple.

  • Assuming you have a bunch of ports on a switch going to a single ethernet interface, what you described may not be possible. Assuming you're doing this in a hotel, what happens if guests in two different rooms have their laptops configured with the same static IP address? There's no way to distinguish between the two guests.

    And what happens when one guest has a hard-coded gateway that happens to be the IP address of another guest?

    Excluding those two possibilities, you just set up a normal IP masquarade system with a DHCP server, and IP aliasing on the internal ethernet port. You set up the routing for the internal network to include all private addresses, which should catch people with static IP addresses. You then watch for ARP reqeusts and assume that they're looking for a gateway, so you add an IP alias for that IP address to the internal ethernet port.

    That should coveralmost everyone. There could be someone with a static non-internal IP number if their laptop is normally on a real network, but you could catch that and add the necessary route, though that's dangerous if someone sets up a static IP of 64.28.67.150 to hijack slashdot, so I would recommend against it.

    Oh, and just for kicks you might want to look into supporting PPPoE connections for anyone who is normally connected via DSL.
    • There's no way to distinguish between the two guests.

      well... there is still the hardware address of the ethernet card.

      Assuming you have a bunch of ports on a switch {...snip...} And what happens when one guest has a hard-coded gateway that happens to be the IP address of another guest?

      i'm guessing you probably re-read that and started to feel pretty silly, since you obviously know something about networking. the other guest's ip address would not be interfered with, due to using the switch (which keeps channels separate so clients can't sniff each other's traffic). the other problem, which is how the gateway would be able to distinguish between clients, i answered above.
      • the other guest's ip address would not be interfered with, due to using the switch (which keeps channels separate so clients can't sniff each other's traffic).

        Right, but the normal way I would think to set up a network would be to have a Linux box with two ethernet ports, one with a real IP address connected to the Internet, and one for the internal network. You then route all the internal addresses to the internal network and IP masquarade them out to the Internet. But the problem with multiple clients using the same IP addresses on the internal network (or having a conflict between a presumed gateway address and a client address) means that you have to totally rethink the normal strategy.

        For this to work, you really have to manage packets based on the MAC address and assume that there aren't two machines that have cloned their MAC addresses. Unfortunately, most of the useful networking tools work at the IP level, not the ethernet level, so you would probably have to write a special IP stack to handle this. (The only ethernet-level tools besides sniffers that I know of are related to bridging or ARP.)

        Of course, I expect you'll have very few complaints if you tell people to either use DHCP or 10.0.{floor}.{room} with 10.0.0.1 as the gateway. People who don't use don't use DHCP usually have half a clue. Still, it's an interesting problem.

        you obviously know something about networking

        Thanks!

  • Not too hard (Score:3, Interesting)

    by photon317 ( 208409 ) on Thursday May 02, 2002 @03:55PM (#3452946)

    First off, for security this gateway box should be running OpenBSD. Nothing else can compete when it comes to being a secure firewall that's open source, flexible, and feature-rich. That aside...

    Run a stateful packet filter and NAT, do all the standard stuff so that they can get out via HTTP, mail protocols, FTP, and VPN (i.e. Cisco vpn cleints).

    Run a DHCP service for the (hopefully majority of) users that either use DHCP anyways, or have the smarts to set their network control panel in winbloze to "autodetect" when they plug into the hotel.

    It's the handling of the wierdos that is problematic. One can assume that the worst case you're willing to support is a guy with a static network configuration of a certain IP, gateway, netmask, and nameservers, all of which don't from the hotel (they are from some company's intranet).

    First off, get a real subnet for the internal NATted DHCP, so that hopefully nobody but you will have used it (i.e. if you used 192.168.x.x, a lot of static config laptops might just happen to use it too, and it would be hard to tell them from your well-behaved DHCP clients).

    Have a sniff on the inside network logging all packets whose source address doesn't match your assigned network. Dynamically insert a rule into your PF and your routing table to make things work for any IP you see on the wire (i.e. you see a source packet from 1.2.3.4, you add into your PF/NAT/Routing setup rules/routes/etc that allow that IP to work). The real trick here is avoiding the problem of someone's laptop having www.yahoo.com's IP address. You might ahve to play some funny rule or policy/tagging trickery to make sure that these added routes don't apply to outbound traffic from other clients.

    Proxy arp for EVERYTHING but your internal assigned client IPs on your internal interface, this should take care of their random default gateway setting. Grab all DNS requests (port 53) and silently redirect them to the local DNS service regardless of where they were supposed to go.

    etc... etc...

    I'd have to actually set up a test environment and do this once to find all the flaws and fix them, but you should be able to go down that general path and make it work.
    • One question...
      What happens when two people who come from different networks but both use the same subnet (i.e. the basically default 192.168.0.x) show up and have the same IP address? The only way I could see this working is if you had each uplink switched and you routed based off of MAC address.
      I don't have the networking know-how to do it yet, but I'm positive it can be done.
  • Here's something that might help

    [root@localhost network-scripts]# /sbin/ifconfig eth0 add 192.168.0.3
    [root@localhost network-scripts]# /sbin/ifconfig
    eth0 Link encap:Ethernet HWaddr 00:03:47:6D:8B:3D
    inet addr:192.168.4.8 Bcast:192.168.255.255 Mask:255.255.0.0
    UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
    RX packets:95 errors:0 dropped:0 overruns:0 frame:0
    TX packets:158 errors:0 dropped:0 overruns:0 carrier:0
    collisions:0 txqueuelen:100
    Interrupt:11 Base address:0x8000

    eth0:0 Link encap:Ethernet HWaddr 00:03:47:6D:8B:3D
    inet addr:192.168.0.3 Bcast:192.168.255.255 Mask:255.255.0.0
    UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
    Interrupt:11 Base address:0x8000
  • Put it in Hotel-speak. What do you do when a customer asks for a non-smoking room so he can smoke? Don't forget that this is probably not supposed to be an *expensive* undertaking. Besides, as others have mentioned there are insoluble problems like IP reuse and discontiguous subnets. I presume here that you don't have explicit cooperation from the rest of that subnet to tunnel the laptop back through.

    I'd start simple with DHCP and WINS. Then examine your customer base and see if adding a few static IPs makes sense without adding a lot of grief.

    Trying to come out of the chute doing everything for everybody sounds like a surefire recipe for failure, with disaster an option.
    • What do you do when a customer asks for a non-smoking room so he can smoke?

      This is a weird question. Most guests who are smokers, yet don't like the smell of old smoke (or are smokers, but not of tobacco), are intelligent enough to get a non-smoking room and apply a simple conversion process once inside it (i.e., light up).

  • watch for any packet coming in, or try and elicit a response by trying some common network requests (I'm thinking some kind of multicast "ping" but the correct term escapes me)

    Anyway when you get a response you can try a reverse-ARP -- the machine *should* spit back its known IP. Of course you won't have any idea what the netmask or gateway is, but screwing around you may be able to determine this info.

    It's an awful lot of non-standard work just to get this kind of bad bad system to work. You have to basically snat packets from the user, dnat packets to him and really really screw with the packets. It's not straightforward and it won't likely work well. Make them use DHCP or nothing. Or provide a network-terminal in the room for them to use. Honestly it's not a good situation any way you look at it if you won't accept them reconfiguring.

  • Here is a company that provides the service to hotels that does what you want. Have no idea what is under the hood though:

    http://globaloop.i.pl/pdf/globaloop-ghotel.pdf [i.pl]

    Here is the google html of the PDF, as the server is SLOOOOW:

    http://216.239.35.100/search?q=cache:ylDnHL43FNIC: globaloop.i.pl/pdf/globaloop-ghotel.pdf+%22no+reco nfiguration+required%22&hl=en [216.239.35.100]

  • Another option (Score:4, Insightful)

    by photon317 ( 208409 ) on Thursday May 02, 2002 @04:13PM (#3453121)

    The consensus (probably correct) is that it's going to be quite difficult to implement, and it will always have corner cases which cause problems and maintenance nightmares, or worse hijacking of public sites.

    So here's a semi-manual different approach:

    Setup the yadda yadda yadda firewall+nat+dhcp standard setup, assuming that all clients are set for dhcp.

    Build a "laptop checker" box with a port hanging out at the reception desk. Inform clients that if they use DHCP (autodetect) like most companies do, they will be fine. If they have doubts or don't know, you can test their laptop's network compatibility for them.

    They plug into the network jack, either a green, yellow or red light lights up near the jack (linux can easily control LEDs :)

    Green means the test machine got a DHCP request from the laptop, so it should be ok.

    Yellow means no DHCP request, and we saw traffic sourced from some random IP. The IP was pinged for on the outside internet, and found to be non-responsive (unlikely hijacking), and doesn't seem wierd in any other way (multicast IP, or the IP of one of your routers, or the IP of another Yellow Light customer currently checked in, or anything else goofy). The receptionist can then (from some little gui) tell the network tester to allow them access. This turns on a special route for them on the inside, and sets it to be removed when they check out. They are warned that if they got the yellow light, we can't support any technical problems they may experience.

    A Red light means there was no DHCP response, and either we didnt see any traffic at all to look at, or they have some bad IP we dont want to assign. We dont add any routes, and we tell them it won't work.

    In both yellow and red conditions, you probably want a little handout to give them that walks through the basics of making your laptop autoconfig so it will work "properly".

    • While the solution expressed earlier (Layer 3 Addressing w/ a seperate virtual Layer 2 network for each node of each switch) would also work, this makes more sense in that it almost certainly would cost less to set up. Also, it could be an easily reusable solution. The red/yellow/green box could be done w/ LEDs as mentioned but would be much simpler done just as a part of a GUI display.
      • It's also quite a PITA for people checking into the hotel. You've been on a plane for 6 hours, waited for your luggage, spent 45 minutes cooped up in a cab or awful rental car...you just want to hop in the shower, change into your white slacks and teal Polo shirt, and hit the bar, maybe chatting up a few ladies or doing a little dancing. You definitely don't want to have to go searching through your luggage looking for your laptop, whose battery is dead from the flight so you need to untangle the AC adapter, oh and find the dongle for the ethernet card, etc. When you come back to your room at 2 or 3 in the morning (maybe not alone!) after several drinks (hey, company's paying), you want to just flip open the laptop and check your email, no hassle.
  • the problem is that in order for your firewall/router to be able to route dhcp from any arbitrary ip address, it has to bind all ip addresses. this would be problematic if a laptop wants to have that address, or if you want to assign that address using dhcp. of course, you could just bind the popular "server" addresses for the popular internal network addresses, so that 95% of people do not have to reconfigure their laptops. (see another post which provides a clue how to do this)

    eg. you don't have to bind 0.0.0.0/0, since you could bind 192.168.0.0/16, 10.0.0.0/8, etc. separately.

    Laptops with really strange(tm) configurations can be told to use dhcp with any one of a dozen server addresses, or else given static addresses. As long as you don't promise that your network will work with 100% of all configurations, you can probably make these hotel contracts work.

    As a start, try playing around with ifconfig in your internal linux network to see what tricks you need depending on the ip address your internal computers are trying to use.

    also, depending on how many client ports are needed, make sure to not put them all on the same router & firewall ethernet card. the more clients are on the same network, the higher the likelihood that they will have ip address collisions. This is especially true of the 192.168.0.x range, since it is very very common. The bright side is that since these are laptops, most or all of them should be using dhcp anyway, so the whole (you don't have to reconfigure) feature would basically boil down to having your firewall bind to the common server addresses, and set up dhcp servers bound to each address, allocating different ip address ranges.

    probably easier to say than to do though... ;-P

    Good luck.

  • Can't be done reliably (Score:3, Informative)

    by pong ( 18266 ) on Thursday May 02, 2002 @04:24PM (#3453221) Homepage
    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.
  • Well, I have seen a lot of people speak to reasons why it can't be done, here is yet another. Think about any two port protocol (FTP comes to mind first). You send the second port out as Data in a TCP packet, unless the ARP tricks or hardware solutions out there want to deal with this you're screwed. All those goofy modules for NAT under Linux exist for very specific reasons. You can't make it work correctly for everybody.

    You can do quite a bit, a ton in fact on a single port protocols. However, you screwing with IP addresses which might screw up IP/VPN/Security/Authentication mechanisms all over the place causing people more problems then just explaining they have to configure the network properly. The real problem is all of the solutions are executing a man in the middle attack. In this case, it is a useful "attack", but an attack none the less. A good security protocol might pick up on it and stop working.

    If you just want them to be able to surf the web, yeah no problem. To reliable be able to accomplish useful work using any tools they are use to, nope too many configuration and or problems with it. Kirby

  • How to do it (Score:2, Informative)

    by Silmaril ( 19015 )
    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.

  • simpliest reason why this can't work. (Score:3, Informative)

    by GiMP ( 10923 ) on Thursday May 02, 2002 @05:05PM (#3453486)
    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.

  • Call people who have already done it (Score:4, Informative)

    by PD ( 9577 ) <slashdotlinux@pdrap.org> on Thursday May 02, 2002 @05:08PM (#3453522) Homepage Journal
    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.
  • Well, one way of doing it is assigning one network card per room - ie, you'll have one box with a dozen cards in it that handles a dozen rooms (you can get multiple ethernet cards - 8ports are not hard to come by). Have each concentrator box essentially act as a gateway on a per port basis. This is called "Killing gnats with a nuke." It works in every case, but is overkill. I'm sure you can figure everything else out with that basic description.

    However, the most effective way to set this up is to assume that 80%-90% of your customers are coming in with a DHCP client. So you wire up the hotel as a regular switched network with DHCP. Then you get very cheap linux boxes, or reverse engineer some of those nifty broadband gateway devices and put your own code in. If a customer is having problems getting on then you truck up to the router closet and reattach their room to one of the linux boxes or gateways which acts like a dhcp enabled translator.

    I suspect you can get a decent router to manage the physical connections and detect the situation so it is completely transparant to the users and the hotel staff.

    Lastly, don't think of it in terms of IP addresses, think of it in terms of MAC addresses. Whenever you receive a packet inside the network with a new ip or mac in the packet, you add it to your database and instruct your NAT to route properly for it. The only situation in which you'll have a problem is when two people come in with the same static address. I'd suggest that this is such a remote possibility that you can instruct the hotel staph to physically reconnect a patch cable to another subnet on your network. Look into switches and routers that route by MAC address only. Then the subnets will take care of themselves, and since your box is dynamically applying IPs based on mac addresses you'll never have a problem.

    -Adam
  • 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...
  • Dont try and build it yourself, there are a ton of headaches, ones you don't realize until you actually start implementing and it doesn't quite work.

    http://www.solutioninc.com/

    I am not affiliated with the company but I know a few of the people working there that developed it (and saw how they were pulling their hair out at times). I have stayed in a few hotels using their product and it just worked.

  • After you have solved the problem with ip-addresses, network masks, etc, you might also consider handling bandwidth hogs. Some PHB is bound to download as much as he can. Maybe you can use traffic shaping to limit each single PCs bandwidth to a certain ratio of the upstream bandwidth (depending on the number active PCs).

    The hotel might also want to bill per megabyte download or per day. I seem to recall that you can get statistics out of ipchains.

  • How the hell are you going to get the person to change their default gateway? Its nearly impossible to get this, especially if you are on an internal network.

  • public port (Score:2, Interesting)

    by OpenMind(tm) ( 129095 )
    At the Univeristy of Illinois, we have a system that does much of what you're looking for, although a foolproof solution is probably not on the market. The network hardware, from Public Port, would tolerate quite a few unreasonable network configurations. You could, for instance, forget that your laptop was statically configed to an IP on one of the campus public networks, and the system wouldn't miss a beat. I've noticed most NAT systems are pretty tolerant of this sort of thing, but this system is seemingly engineered for it. I believe the hardware is currently known as the Tut Systems Expresso SMS/OCS.

    Two scenarios are unlikely to work out for you:
    1. Two users on the private network with the same staticly coded IP. With the proliferation of home NAT routers, this is not unlikely.
    2. A user on the private network tries to contact a public IP address claimed by a machine on the private network. This is fairly unlikely.

    To get around these possibilities would require each port to be treated like its own NAT domain, as well as some fancy routing logic. I won't say it is impossible, just very complicated.

  • Varying responses (Score:2, Insightful)

    by NaDrew ( 561847 )
    I'm not even close to being knowledgeable enough on networking to provide a useable response. I just thought it was funny reading the replies and seeing how they alternated just about one-for-one with "can't be done" and "should be easy, here's how".

    Do the people who think it "can't be done" need more knowledge, or are the ones who say "should be easy, here's how" missing a vital point? Or maybe both?

    Fascinating reading either way.

    • Re:Varying responses (Score:1, Informative)

      by Anonymous Coward
      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.
  • I fail to see the necessity of such a bastardized network. If one of the hotel occupants needs his internet connection badly enough to pay the hotel 20$ for one night, then I'll assume he already knows how to use DHCP. If not, then someone in the hotel will be available to set up his laptop accordingly for another 20$. If they're doing something that requires broadband access, then it's safe to assume they're doing something fairly technical and/or important that justifies the expense or at least basic training on how to configure the network connection. If they're a CEO checking their email in-between suit conventions, let them dial up through a phone line and wait a few more milliseconds.

  • Get 'em on DHCP (Score:3, Interesting)

    by raju1kabir ( 251972 ) on Friday May 03, 2002 @12:20AM (#3455310) Homepage

    I'd suggest doing it this way:

    1) Run a DHCP server to handle the normal people.

    2) Slurp up all traffic originating from an address not handed out by your DHCP server. Respond to requests on viable protocols (telnet, http) with a notice informing people how to switch to DHCP.

    3) Put cards by the telephones that explain how people can set their machines to use DHCP.

    4) Provide raju1kabir with free rooms chainwide for life in exchange for this helpful advice.

    You could easily just alter step 2 in such a way that you indefinitely NAT people's traffic regardless of their preconfigured static addresses, but there is some chance that you'll have two guests who are both set to 192.168.1.1 or who have their gateways set to each other's addresses or something. The chance is slight, but it's hard to deal with without expensive physical segmentation of the network. So it's best to minimize the chances by getting 'em to switch to properly allocated addresses ASAP.
  • I don't know what exactly your hotel guys said, but I expect once you're done with all the hassle, they will boldly advertise "Anyone visiting our hotel with a laptop will have instant Internet access". And then there come the problems. Imagine these cases:
    • During their bold advertisemnt, hotel forgets to mention you need a laptop with a NIC for this. Believe me, many people - especially manager folks - don't know this :-)
    • Laptop has NIC, but is usually used on an isolated network, i.e. has no default gateway, DNS-Server, whatever. The system wouldn't even try to resolve any names to ip addresses or ip addresses to mac addresses, it would just say "No"
    • If used on an isolated network, laptop might not have TCP/IP installed. There's quite a few old Novell IPX and MS NetBEUI installations out there. Or it might have a modem, which is usually used for Internet access, and has TCP/IP only bound to the Dial-Up Adapter, while the NIC has only IPX and/or NetBEUI.
    • Even if laptop has NIC and TCP/IP and a working browser etc., I myself have set up a number of networks where internet access is done via http-proxy. That means, the clients again don't have any default gateway or dns servers. The router/proxy/whatever you need to setup somehow needs to know that it has to play proxy server for these laptops. Others might be using a proxy accessible from the Internet as a gateway into their corporate network. How would you distinguish when to do transparent proxy and when not?

    In short, I would try to explain that for reasons of security, simplicity and budget there is no reasonable solution at the moment. That's what I would do, at least ;-)
    • You are an optimist. You assume:

      -People know the difference between a NIC and a modem jack.
      -laptops always run on different voltages. (110-240 Volt). we are talking hotels.
      -Those company laptops: "The administator has restricted access to the network". (So users are not figgling with their settings).
      -You made a dhcp+nat setup. You made A4 papers explaing how to set up dhcp (and remove proxy settings). You forgot to make a japaneese sheet. Japaneese people own the hotel chain.

  • problems, problems, problems. (Score:1)

    by Anonymous Coward
    Do not forget that as soon as the hotel guest gets back to work and there are *any* problems, they will likely blame the hotel techie for screwing up their laptop. "it used to work" etc.

  • Nomadix [nomadix.com] makes the USG, a network box that was designed just for hotel internet access. It solves the problem of computers with static IP addresses, and also includes hotel-oriented features like billing.
  • The ISC DHCP server will ping an IP address before it assigns a lease. This should work well for almost all clients except Win95. Win95 will reply back even if it doesn't have a lease eventually stealing all of your IP's. As far as supporting public IP's and private IP's two gateways should handle that fine.
  • Educate the Hotel People.

    Explain to them what they want.
    Explain to the the extra time/money/effort required.
    Provide an alternate solution, or charge them out the wazoo =)

    Enjoy =)
  • I can see that you would be able to accomplish this would be to have a gateway/router for every jack in every room. It would be just as easy to put a computer in every room (and I would rather that money be put in new bed sheets and mattereses :-)

    So.. My suggestion is is to just show the staff how to setup DHCP. First, only support windows and Mac (version 9ish and up). Don't support Linux, BSD, Os/2 etc, because if they are using this, they will more than likely already know how to set it up.
    Then, train the staff, seriously, It's not as hard as it seems, I've done it. In windows (and possibly mac, I've never used it much) make sure the hotel has all the cds they will need (or just put all the tcp/ip drivers on one CD). Show the staff how to install tcp/ip, turn on DCHP, turn on proxy if your using it, and then test it.
    Walla, your done!

Slashdot Top Deals

Kleeneness is next to Godelness.

Close