Posted
by
kdawson
on Monday July 16, 2007 @08:10PM
from the arp-storm dept.

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."

Not to mention that there are several hundred wireless access points on the Apple campus, and several hundred (possibly thousands) of iPhones on the same campus. You'd have thought that any inherent problem with the phone and networking would have been caught, isolated, patched, and distributed by now...

You would have thought, but what happens on paper and what happens in the real world are often two entirely different things. It all goes back to how many possible different configurations you can test for in a laboratory before you let something go loose in the wild.

If you RTFA, you'll see that the iPhones were activated off-campus and were trying to access a non-existent IP, most likely related to the first IP that the iPhone came into contact with after being activated. Whenever the iPhone lost connectivity on campus, it would try to seek out that original IP upon re-establishing a connection. In the case of Apple testing on their own campus, the phones were most likely activated at Apple and stayed the majority of the time at Apple - thus the problem never had a chance to crop up. Bizarre behavior, but bugs will happen.

Actually, it's probably really an ARP request. They probably have a very large, flat network and when the iPhones does an ARP broadcast request the AP gets overloaded by the results. This was a known problem with the old Aironet AP's, one of the senior software guys at Cisco/Aironet produced a one off patch for a large university client for the old VxWorks based AP's when I supported them back around the 2001 timeframe. It was actually one of the best examples of object oriented code I had ever seen, he changed the definition of the ARP buffer in one place, recompiled and everywhere that ARP was used the code was updated, very slick.

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 au

But the iPhone is from Apple, of course it would ask for a Mac address! Heck, they should be glad it didn't ask for a Mac-II address, things would be twice as bad! (You can do the math for a Mac-IIcx:)

But that's exactly the problem. The iPhone handshakes with a "How are you gentlemen." and asks for a MAC address, at which point the WLAN's response is "What you say !!" and it goes downhill from there...

So, who cares? So he submits stories from Network World. He probably works for Network World. Does that fact alone make the story less valuable or interesting? If someone else had submitted the same story, it would be OK then? Slashdot has editors and a moderation system. There's nothing inherently deceptive in submitting your company's (or your own) stories.

If it's not good and still getting accepted, that is a problem with the editors. But so long as the article provides something interesting, what does it matter if the person who submits it gets a profit off the site?

At least 2 of his 20 published submissions [slashdot.org] were from non-networkworld sources. Of course his only posted comment is a 'correction' to a story linking which he's trying to point to....networkworld. Astro-tuffing should get some kind of modding too. And why are submitters not linked to directly, I had to cut/paste his name in just to see his profile.

He states now it's not a big problem, (guessing because it's summer and not as many students there). Then expecting it to be a BIG problem once students arrive. So to me this says that the iPhones using their service aren't students at all. If this is the case, buckle down the AP settings so they're not open or easily accessible via iPhone and require students to anti up their MAC addresses to connect to the wireless network.

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.

Okay if this is really the case, no DHCP network, then why does this same thing not happen when Laptops looking for DHCP addresses come in range of duke? For example, I would imagine that whenever there's a conference or perhaps when the student show up in september that all the laptops on campus are set to hunt for DHCP by default (since that's how one usually sets up wireless networks). Seems like you'd have the same sort of storm.

Movement. Laptops are often off when they move and most people carry them very slowly if they're off. An iPhone can move around the campus a lot faster and will try to connect to every access point along the way. In colleges a lot of movement is at exactly the same time i.e. lunch and between classes. During these times a large number of devices could move from one node to another. The network might have trouble keeping up with all the movement of devices into and out of it.

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.

I suggest everyone to read Douglas E Comer's Internetworking with TCP/IP Vol 1 - Principles, Protocols and Architecture. It's a little old book but amazingly good one, allthought new editions comes with yellow cover, I liked the red one better (we used to call it Comer's Red Book:) Anyway, it came really handy when I was dealing with NDIS intermediate network drivers (Windows stuff) and Ethernet & TCPIP protocols.

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 o

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)

