Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 



Forgot your password?
typodupeerror
×
Wireless Networking Bug Businesses Communications Hardware Apple

IPhones Flooding Wireless LAN At Duke 441

coondoggie sends us to a Network World story, as is his wont, about network problems at Duke University in Durham, N.C. that seem to be related to the iPhone. "The Wi-Fi connection on Apple's recently released iPhone seems to be the source of a big headache for network administrators at Duke. The built-in 802.11b/g adapters on several iPhones periodically flood sections of the school's wireless LAN with MAC address requests, temporarily knocking out anywhere from a dozen to 30 wireless access points at a time. Campus network staff are talking with Cisco, the main WLAN provider, and have opened a help-desk ticket with Apple. But so far, the precise cause of the problem remains unknown. 'Because of the time of year for us, it's not a severe problem,' says Kevin Miller, assistant director, communications infrastructure, with Duke's Office of Information Technology. 'But from late August through May, our wireless net is critical. My concern is how many students will be coming back in August with iPhones? It's a pretty big annoyance, right now, with 20-30 access points signaling they're down, and then coming back up a few minutes later. But in late August, this would be devastating.'" So far, the communication with Apple has been "one-way."
This discussion has been archived. No new comments can be posted.

IPhones Flooding Wireless LAN At Duke

Comments Filter:
  • by bucky0 ( 229117 ) on Monday July 16, 2007 @09:16PM (#19883011)
    Summer school students?
  • by MoOsEb0y ( 2177 ) on Monday July 16, 2007 @09:32PM (#19883121)
    Zombie graduate students.
  • by bhmit1 ( 2270 ) on Monday July 16, 2007 @09:36PM (#19883147) Homepage
    Any non-secured network (either where users can plug into the lan or over wireless) where a device is able to bring down the network should be considered defective. I've seen places were the entire lan was flat with users connecting on cisco's management vlan and could bring down the whole company by plugging in a device that advertised a new route to the internet (legit or not). To a similar point, if a device on a wireless network is able to flood the network, then the access points need to be tuned. Sure, they can jam the airwaves, and there's nothing you can do to stop that DoS. But, you don't have to turn 18,000 requests per second into something that broadcasts across the rest of the network. Every firewall app that I've worked with includes throttling and I would hope these APs do as well.

    This doesn't mean that apple released a product without a defect. But if your network crashes because of a defective device, then you should fix your network first.
  • Not apple's fault (Score:1, Informative)

    by megaditto ( 982598 ) on Monday July 16, 2007 @09:45PM (#19883219)
    It's the university's, since their network people allow ARP broadcasts to cross subnets.
  • Re:Cisco (Score:4, Informative)

    by prisoner-of-enigma ( 535770 ) on Monday July 16, 2007 @09:47PM (#19883235) Homepage
    Probably because he knows that a wireless network -- no matter how robust -- will always be at the mercy of a misbehaving device. Air is a shared medium. You can't force a device to shut up no matter what you try, assuming the device is engineered badly enough. That seems to be the case here. Even attempting something basic like blocking a wildcard MAC for all iPhones wouldn't work if the device just persistently floods the airwaves with spurious requests. It's essentially a DoS attack similar to a ping flood, but with no way to "cut it off" at an upstream router. Even better, the "attacking" device isn't fixed to a landline somewhere, it could be roving around in somebody's pocket or purse making neutralization a huge headache. Fun!

    I've done consulting in the wireless market for a while now. One of my key markets is the healthcare market, and I make sure I tell any hospital using wireless that there is absolutely, positively, unequivocally no way they can stop a determined DoS WLAN attack. Set up a noise source at 2.4GHz (or 5.8GHz for 802.11a), crank up the wattage well above the FCC limit for the ISM bands, and aim the antenna at the building. It *will* shut down *any* WLAN you've got unless the building is built like a Faraday cage.

    There is nothing you can do about it short of rooting out the source of the noise and shutting it down. Granted, such an attack is highly illegal (violates FCC radiated power limits, which might be a felony, I'm not sure), but I doubt that's on the mind of the prankster (or terrorist) who's shutting you down.
  • Apple DHCP client (Score:5, Informative)

    by papasui ( 567265 ) on Monday July 16, 2007 @09:52PM (#19883271) Homepage
    I'm a net engineer for one of the major US cable isps.. A VERY common issue I see with the Apple Airport Extremes is a problem with them declining offered leases infinitely. When this happens the DHCP server marks the lease as temporarily unavailable, the end result is a single offending Airport extreme can eat all the available addresses. The work around is to configure the dhcp server to ignore declines from the client. Regardless it's very annonying (and I'm typing this post on a Macbook so I'm not anti-Apple).
  • by icydog ( 923695 ) on Monday July 16, 2007 @09:55PM (#19883293) Homepage
    For all you saying "It's Duke's fault! Secure the network!" maybe you should consider that Duke provides wireless access to something like 15,000 undergrads, grads, faculty, etc. Duke's network is set up so that you can connect to a pool of internal IPs with no authentication, but before you can actually go to any sites other than the network registration site, you have to type in your Duke ID and password.

    This is an effective solution. Can you imagine if Duke locked down APs with MAC filtering? You'd have 10,000 "authorize my MAC" requests between August 15 and 30 each year on an already-overwhelmed IT staff, and you can spoof MACs anyways. How many people actually know what a MAC is and how to find it? Sure, they could provide a tool that automatically detects your MAC, but how are you going to download it if you can't get on in th first place?

    Also, please don't suggest WEP/WPA, because distributing a password/passkey amoung that number of users is as good as not having one at all. And a more complex solution, like PKI or smartcards, is going to create more headaches than it's worth when deployed to this number of users.
  • by Vulturejoe ( 570401 ) <vulturejoe@gmai[ ]om ['l.c' in gap]> on Monday July 16, 2007 @09:58PM (#19883317) Homepage
    They're requesting the MAC addresses of other devices, using ARP. The problem seems to be at least partially the fault of Duke's network. From TFA:

    "The requests are for what is, at least for Duke's network, an invalid router address. Devices use the Address Resolution Protocol (ARP) to request the MAC address of the destination node, for which it already has the IP address. When it doesn't get an answer, the iPhone just keeps asking."
  • by mveloso ( 325617 ) on Monday July 16, 2007 @10:19PM (#19883485)
    They're not using the right terminology. It sounds like the iPhones are doing an ARP request for an IP address that isn't on the Duke network. Maybe it's trying to update its ARP tables?

    Anyhow, the ARP standard is unclear enough that it's undefined what the response should be for an ARP request to an unknown destination should be (http://www.faqs.org/rfcs/std/std37.html). Theoretically, every packet that you send needs an ARP entry, which means that every packet sent to something that isn't in your machine's ARP table would generate an ARP request. In reality, it seems that your router tends to substitute its own MAC address for non-local ARP entries (since all non-local packets go through the router, you really don't have to know what the real MAC address is)

    It sounds like the Duke Cisco routers are misconfigured somehow, and are generating an ARP storm. Some Cisco routers has a bug where a packet sent to an IP address for which the router doesn't have an ARP entry causes the router to broadcast all subsequent packets across all of the router's ports. It happens in the cable industry when someone swaps out a GigE card and forgets to update the ARP tables on the Ciscos. Solution: use dynamic ARP tables, which can be a security hole.

    FWIW.
  • by Architect_sasyr ( 938685 ) on Monday July 16, 2007 @10:29PM (#19883539)
    I don't know if this is a "better" answer, but I haven't liked the one's given yet: Initial DHCP request goes to ARP broadcast (which should NEVER make it past the AP/Authenticator depending on setup - much less into another subnet), a response is returned containing an IP address. Most units hold the IP address in temporary information and do another ARP request to see if anyone has that address in use (again to ARP broadcast). If it is in use then they try again, if not the unit assigns itself the IP address and joins the network. It then tries to find the ARP address of the DNS servers (look at it in wireshark or tcpdump - "who has x.x.x.x tell y.y.y.y"), the Gateway and whatever else your standard unit would be looking for (Domain Controller for a PC, Samba shares if you have auto-search enabled etc.).

    My guess is that either there is no DHCP and the iPhones just try like crazy, or some other misconfiguration of the network is causing these. Couple this with potential interference from all the other iPhone devices in the area, which could (and probably does) cause dropped packets, and one has a veritable storm of ARP requests which could easily take out subnets. 8 wireless cards is enough to DoS a high end wireless access point (Yellow Laptop anyone) so it doesn't stretch the imagination to think that some iPhone's could do it.

    My $0.02 AU
  • Re:Critical? (Score:2, Informative)

    by Citius ( 991975 ) on Monday July 16, 2007 @10:56PM (#19883729) Homepage Journal
    No, not technically, but most students at Duke do have laptops. What we do have, however, is this: Our libraries have a small cadre of laptops that can be borrowed from the library for at most 3 hours. Since 3 hours is about the maximum length of any final exam, we all can get away with just borrowing one if the need arises.
  • by Anonymous Coward on Monday July 16, 2007 @11:02PM (#19883765)
    From TFA:

    The requests are for what is, at least for Duke's network, an invalid router address. Devices use the Address Resolution Protocol (ARP) to request the MAC address of the destination node, for which it already has the IP address. When it doesn't get an answer, the iPhone just keeps asking.
  • by Anonymous Coward on Monday July 16, 2007 @11:10PM (#19883843)
    Read the article, it is sending an arp request for the mac of a specific router or gateway, I guess you could call that a "mac address request". When it does not receive a response, it does it again, apparently about 18K times a second. Why does it not receive a response for what it is looking for? Because the mac of the router or machine it is requesting is not on that subnet and no one is really sure what router or MAC the iPhone is looking for it and why.

    This is just a guess but it is probably looking to connect to the previous router or some router it knew about at one time in the recent past. The only thing a device needs the MAC for is its router and other devices in its subnet. I've seen Windows laptops do this on occasion when they switch to a different access point in a mesh that has a different gateway. Example, you are attached to AP1 with a 192.168.0/24 network and a gateway of .1, you walk 20 feet down the hall and your wireless decides to switch to the now closer AP2 which is in a different vlan with a network of 192.168.1/24 and a gateway of .1. Your device attaches to the different AP but your IP stack does not fully reconfigure itself, your device while attempting to send packets can't find the MAC of 192.168.0.1 which was the old gateway and starts asking with ARP where the hell it is (looking for the MAC). It may even be looking for 192.168.0.10 which was some other network device it was communicating with when it was on the old subnet and may be flooding ARP requests for that as well. This is just speculation but maybe there were open connections when it switched networks and the stack can not free that up and allow the switch to happen cleanly.

    Should a Cisco AP crash because of this? No, you never trust the client for security or for stability. Put some adjustable rate limiting per client setting in there. Should the iPhone be flooding ARP requests? No as well.

    What makes this even more interesting is Cisco and Apple are generally slow to publicly acknowledge "issues" with in their hardware and software.
  • Re:Apple DHCP client (Score:5, Informative)

    by Doctor Memory ( 6336 ) on Monday July 16, 2007 @11:17PM (#19883887)
    Actually, that's just what the server should do. The client is only supposed to send DHCPDECLINE if it detects that the network address is already in use. DHCP servers are encouraged to check any address offered (using an ICMP Echo Request) to make sure it is not in use. However, there's also supposed to be a switch to turn this off. DHCP clients are encouraged to check any offered addresses using an ARP packet. If the ARP packet generates a response (indicating that another machine already has the offered address), then the client should respond with DHCPDECLINE. Therefore, if the server isn't checking addresses before it hands them out, it stands to reason that it would mark them as "unavailable" if a client responds that the address is already in use. Unfortunately, the side effect would seem to be that a misbehaving piece of hardware could indeed eat all available addresses. I'd suggest that the remedy for that is to have the server check any declined address, and only mark it "in use" if it got a response.
  • by dgatwood ( 11270 ) on Monday July 16, 2007 @11:23PM (#19883911) Homepage Journal

    I suspect what the GP meant is that it's part of the Rendezvous/zeroconf dynamic IP process, which is often built into dhcpcd/pump/dhclient or equivalent. The very first thing most modern computers do when they see a network is to pick a random address and ARP for it, then assign themselves that IP if it isn't used.

    Also, it is part of the DHCP process, I think. The last step in the process is to ARP for your assigned IP to make sure it hasn't been doubly assigned. I'm not sure if that's actually part of the spec or not, but every OS I've ever studied under tcpdump did it, so I would assume that it is.

  • by Dhalka226 ( 559740 ) on Monday July 16, 2007 @11:27PM (#19883953)

    Instead of being wealthy and pay tuition, you can also simply be smart and hard working.

    He mentioned scholarships, though it was in an offhand way. You're certainly free to disagree with what he's saying, but insulting him twice in six sentences while "refuting" him with a point he already made is absolutely wrong on any level.

    Besides which, your own point is really no gem either. Your advice to get a scholarship is to be smart and hard working? It's half true, sure. Colleges do give scholarships to people with good grades--though often you also need extra-curricular activities to put you ahead even though that really has nothing to do with intelligence or hard work, merely interest in organized activities--but those are limited. If every student in the nation suddenly became smart and hard working, it would still help only an exceptionally small percentage of them receive a scholarship. In fact, since Duke is a good school you can be relatively sure that the vast majority of students who are accepted there are already smart and hard working, so even in your limited example

    I happen to think the way the OP handled himself was flamebait, but the question he raised about free education is a debate worth having. Preferably without insults.

    Congratulations to your daughter for getting in, getting money and getting through--but just because she did doesn't mean everybody else can, even those equally smart and hard working.

  • Re:Cisco (Score:5, Informative)

    by prisoner-of-enigma ( 535770 ) on Tuesday July 17, 2007 @12:12AM (#19884209) Homepage
    I am taking a cisco internetworking class and I do not think that it is similar to a DoS attack because a DoS attack involves changing the source address in the packets that are sent to a server. I do not think any students at Duke have found a way to hack the iphone to allow modified packets to be sent out.

    Not to seem unkind, but it sounds like you need to finish your classes before weighing in on this subject. You do not seem to understand the nature of a DoS attack enough to comment properly on it.

    To clarify, it has nothing to do with altering the source address. While some hardwired DoS attacks involve the spoofing of source addresses, it is not required. Any kind of action that prevents the target from functioning as designed constitutes a DoS attack, and flooding an AP with spurious MAC requests fits that description. Since the iPhone is doing this as part of its (probably flawed) design, no hacking of the iPhone is required.

    The Cisco AP's and WLAN controller have little choice but to listen to whatever traffic the iPhone spews out. Sure, they can discard or ignore the traffic, but it doesn't change the fact that a rampant iPhone "attack" will consume shared air time even if such action is taken. With enough iPhones, any single AP can be completely overwhelmed even if it's ignoring everything the iPhone is throwing at it.

    As I said before, you can't switch, route, or firewall air. You're always at the mercy of the person transmitting with the least control or scruples.
  • by kayditty ( 641006 ) on Tuesday July 17, 2007 @12:42AM (#19884381)
    I have no idea why no one on the entirety of slashdot knows anything about networks. If I were to reply to every wrong post in this thread alone, I'd be here all fucking morning, so I'm just going to deal with this one.

    DHCP is not implicit in any network topology. It may be modern and 'expected,' but, jesus christ, every time there's a network discussion on this site, DHCP is strewn all over it like shit on a truck stop toilet. Just because you were born in 1995 and have an "ADSL" connection that uses DHCP (well, it probably uses PPPoE now) doesn't mean you're qualified to say anything, and it certainly doesn't mean there aren't real networks that have never even heard of the silly little protocol.

    That said, the initial DHCP request does go to a broadcast address, but it certainly has nothing to do with ARP. It goes to the global broadcast address (MAC: FF:FF:FF:FF:FF:FF). There's no such thing as an ARP address. ARP is a network layer protocol lying atop Ethernet (primarily; it isn't limited to Ethernet, of course). It is a MAC address you are thinking of.

    Your use of commas is worse than your knowledge of low-level network protocols, really. I don't even know why I bother. Whoever mods this shit up, go fuck yourself. And whoever's out there that actually does know what they're talking about (surely there's someone else out of two million users), like I do, fuck you for not replying and setting these morons straight. It's a ridiculous place to read for technological discussion, anymore.
  • by schon ( 31600 ) on Tuesday July 17, 2007 @01:33AM (#19884543)
    Oh. My. God.

    How the hell did you get modded informative with that god-awful collection of misunderstandings and poor comprehension of clearly understood concepts?

    the ARP standard is unclear enough that it's undefined what the response should be for an ARP request to an unknown destination should be
    Umm, what?!?!?!

    There's nothing unclear about the standard, except when you apply it incorrectly.

    To begin with, there is no such thing as an "unknown destination" - if the address is unknown, how the hell do you send a request for it?!?! (You ever call 411 and say "Hi, I need the phone number for someone, but I don't know who they are, where they live, what they do, or anything about them.")

    Now, if you're clumsily trying to say "there's no way to answer: what is the MAC address of an IP address that is unassigned", then that's simple - there is no answer (nobody responds, so therefore there is no answer - which means that the IP address is unassigned.)

    However, if you're trying to say "what is the MAC address of an IP address that resides on a different network" then the answer is the same - there (again) will only be a reply if
    a machine with that IP address exists on the network. IP networks are virtual - you can have many different IP networks residing on the same wire. If a machine hears an ARP request for an address that is not on it's network, it just doesn't answer (the inherit assumption is that there is another IP network on the same wire, and the request is ignored.)

    ARP doesn't know anything about IP network layout - basically, machines just respond if they hear a request for their IP address.

    Theoretically, every packet that you send needs an ARP entry, which means that every packet sent to something that isn't in your machine's ARP table would generate an ARP request.
    No - every packet you send needs a DESTINATION (either broadcast, unicast, or multicast). Unicast packets (which is what we're talking about here) require a destination MAC address, but these destinations don't have to be resolved using ARP - it's quite possible to have some or all of them in a static table, if you like. However, it looks like you're just confused, because of...

    In reality, it seems that your router tends to substitute its own MAC address for non-local ARP entries (since all non-local packets go through the router, you really don't have to know what the real MAC address is)
    You are confusing IP and Ethernet (802.3, 802.11, etc.) networks. To ethernet, there is no such thing as a "non-local" packet - all packets are local.

    When you want to send to an *IP* address that is not on the local link, you look up the IP address for the router(s) to that network, ARP for it (if you don't already know it's MAC address) and send the packet to it - there is no 'substitution' involved. You never ask for the MAC address of the destination IP address, you ask for the MAC address of your router, then send it the packet for forwarding.
  • by tolomea ( 1026104 ) on Tuesday July 17, 2007 @01:51AM (#19884631)
    There is a standard called proxy arp that does essentially this. In essence the router will start responding to arps for IP addresses on it's other interfaces. The valid use cases for it are virtually all bizarre and it can cause all sorts of horrific problems.
  • Re:Not apple's fault (Score:3, Informative)

    by JFitzsimmons ( 764599 ) <justin@fitzsimmons.ca> on Tuesday July 17, 2007 @01:56AM (#19884653)
    Wait, I think I know what you're suggesting here: You're saying that more than one IP network is being used within a single broadcast domain, and all of the clients connected to that broadcast domain receive the ARP request since it is a layer 2 broadcast. I think that's irrelevant, but it does makes sense, and you would hope that VLANs would help with this problem. VLANs probably ARE helping considering that only certain segments are going down and not the whole thing. Presumably only VLANs with iPhones connected are being DoSed. I think this is clearly an iPhone problem; It shouldn't be flooding a network asking for information it already has and/or is unable to get. Now that I think about it, what you say is happening is probably true, but is completely unavoidable, by design. The only way to limit layer 2 broadcasts is to split up broadcast domains with VLANs and use layer 3 routing. You can't vlan the clients on a wireless access point because a WAP is effectively a hub. In theory any malicious person would be able to join the wireless lan and spew layer 2 garbage addressed to FF:FF:FF:FF:FF and there's nothing anyone could do.
  • by itwerx ( 165526 ) on Tuesday July 17, 2007 @02:21AM (#19884771) Homepage
    but several phones can bring down the network? seems very vulnerable. Is there anything AP can do to just ignore the rogue requests?

    It's probably related to Cisco's built in defense mechanisms. By default if a Cisco AP detects what it thinks is an attack it will go offline for awhile. The problem is that in the real world there are buggy chipsets and drivers that will trigger this so one usually ends up disabling them in self-defense. As a specific example there is an Intel WLAN chipset present in many older laptops that will randomly resend packets. An AP configured with default settings will shut off for exactly 60 seconds after it sees a couple of those as it thinks a replay attack is being used against it.
          There are several different attack vectors detected and timers associated. But I would think a university would already know all about this and have them configured correctly but if not then yeah, a couple of rogue devices can bring the whole shootin' match down. (To be fair Cisco isn't the only AP vendor that this can happen to).
  • by Anonymous Coward on Tuesday July 17, 2007 @03:12AM (#19884987)

    I suspect what the GP meant is that it's part of the Rendezvous/zeroconf dynamic IP process, which is often built into dhcpcd/pump/dhclient or equivalent. The very first thing most modern computers do when they see a network is to pick a random address and ARP for it, then assign themselves that IP if it isn't used.

    If that's what the GP meant then that's what they should have said! You're talking about this:

    So no, the IP address is not "random" but yes, ARP does get involved - but not specifically as part of DHCP per se.

    Also, it is part of the DHCP process, I think. The last step in the process is to ARP for your assigned IP to make sure it hasn't been doubly assigned.

    Technically it is not required, but many clients will double-check just in case (section 2.2, IETF RFC 2131).

    I'm not sure if that's actually part of the spec or not, but every OS I've ever studied under tcpdump did it, so I would assume that it is.

    Never trust various vendors as your source of how things are "supposed" to work! :-)

  • by lmfr ( 567586 ) on Tuesday July 17, 2007 @06:27AM (#19885665) Journal
    From the article:

    The requests are for what is, at least for Duke's network, an invalid router address. Devices use the Address Resolution Protocol (ARP) to request the MAC address of the destination node, for which it already has the IP address. When it doesn't get an answer, the iPhone just keeps asking.

    "I'm not exactly sure where the 'bad' router address is coming from," Miller says. One possibility: each offending iPhone may have been first connected to a home wireless router or gateway, and it may automatically and repeatedly be trying to reconnect to it again when something happens to the iPhone's initial connection on the Duke WLAN.

  • Are you somehow trying to imply that a campus-wide network that supports THOUSANDS of wireless devices with no issues, is automatically the one to blame when 1-2 iPhones bring it down, without even knowing the details?

    It's amazing the Apple fanboy-ism around here. I have seen MANY devices have flaws like this in my time. Everyone knew the iPhone, as a first gen product, was going to have it's problems. This is likely one of them.

    And no matter what you seem to think you know about WiFi - one device can EASILY flood others off of an AP with a lot of ARP requests, because they will suck up all the available bandwidth for itself. It is a well known fact very easy to DOS a wireless access point in this way. You gotta remember WiFi is a shared medium every client doesn't have dedicated bandwidth by any stretch of the imagination. It is not hard at all to assume that this is a broken WiFi driver in the iPhone.
  • by that IT girl ( 864406 ) on Tuesday July 17, 2007 @08:30AM (#19886179) Journal

    Zombie graduate students


    I just love that this post is, as of the moment, modded as Informative.
  • by Phreakiture ( 547094 ) on Tuesday July 17, 2007 @08:50AM (#19886285) Homepage

    I'm sorry, but there's something a little OFF here. No wireless hardware requests a MAC address. It may use MAC to authenticate to a table, but it goes for a DHCP lease.

    I would suggest that perhaps you didn't RTFA, but that is a given, since this is Slashdot.

    It is, indeed, asking for a MAC address.... it's called ARP [wikipedia.org] and it is how an Ethernet device determines what MAC address to use to reach a destination IP address.

  • by Anonymous Coward on Tuesday July 17, 2007 @10:03AM (#19886875)
    How in the world you got moded up for this is I will never know. It is just completely wrong. If you send an AP a packet it has to AT LEAST read the header. You can bring down ANY network just by sending it more headers then it has bandwidth.
  • by profplump ( 309017 ) <zach-slashjunk@kotlarek.com> on Tuesday July 17, 2007 @10:04AM (#19886885)
    I've been living in Iowa, financing my own education -- I just finished ugrad in 2005, and I'm now working and starting my grad degree. I'm not just making this up.

    This fall total tuition and fees for most majors at Iowa State is $3080.66 / semester:
    http://www.iastate.edu/~registrar/fees/tuition0708 .html [iastate.edu]

    Minnesota: $4705 / semester
    http://admissions.tc.umn.edu/costsaid/tuition.html [umn.edu]

    Wisconsin: $3365 / semester
    http://www.admissions.wisc.edu/costs.php [wisc.edu]

    Those figures don't include "Room & Board" because you need "Room & Board" whether you're in school or not, so it's a little silly to pretend that it's a cost related to your education. Even if you include R&B, which is on the order of $6k/year at those schools, you could make that much working a student-wage job for an annual average of 20 hours/week (or 14 hours/week if you work full-time for 12 weeks in the summer).
  • Re:Not apple's fault (Score:2, Informative)

    by Dorkmunder ( 950796 ) on Tuesday July 17, 2007 @12:46PM (#19889183)
    you actually can separate out traffic into VLAN's from a WAP, you would just have to have an AP that could run a trunk back to a switch and then you could run a RADIUS server or something to do the segmenting (either based on a user login or by MAC address). In fact they could create a separate, dead-end VLAN on all their AP's that all iPhones are "switched" to if the iPhones' MAC addresses have enough in common to sort them out (without dead-ending a bunch of MacBooks or something).
  • Re:Not apple's fault (Score:3, Informative)

    by JFitzsimmons ( 764599 ) <justin@fitzsimmons.ca> on Tuesday July 17, 2007 @01:39PM (#19890093)
    Except a WAP is a hub. You can't segment it. Everything gets broadcast over the same medium if it is a broadcast packet or not.

Understanding is always the understanding of a smaller problem in relation to a bigger problem. -- P.D. Ouspensky

Working...