Home arrow Tutorials arrow Software arrow Feeding the Shark - Turning the Freakduino into a Realtime Wireless Protocol Analyzer with Wireshark
Feeding the Shark - Turning the Freakduino into a Realtime Wireless Protocol Analyzer with Wireshark | Print |
Written by Akiba   
Wednesday, 29 December 2010

One of the most powerful tools to have when doing any type of design that involves communication protocols is a protocol analyzer. It allows you to see exactly what the communicating devices are seeing which is very useful for troubleshooting many types of problems that might come up. This is especially important for wireless communications because this is often the only way to see what type of data is going over the air. It also allows the user to see if there are any rogue frames, check for breaches of the communication protocol, analyze traffic, or reverse engineer a proprietary protocol. And of course, it’s extremely useful for learning about how a protocol operates and behaves in real-life.

Wireshark is probably one of the most well-known of all protocol analyzers. It’s widely used in the IT world for analyzing network problems, bottlenecks, failed hardware, and a host of other things. It’s also used in the security world for snooping, packet analysis, and reverse engineering. Over the past 2-3 years, wireshark support for the IEEE 802.15.4 protocol has been growing and improving due to contributions from the wireless sensor network community and the increased interest and usage of protocols that ride on top of 802.15.4 such as Zigbee and 6LoWPAN (IPv6 over 802.15.4). However it has always been a challenge to get raw 802.15.4 data frames fed into Wireshark.

The problem with feeding wireshark is that it usually uses libpcap (winpcap on windows) for the packet capture and those libraries mainly capture data from network interfaces, ie: ethernet or Wi-Fi. The 802.15.4/6LoWPAN community got around this by emulating an ethernet interface on the Atmel Raven USB boards and encapsulating 802.15.4 frames inside ethernet packets. One of the first companies to put out an interface for 802.15.4 to Wireshark was Exegin and they actually used a gateway router that took 802.15.4 frames, encapsulated them into UDP payloads, ran them down a UDP/IP stack into an ethernet interface, and from there, got them inside libpcap to feed wireshark. There was some serious protocol stacking going on there just to get data into the analyzer.


So anyways, there is an actual point to this post. I though it would be interesting to convert the Freakduino boards into a wireless sniffer and feed the raw data into wireshark. It also demonstrates how Arduino-based boards can be turned into powerful, low-cost tools for communications software development and security research.

One of the benefits of an open source protocol stack is that you can configure it however you want. In the case of chibi and chibiArduino, the main modification was to put the radio into promiscuous mode. In this mode, the radio is just a listener that accepts all packets and dumps them out to the serial port. The modifications to the stack were actually very minimal. The protocol stack relies on the hardware features of the Atmel radio to do a lot of the 802.15.4 protocol handling. To enable promiscuous mode, all the extended hardware features such as address filtering and auto-ACK were disabled. The associated Arduino sketch is minimal, almost shorter than the hello_world example, and just waits for received data and dumps it out the serial port. The Chibi promiscuous mode demo is also mainly a two line change from the original demo. Before proceeding, you'll want to get the Chibi stack (from v0.91) or chibiArduino stack (from v0.51) from the project pages

Once you have access to the raw data, the next step is to figure out how to get it into Wireshark. There are three main ways to feed the shark: capture data via a network interface, open a static packet capture file, or piping the data into the program. I chose the last option which is probably the least common way to get data into wireshark and deserves a bit more explanation.  

Wireshark supports packet capture via named pipes which is a form of interprocess communications (IPC) supported by most OSes. Interprocess communications is a way for one program (process) on an OS to talk to another. In the case of named pipes, one program creates a pseudo file to write into and another program opens that file and reads from it. People that use Linux or Unix are probably familiar with the pipe operator (“|”) which sends data from one program into another. A named pipe behaves similarly but the pipe has a filename and location associated with it.

Once the communications method was established, the next task was to take the raw data from the serial port and put it in the packet capture format that wireshark understands. Normally this is handled by libpcap but since libpcap doesn’t support serial port interfaces natively, I decided it was easiest just to implement this manually.

The libpcap capture format is a binary format that’s fairly straightforward. At the beginning of the capture, you need to pass in a global header which tells wireshark some needed parameters like endian-ness and the base data link protocol. After that, you need to add a frame header for each raw frame you pass into it. The frame header give wireshark the length of the frame and the timestamp. The raw data frame comes after the frame header.

