How to construct & send the magic packet for Wake on Wireless LAN?
The Wikipedia article on the subject only describes the standard Wake-on-LAN magic packet. However the same article describes that a supplementary standard would need to be used for waking up wireless hosts.
... If the computer being woken up is communicating via Wi-Fi, a supplementary standard called Wake on Wireless LAN (WoWLAN) must be employed....
Unfortunately I can't seem to find an authoritative source / method on how to implement Wake-on-LAN that for waking up nodes on WiFi.
The blog that wikipedia linked to say:
The simple fact is that there is not enough industry support for WoWLAN to make it feasible for most organizations.
From TCP/IP Illustrated volume 1:
using PSM (power save mode) can affect throughput performance significantly as idle periods are added between frame transmissions and time is spent switching modes
So I am not sure you really want this feature.
I am not sure if there is a RFC standard about WoWLAN, but there exists PSM in 802.11, which make station into a limited power state and can be woke up by AP. In order to wake the station that in PSM, you just need to send your data message to it, and AP will notify that station in next Beacon frame.
Update:
Some notice:
Only newer Macs support Wake-On-Lan over Wifi. If your Mac is a 2012 or older model, it probably does not support this feature.
You cannot wake from off or hibernate mode the way you can on a PC. You can only wake it from sleep mode. Also note that after a certain amount of time sleeping they will hibernate automatically. You can check this with the pmset -g command. I believe it's the StandbyDelay setting.
Some steps:
Configure your Mac to allow wake from Wi-Fi in the power adapter section of Energy Saver
Use Remote Desktop or an equivalent tool to send the Wake-on-lan (WOL) packet to your router that will then deliver it to your sleeping Mac.
Use some tools like wireshark to view the magic packet structure and protocol, then you can try it through WiFi.
Ref:
wake-on-lan-wol-over-wifi-not-working-on-mac
how-do-i-remotely-wake-my-mac-over-wi-fi
Apart from the above links pointed by Tony, I think the below link for WOL (wake on lan) works for Wake on Wifi as well. If you are not using iphone as a client to wake up as mentioned in the article, you can use any other WOL apps for your client machine:
http://osxdaily.com/2013/12/14/wake-on-lan-mac-iphone/
Hope it helps!
Related
I'm doing a security analysis project on an IoT device that uses an unencrypted BLE connection (with ATT protocol) and I want to spoof an individual BLE packet with the source address of an already connected device. Is there some tool or API that would allow me to do this easily? I've already tried gatttool and spooftooph but they seem to be connection based and don't allow you to send out single packets with modified fields (as far as I could tell).
You will need some hardware where you can access the radio peripheral directly. What you basically need to do is to find or write a ble sniffer firmware, with the modification that it at a given moment sends a packet on the connection it is currently listening to. But note that the signal strength must be stronger than the original device's signal so it doesn't interfere.
The only open source project I'm aware of is Ubertooth. You will also be able to do this with an nRF52 but then you need to write your own sniffer firmware since Nordic Semiconductor's is closed source.
I can't comment on Emils reply yet, < 50 rep:
Nordic Semis nRF Sniffer v2 needs only the nRF52DK and wireshark to work as a general BLE sniffer. At 40$ it's not that expensive. I know for a fact they will release a new dongle soon that will sell for ~10-15 bucks if you can wait a a month or two.
Can we broadcast Music using wifi broadcast and listen to thhe same on devices supporting monitor mode.
I would like to listen on monitor mode because I expect the number of devices getting connected is too high for wifi to work properly using IP-protocol.
I want the wifi device to act as a FM broadcast where every device recieves every packets and stream the music.
Are you talking about this Wifibroadcast , here?
If so: well yes, monitor mode is the underlying technology, as can be seen here.
Now, if this is about doing a commercial product, sadly, you cannot expect any kind of interoperability from this.
Streaming audio/video over Wi-Fi is a business, and the the power in charge (Wi-Fi Alliance aka WFA) as some view on it, including certification programs. Have a look at Miracast, using Wi-Fi Direct.
As for multicast / broadcast, it is even more of a business and the realm of proprietary technologies for now (example here - and no, this is not limited to automobile). This is quite complicated, to start with because of the synchronization problem across receivers: you don't want 2 radio receivers in the same room to play with a 1 seconds delay, this would be cacophony.
EDIT:
Meaning, be it with the Wifibroadcast OSS project or with the proprietary industry about it, since there is not yet an open protocol for this (as "publicly available standard specification", I don't even go about implementation, FLOSS or not), you will have to provide a specific application for every receiver to match your broadcaster protocol, and vice versa. And that is the state of the industry today. That is what the company I mentioned above, or this other one more well know, or these are doing. And so, they do not interoperate. This will be your problem: provide a receiver app for Windows, Mac OS, Android and iOS (where you may not even have access to sub-layer 3 API) that will match your radio broadcaster protocol. And Linux too, please.
Though, this is the direction of history because this is what the user wants: stream A/V to/from device/application X from brand A to device/application Y from brand B.
And so people have been working on this, on layer 2, because layer 3 and above have unsolvable challenges with it, at IEEE since 2004 with Ethernet AVB, which is a set of protocols. You can download some of its standards for free, others for a moderate fee depending on how old they are. There is a SIG taking care of certification(http://avnu.org/certified-products/) to guarantee interoperability.
It is for 802.3 (aka wired Ethernet), but there is some work done to bring this to 802.11 Wi-Fi. Because again, that's what the user wants, the market is here, no question about that. It will take a long time. Even more to get consumer electronic grade devices or applications of the shelves. But they will interoperate out of the box, that's the goal.
There's even been work done on moving this to layer 3/IP as well BTW, with some performance sacrifice.
So come back in a few years, and all should be setup. Or, if you have lots of time and money and no urge to deliver, implement a solution based on these standards?
PS:
Link to AVnu (Ethernet AVB SIG) page about use cases for consumer electronics audio streaming, wired or wireless:
http://avnu.org/consumer/
...and its 10 pages white paper at the bottom of the page.
I read a lot about WiFi sensors being used to track smart phones in Retail environment. The location triangulation is done on basis that a smart phone has its WiFi turned ON, be it in connected or unconnected state.
Case 1 : WiFi turned ON but unconnected
Why should a smart phone which has its WiFi turned ON need to transmit the packets, unless the user 'scans' for nearby WiFi networks?
Case 2 : WiFi turned ON and connected
Why should a smart phone transmit any packets, unless the user is browsing the net?
In both the above cases, there is a high chance that most of the time the WiFi device does not send any packet, which means none of the WiFi sensors detect it. If that is true, then the whole idea behind WiFi sensor based triangulation in Retail goes for toss, clearly with so many companies working on this, I must be wrong. Please answer with more than a yes or no, as to which packets are generally sent in both the above scenarios.
If wifi is turned on it will periodically search for new networks. This happens even if you are already connected to one, as it allows the device to connect to a 'better' network, if available.
Scanning/network discovery can be done in two ways. First is passive when a device listens to surrounding access point's (AP) beacon frames. These are basically advertisements for their network. The second method is called active. This is the most likely explanation of how the technology you mentioned works. Active scanning is when the device sends out a probe frame asking for available APs. These are generally ones that you have associated with previously, e.g. Your home network. These probes can be listened to from nearby 802.11 (wifi) devices, therefore tracking you.
Active and passive scanning
801.11 frames
As mentioned in #AndrewLeeming answer, one of the causes for data transmission data is scanning.
It's not necessary but normally it will be performed to find a network to connect to (or a better network in case of already connected). Active scanning can be turned off for power saving reasons. Passive scanning doesn't involve transmissions, so it's irrelevant to this question.
However, the most important reason for WiFi devices to transmit packets while connected is to let the AP know that the client is still available. Otherwise the AP will drop the link after a certain period of time without activity. Additionally, the clients might be in power save mode and instruct the AP not to transmit data to them. From time to time the client will inquire the AP to see if there are any pending packets for it.
I have a GSM ModeM connected to a serial port, and I use it so send SMS upon certain events.
Since it is not Plug-and-Play, I am confused as to how I'll detect its connection status. Win APIs like GetCommState will obviously not work.
I could periodically send packets of data and check whether the data is being consumed or not, but I'm wary about the risks of polling over performance and clogging up the buffers which might be in use.
So, is there any other method, or some interrupt based thing, which I could use to check whether is still connected, via a serial port, to my system?
I'd be grateful for any help on this.
Thanks.
From Windows 7 onwards, use Windows Mobile Broadband API to get information about a GSM modem.
Serial ports are very primitive communication devices, they date from the very early days of computing. It is what you plugged your ASR-33 teletype into to start banging in your Fortran program. The only reason they are still around is because they are simple, hardware vendors like them because they don't have to spend money developing and supporting a custom api to use their device.
Still, even back in the sixties did a computer have a need to find out if a teletype was attached. Which is done through the hardware handshake signals. The DSR signal, Data Set Ready, is turned on by the device when it is powered up. If you use the .NET SerialPort class then you can check that signal with the SerialPort.DsrHolding property. If you use the winapi then use GetCommModemStatus(), MS_DSR_ON flag.
That still only tells you that some device is attached. If you want to find out that it is the modem that you wrote your program for then you can interrogate it with AT commands, a protocol that's specific to modems. No vendor implements this exactly the same way but you can usually count on an identification from the modem with the ATI command. Check the programming manual for the modem for details.
Im writing application that communicate (via serial port) with electronic device which i designed myself.
When my PC application starts - it opens available COM ports one by one and it sends some string ("What are you?" for example).
My device is programmed, to reply to that "magic question" with own ID (for example: "I am evil device for supervising employees").
When my PC software receive that "magic reply" it starts working normally and its not searching other ports anymore.
Of course im not using stupid questions in data transmission, its just example.
Question is - can i send strings like on all (not busy) ports, to discover my device?
If I can - how that "question" string should look? Are there any normalized standards?
This is not first project like this on my desk, but now im developing solution for little industry and i need to pay more attention what my application is doing, because there may be other devices connected to COM ports and I do not know how they can react.
Im sorry, if i made some language mistakes, english is my third language.
Thanks in advance for replies.
After Alvin Wong confirmed my concerns I thought about it again and redesigned my device discovery functionality, because I don't want to abandon that idea.
I will send unique-complicated-ID every 1-5 seconds from device.
When my PC starts - it will try to open sequentially all available ports and will listen for that ID for few seconds.
If application receive that ID - it will be confirmation, that port number/name is correct and I my connection is established.
No, you wouldn't want to do that.
When you are using COM serial port, you have no idea what is plugged into the port. It could be nothing, your device, a modem, a mouse (though I believe nobody uses this anymore...) or whatever you can't even imagine.
Imagine if it is connected to another computer (probably a Linux/router), sending things may lead to execution of "that command", thus creating unexpected effects (though your program may not notice). Or if it is some badly-programmed device, it may trigger a bug in the firmware, thus failing the device and making it malfunction.
In short, in the worst case, you can cause a catastrophic event.
Serial (RS232 or UART I assume) communications don't have a designated transfer protocol (in contrast to USB which has one) to identify a device, so it isn't fail-safe. The user must make sure he selected the correct port. This is probably one of the reasons why hardware manufacturers choose USB, and one of the reasons why USB is so popular, even to computer idiots.