Radar detection with Linux
Most wireless networking happens in the 2.4 GHz frequency band; as many users will have noticed, that band tends to get crowded and noisy in places. For this reason, both 802.11a and 802.11n specify a number of channels in the 5GHz band as well. The relative lack of traffic at 5GHz makes it attractive for this use, even though the effective range of an access point is reduced somewhat. Pushing more wireless traffic to 5GHz will greatly increase the total bandwidth available.
Naturally, there is a catch. While other uses of that frequency range are few, among them are counted air traffic control and weather radars. Interfering with these radars will be frowned upon by regulators who have strange notions about how aviation safety should take priority over that post-lunch Twitter update. These regulators typically show a distinct lack of humor toward anybody who doesn't pay attention to their rules; once again we see how wireless networking often tends to be the leading edge of encounters between Linux and the regulatory environment.
To make the 5GHz band available for wireless networking in a safe manner, various agencies have laid out specifications for how a wireless device selects an operating channel. This scheme, called "dynamic frequency selection" (DFS), requires that a "master" station listen to a channel for a minimum period of time to ensure that no radars are operating there before transmitting. Thereafter, the station must continue to listen for radars; should one happen to move into the neighborhood, the station must shut down all communications and move to a different channel. In essence, wireless devices operating in the 5GHz band must actively avoid transmitting on channels where radars are operating.
Most Linux systems will not have to concern themselves directly with radar detection. A "slave" device, as might be found in a typical laptop, need only follow the master device's instructions with regard to where it can transmit. But any device which wants to function as a master - including access points and anything running in ad hoc mode - must notice radars and react accordingly.
Wireless adapters, having radio receivers tuned to the frequency range of interest, can help with this process. Should a blast of RF energy hit the antenna, the adapter can return an error to the host system indicating that a radar-like patch of interference was encountered. It's not quite that simple, though: random interference is far from unknown in the wireless world. If a wireless device bailed out of a channel every time it received some unexpected interference, communication would be painful at best. So something a little smarter needs to be done.
That something, of course, is to look for the specific patterns of interference that will be generated by a radar. Radars emit short bursts of RF radiation, followed by longer periods of listening for the returns. The good news is that these patterns are fairly well defined in terms of the radar's pulse width, pulse repetition interval, and frequency. The bad news is that these parameters vary from one regulatory domain to the next. So while the US has specified a specific set of patterns that a device must recognize, the European Union has defined something different, and Japan has a variant of its own. So radar detection must be specific to the environment in which the device is operating.
A group of developers, mostly representing wireless hardware companies has started a project to implement DFS for Linux. A preliminary patch set has been posted by Zefir Kurtisi to how how DFS might be done. These patches add a simple function to the ieee80211 API:
void ieee80211_add_radar_pulse(u16 freq, u64 ts, u8 rssi, u8 width);
The hardware driver can use this function to inform the 802.11 core whenever the interface reports the detection of a radar pulse. These events will be tracked; if, over time, they match the pattern for radars defined by the regulatory environment, the code will conclude that a radar is operating and that evasive action is called for. If the hardware can do full radar detection directly, the driver can report the existence of a radar with:
void ieee80211_radar_detected(u16 freq);
The current patch is only able to detect one variety of European radar; it
is meant as a sort of proof of concept. The means by which parameters will
be loaded to describe radars in different jurisdictions is yet to be worked
out; one assumes that the existing regulatory compliance mechanism will be
used, but alternatives are being considered. One way or the other, Linux
should be able to coexist with radars in the 5GHz band in the near future.
A version which helps in the avoidance of speeding tickets may take a
little longer.
| Index entries for this article | |
|---|---|
| Kernel | Device drivers/Wireless networking |
| Kernel | Dynamic frequency selection |
| Kernel | Networking/Wireless |
Posted Dec 23, 2010 11:58 UTC (Thu)
by jag (subscriber, #3766)
[Link] (5 responses)
Posted Dec 23, 2010 13:25 UTC (Thu)
by nbd (subscriber, #14393)
[Link]
Posted Dec 23, 2010 23:37 UTC (Thu)
by gdt (subscriber, #6284)
[Link] (2 responses)
Whilst it could, that's also an action for which your nation's equivalent of a "radio inspector" can find before breakfast and for which his manager would think was time well spent. A covert-like jamming would be taken very seriously. The matter would likely be referred to your nation's air force. Finding a few radar pulses in the RF environment is a typical "electronic warfare" task. I doubt a judge would think that anything less than a custodial sentence was appropriate. If you were stupid enough to attempt this in one of the world's trouble spots you could expect incoming ordnance followed by a special forces operation to recover the hardware and people concerned with this previously-unrecorded EW device. Neither hardware nor people would likely be seen in public again. On the plus side, you'd get a NATO weapons designator :-)
Posted Aug 24, 2011 9:11 UTC (Wed)
by ortalo (guest, #4654)
[Link] (1 responses)
If you are knowledgeable in this field, do you think such situation will be sustainable in the future by regulatory/military organizations?
They keeping permanent control of the entire radio frequency space sounds more and more unrealistic to me as time goes and more and more smart/programmable RF devices and general useful applications enter the scene. I cannot refrain from seeing a parallel with the situation with respect to cryptography in the 90s.
Posted Feb 28, 2013 12:42 UTC (Thu)
by ctpm (guest, #35884)
[Link]
RF Spectrum regulation has been around for a _lot_ longer than that and actually is, generally, a Good Thing. Granted, we've had some regrettable episodes related to some national regulators kind of wanting to make a profit by selling big chunks of RF spectrum to the highest bidder and all other users be damned, and perhaps some other over-the-top power demonstrations.
But the bottom line is, IMO, the RF spectrum really does need to be managed and, in some cases, enforced. Anarchy tends to work badly in this case -- it just lowers the Signal/Noise ratio and ends up making everyone's life miserable. Think of it the same way you think of the streets: you don't desire oppression, but you also don't want to be run over or mugged every 5 minutes. Some some cops and _also_ _some_ _voluntary_ _cooperation_ is needed to keep things civil. On the street and over the radio (note that I'm not talking about freedom of speech, just the RF technical side of things).
And this is true for hardware that is supposed to transmit, as well as for other electrical stuff that had nothing to do with radio in the first place, but ends up radiating lots of crap and harassing every RF user around. Some degree of regulation is needed in this case, _as well as_ some degree of design common sense, which doesn't always happen, sadly (ask any Ham Radio operator, the folks that operate the HF Air Traffic Control radio stations, the radio astronomers, or the guys at the Deep Space Network).
As for the military and related branches, although they usually get priority access to spectrum, especially in conflict/problematic zones, they normally are just another user with their own allocated frequencies and channels, and normally the other users should not be impacted by this.
Posted Dec 31, 2010 17:28 UTC (Fri)
by etienne (guest, #25256)
[Link]
Radar detection with Linux
Radar detection with Linux
Additionally, there are easier and more effective ways to jam all wireless communication using standard 802.11 hardware, and they're not limited to 5 GHz.
Radar detection with Linux
Radar detection with Linux
Radar detection with Linux
Radar detection with Linux