Why your devices can't see each other on campus Wi-Fi

Almost certainly not — and this is the most repeated piece of wrong advice on the subject.

AirDrop does not send your file through the university network. It does not route through the access point, and it does not need the two devices to be on the same Wi-Fi, or on any Wi-Fi. Apple’s stated requirements are that both devices have Wi-Fi and Bluetooth switched on and are within about 10 metres of each other. A shared network is not among them.

So when AirDrop fails on campus, the cause is nearly always on one of the two devices. The four real ones are below — and none of them are fixed by switching networks, which is why that advice so rarely helps.

Two radios, two jobs. Bluetooth Low Energy handles discovery: it is how your phone notices there is a nearby device willing to receive something. The transfer itself then runs over a direct device-to-device Wi-Fi link that Apple calls AWDL, Apple Wireless Direct Link.

The part that surprises people is that your iPhone holds that direct link at the same timeas its ordinary Wi-Fi connection, by switching its radio rapidly between the two. From the campus network’s point of view the AirDrop traffic simply is not there. It never crosses the access point, so nothing configured on the access point can block it.

This is also why there is no AirDrop for Windows and probably never will be: AWDL is Apple’s own protocol and its specification has never been published. The public technical descriptions of it exist because researchers reverse-engineered it.

1. The receiving device is on Contacts Only, or its discoverability timed out. “Everyone for 10 Minutes” does exactly what it says and then quietly reverts. If it was set a while ago, it is off again.
2. Personal Hotspot is on. An iPhone sharing its connection cannot also hold an AirDrop link. This catches people constantly, because the hotspot may have been switched on hours earlier and forgotten.
3. The device is managed by the university. Institution-owned and enrolled devices can have AirDrop restricted by mobile device management policy. Administrators have reported managed iOS fleets where sending still works but receiving is blocked. We could not confirm that against official documentation, so treat it as a question for your IT desk rather than an established fact.
4. Range, or a locked screen on the receiving device. Roughly 10 metres, with walls counting against you, and a locked iPhone may not advertise itself at all.

Client isolation — also called AP isolation or wireless client isolation — is a setting on the access point that stops devices on the same Wi-Fi from reaching each other. Your laptop still reaches the internet perfectly well. It just cannot reach the phone sitting next to it, even though both show the same network name.

Vendor documentation puts it plainly: an isolated client is allowed to talk to the default gateway and essentially nothing else on its segment, and broadcast traffic from one wireless client is not passed on to the others. That second half is the part that matters, because broadcast and multicast are how devices announce themselves.

Universities, hotels, airports and student accommodation turn it on for good reason. When a few thousand strangers share one network, stopping devices from reaching each other prevents a whole class of attacks and stops one compromised laptop from scanning everyone else’s. It is a deliberate control that is working as intended, not an oversight.

It is not always absolute. Some enterprise equipment can forward specific discovery traffic while isolation stays on, so a network may block most device-to-device traffic and still let a printer or a cast target appear. If one thing works and another does not, that is usually why.

Every local transfer tool works the same way underneath: it announces itself on the local network and listens for others doing the same. LocalSend runs a service on each device and finds peers on the same local network — it is explicitly built to need no internet connection and no third-party server, which is what makes it excellent, and exactly what makes it helpless here.

Client isolation eats the announcement. Neither device is broken, neither is misconfigured, and both are genuinely on the network. They simply cannot hear each other, so the device list stays empty.

The same mechanism explains the rest of it:

• Wireless printers vanish from the printer list.
• Chromecast and AirPlay targets never appear.
• Shared folders and SMB network drives cannot be reached.
• Console remote play never finds its companion app.

AirDrop is notably not on that list — because, as above, it was never using the network in the first place.

Search this problem and you get two suggestions everywhere. Both assume you own the network.

• “Disable AP isolation in your router settings.” You cannot log in to eduroam. There is no settings page for you.
• “Set your network profile to Private in Windows.” On a network shared with thousands of strangers this is genuinely bad advice — it loosens your own machine’s firewall posture, and it still will not work, because the block is at the access point rather than on your laptop.

Asking IT to disable isolation for you is not realistic either. It protects everyone else on that network.