That’s pretty much it. I wrote an application to open a named pipe, take the raw data from the serial port, add on the headers, and feed it into wireshark. To use it, you just need to run the program, open wireshark, and input the named pipe in the capture interface. I call the application "WSbridge" and you can get it from the Projects page under WSBridge.

I’ve also put together a little tutorial on how to use it with the Freakduino . I’ve made the firmware modifications in the chibi and chibiArduino stack so either one can be used to capture the raw data and output it via the serial port. You'll need to enable the promiscuous mode feature inside the stack. Don't forget to disable it after you're done :)

The application was written in two different languages. For Windows, I wrote the application in C# since I figured it’d be easier to support all the different Windows flavors using the .Net framework. I know some good C# developers too so I figured it'd be easier for them to improve on the code if its written in their preferred language. I also wrote the application in C for Linux and Mac OSX. Unfortunately, it works fine on Linux but I can’t seem to get the serial port to dump data in Mac OSX with the wsbridge application. I naively assumed that both OSes would behave similarly since both of them are Unix based and support a standard POSIX interface. Interestingly enough, everything is perfectly fine on OSX with the standard chibi or chibiArduino command line interface using a terminal program so I figure there must be something I'm missing in my application code. If anyone wants to take a crack at getting the application to work on OSX, it’d be much appreciated.

Also, I wrote both applications as console programs so that they can be used in a batch file. That way, you don’t need to manually open both programs each time you want to capture data. The location of the pipes are different on Windows and Linux. Windows puts their named pipes in the \\.\pipe\ location by default. I put the location of the named pipe in the /tmp/ directory on Linux since it's universally writeable by applications. Notice that on Windows, backslashes are used but on Linux, forward slashes are used. You can change the locations and names of the pipes in the source code, too.

The tutorial is below. One thing to note is that the tutorial assumes that Wireshark is installed, the Chibi or chibiArduino release supporting promiscuous mode has been downloaded, and you're using hardware that supports the protocol stacks. Also, please feel free to post any comments, questions, or suggestions about the tutorial.

That’s about it. Hope you enjoy it and happy sniffing :)

Click image to open!
Click image to open!
Click image to open!
Click image to open!
Click image to open!
Click image to open!
Click image to open!
Click image to open!
Click image to open!
Click image to open!
Click image to open!
Click image to open!
Click image to open!
Click image to open!
Click image to open!
Click image to open!
Click image to open!
Click image to open!
Click image to open!
Click image to open!
Click image to open!
Click image to open!
Click image to open!
Click image to open!
Click image to open!
Click image to open!
Click image to open!

Hits: 59442
Trackback(0)
Comments (50)Add Comment
piping
written by Mariano Alvira, December 29, 2010
I didn't know you can pipe data into wireshark. I will be trying this soon!

-Mar.
report abuse
vote down
vote up
Votes: +0
...
written by Akiba, December 29, 2010
Yeah, I was surprised when I first read about it on the Wireshark Wiki. First thing that popped into my head was a serial to wireshark bridge smilies/smiley.gif

Akiba
report abuse
vote down
vote up
Votes: +0
great job!
written by noonv, December 29, 2010
its realy cool! smilies/smiley.gif
report abuse
vote down
vote up
Votes: +0
Awesome!
written by Tim B, December 30, 2010
I don't even have an ardiuno yet but this is so well written even I understood it!!!!

Good job, hope you do more like this and I can understand them too smilies/smiley.gif
report abuse
vote down
vote up
Votes: +0
Good work!
written by Hamlet Khodaverdian, December 30, 2010
Excellent writeup Akiba.
report abuse
vote down
vote up
Votes: +0
awesome
written by GregUzelac, December 31, 2010
Well-written and interesting. Great work!
report abuse
vote down
vote up
Votes: +0
...
written by Nicolas, December 31, 2010
Great post and work.
I did the same thing with a dual interface ethernet/802.15.4 board, using Wireshark through ethernet. Works great too.

