op25-dev

op25-dev@lists.osmocom.org

312 discussions

Court Rules that the Wiretap Act Does Not Prohibit Intercepting Unencrypted Wire
by ahenney 25 Sep '12

25 Sep '12

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.

3 3

OP25 + UHD Bounty
by Matt Mills 11 Sep '12

11 Sep '12

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.

3 2

repeater.vocoder doesnt run to completion [1 Attachment]
by Matt Mills 11 Sep '12

11 Sep '12

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.

3 3

Wireshark expected output
by Matt Mills 09 Sep '12

09 Sep '12

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.

2 1

"NameError: global name 'msgq' is not defined" in audio_p25_rx.py
by rajani_38 28 Aug '12

28 Aug '12

I'm new to GNURadio and OP25, and am facing the above error when trying to run audio_p25_rx.py. How I installed: On Ubuntu 10.04, I installed GNURadio 3.6, ensured that the prerequisites on the BeginnersBuild page were installed, then installed and built OP25, the imbe_vocoder, and then the repeater as instructed on the BuildInstructions page. Also installed gr-fsk4. I had put in the following symlink to get over some gruel problems while trying to build gr-fsk4: $ln -s /usr/local/include/gruel/swig/gruel_common.i /usr/local/include/gnuradio/swig/gruel_common.i Now I am stuck with the msgq error. I'd like to know if the build is expected to work with gnuradio 3.6. and whether audio_p25_rx.py can be executed without any input, just to make sure the OP25 build works. (I understand that in gnuradio 3.6 the usrpm folder has been deprecated and that seems to be giving rise to other Not Found errors for other scripts...) Any help will be greatly appreciated. Don't mind going to Gnuradio 3.2.2 if that will make life simpler. Thanks - Ram

5 11

Wireshark compile error
by allanjs1986 27 Aug '12

27 Aug '12

Hi group im trying to compile wireshark from the files section but i keep getting errors. My system is Ubuntu 11.10 and the error i get is after the "make" cmd. -------------------- wiretap/.libs/libwiretap.so: undefined reference to `g_list_foreach' collect2: ld returned 1 exit status make[2]: *** [randpkt] Error 1 make[2]: Leaving directory `/home/allan/wireshark/1.0.2-patched' make[1]: *** [all-recursive] Error 1 make[1]: Leaving directory `/home/allan/wireshark/1.0.2-patched' make: *** [all] Error 2 allan@gnuradio:~/wireshark/1.0.2-patched$ ----------------- And on a side not once i have wireshark installed and running if i just run the sample p25 flowchart in gr-baz should that pipe the date to wireshark? Thanks Al

1 0

Experiences in package building
by ikj1234i 15 Aug '12

15 Aug '12

Recently did a clean install from source and had a few minor issues which I thought I'd write up here. Machine is a 32 bit Ubuntu 11.04 install (and yes, the "unity" UI is truly as bad as they said)... First, the following packages need to be included in the list of pre-req stuff installed via apt-get : libpcap0.8-dev cmake Second apparently the newer versions of GR or SWIG have a new gruel library, causing a compile time error which I fixed by appending the path to this new library (file Makefile.common) as follows SWIGGRFLAGS = -I$(GNURADIO_CORE_INCLUDEDIR)/swig -I$(GNURADIO_CORE_INCLUDEDIR) -I/usr/local/include/gruel/swig This addition was needed for both the repeater and gr-fsk4 projects. Third (for those of us dinosaurs still using the original gr-fsk4 sources) there were a few source modules that were failing on a missing printf definition, I fixed by adding #include <stdio.h> as necessary... Best Max

1 1

Re: [op25-dev] Control channel decoding
by Dmitry Medvedev 02 Aug '12

02 Aug '12

Yes, valve is the block I was looking for. But, first try did not turn well: it works for a while, turning channels on and off, but after 10-100 switches something goes wrong and I get OOOOO. Experiments with dynamic reconfiguration gave me the same results (+memory leak, is there way to tell from python to release block memory after disconnect?). Maybe it's related to threading, as I turn valves on/off from separate thread. I'll try this again in some days. Regarding the code: right not it's no more than a heap of proof-of-concept python code not tightly connected to gnuradio. Gnuradio part consists of application with multiple channels. Each channel is xlating fir -> quadrature demod -> symbol filter -> fsk4_demod -> slicer -> frame assembler --msg queue--> custom UDP sender (it adds frequency id to udp packet). And there are standalone python program which receives UDP frames and stores it in db-like format. Further programs work on this files in pure python. I'll release code in some days after I clean it up a little. Best regards, Dmitry ________________________________ From: Matt Mills <mmills(a)2bn.net> To: qaghqga(a)yahoo.com Sent: Tuesday, July 31, 2012 2:20 PM Subject: Re: [op25-dev] Control channel decoding Dmitry, I'd suggest using a valve or stream selector for that. Do you have any interest in sharing your source code? Thanks, Matt. On Tue, Jul 31, 2012 at 2:09 AM, Dmitry Medvedev <qaghqga(a)yahoo.com> wrote: > >I'm writing multichannel p25 recorder. It mostly works (thanks to op25 team and other contributors). Is there any open documentation on control channel messages, especially TSBK frames? I did trellis decoding and CRC algorithm (reverse engineered the later, as I couldn't find parameters). I understand structure of some messages, for example "Group Voice Channel Grant Update" (opcode 02, manufacturer id 00), but many opcodes remain unknown. Do you have any leads on this? > >Also, I'm not very familiar with gnuradio, is there way to place some kind of "gate" in flowgraph so some parts of it can be switched on/off by external event? I want to use such feature to gate voice channels on/off and do not waste processor cycles on filtering channels that do not carry traffic at the moment. > > >Best regards, >Dmitry > >

2 1

Control channel decoding
by Dmitry Medvedev 01 Aug '12

01 Aug '12

I'm writing multichannel p25 recorder. It mostly works (thanks to op25 team and other contributors). Is there any open documentation on control channel messages, especially TSBK frames? I did trellis decoding and CRC algorithm (reverse engineered the later, as I couldn't find parameters). I understand structure of some messages, for example "Group Voice Channel Grant Update" (opcode 02, manufacturer id 00), but many opcodes remain unknown. Do you have any leads on this? Also, I'm not very familiar with gnuradio, is there way to place some kind of "gate" in flowgraph so some parts of it can be switched on/off by external event? I want to use such feature to gate voice channels on/off and do not waste processor cycles on filtering channels that do not carry traffic at the moment. Best regards, Dmitry

4 3

question about frequency correction messages from fsk4 demo
by Stephen 24 Jun '12

24 Jun '12

Hi, I'm trying to do everything in c++ instead of using python. I've got it working. Mostly. Well, sort of. I have a couple of questions about what to do with the frequency correction messages coming from the fsk4demod block. I'm seeing a constant stream of frequency correction messages when there is no signal present. They quickly cause the channel selection filter I'm using to tune way off frequency. If I don't process those messages I get voice output so I know everything else is working. Some channels I tune to seem to work just fine with out needing any tuning. But other times I see transmissions where I don't get any voice output. I'm wondering if in those cases the tuning is needed ? In looking at the grc file it just subtracts the correction. When I look at the uhd_p25_rx_gl.py file it's doing a calculation with the correction and limiting it. Does one method work better than the other? So, does anyone have any suggestions or any idea why I would be getting a constant stream of the messages? thanks, Stephen

1 0

Jump to page:

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

op25-dev