Aha, gotcha. WiFi scanning is an odd activity that is off my radar. I’ve never even had an Ethernet scanner. Given the importance of the things I scan and the fact that sometimes the scans are not clean (stuck pages, etc), I’ll never be comfortable with “headless” scanning.
I also pondered that maybe WiFi could be handy scanning for on-the-road. But that doesn’t sound right, since you’re going to have to re-WiFi the scanner everywhere you go, and may not even have WiFi if you’re out and about. In those cases, a cable would be much simpler.
But maybe WiFi is handy to go uncabled to mobile while you’re around the house? This is slightly off topic, but curious if there are other advantages I’m missing.
Exactly. Regarding scanners acting as ad-hoc Wi-Fi access points, sometimes they’ll have a default SSID and password for ad-hoc purposes on the scanner’s serial number label, especially with older scanners that don’t support Bonjour. Note, however, that ad-hoc networking may need to be enabled manually, and it is possible that the default SSID/password has been changed.
In any case, the best way to figure all of this out is to look up the documentation for a particular scanner on the manufacturer’s support site.
Yea, it’s a totally different setup if the printer itself is the hotspot vs. just a device on the WiFi network. I have a WiFi HP Color Laser printer and it’s not a hot spot; it’s just another device on the network. I’m not sure if it supports hot-spot mode, but that would be a regression in usability for my use case, since every time any device wanted to print, it would have to switch networks to do so (yes, almost all my devices are on WiFi).
Am I right that if you use the hotspot mode for your printer, that your client has to drop any WiFi internet connection in order to print?
Off-the-cuff, I would say yes. But I haven’t actually tried it. My printer has an Ethernet connection to my LAN, and Bonjour discovery works over that connection (via my Wi-Fi mesh nodes that connect to the wired LAN), so I’ve actually disabled the printer’s Wi-Fi interface.
I know that AirDrop, for instance, uses a private ad-hoc network for file transfer but it switches your phone to it and back automatically, so you normally don’t notice an interruption. It should be possible for a printer or scanner to do something similar (maybe requiring Bluetooth for device discovery), but I have no idea if any device actually does.
My recollection is that AirDrop uses temporary IPv6 connections without relinquishing the devices’ normal IPv4 connection. You’ll notice, for example, that most modern devices simultaneously have IPv4 and IPv6 addresses associated with each network hardware interface. I think that’s why you can get files via AirDrop without actually losing an IPv4 network connection, but I may be wrong about the specific implementation.
I don’t know how the Fujitsu service works. I’d guess it is using the IPv6 interfaces, but it may be using IPv4. If it is using IPv4, then it probably would only support one type of connection at a time.
AirDrop uses Bluetooth for the control-plane data. That is, for telling the other device that you want to transfer a file, metadata (file type, size, preview image) and for the various levels of authentication.
It then uses Wi-Fi to create a private peer-to-peer connection between the devices. It uses IPv6 and the devices’ link-local addresses (which are constructed locally, don’t have to be unique, but are restricted to direct connections and can not be routed to other networks) to actually move the data. Since IPv6 devices can always support multiple addresses, the use of link-local addresses will not have to break any pre-existing IP (v4 or v6) sessions, since that link-local address can and will co-exist with any other addresses that may be in use.
TLS and encryption are used to secure the data in transit. The most recent versions of the protocol will also create a temporary iCloud ID, to allow data transfer to continue over the Internet if the two devices move out of range of each other.
I know that AirDrop will not initiate connections using a pre-existing network connection. It always creates its own via Wi-Fi. Which is why (for example) a Mac must have Wi-Fi enabled, even if it is connected to the same LAN (e.g. via Ethernet) as the remote device.
What I don’t yet know is if a pre-existing Wi-Fi connection (e.g. to the Internet) gets temporarily disconnected while the file transfer is taking place.
I suspect it may not have to, since all AirDrop-capable Apple equipment have dual-band Wi-Fi radios (2.4 and 5 GHz), and a device can only be connected to an access point with one at a time. So it should (I would assume) be able to use whichever band is not used for Internet connectiity.
It may also be possible for iOS/macOS to temporarily suspend an existing Wi-Fi connection in order to briefly use the radio for AirDrop and then switch back without breaking existing connections.
But these last few paragraphs are speculation on my part.
Thanks! You and the article answered almost all my questions!
I’m not clear only on how initial authentication is established to set up the TLS tunnel without exposing any secrets. Perhaps Apple uses a public key publicly published for each iCloud account to allow that.
I have more questions, and we clearly have a new thread topic going on here.
But this line:
Other Apple devices that are awake, in close proximity, and have AirDrop turned on, detect the signal and respond using peer-to-peer Wi-Fi, so that the sending device can discover the identity of any responding devices.
Appears to contradict the idea that the whole handshake, including authentication, is done via Bluetooth.