Nicolas
report abuse
vote down
vote up
Votes: +0
...
written by Akiba, January 01, 2011
Yeah, I think ethernet encapsulation is the most common way I've seen to get data into wireshark. That's why I was surprised when I found out that it supports named pipes as well. Also, looking forward to your http://sen.se site. Let me know when its open to the public and I'll post it on my newsfeed.
report abuse
vote down
vote up
Votes: +0
...
written by Nicolas, January 03, 2011
I sure will. Thanks.
report abuse
vote down
vote up
Votes: +0
Interesting Solution!
written by rmspeers, January 10, 2011
Great writeup. We'll look at that more from here. On a similar topic, we are handling the sniffing slightly differently and actually feeding it over serial into a program that can write to pcap/daintree or dissect in Scapy. We're using your Freakduino board to add things like logging/GPS which enhance the sniffing with metadata.
report abuse
vote down
vote up
Votes: +0
...
written by Akiba, January 10, 2011
Oh nice. GPS as well? Talk about accurate timestamping. Are you also recording the coordinates into the frames? Anyways, I'd love to hear more about it if you publish the research.
report abuse
vote down
vote up
Votes: +0
Very cool
written by Rick Knowles, January 13, 2011
Fantastic job, the value of this to people getting started with Zigbee can't be understated.

Being able to see exactly what's going over the air non-intrusively (and as you pointed out the amount of overhead on each packet) is going to save a lot of people without expensive labs full of gear a lot of time/money.

A small addendum: the example of listening in on two XBees assumes a Series 2 XBee. People like me who have Series 1 versions (which don't support the channel hopping behaviour) will need to ensure manually that the channel on the Freakduino-Chibi is the same as that on the XBees being monitored.

The default on the Freakduino-Chibi is channel 0xB (11), the Series 1 XBee uses 0xC (12) by default. Either

1) switch each of the XBees with X-CTU as akiba described or " (pause) ATCH B" over a serial connection

or

2) Switch the Freakduino-Chibi's channel by changing the following in libaries/Chibi/chibiUsrConfig.h
from:
#define CHB_CHANNEL 11
to:
#define CHB_CHANNEL 12

Should work as described after that. Hope this helps someone, and thanks again to the Freak-tachi.
report abuse
vote down
vote up
Votes: +1
...
written by Rick Knowles, January 13, 2011
It appears the serial string got mangled by the comment editor. It should be "(plus)(plus)(plus)(pause)ATCH(space)B"
report abuse
vote down
vote up
Votes: +0
...
written by Akiba, January 13, 2011
Glad you find the software useful. I actually paid about $3,000 for my 802.15.4/Zigbee protocol analyzer from Daintree so figuring out I could've done it using Wireshark was a little painful for me smilies/smiley.gif

As for the XBee channel setting, it's actually the same for the Series 2 as the Series 1. 802.15.4 doesn't frequency hop but Zigbee does automatically choose a channel from a list of allowed channels. In either XBee series, there is a scan channel field in X-CTU. The scan channels is a 16-bit bitmask where each bit enables or disables the corresponding channel from being used. To force the channel, you only set one bit. I usually just set the first bit since that corresponds to the the first channel (channel 11) for 802.15.4 at 2.4 GHz.
report abuse
vote down
vote up
Votes: +1
...
written by Rick Knowles, January 14, 2011
Ah OK, sorry. I didn't see that setting in x-ctu and assumed it was a new feature in version 2. In firmware 10e8 of the XB24 it is about 15 lines down (not 2nd as in your screenshot) and in its place is a single "Channel" setting option.

