Hi folks,
I had the pleasure of sitting with some major OP25 contributors (Max and
Mike) at the GNU Radio conference today, and also managed to get OP25
working with a USRP N210 using UHD. You can see in the attached image that
I'm using the OP25 block from gr-baz in GRC (the flowgraph sends the decoded
audio to the speakers via the Audio Sink). The voice frames' data is being
printed in the console, and four-level dibits are shown on the scope. The
other tabs contain FFTs for the entire baseband and the selected channel,
and make use of the new click-handler feature that triggers a callback
containing the frequency you clicked on. You can therefore tune (really
change the offset in the Freq Xlating Filter) to a signal you see appear on
the FFT just by clicking on it (the same way you can with the Python apps,
e.g. usrp_p25_rx/audio_p25_rx, however this is all from GRC).
The IT++ 4.2 BCH problem still exists, so I've used the alternate
implementation that Max also uses in the 'repeater' code to handle
identification of the frame header.
The GRC flowgraph obviously uses the UHD Source block to capture the
baseband data, but the Python scripts (e.g. those mentioned above) also now
work with UHD. The legacy USRP code is actually untouched as I've written a
thin wrapper for UHD that makes any UHD-compatible device accessible through
the legacy interface (i.e. brought 'from gnuradio import usrp' &
usrp.source_c back). Not the best approach to force projects to move to UHD
properly, but a temporary measure in the meantime ;)
I'll post some code soon!
Kind regard,
Balint
The Volokh Conspiracy
September 7, 2012 Friday 4:02 AM EST
District Court Rules that the Wiretap Act Does Not Prohibit Intercepting Unencrypted Wireless Communications
LENGTH: 1078 words
The decision is In re INNOVATIO IP VENTURES, LLC PATENT LITIGATION. MDL Docket No. 2303, Case No. 11 C 9308. (N.D.Ill. August 22, 2012), via Cybercrime Review. The opinion holds that anyone can monitor the unencrypted wi-fi communications of anyone else without implicating the Wiretap Act. I think the decision is wrong, and I wanted to explain why.
The court holds that unsecured wireless communications are not covered by the Wiretap Act because of the exception found in 18 U.S.C. § 2511(g)(i). That exception states:
(g) It shall not be unlawful under this chapter or chapter 121 of this title for any person-
(i) to intercept or access an electronic communication made through an electronic communication system that is configured so that such electronic communication is readily accessible to the general public;
The Court concludes that this exception covers unsecured wi-fi communications, so that it is entirely lawful to snoop in on someone else's private communications over an unsecured wireless network:
Innovatio is intercepting Wi-Fi communications with a Riverbed AirPcap Nx packet capture adapter, which is available to the public for purchase for $698.00. See Riverbed Technology Product Catalog, http://www.cacetech.com/products/catalog/ (last visited Aug. 21, 2012). A more basic packet capture adapter is available for only $198.00. Id. The software necessary to analyze the data that the packet capture adapters collect is available for down load for free. See Wireshark Frequently Asked Questions, http://www.wireshark.org/faq.html#sec1 (last visited Aug. 21, 2012) ("Wireshark® is a network protocol analyzer. . . . It is freely available as open source. . . ."). With a packet capture adapter and the software, along with a basic laptop computer, any member of the general public within range of an unencrypted Wi-Fi network can begin intercepting communications sent on that network. Many Wi-Fi networks provided by commercial establishments (such as coffee shops and restaurants) are unencrypted, and open to such interference from anyone with the right equipment. In light of the ease of "sniffing" Wi-Fi networks, the court concludes that the communications sent on an unencrypted Wi-Fi network are readily available to the general public.
I don't think that's right. Look closely at the text: "configured so that such electronic communication is readily accessible to the general public." In my view, that text focuses on the intent of the designer - the person who does the configuring of the network so that it works a particular way - to design the network so that the general public was supposed to be able to access them. Of course, you might not know the actual intent of the designer with 100% certainty. But with many technologies, it's obvious what counts as an expected use and what counts as an unexpected use. Cf. United States v. Morris, 928 F.2d 504 (2d. Cir. 1991) (creating an "intended function" test to distinguish authorized access to a network from unauthorized access to a network). No one suggests that unsecured wireless networks are set up with the goal that everyone on the network would be free to read the private communications of others. In my view, that ends the matter: the exception doesn't apply, and the interception of the contents of wireless communications is covered by the Wiretap Act.
An analogous issue arose in Tapley v. Collins, 41 F.Supp.2d 1366 (S.D.Ga. 1999), which involved listening in on cordless telephone calls that were broadcast by cordless phones and (back then) not encrypted. The Tapley court held that this exception did not permit the interception of unencrypted cordless telephone calls:
This subdivision . . . obviously contemplates the use of scanners to intercept (a) police, fire and emergency radio traffic; along with (b) any other electronic communications the designers and users of which-from decades of experience-have no reasonable grounds to expect anything but casual, even wide-scale interception by others (e.g., "CB radios").
In contrast, cordless telephones were never designed with that intent. True, early versions were prone to substantial electronic "leakage," leading courts and Congress alike to conclude that no one could reasonably claim a right to privacy when using them. See Spetalieri, 36 F.Supp.2d at 113; Peavy, 37 F.Supp.2d at 505-06. But no one has argued that cordless phone manufacturers intended, or were even lax about, any "incidental broadcast" feature.
That's right, I think. The issue under 2511(2)(g)(i) is what the designers intended users to be able to do, not what someone can do contrary to the designer's intentions.
Consider the implications of a contrary rule by focusing on the example of communications over a wire. You can buy a KeyKatcher keylogger for $55 from Amazon (with free super saver shipping!) and install it on a wire of Internet traffic. It's a lot cheaper than the wireless packet capture devices the Court is focused on in its decision. Under the Court's decision, the Wiretap Act categorically should not apply to that quintessential act of wiretapping whenever the wire was itself available to the public simply because anyone can buy the $55 device and install it. In my view, that can't be the test: The issue is not whether a member of the public could engage in the wiretapping as a matter of cost and practicality, but rather whether the technology is set up consistently with a design that reflects an intent that members of the public would be able to monitor those communications.
Two final points. First, my sense is that the court did not need to reach this legal question in the first place. The case is a patent dispute rather than a wiretapping case, and there is no suppression remedy because the communications are electronic communications (and the statutory suppression remedy only applies to wire and oral communications). Second, a much more difficult question is the one presented in In re Google Inc. Street View Electronic Communications Litigation, 794 F. Supp. 2d 1067, 1070 (N.D. Cal. 2011): Does the "radio communication" exception in 18 U.S.C. 2511(2)(g)(ii) exempt wireless communications from the Wiretap Act? That issue is now on appeal before the Ninth Circuit in the Google Street View case, and I think Judge Ware was correct to conclude that the exception does not apply. But whatever you think is the right answer to that question, I think it's the more difficult issue.
Also,
If anyone has the inclination to improve OP25, I'll offer a 250$
bounty for a version of OP25 checked into subversion that is
compatible with the latest version of gnuradio and UHD (claimable for
the next 30 days).
Thanks,
Matt.
Hi All,
I'm trying to have repeater.vocoder() run as a small app to read from
a file sink and write to a wav sink... If I replace the vocoder with a
char_to_short() block it works as expected, however with the vocoder
in place it never completes...
Also, it looks as though even though it has run out of samples the
vocoder thread continuously runs at 100% cpu.
Anyone have any ideas? (associated python is attached.
thanks,
Matt.
All,
What should the expected output of P25 data in wireshark be while
running uhd_c4fm_rx_nogui.py? I have it running, hooked up a UDP sink
and can see distinct dibits flowing into the slicer/decoder, and I
receive UDP to my patched wireshark however all I ever get are 141
length Header Data Units. I also cant seem to get any audio out of the
signal using OP25 (however if I pipe the same signal through DSD it
produces audio).
FYI, I'm also using the latest gnuradio with UHD.
Thanks,
Matt.