Say what? The last time I saw something equally screwy it was a Cisco LightStream 1010 (ATM switch) running LANE (LAN Emulation) that played no part in layer 3 at all, yet it was still building up an ARP table of every IP datagram that flowed through it (and wondered why it kept running out of memory).

If you send out an ARP for an "unknown address", you'll get no response - it's not up to the router to respond on behalf of "non-local packets", it's up to the client to determine that the destination is non-local (by using the network and mask together) then picking a suitable gateway (usually default) for sending the packet on its way.

Therefore, the client already knows it needs to send the non-local/unknown-addressed packet through the router so it explicitly ARPs for the router's MAC address (if not already cached) - nothing to do with trying to get the MAC of the remote destination.

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 ifa 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.

He states now it's not a big problem, (guessing because it's summer and not as many students there). Then expecting it to be a BIG problem once students arrive. So to me this says that the iPhones using their service aren't students at all.

Little leap of logic there. Most campuses have a decent number of students on campus during summer for any of the following reasons:

(i) summer classes
(ii) research (i.e. most grad students who don't even realize its summer)
(iii) friggin professors

The first people I can think of that would be on campus: professors, grad students, summer classes, visiting students, administrative staff, and summer camps & programs. I'm sure there are more, but the point is that a University of that size never completely shuts down.

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

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 o

Mod parent up. My university has gone to all-wireless too, and it's completely retarded because it's so unreliable. **A MICROWAVE OVEN IN THE KITCHEN KNOCKS EVERYONE OFF THE NETWORK**, for christ's sake, and that's to say nothing of intentional disruption.

Yes it is dumb. Run some cable and leave the wireless for students with laptops and shit. Cables are the best method for mission critical things anyways.

Ofcourse, if they are using it for everything even desktop computers in labs... It could very easily be that a few iPhones can bring down APs but that would be a colossally stupid idea to begin with and any network designer approving such a plan should be shot.

The number of students who use a wireless network for basic needs is rapidly growing at Duke. As a recent Duke graduate, I've been in a number of classes where tests are administered over the WLAN using Blackboard (burn BB to hell!). If a WLAN AP goes down, and that's during a test, you've got the grades - and unhappiness - of 40+ people/class on your head.
Given that we're a rather nitpicky bunch over our grades, grade unhappiness doesn't end well for those who cause it...
So yes. Wireless is critical at Duke.

Student: I'm at Duke and my iPhone's wifi just stopped working.Apple rep: I'm sorry sir, but Apples just workStudent: Yeah, well mine isn't just working right now!Apple rep: Sir, do you BELIEVE in the power of Steve?Student: The what?Apple Rep: Sir, maybe if you had more faith in Steve, you wouldn't be having problems...Student: Look, I just want my damn phone to work.Apple Rep: Then I think you need to attend our Apple Reaffirmation CampStudent: Will it help get my wifi signal back?Apple Rep: No, but it will help you get your FAITH back, and stop questioning the infallability of Apple productsStudent: Um, okay. Anything to get my smug sense of superiority back.

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.

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.

Dude, WTF? A DoS ("Denial of Service") attack is any attack that makes things stop working (or is intended to do that). Nothing to do with changing the source address, that's just to make it easier to not get caught.

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.

Sure. And when some script kiddies launch a DoS attack that takes out your router, leaving you completely without connectivity, that's not a Cisco problem either. It's obviously a script kiddie problem.

...it's their network. Why are we only hearing about it here? They probably have a loop in their network or some kind of ARP forwarding active they don't understand. You would think something like this would get caught early on in testing with the iPhone, this kind of problem tends to stand out. I also doubt the iPhone has enough horsepower to pump out 10Mbps of ARP requests, sounds like a networking device is sourcing these packets.

I also doubt the iPhone has enough horsepower to pump out 10Mbps of ARP requests

A 486 can swamp a T-1 line, I don't doubt that the ARM processor(s) in the iPhone can max out a 54Mb 802.11/g link. One ARP request is only about 28 bytes, and it's not like there's a lot of computation involved in creating one. I agree, it sounds like there's some kind of misconfiguration, I can't imagine why any device would fire off that many requests unless it was receiving some kind of response that caused it to send a new request. Hmmm, I wonder if it's some kind of timing issue, maybe the phone i

Actually I was in an Apple store last Thursday and they were having the same problem. I was trying to connect to their network with another non apple device and finally connected on third attempt. The store employees were all aware that their phones were having trouble connecting and staying connected to the wireless. Many of the phones were having to connect through ATT.

I can take out a cisco WLAN controller with thin APs and aironet APs with an arp flood for a non-existent IP. Are they even in the same subnet? Is the whole wifi network from one building to another layer2? Or is the problem arising because it is actually layer3 from building to building and the APN name doesn't change.Judging by the statement that they can exhibit the behavior after being handed from one access point to another kind of nullifies the theory that they may be trying to re associate with the u

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.

Your network isn't secure because you're not able to bring it down. It's secure if during the processes you are able to avoid information leaks. Any network, no matter how secure, using a wrong implementation of a protocol becomes vulnerable.

To clarify, I was referring to physical security, which few networks have. A properly configured network should isolate any poorly configured device as close to the source as possible. So a mis-configured wireless devices should optimally only be able to impact thi

18,000 arp requests a second? Smells like a spanning tree loop to me. Thats where I would start looking. Could be a single AP bridging the same vlan with spanning tree disabled. Anyone roaming into into its range could cause havoc.

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 EASIL

I would imagine that this problem is either A) a configuration problem on the school's end, or B) will be fixed fairly quickly. I suggest "fixed quickly" because if this is a problem, then all those iPhones Apple is giving to their own employees will crash the Apple campus wireless network too. Plus given all the amazing paid and free press Apple is getting on the iPhone I'm sure they don't want any significant problems arising to generate legitimate bad press about their shiny new product.

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).

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.

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