Apologies to anyone I may have led temporarily astray.
report abuse
vote down
vote up
Votes: +0
...
written by Dub Dublin, January 18, 2011
Nice to see there are more options. As noted above in the comments, Wireshark already supports Ethernet/UDP encapsulation via ZEP: ZigBee Encapsulation Protocol. Wireshark has included decoders for ZEP packets for a while now: "Exegin's ZigBee, ZigBee Cluster Library, SCoP, and 6LoWPAN dissectors have now been integrated in the main Wireshark code." (Exegin is the company that makes the 15.4 sniffer hardware I use with wireshark - no relation other than as a satisfied customer: http://store.exegin.com/Produc...ode=98-051)

BTW - I disagree with the terms of usage that say you can change/modify what I say. Delete them, fine, but don't put words in my mouth...

I only use raw 802.15 (since ZigBee can't be made to scale beyond a few dozen nodes and we need tens of thousands) so I can't speak to the dissectors mentioned above. It does a decent job with raw 802.15.4, though, and is easy enough to customize for our own protocol uh, extensions...
report abuse
vote down
vote up
Votes: +1
...
written by Marius_py, January 19, 2011
Hi, You tested the communication between two Xbee module radios in transparent mode. I assume that this is the transparent operation of the Xbee. Besides the Transparent Operation there is also the API operation. I wonder if the sniffer works to monitor between two Xbee radios in API operation.
Thanks.
Regards.
report abuse
vote down
vote up
Votes: +0
...
written by Akiba, January 19, 2011
Yes, from a protocol point of view, there is no difference between the API mode and transparent mode. Both of them use the Zigbee protocol which at its base uses 802.15.4. So as long as you can capture the 802.15.4 frame, you also get the contents of the frame payload which includes all the Zigbee information.

Transparent mode is just a special application of Zigbee. In Zigbee terminology, it would be called a "manufacturer specific profile". API mode is more general and allows the user to create their own application either based on the Zigbee standard profiles or their own.

So to answer your question, it will be able to capture data in API mode or transparent mode since they're basically the same thing. Transparent mode is just a particular application of the more general API mode.
report abuse
vote down
vote up
Votes: +0
...
written by Thomas tomi, March 28, 2011
This is an great tool. But can somebody help me to change this tool?
The output on com port looks like this:
0000 41 c8 32 cd ab ff ff 00 00 99 72 33 55 44 22 41 A.2.......r3UD"A
0010 60 00 00 00 00 28 3a ff fe 80 00 00 00 00 00 00 `....(:.........
0020 20 44 55 33 72 99 00 00 ff 02 00 00 00 00 00 00 DU3r...........
0030 00 00 00 01 ff 66 66 66 87 00 ac 0c 00 00 00 00 .....fff........
0040 fe 80 00 00 00 00 00 00 64 66 66 66 66 66 66 66 ........dfffffff
0050 01 02 22 44 55 33 72 99 00 00 00 00 00 00 00 00 .."DU3r.........

0000 41 c8 32 cd ab ff ff 00 00 99 72 33 55 44 22 41 A.2.......r3UD"A
0010 60 00 00 00 00 28 3a ff fe 80 00 00 00 00 00 00 `....(:.........
0020 20 44 55 33 72 99 00 00 ff 02 00 00 00 00 00 00 DU3r...........
0030 00 00 00 01 ff 66 66 66 87 00 ac 0c 00 00 00 00 .....fff........
0040 fe 80 00 00 00 00 00 00 64 66 66 66 66 66 66 66 ........dfffffff
0050 01 02 22 44 55 33 72 99 00 00 00 00 00 00 00 00 .."DU3r.........

0000 41 c8 33 cd ab ff ff 00 00 99 72 33 55 44 22 41 A.3.......r3UD"A
0010 60 00 00 00 00 28 3a ff fe 80 00 00 00 00 00 00 `....(:.........
0020 20 44 55 33 72 99 00 00 ff 02 00 00 00 00 00 00 DU3r...........
0030 00 00 00 01 ff 66 66 66 87 00 ac 0c 00 00 00 00 .....fff........
0040 fe 80 00 00 00 00 00 00 64 66 66 66 66 66 66 66 ........dfffffff
0050 01 02 22 44 55 33 72 99 00 00 00 00 00 00 00 00 .."DU3r.........

And i want to pipe this without changing or adding header, time information. How can i do this?
report abuse
vote down
vote up
Votes: +0
Xbee Pro and chibiArduino
written by Ricardo Carrano, May 23, 2011
Great!

Hi all! And thank you, Akiba, for putting this together!

I couldn´t make it work, though, but I think that it may have something to do with my setup (arduino duemilanove libelum shield Xbee Pro). I´ve changed the channel settings in chibbi since XbeePro does not
support channel 11, but it seems that there is something more.

After I upload chibi the XbeePro module starts behaving strangely. One example: If I take the module out and connect it to another arduino with no microcontroller (so to connect direct the Xbee Module) it
sometimes does not respond to AT commands. If I then reset the module it comes back to normality again.

But the fact is that the WSBridge is not beeing fed by the sniffer. I test it by sending data via serial. The WSbridge echoed the data.

I also uploaded the hello world example in that same hardware, but apparently nothing is being transmitted (I double check by using a Metageek Wispy dongle).

Is there something more (besides changing the channel) that I should pay attention when using XbeePro? Or is it the case that it does work fine with that module but I am overlooking something else?

Again, Thank you for your time!
report abuse
vote down
vote up
Votes: +0
...
written by Akiba, May 24, 2011
Hi Ricardo. Are you running the ChibiArduino library on a Duemilanova XBee? The Duemilanova is okay but chibiArduino is not compatible with the XBee. XBees only communicate via Zigbee frames while chibiArduino communicates using 802.15.4 frames. It's analogous to a device only communicating with HTTP and another device that only communicates with raw ethernet frames. So unfortunately, the XBee can't be used with the chibiArduino.
report abuse
vote down
vote up
Votes: +0
...
written by Ricardo Carrano, May 24, 2011
I see. I was under the impression that series 1 Xbee used "pure" 802.15.4 and series 2 were ZigBee. Now I see that the difference has nothing to do with that. It seems that series 1 is for point-to-(multi)point and series 2 is for mesh. My bad!
I´ll visit the freakduino shop! smilies/wink.gif
Thank you very much!
report abuse
vote down
vote up
Votes: -2
...
written by Ricardo Carrano, May 27, 2011
I found where I've read that XBee modules were 802.15.4:
http://www.digi.com/products/w...p#overview. It seems that there are Xbee and Xbee ZB modules.


XBee and XBee-PRO 802.15.4 OEM RF modules are embedded solutions providing wireless end-point connectivity to devices. These modules use the IEEE 802.15.4 networking protocol for fast point-to-multipoint or peer-to-peer networking. They are designed for high-throughput applications requiring low latency and predictable communication timing.


Digi's naming schemes is rather confusing.
report abuse
vote down
vote up
Votes: +0
All channels
written by Allen, June 01, 2011
I've got this up and running and it works really well. It appears on limitation is that it will only sniff all traffic on one channel at a time, so you have to chibiSetChannel(channelNum) to the channel you know your devices are using to see the traffic there.

Is there a way to set this up to roll through all the channels and capture all 802.15.4 traffic on all channels? I've gone through a few iterations of code that attempts to do this, but since there's 11 channels to scan and it always seems to drop a many of the packets. Is this something that could be done in the driver to handle this more efficiently? Is this a limitation of the radio or the software?

Thanks for all the hard work.
report abuse
vote down
vote up
Votes: +0
Error
written by Tom.U.S, December 05, 2011
Hi,

I am using your application with another RF chipset. This device sends len,mac packet, another 2 bytes, len = sizeof (mac packet) 2 on the serial port.

E.g:
Frame 1: 105 bytes on wire (840 bits), 103 bytes captured (824 bits)

Message from wsbridge.exe:
69 41 C8 33 CD AB FF FF 8 7 6 5 4 3 2 1 7A 3B 3A 1A 9B 1 88 D6 0 5 1
0 10 2 0 0 AA AA 0 0 0 0 0 0 0 0 0 FF FE 0 0 1 2 6 7 4 0 2
0 0 4 E 0 8 C A 3 0 1 0 0 1 0 FF FF FF 8 1E 40 40 0 0 0 0 0
0 0 0 0 0 0 0 AA AA 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0 0

Pipe has been closed.

But, somehow I keep on getting consistently "Frame 2 too long (-2 bytes)" error after which the capture fails. I am using wireshark 1.6.2. Please let me know what am I missing.

Regards,
Tom
report abuse
vote down
vote up
Votes: +0
...
written by Tom.U.S, December 05, 2011
Hi,

Correction...

I am using your application with another RF chipset. This device sends len,mac packet, another 2 bytes, where len = sizeof (mac packet) 2 on the serial port.

Regards,
Tom
report abuse
vote down
vote up
Votes: +0
...
written by Akiba, December 05, 2011
Wireshark expects 2 extra bytes on the wire at the end of the frame. For 802.15.4, those would be the CRC bytes. These are not used but are expected. If you look at my captures, you can see that the the number of bytes "on the wire" and the number of bytes "captured" always differ by two. I think this might be where your problem is.
report abuse
vote down
vote up
Votes: +0
...
written by Tom.U.S, December 05, 2011
Hi,

I noticed. smilies/cry.gif

Even my capture shows :
Frame 1: 105 bytes on wire (840 bits), 103 bytes captured (824 bits)

2 extra bytes... smilies/cry.gif Still the error

Regards,
Tom
report abuse
vote down
vote up
Votes: +0
...
written by Tom.U.S, December 05, 2011
Hi,

I have tried increasing len by another 2 and by reducing another 2... all cases fail.

Regards,
Tom
report abuse
vote down
vote up
Votes: +0
...
written by Akiba, December 05, 2011
Only thing I can tell you is to start counting bytes in both frames 1 and 2. Make sure that they match the length byte in the 802.15.4 frame and also the values that are showing up on the wire in wireshark. Also, try sending out identical frames and see if the same things happens.
report abuse
vote down
vote up
Votes: +0
...
written by Tom.U.S, December 05, 2011
I don't get what do you mean by frame 1 and frame 2.. anyways let me try digging deeper...

The dumpcap.c code snippet responsible for the error message...

case PD_REC_HDR_READ:
/* We've read the header. Take care of byte order. */
cap_pipe_adjust_header(ld->cap_pipe_byte_swapped, &ld;->cap_pipe_hdr,
&ld;->cap_pipe_rechdr.hdr);
if (ld->cap_pipe_rechdr.hdr.incl_len > WTAP_MAX_PACKET_SIZE) {
g_snprintf(errmsg, errmsgl, "Frame %u too long (%d bytes)",
ld->packet_count 1, ld->cap_pipe_rechdr.hdr.incl_len);
break;
}
report abuse
vote down
vote up
Votes: +0
you need 802.15.4 no FCS network in the pcap
written by Mariano Alvira, December 05, 2011
instead of

uint32_t network = 195; /* data link type (DLT) - IEEE 802.15.4 */

you probably need

uint32_t network = 230; /* IEEE 802.15.4 no FCS */

That should work in newish versions of wireshark. Akiba, you could make this a command line switch.

-Mar.
report abuse
vote down
vote up
Votes: +0
...
written by Akiba, December 06, 2011
Hmmm...I'll check it out. Thanks for the heads up, Mar.
report abuse
vote down
vote up
Votes: +0
Wireshark erroring out
written by Rob, January 31, 2012
Thanks for the great article.

I seem to have it all working fine, other than I'm getting an error in Wireshark "Frame x too long (-2 bytes)", where x varies between 1 and about 14.

Has anyone any ideas as to what I might be doing wrongly?
report abuse
vote down
vote up
Votes: +0
...
written by Akiba, January 31, 2012
The frame size that is going into wireshark is longer than what it is expecting. You should be able to dump the raw data and compare it with what is being fed into wireshark. What are you using to generate the traffic?
report abuse
vote down
vote up
Votes: +0
alternatives for a HW sniffer?
written by bw, March 06, 2012
way cool & educational. great work Akiba, really beneficial to a home hobbyist

what are some alternatives to say the,(Exegin sniffer hardware) - it is a bit steep cost wise for me. and i don't have any arduino boards.

would the TI CC2531 USB Dongle work with wireshark to cap/analyze zigbee packets?
report abuse
vote down
vote up
Votes: +0
...
written by Akiba, March 06, 2012
It should work but you'll probably need source code access to a CC2531 driver or write your own. You'll basically need to dump the raw packets out of the interface. I don't think you can get access to it from the TI Z-Stack driver.
report abuse
vote down
vote up
Votes: +0
TI CC2531 usb dongle
written by jonatan, June 07, 2012
It could work and i'm going to try it out. TI provides free packet sniffer sw which works with CC2531 dongle - http://www.ti.com/tool/packet-sniffer . This sw can parse packets but sadly it can't show all zigbee packets in nice way but interestingly it has got the ability to forward all captured packets via UDP broadcasting. Don't know if its possible to directly capture those packets with wireshark (i think some transformation will be needed). Anyway when i googled on this topic i came across somewhere on the net with ruby/perl script which start udp server and just shows raw packets on std output (sadly no parsing is done). Another possibility is to use microship zena packet analyzer (hw analyzer sw is at 100 Eur mark compared to 50 Eur for CC2531 usb dongle).
report abuse
vote down
vote up
Votes: +1
SC 1FFE
written by rob, August 11, 2012
Hello.

I'd like to sniff some XBee on SC 1FFE. I can't change this on the xbee modules, so what should I change on freakduino side to get this channel?

Thanks,
report abuse
vote down
vote up
Votes: +0
...
written by Akiba, August 12, 2012
I believe 0x1FFE is the channel mask. Each bit represents one channel that is enabled. The XBee will randomly select a channel to operate on based on the channel mask. If you want to know exactly what a channel is on, then you need to force the channel mask to one bit, ie: 0x0004, 0x0008, 0x1000, etc. Otherwise, you will need to constantly send data on the XBee and write a sketch on the freakduino to scan the channels for data.
report abuse
vote down
vote up
Votes: +0
...
written by Pravin, September 15, 2012
Do you it it can receive all wifi packets, like management and control?
report abuse
vote down
vote up
Votes: +0
Wow, just freakin' Wow.
written by draythomp, October 20, 2012
I've been fighting problems with collisions, partial messages, all the crap that comes with a network including insufficient processor power to parse the messages. The single biggest problem is that I can't see everything on my XBee Series 2 zigbee network.

Now I can.

Yes, I had to learn the hard way to set the channel number, and I had to stumble over a couple of other misunderstandings, but now I can see every stinking message on my network of devices. The ones that do point to point between two XBees and can't be seen by any other device were a special problem for me. The retries, acks, etc. all show up.

Right now, I don't need a network analyzer, I just need to understand what my network is doing behind the scenes to screw up my efforts. So, I'm busily building a parser to capture my own messages and output serial data that is meaningful to me.

Thanks for your hard work, good job.
report abuse
vote down
vote up
Votes: +0
...
written by Akiba, October 20, 2012
Thanks for sharing and I'm glad it helped out. For anyone doing networking or network programming, I always think it's important to see what's going on over the wire or over the air. Otherwise, you're just relying on guesses and inference. Happy this helped, but the real work is done by the Wireshark guys smilies/smiley.gif
report abuse
vote down
vote up
Votes: +0
OK, spoke way too soon.
written by draythomp, October 23, 2012
Wireshark was working fine on a couple of XBees, but when I started watching my entire network (about 12 devices), I started getting the -2 error mentioned several times above. I went looking through the various codes and noticed a couple of things. In the wsbridge.pde code the buffer used is CHB_MAX_PAYLOAD size, that's only a hundred bytes and I saw it reach 120 a few times. After which, the arduino rebooted which killed the wireshark feed. Also, promiscuous mode sets the rx circular buffer to 1024 which puts the board dangerously near to running out of memory. Especially when I put a couple of debugging statements in there to see what was going on.

But, the problem didn't go away, even when I worked around those little problems. I firmly believe wireshark has a bug in the protocol dissection. Shouldn't it just mark the packet as invalid and continue instead of stopping?

At any rate, I took some of the code from wsbridge and added some parsing to look at my network addresses as I needed them and was able to monitor my network quite nicely. Wireshark would have been nice, but it just didn't hold up with a lot of traffic.
report abuse
vote down
vote up
Votes: +0
...
written by Akiba, October 23, 2012
Hmm....let me look into it. I suspect it's probably on the firmware side and not on the wireshark side. I suspect I won't have any time to work on it until the weekend though. I'll post here if I make any discoveries.
report abuse
vote down
vote up
Votes: +1
Problem with 115200 Serial baud rate
written by mikew, February 11, 2013
Just wanted to let everyone know that I was having a problem with that -2 error in WireShark that some people have mentioned. I lowered the serial speed to 57600 in the Arduino sketch and modified Akiba's C# code in wsbridge and the packet capture started working flawlessly!

I wrote a python script to dump out the raw hex data coming from the Arduino and it looked like, at the higher speed, some of the data was getting all messed up (including the frame size byte). I then wrote a sketch to make sure it was the serial port by checking the frame size byte with the chibiGetData return value and I always got good data from the radio.

Hope this helps someone out and saves them the hours of debugging and troubleshooting!
report abuse
vote down
vote up
Votes: +0
...
written by Akiba, February 11, 2013
Interesting. I definitely know that 57600 is extremely stable with the boards. Thanks for taking the time to post your results. Sounds like there's an issue with some boards and the timing accuracy at 115200. I guess 57600 is the better speed to use. Sorry about that.
report abuse
vote down
vote up
Votes: +0
Great work!!!!
written by Liss, May 27, 2013
Hi, your work is amazing smilies/smiley.gif. Do you have a video tutorial about this?
report abuse
vote down
vote up
Votes: +0
...
written by Akiba, June 04, 2013
That should be on the way. I'm going to do a bit of an overhaul for this tutorial smilies/smiley.gif
report abuse
vote down
vote up
Votes: +1
API Mode
written by khristopheryan, April 02, 2014
Will this work if the xbees are operating in API mode? thanks
report abuse
vote down
vote up
Votes: +0

Write comment

busy
  No Comments.

Discuss...
< Prev   Next >