The usual workaround is to turn your phone into a hotspot, join the laptop to it, and use a local transfer tool on that small private network. It genuinely works — you have made a network where nothing is isolated. Three reasons it often is not practical:

• It spends mobile data, and a large video can spend a lot of it.
• Some institutions restrict running your own access point on campus — worth checking your acceptable use policy first.
• It cannot work if the phone is the device without data, or if you are trying to reach a desktop with no Wi-Fi adapter.

Worth separating out, because for this pair AirDrop was never available in the first place. A Windows laptop cannot receive an AirDrop — not on campus, not at home, not ever.

So you are hit twice: the Apple route does not exist for Windows, and the cross-platform local tools that would fill the gap are the exact ones client isolation breaks. We compared every method for this pair in how to send files from an iPhone to a Windows PC.

Once you know the block is on device-to-device traffic specifically, the options sort themselves. Anything that goes outward from each device still works, because the network has no objection to ordinary web traffic — that is what it is there for.

• A USB cable. No network at all. Still the most reliable method there is.
• Cloud storage.Both devices talk outward to the provider. Reliable, and the file sits on a third party’s servers until you remove it.
• Emailing it to yourself. Works everywhere for the same reason, which is exactly why people keep doing it. Attachment limits and a cluttered inbox are the cost.
• Pairing-code tools.Some browser tools — PairDrop, for instance — pair two devices with a short code or QR and then connect them regardless of the local network. Worth knowing, because they are often described as “local only” when that is not the whole story.
• A relay you send through. Each device makes its own outbound HTTPS connection to a server that holds the file in between. This is what todevice does.

To be exact about the last one, since it is our own product: todevice does not try to connect your devices directly, and does not attempt anything the network is refusing. Each device makes a normal outbound HTTPS connection to todevice.app — the same kind your browser makes to load any website — and we relay the encrypted file between them. The file is encrypted in your browser before upload and we are never given the key to open it. If your network allows normal web browsing, this works.

Worth addressing directly, because searching for “file sharing on campus Wi-Fi” mostly returns university pages about copyright enforcement, and the two get confused.

Those policies are about peer-to-peer distribution of copyrighted material to other people. Moving your own lecture recording from your own phone to your own laptop is a different activity, and every method on this page uses standard web traffic the network already permits.

What we would not encourage is anything framed as defeating a control. If your institution has deliberately blocked a category of site, that is a decision made by the people responsible for the network, and the right response is to ask them rather than route around them. Everything here works with what the network allows.

Ordered to eliminate the cheapest causes first.

1. Both devices Apple, in the same room? Check Personal Hotspot is off on both, both screens are unlocked, and the receiver’s AirDrop is set to Everyone. If it now works, the network was never involved.
2. Still failing, and one device is university-issued? Ask your IT desk whether AirDrop is restricted by device policy. You cannot change this yourself.
3. Is one device a Windows PC or an Android phone? AirDrop is not an option at all — skip to step 4.
4. Using LocalSend, Snapdrop or a shared folder and the device list is empty? Confirm both devices are on the same Wi-Fi, then assume client isolation. An empty list with both devices connected is the signature.
5. Confirm the network is otherwise fine: load any website on both devices. Browsing works but discovery does not? That is client isolation, and nothing on either device will fix it.
6. Need it now, file is small, data to spare? Phone hotspot plus a local tool. Check your acceptable use policy first.
7. Otherwise use something that goes outward from each device: a cable, cloud storage, a pairing-code tool, or a relay like todevice.
8. Sensitive file? Prefer the cable, or something that encrypts before upload. The compatibility matrix shows which methods leave your file readable on someone else’s server.

• Apple — “Use AirDrop to send items to nearby devices”: support.apple.com — Wi-Fi and Bluetooth on, within 10 metres; no same-network requirement stated.
• Cisco Meraki — “Wireless Client Isolation”: documentation.meraki.com — isolated clients reach the gateway only; client broadcast is not forwarded to other clients.
• TP-Link — “What Is AP Isolation?”: tp-link.com
• LocalSend: github.com/localsend/localsend — same local network; no internet or third-party server required.
• PairDrop: github.com/schlagmichdoch/PairDrop — paired devices find each other independently of the local network.

Where this guide describes something we could not confirm against primary documentation — the managed-device AirDrop reports in section three — it says so in place rather than asserting it.