Oh come on. MAC registrations are almost wholly automated at any given large university--including Stanford, Berkeley, UBC, UC Davis, and Penn, where I have had personal experience. All you do is login with your staff (or I suppose student) account information and head to a page where you enter the MAC address(es) of your computer(s) along with your employee number and birthday or some other personally identifying information they already have on file. You click submit, and within 30 minutes you get an email saying your computers have been authorized.

The only downside is that some schools require this must be done from an authorized computer, so you have to head to a computer lab or classroom the first time you do it. Other schools allow you to get into the system from any Internet-connected computer, which is the ideal solution, since it's behind a two-part authentication system anyway.

You make the mistaken assumption that the goal of MAC address restrictions on university campuses is to crack down with an iron fist. It's not. Since the networks are so large and fluid, with tens of thousands of users and machines, it's pointless to expend tremendous funds to lock down the Internet like a Defense Department project.

MAC address filtering is simply a roadblock to keep the general public off the network. This need must be balanced with the high number of legitimate visitors on campuses (for presentations, symposiums, conferences, guest lectures, and all sorts of other purposes) which need to have a way to access the Internet (simple using preconfigured authentication tokens).

The students and staff are not the concern at all. Their MAC address spoofing and playing around is simply a matter of course. It's people outside the campus community that they want kept out. A combination of authentication and MAC filtering pretty much takes care of that. Even if they do successfully spoof a valid MAC, they don't have a username/password to get past the login screen. If they've gotten all of that, there's really nothing practical that will stop them from gaining access. It's also irrelevant for that handful of people. There's little point to waste any time or money tracking them down or even trying to find those isolated incidents unless a crime or breach occurred as a result.

spend thousands of dollars on expensive Cisco AP equipment, a factor above consumer grade systems, and something goes wrong, the extra instrumentation doesn't help and the vendor just blames somebody else? Is this a good reason not to go with expensive equipment, or just colossal incompetence of the administrator who configured everything?

