[Discuss-gnuradio] WiMAX scanner
Hello, I am interested in WiMAX technology (802.16e). In my research I am dealing with algorithms for admission control in Matlab. Typically these algorithms are located “within base station” – although they are not standardized by any organization. In simulations it is simple to “deploy them” as they are located inside BTS source code. As regards verification and validation of such algorithms I am currently using well known simulator which is ns2 – i.e. well known to the research community. It is clear however that “simulations vs reality” is not always very close…. That is why I am interested in collecting data from real network in a vendor agnostic way (in general from any network i.e. build upon BTSes delivered by any vendor) – it means that I would like to “observe” traffic intensity/duration/etc directly from the radio. I am using PureWave 6600 at university premises. The input data for the algorithms I am interested in is the wireless connection characteristics e.g.: connection requests, time of connection, type of traffic, connection close, etc. Unfortunately to my knowledge there is no one-fits-all (or virtually any) solution to communicate with inside components of a BTS in an automated manner (i.e. from within a software program that is learning for best policy etc). That is why I have started to think about using USRP (or its brother from NI / or any other SDR) to play a role of passive probe for WiMAX wireless signalling. I have seen that there is a “wimax scanner” project but it seems unfinished (or would it actually be operational in the area I mention?). Please let me know: 1. Is it possible to use “wimax scanner” with USRP right away (i.e. without much effort spent on programming)? 2. Is wimax scanner full featured solution? (i.e. what can I do with it) 3. What statistics I could capture with it? 4. What limitations does it has? 5. Are there any plans for continuing its development? 6. Do you know if there is already happening an approach to develop complete WiMAX stack as there is for GSM – OpenBTS…? Thank you for the assessment of my question or any hints. Best, Sebastian ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] WiMAX scanner
Hi Sebastian, google showed that the wimax scanner project is hosted at http://code.google.com/p/wimax-scanner/ and that they even have a mailing list, especially since that page shows no connection of that project to GNU Radio. Greetings, Marcus On 10/22/2014 08:52 AM, Sebastian Komorowski wrote: Hello, I am interested in WiMAX technology (802.16e). In my research I am dealing with algorithms for admission control in Matlab. Typically these algorithms are located “within base station” – although they are not standardized by any organization. In simulations it is simple to “deploy them” as they are located inside BTS source code. As regards verification and validation of such algorithms I am currently using well known simulator which is ns2 – i.e. well known to the research community. It is clear however that “simulations vs reality” is not always very close…. That is why I am interested in collecting data from real network in a vendor agnostic way (in general from any network i.e. build upon BTSes delivered by any vendor) – it means that I would like to “observe” traffic intensity/duration/etc directly from the radio. I am using PureWave 6600 at university premises. The input data for the algorithms I am interested in is the wireless connection characteristics e.g.: connection requests, time of connection, type of traffic, connection close, etc. Unfortunately to my knowledge there is no one-fits-all (or virtually any) solution to communicate with inside components of a BTS in an automated manner (i.e. from within a software program that is learning for best policy etc). That is why I have started to think about using USRP (or its brother from NI / or any other SDR) to play a role of passive probe for WiMAX wireless signalling. I have seen that there is a “wimax scanner” project but it seems unfinished (or would it actually be operational in the area I mention?). Please let me know: 1. Is it possible to use “wimax scanner” with USRP right away (i.e. without much effort spent on programming)? 2. Is wimax scanner full featured solution? (i.e. what can I do with it) 3. What statistics I could capture with it? 4. What limitations does it has? 5. Are there any plans for continuing its development? 6. Do you know if there is already happening an approach to develop complete WiMAX stack as there is for GSM – OpenBTS…? Thank you for the assessment of my question or any hints. Best, Sebastian ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org https://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] WiMAX decoding: DL-PUSC question
Hi all, This is a little bit offtopic for this mailing list, but I can't find a better place to ask this question. We're doing an open-source project on WiMAX decoding (http://code.google.com/p/wimax-scanner/) and at this point we have a trouble with correct subchannelization of DL-PUSC, so we're looking for some advise on what we're doing wrong. Or may someone could just contribute some code for correct subchannelization? My implementation is available as Matlab code and as Excel spreadsheet here: http://code.google.com/p/wimax-scanner/source/browse/matlab/get_slot_data.m http://code.google.com/p/wimax-scanner/source/browse/matlab/PUSC-permutation.xls It is able to correctly list sub-carriers for FCH of segment 0 (i.e. for subchannels 0-3), but looks like it gives incorrect results for all other subchannels. The result of this is that I can see only two consecutive repetitions of slot data in DL-MAP part of the header, where I should see 4 or 6 repetitions. The standard is very vague and unclear on this topic and people who write textbooks certainly thinks it's an obvious part and no one document it in an understandable way. If you have a working implementation of DL-PUSC subchannelization, which you can't share with us, we would appreciate if you just share mappings of subchannels to sub-carriers for a few sets of parameters. That would be very helpful for us to debug our own code. PS If you're interested in contributing to an open-source WiMAX implementation - you're very welcome to join the effort! We believe we can make a real difference in the wireless world. -- Regards, Alexander Chemeris. http://www.fairwaves.ru ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
[Discuss-gnuradio] Wimax
hello, evaluating the possibility of start a Wimax fuzzing test bed project with Gnu Radio/USRP . anybody knows if : - there is a working 802.16d implementation based on Gnu Radio , that works fine with USRP - there are SDR based projects preferably based on GNU Radio , to fuzz Radio systems : GSM BTS , Wimax Radio , TETRA base stations , etc . the goal is to do with the Radio what we do with software in Fuzzing stage of security related projects . to conduct a huge series of tests , examine the results and see when and how the Radio is not up to the task regards ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Wimax
evaluating the possibility of start a Wimax fuzzing test bed project with Gnu Radio/USRP . . . the goal is to do with the Radio what we do with software in Fuzzing stage of security related projects . to conduct a huge series of tests , examine the results and see when and how the Radio is not up to the task Sounds like a great idea. (For those who don't know, fuzzing involves sending subtly or wildly wrong values in every field in a protocol, testing how the receiving device handles the error. Fuzzing attacks against Unix command-line utilities found hundreds or thousands of implementation errors by sending, e.g. lines containing millions of characters; negative, zero, or huge length values; non-ASCII character sets, etc, etc, etc. Some fuzz is randomly created, finding bugs that humans never conceived of looking for. But after the first round of fuzz testing, throwing totally random values at a protocol seldom exercises all the code paths in less than an aeon; most of the garbage is rejected at the front door. Fiendish software testers with intimate knowledge of the protocol involved can create constrained fuzzers that smuggle randomly erroneous data deep into the heart of the receiving system before it explodes.) If you write this code, products in the market that it addresses will evolve to become better hardened against both mistakes and attack. But note that deploying fuzzing systems against targets you don't control (e.g. other peoples' infrastructures or mobile devices) is often considered a hostile act and could lead to criminal penalties (or war, if done by one country to another). As for WiMax, I don't know who (if anyone) is working on it in GNU Radio. - there are SDR based projects preferably based on GNU Radio , to fuzz Radio systems : GSM BTS , Wimax Radio , TETRA base stations , etc . The OpenBTS code implements a GSM base station; this code could easily be improved to fuzz GSM handsets. Anecdotal reports from the developers indicate that it's pretty easy for a buggy base station to tickle numerous bugs in handsets from every manufacturer. (Indeed, real-world base stations appear to need workarounds for known bugs in common handsets.) The creation of a GSM handset fuzzing program would probably improve that situation dramatically. It would also make possible a powerful denial of service attack on the cellular networks, making large numbers of existing cellphones crash in their users' pockets. OpenBTS doesn't currently have a GSM *handset* protocol stack (you can't currently emulate a GSM handset with GNU Radio.) Adding that capability would be very useful -- and would probably eventually lead to the code actually *running* in freed handsets. (The baseband processor code in modern cellphones is often the last bastion of proprietary software in the phone -- because there's no free software choice that works.) If someone improved OpenBTS to include a GSM handset stack, then that stack could be improved to fuzz GSM base stations, which would lead to better-hardened base stations. John Gilmore ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
Re: [Discuss-gnuradio] Wimax
John - The more recent 2.5-series releases of OpenBTS includes a feature called test call specifically for fuzing handsets. From the CLI, you can initiate a mobile-terminated transaction a specific handset using the test call feature. What the test call feature does is open an SDCCH in multiframe mode and then just tie that SDCCH to a UDP socket in L3. Then an external application can interact with the handset directly in L3 via the UDP socket, allowing you to fuzz to your heart's content without actually hacking OpenBTS. -- David On May 26, 2010, at 4:44 PM, John Gilmore wrote: The OpenBTS code implements a GSM base station; this code could easily be improved to fuzz GSM handsets. Anecdotal reports from the developers indicate that it's pretty easy for a buggy base station to tickle numerous bugs in handsets from every manufacturer. (Indeed, real-world base stations appear to need workarounds for known bugs in common handsets.) The creation of a GSM handset fuzzing program would probably improve that situation dramatically. It would also make possible a powerful denial of service attack on the cellular networks, making large numbers of existing cellphones crash in their users' pockets. David A. Burgess Kestrel Signal Processing, Inc. ___ Discuss-gnuradio mailing list Discuss-gnuradio@gnu.org http://lists.gnu.org/mailman/listinfo/discuss-gnuradio
