[flagged]
And, of course this only solves the phone - phone, and not even all of them. Desktops & laptops have less hope.
This seems like such a basic solution that I'm surprised that it isn't required by any of the mainstream standards before WiFi Aware. I wonder if this was some sort of a patent issue or similar.
However the path towards this type of interoperability would likely go through additional standardization via IEEE 802.11* and the Wi-Fi alliance. At which point Apple will need to implement and support the new standards. There is no need to reverse engineer AWDL to meet the new European interoperability requirements. What is needed is for wifi chipset OEMs to implement such standardization. Something pretty routine of them.
It can be expected that Apple will also maintain the proprietary AWDL in order to support their legacy devices.
It’s a future promising tech though. A much better version of Wi-Fi Direct.
As for WiFi NAN: support for it seems rather limited outside of iOS and Android. From what I can tell the feature is barely tested on Linux and I can't find any generic Windows APIs for it either.
I've definitely used STA and AP modes concurrently on my Windows laptop with the operating system's built-in internet connection sharing function to help troubleshoot a problem in the field.
That was around a decade ago. It didn't take any extra effort on my part; I just told it to do the thing, and then it did that thing.
When Quickshare drops your Wi-Fi connection, its not Direct anymore, that's just soft AP from an error, and if that doesn't work, it fallback to Bluetooth. Bluetooth is used for provisioning as well.
The only reason why many apps don't use it is because of buggy implementation, some phones require a full restart after using Wi-Fi Direct to fix connectivity issues, even Motorola's own product line with Smart Connect use it only with certain models, despite having Wi-Fi direct due to poor implementation (can be forced). They even have a white list of supported adapter for the Windows app since direct is used as well, can be unofficially force enabled for Mediatek based adapters (rare on some laptops).
Back in 2016 things were much stable on Android phones with Wi-Fi Direct, even with old Blackberry, there were many apps including file managers that used it before it was essentially dropped, even for onboarding/provisioning apps like HP printers...
Apple's Airdrop success is about gaining traction, in the era of Wi-Fi Direct or other methods, most people were not aware of such features, as it required an app to be installed, they used email/messaging, even when Airdrop was first introduced and preinstalled, it took years for the average person to use it.
A research lab from TUD worked on a project investigating Apple's wireless ecosystem Link: https://owlink.org/publications/
Also something interesting that I remembered reading closely linked to AWDL?
Link: https://projectzero.google/2020/12/an-ios-zero-click-radio-p...
Maybe a network nerd can chime in - is this implementation so difficult that it's unrealistic we'll see an OSS version?
Say you've got an android phone, windows PC, and a linux box, and you want to be able to quickly drop files from each one. unless we get some kind of cooperation across all three platforms at the OS level, you'd at minimum need to install some kind of client into each system - when the nicest feature of airdrop is that it's baked into all of Apple's OSs, in my opinion. even if it worked exactly the same way, but had to be installed, I think it would see less use - and there's no real way for a single OSS project to do that across multiple OS platforms, to my knowledge
What's tricky is to specify and get everybody to implement the layers on top of it, including device discovery (frequently offloaded to Bluetooth for efficiency reasons), user identification (Apple runs a PKI for this) etc.
This is really nothing special as 802.11 implementations go, as it's pretty easy to do as long as you can control the physical channel for at least one side.
Many Windows, Linux, and Android devices have been supporthing this for years. It's usually called something like "simultaneous AP/STA mode".
Anyway, good to know we can use our NAN signal to send signal NaNs!
1. Backoff and timer logic to not flood network.
2. Caching entries for the same reason.
3. Handling multiple network interfaces, and detecting when they changed.
for 1. i send a mutlicast of max 512 bytes on 224.0.0.167:26999 every 3 seconds 2. not really caching, just have a map of people that get discovered.
and god bless, I just rolled with this. if people will use the tool and they will complain about it, then it will be a problem for later. for me between my home devices did not notice inconveniences.
in total around 200 lines of golang.