Cisco has it's moments, but IMHO they're not remotely worth the premium you pay. Go with HP; they sell the same level of hardware and offer the same level of support, but it costs a hell of a lot less, and since it costs so much less you can get the hardware you actually need rather than just what you have to settle for because your budget doesn't swing more than one 10,000 dollar PIX.

Add to that the byzantine configurations, and it's easy for a non-gifted engineer to make pretty big mistakes.

If Apple can't make hardware that works, and/or won't own up to their problems and fix them, then ban all iPhones from connecting to the university WiFi network via their MAC vendor and device ID portions. After all that is what the structure of a MAC is for - so the network admins know what kind of devices are being used.

Banning iPhones campus wide because they are faulty would trigger some nice nasty press for Apple and piss off a lot of owners of the device - I imagine they would fix the problem much faster (or at least respond to the ticket!)

Sounds like they are having some issues with arp-whois being propagated across the subnets. Knowing Apple, each time these iPhones try to 'rendezvous' with all the Macs or iTuned PCs they refresh their ARP tables off the entire campus. Something is fucked up with their network machines if the arp boroadcasts are seen by the entire campus (hence the 30 access points going at once).

What they need is an AP isolation: the connected client should not (easily) see other subnets and should definitely not be able to spam ARP broadcasts across subnets.

An interesting factoid on this, though a little OT: iPhones do not appear to implement rendezvous/bonjour/zeroconf. I can't connect to any of my Mac zeroconf hosts by connecting through the *.local domain names that bonjour usually sets up, and I've read others [duncandavidson.com] are unable to do this as well.

It would probably be prudent to fix the existing "lower" education systems we already have so that they are once again adequate training to hold a normal job. We should be fully trained in "general studies" by the end of our 6th or 7th year of school, and ready to take 4 or 5 years of specialized training for a field. The first 4 or 5 year specialist training course should be paid for by the government, any additional ones, well, ka-ching!

Do you assume that "higher education" (past high school) is necessary for employment?Further, do you assume that everyone is capable of making use of such "higher education"?

We seem to be pointed down this road in the US today and the truth is the answers to the two questions above are "no" and "oh my". So far, we're pretty far down the road of importing non-outsourceable low-skill jobs and moving everything else somewhere else so all the low-skill jobs don't exist for Americans. This isn't a long-term su

While I agree that overall, Duke is worse than many top schools as far as being full of rich preppy kids (though they do have need-blind undergrad admissions now, but that doesn't mean they're truly fulfilling everyone's need), the article states there are 150 iPhones there. At a school of over 12,000 students plus well over 30,000 employees and faculty, I'm not sure you can say that 150 fancy phones (one for every 280 people on campus) are a sign of excess.

.........but why should tuition be a barrier for anyone in a society as wealthy as ours?.......You are a fountain of ignorance, at least concerning your diatribe against Duke. Instead of being wealthy and pay tuition, you can also simply be smart and hard working. My daughter just graduated from Duke, from which she had gotten a full scholarship. Without that, there would have been no way she could have afforded to study there. Many Colleges and Universities give scholarships to exceptional young people who

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.

No. I don't care who pays too much for a phone.Anybody who is smart and accomplished can go to to a good school, if not Duke in particular. You can always borrow the money. Many, many, if not all good schools now have need-blind admissions. Anyways, everyone knows it's really the middle class that get screwed over on aid anyways, not poor folks.

*Some* people with connections can get in even if they are not so smart, or really accomplished is the more accurate term, as grades count. You don't have to be

I'm going to guess the one who has to work to put himself through school, because he realizes the cost of the education, and is more willing to dedicate himself to it. The rich kid who has his school handed to him generally looks at the education as a given, and doesn't put in the effort. In both my undergraduate and graduate studies, that was often the case. Of course, there are rich, smart, dedicated students, but your assertion that the rich kids who don't have to work do better in school has been ver

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]