Home arrow Projects arrow WSBridge - Wireshark Bridge
WSBridge | Print |
Written by Akiba   
Wednesday, 29 December 2010

This is a simple application that acts as a bridge between Chibi/chibiArduino and Wireshark. The Chibi/chibiArduino stacks need to be put into promiscuous mode. From there, raw 802.15.4 data frames are output via serial port (virtual COM port) to WSBridge which feeds them into Wireshark.

WSBridge v0.51

  • Fixed issue regarding cpu utilization on Linux
    • On Linux, I assumed the serial port read was blocking so it wouldn't consume CPU cycles. However it is not and it was causing the CPU utilization to go to 100% when Wireshark connects. I added a select() statement which will block until data is available on the serial port. This reduces CPU utilization since the process won't execute until there is data from the serial port.
Link to WSBridge v.0.51

WSBridge v0.50

  • Initial release

Link to WSBridge v0.50

Updated 2011-05-18: I've been getting complaints that when running Wireshark and WSBridge on Windows machines, cpu utilization starts going very high. Wireshark just recently fixed a bug on Windows related to sending in data via named pipes from v1.4.2. Click here for more info regarding the bug .
Hits: 44550
Trackback(0)
Comments (34)Add Comment
100% CPU load after running WSBridge
written by Pablo2048, January 27, 2011
Hi Akiba,
thanks for great job with this tool, but if i run wsbridge (Windows XP) my CPU load rises to 100%. In Wireshark if i try to write .pipewireshark it responds VERY slowly. Do You have any idea how to avoid this behavior?
Thanks
Pavel Brychta
report abuse
vote down
vote up
Votes: +0
...
written by Akiba, January 27, 2011
Yeah, thats kind of strange. I just opened wsbridge and wireshark on my PC running WinXP and the CPU load is at 1%. Not really sure what could be happening to cause it to load the PC down that much. Is it possible to test it on a different PC or even OS to see if the result is the same? Also, in the Windows Task Manager, when you're running WSBridge, can you check in the Process tab to see if wsbridge is consuming the CPU or if there is another app, like say an antivirus that might get triggered to run because of it?

As for writing the pipe name in Wireshark, that particular textbox where you specify the capture input in Wireshark does respond slowly. However I'm sure its even slower if you're at 100% CPU utilization.
report abuse
vote down
vote up
Votes: +0
...
written by Akiba, January 29, 2011
Hi. Are you still having problems running WSBridge? So far, I've tested it on three different machines running WinXP and the resource utilization is almost 0% for the WSBridge process on each of them. Is it possible to try it out on a different machine and let me know the outcome? I'd like to get to the bottom of it.
report abuse
vote down
vote up
Votes: +0
...
written by Pablo2048, February 01, 2011
Hi Akiba,
Yes - I still have problem with WSBridge. Meantime a friend of mine slightly modified Your code, but the modification is not finished yet. I will post You new code with modified Arduino code ASAP. Problem with slow Wireshark response we solved with commandline script.
It seems the problem with WSBridge has to do something with "heavy" Zigbee traffic which are we monitoring (2 Zigbee stations, 1 Coordinator, Zigbee packet sent every 0.5-1 second].
report abuse
vote down
vote up
Votes: +0
...
written by Kevin Townsend, February 13, 2011
The fact that the pipe address writes very slow in Wireshark is normal ... one a fast machine I have the same problem, and it's a wireshark issue. You simply need to type the characters with a small delay between them. As for CPU usage being really high, it's not something I've seen myself. Are you disabling everything excet 802.15.4 in wireshark perhaps? Something I noticed myself with wsbridge is if you open the named pipe mid-frame (which is possible with heavy traffic) the entire feed will be screwed up. You need to make sure you join when their is no incoming frame. I modified the swbridge code to check the frame length, and iof the length exceeds 127 bytes I know there are frame issues and I drop the entire buffer and wait for a new frame to come in. That allows me to safely start sniffing traffic even with 50 or sames frames per second being sent, at the expense of the first 5-10 frames being garbled. Just something to think about anyway.
report abuse
vote down
vote up
Votes: +0
WSBridge CPU usage.
written by Milen, March 13, 2011
Hi Akiba,

You did a great job with this tool.
I have tested the wsbridge on windows vista and have 50% CPU usage. I found in the code
// run forever
while (true)
{
}
I changed it to
while (true)
{
System.Threading.Thread.Sleep(5000);

}
It is ok now only 2% CPU usage.
report abuse
vote down
vote up
Votes: +1
...
written by Akiba, March 13, 2011
Thanks! Looks like I still need to work on my Windows programming smilies/smiley.gif
report abuse
vote down
vote up
Votes: +0
The 100% cpu usage on OSX and possibly Linux
written by John A. Stewart, March 26, 2011
Hi all;

I've been meaning to send in some code, but vacations have got in the way.

Anyway, I copied the Linux code to Apple OSX, and compiled it. It ran "perfectly".

There is an issue where the non-blocking read from the USB port consumes 100% of cpu usage on that core. Sleeping for a bit if "-1" is returned works much better. I don't know how much to sleep; hopefully this weekend I'll get back to programming with it.

Great little project!

JohnS.
report abuse
vote down
vote up
Votes: +0
...
written by Akiba, March 26, 2011
Thanks John! I still need to send out that extra board. It should go out this week. Thanks for the help!
report abuse
vote down
vote up
Votes: +0
...
written by Bedas, March 26, 2011
What is the format of input data for this bridge? Is any special character to indicate begin of frame, end of frame,... etc.? Or you just send raw 802.15.4 frame into this bridge?
report abuse
vote down
vote up
Votes: +0
...
written by Bedas, March 26, 2011
I am idiot..it is written at the top of this page smilies/cheesy.gif...sorrysmilies/sad.gif .....raw 802.15.4 data frames are output via serial port (virtual COM port) to WSBridge which feeds them into Wireshark
report abuse
vote down
vote up
Votes: +0
Another little bit of an issue on OSX.
written by John A. Stewart, March 31, 2011
Ok - after a bit of headscratching, I have a working OSX scanner - so far!

Taking the Linux main.c:

1) sleep a bit (as mentioned at least once)

....
// wait for data to come in on the serial port
nbytes = read(FD_com, port_buf, PORTBUFSIZE);

// if we read -1 bytes, sleep for a bit, so we dont chew up lots of
// CPU cycling reading -1 bytes.
//
// we do not do non-blocking reading, because Wireshark needs the
// pipe to have data sent to it in order to properly run.

if (nbytes == -1) {
// 50,000 == 20 tries per second.
usleep (500000);
}
if (nbytes > 0)
....

That sleep seems ok for me; it might have to change when I really get into debugging my ZigBee stuff.

2) OSX - the serial port was not set for raw mode. This is a bit of an issue as, say, NULLs get dropped, OXOAs get interpreted, yada, yada... I'd assume that the following would work on Linux, too:

term.c_cflag |= CS8;

term.c_cflag |= (CLOCAL | CREAD);

/* JAS - set RAW so that NULLs come through, and command chars are not interpreted. */
cfmakeraw(&term;smilies/wink.gif;

tcsetattr(FD_com, TCSANOW, &term;smilies/wink.gif;
}

Note the simple addition of the cfmakeraw line.

It has gone from:

Client connected to pipe.
read in 1 bytes
Len = 0A.
read in 9 bytes
03 08 FF FF FF FF 07 38 0A
read in 10 bytes
Len = 03.
08 10
Len = FF.
FF FF FF 07 88 0A read in 10 bytes
03 08 20 FF FF FF FF 07 58 0A read in 10 bytes
03 08 30 FF FF FF FF 07 E8 0A read in 9 bytes
03 08 FF FF FF FF 07 38 0A read in 10 bytes
03 08 10 FF FF FF FF 07 88 0A read in 10 bytes


to

Client connected to pipe.
read in 10 bytes
Len = 0A.
03 08 00 FF FF FF FF 07 38
read in 10 bytes
Len = 0A.
03 08 10 FF FF FF FF 07 88
read in 10 bytes
Len = 0A.
03 08 20 FF FF FF FF 07 58
read in 10 bytes
Len = 0A.

Which makes more sense!
report abuse
vote down
vote up
Votes: +0
...
written by Akiba, April 02, 2011
Hey John.
Sorry for the late reply. Things got crazy last week. I'm going to give it a try later. If I can get it to work on my Mac, I'll be releasing your code. Thanks so much for your help smilies/smiley.gif
report abuse
vote down
vote up
Votes: +0
chibiArduino Promiscuous mode returns one too few bytes
written by SteveH, April 18, 2011
Hi Akiba,

Fantastic job with the Freakduino Chibi and WSbridge!

I've been using it to monitor traffic on what turns out to be a Synapse SNAP network: although it's based on the 801.15.4 physical layer, unfortunately Wireshark doesn't understand the MAC layer and it appears not to be published anywhere (If anyone knows any details, please do tell).

Anyway, I was forced to start looking at raw packets so I looked more closely at the console output from WSbridge, and noticed it only shows one byte of the frame checksum. (You don't see this in Wireshark because WSbridge doesn't write the checksum to Wireshark).

The problem lies in chb_read (chb.c): the frame length - len - is copied to the output buffer, followed by len data bytes (which include the two frame checksum bytes), so the buffer receives a total of len 1 bytes. If CHIBI_PROMISCUOUS is true the function simply returns len, which means that the last checksum byte is ignored. Changing the return value to len 1 fixes this.

If you fix this it exposes an off-by-one error in WSbridge (write_frm) that also has to be fixed or the code loses count of bytes in the buffer.

Steve
report abuse
vote down
vote up
Votes: +0
Add Steves comments my changes == seems to work fine on OSX.
written by John A Stewart, April 21, 2011
Akiba; (and, others)

I see what Steve means; I have put my modified "chb.c" from the Arduino side, and my modified "main.c" from the OSX/Linux wsbridge side on a website; hopefully here:

http://freewrl.sf.net/JAS/wsbridge/chb.c
http://freewrl.sf.net/JAS/wsbridge/main.c

Hopefully of some use to some others...

JohnS.
report abuse
vote down
vote up
Votes: +1
Wireshark doesn't see the packets.
written by GregB, April 28, 2011
Hello all,

I am running Ubuntu 10.10. 64bit

After starting wireshark, the terminal I run wsbridge in fills with data. Wireshark might see one packet and most off the time it sees none of the traffic.

In this example it sees one packet and then the next has Len = 0


Serial port connected. Waiting for wireshark connection.
Open wireshark and connect to local interface: /tmp/wireshark
Client connected to pipe.
Len = 40.
00 01 00 00 E6 21 C2 04 00 00 00 00 25 20 61 88 3D 34 02 00 00 04 00 44 00 00 00 04 00 20 BC 40 00 01 00 00 E6 21 C2 04 00 00 00 00 25 0C 63 88 3E 34 02 00 00 04 00 04 10 0C 63 88 3F 34 02
Len = 00.
00 04 00 04 AF 0C 63 88 3F 34 02 00 00 04 00 04 AF 0C 63 88 39 34 02 71 5B 73 5B 04 28 0C 63 88

after that there is about 750,000 characters at which point I killed the process.


Do anyone know what I could be doing wrong?
report abuse
vote down
vote up
Votes: +0
...
written by John A Stewart, April 29, 2011
Hi GregB;

Try compiling the wsbridge program with the message from the one above yours. I took the Linux version, and fixed a bug in it; it seems "ok" with one issue - on OSX.

Save your original, of course, and save the "chb.c" and replace it with the one in the link above. The "chb.c" is a file that goes in the Arduino application area, at least on OSX.

(I presume that you compiled your "wsbridge" program??)

There is still a bug with my changes so Akiba's program - the wsbridge gets only 1 byte of the 2 bytes of the frame check sequence, but that is not of major importance for right now for you.

Give it a try and see what happens.

JohnS.
report abuse
vote down
vote up
Votes: +0
...
written by Akiba, April 29, 2011
For the wsbridge program, you may be getting the synchronization incorrect. The first frame's length shows 0x40 or 64 bytes. The second frame's length shows 0x00 or 0 bytes. This seems to be what's messing it up. Are you using the chibi stack for the data?
report abuse
vote down
vote up
Votes: +0
Re: Wireshark doesn't see the packets.
written by GregB, May 01, 2011
Hello All,

Thanks for the quick response. It was not obvious that the problem, as stated above, was the same one that I was having (with all the talk of OSX specific). I had the opportunity to try the fix and it did do a lot better. At first I was getting some data that seemed to be corrupted (mostly zeros) but once I restarted wsbridge, it seemed to work. I have not had time to analyze the data completely but the data I was getting was interpreted by Wireshark as valid.

Akiba,

The data is coming from what is assumed to be XBee sources. It is thought that they are being used on research windmill near the lab where I was doing the capture.

Thanks again for all your help!

report abuse
vote down
vote up
Votes: +0
...
written by Akiba, May 18, 2011
Hi all.
Regarding the bug that was reported for the high CPU usage on Wireshark, Wireshark recently fixed a bug with named pipes sending data into the program. Its fixed from version 1.4.2. You can find the details here:

https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=5309
report abuse
vote down
vote up
Votes: +0
...
written by a. zulficar, May 27, 2011
Thanks for all your excellent work on this. Getting two freakduino's to talk was so easy. I'm able to get this working only with another Freakdunio transmitting the 'hello world' program data ...

The problem is I'm really interested in using this for sniffing but am having a couple issues.

1. Wireshark is reporting that the zigbee NWK data is malformed (I can see Hello World" in ASCII next to the HEX).

2. The Freakduino sniffer doesn't see any other Zigbee devices I have (3 others). I have XBP24 (XBee Pro), a certified retail Zigbee device made by Landis Gyr called an ecoMeter as well as on other unknown radio that's acting as a coordinator and is also certified ZigBee.

I've quadruple-checked to make sure Promiscuous mode is on in the header file and redeployed the code to the freakduino many many times.

I noticed in your screenshots your packets were not malformed and you also did a test an XBee and it picked up the data...

Thoughts?

Thanks again.
report abuse
vote down
vote up
Votes: +0
High CPU and malformed packets
written by Dave, March 06, 2012
Hi Akiba,

Many thanks for the quick shipment of the Chibi and the great work you are doing. I bought the chibi to gain my knowledge regarding zigbee and since my background is an network administrator, what's better than to start digging into the frames. Unfortunately I ran into the same problems as mentioned earlier (high CPU usage of WSBridge and malformed packets). WSBridge is causing the high CPU as soon as WireShark is connected to the name pipe. I addressed the high CPU issue by applying the modification Milen proposed but I've to dig a little deeper into the code to address the malformed packets in wireshark. I looks like the starts/ends of the packets sent over the serial are not recognised, sometime it's necessary that two packets are coming into WSbridge before wireshark shows them. Then wireshark shows packets longer then 127 bytes so it looks like it combines two packets before showing them. I'm using wireshark 1.6.5, WSBridge 0.51 and chibiArduino-v0.55. Can you tell me if there is already a solution for this problem.

Many thanks for the great work !
Dave
report abuse
vote down
vote up
Votes: +0
...
written by Akiba, March 06, 2012
It sounds like a synchronization issue. When the freakduino is first turned on, it will start transmitting packets if it sees any. At this time, the PC side WSBridge program might not be started yet. So when you start the program, then WSBridge might start listening in the middle of a frame and hence lose sync. The first byte WSBridge sees, it will think it's the length byte. So if it is not the length byte, then it will mess up the system. The fix is to hold the freakduino in reset until the WSBridge program and Wireshark start up. Otherwise, to start the programs first before firing up the freakduino. Can you try that and see if it helps your issue?
report abuse
vote down
vote up
Votes: +0
...
written by Dave, March 07, 2012
Can it maybe caused by the serial port settings. I left this the default (115200, Parity.None, 8, StopBits.One)
report abuse
vote down
vote up
Votes: +0
...
written by Akiba, March 07, 2012
[Akiba]Oops, accidentally deleted this post when I was cleaning up spam posts. Sorry.[/Akiba]

Thanks for the fast reply. Hmm, I'm sure there is no data send before chibi, wsbridge and wireshark are fully up and running. Keeping the reset button pressed seems not the solution also. I'm also seeing the "Frame X too long (-2 bytes)" error in wireshark. Also when I'm powering the chibi for the first time it does not sent any data. After I upload chibi_ex9_wsbridge to the chibi it starts sending data (I know because I see the TX & aux leds flashing when I send a packet from the XBee.) I'm running WinXP and using Xbee's (ZB) to generate data. Any thoughts? It looks indeed that the data received on the serial or sent via the pipe is not in sync. Do you have a reference to the frame structure somewhere. I really hope I can get this solution working. Thanks again !
report abuse
vote down
vote up
Votes: +0
...
written by Akiba, March 07, 2012
Hi Dave.
Can you try changing the serial port settings to 57600 in the Arduino firmware and also when you open the serial port on the PC? I'm curious if its a possible issue with the serial port. It's the first time I've heard of a problem like this with wsbridge and it's used quite a bit.

Also, if you can send me some screen captures of the issue you're seeing, it'd help.
Thanks.
report abuse
vote down
vote up
Votes: +0
...
written by Dave, March 08, 2012
Hi Akiba,

I've changed the serial port speed to 57600 and even tried as low as 9600 but I always see the first packet coming out of the chibi has length of 0xE0, 224 bytes ?? This seems a false start. I've added some extra debug info to WSbridge. See below the results, this is exactly what wireshark is showing so it looks to me that the problem pinpoints to the chibi. (I think it's also strange that, after reconnecting the power, it only starts sending data to the the serial after I upload the sketch again.)

Thanks again for you help, really appreciate it !
Dave

-- new frame on serial ---- Length=224
E0 80 1E 9E 80 E0 E0 FE 7E 9E 98 86 0 0 66 86 F8 60 80 0 66 80 18 80 0 E0 FE 98 FE 1E 98 80 6 6 E6 FE 7E 9E 98 86 0 0 66 86 F8 80 98 80 60 0 0 66 86 F
8 F8 60 FE 7E E6 98 80 9E 0 6 0 18 E6 1E 60 0 60 9E E6 98 E0 6 80 6 0 18 E6 1E 60 0 0 6 E6 18 78 0 66 80 6 F8 80 FE 0 66 0 0 6 80 0 0 6 80 9E
80 60 80 FE 98 66 80 18 80 0 E6 FE 1E E6 E6 60 0 6 6 F8 9E 78 98 86 FE FE 0 0 86 80 0 60 F8 FE 0 0 6 80 E0 80 7E E6 98 80 9E 0 6 0 18 E6 1E 60 0
80 80 0 86 E0 80 1E 9E 80 E0 1E E6 7E 9E 98 86 0 0 86 80 E6 FE 60 80 0 66 6 18 0 0 1E E6 86 86 1E 98 80 6 6 60 E6 7E 9E 98 86 0 0 86 80 E6 FE 80 98 8
0 60 0 0 86 80 E6 FE F8 60 E0
-- new frame on serial ---- Length=158
9E 98 98 80 9E 0 6 0 18 E6 1E 60 0
------ Writing frame to wireshark -- sec=20,usec=78125,incl_len=222,orig_len=224
------ done Writing frame to wireshark --------- rd_idx=224
E6 E0 E6 98 E0 6 80 6 0 18 E6 1E 60 0 0 6 E6 18 78 0 66 80 6 F8 80 FE 7E 6 80 0 0 6 E0 1E 80 98 18 6 6 F8 60 66 80 18 80 0 60 E6 78 78 78 66 E0
6 6 66 E6 7E 9E 98 86 0 0 86 80 E6 FE 80 98 80 60 0 0 86 80 E6 FE F8 60 86 9E 98 98 80 9E 0 6 0 18 E6 1E 60 0 E6 E0 E6 98 E0 6 80 6 0 18 E6 1E 60 0
0 6 E6 18 78 0 66 80 6 F8 80 FE 80 6 80 0 0 6 E0 1E 80 86 18 6 6 F8 18 E6 66 80 18 80 0 66 E6 FE 60 78
-- new frame on serial ---- Length=102
66 E0 6 6 78 E6 7E 9E 98 86 0 0 86 80 E6 FE 80 98 80 60 0 0 86 80 E6 FE F8 60 78 7E E6 98 80 9E 0 6 0 18 E6 1E 60 0 E6 E0 E6 98 E0 6 80 6 0 18 E6 1
E 60 0 0 6 E6 18 78 0 66 80 6 F8 80 FE 86 6 80 0 0 6 E0 1E 80 98 18 6 6 E0 E6 9E 78 66 E0 6 6 78 E6 7E 9E 98 86 0 0 86 80 E6 FE 80
-- new frame on serial ---- Length=152
98 80 60 0 0 86 80 E6 FE F8 60 78 7E E6 98 80 9E 0 6 0 18 E6 1E 60 0 E6 E0 E6 98 E0 6 80 6 0 18 E6 1E 60 0 0 6 E6 18 78 0 66 80 6 F8 80 FE 86 6 8
0 0 0 6 E0 1E 80 98 18 6 6 E0 E6 9E 6 18 18 6 0 78 E6 6 E0
------ Writing frame to wireshark -- sec=20,usec=125000,incl_len=156,orig_len=158
------ done Writing frame to wireshark --------- rd_idx=382

report abuse
vote down
vote up
Votes: +0
...
written by Dave, March 08, 2012
I'm uploading the code with the Arduino 1.0 IDE. In Tools -> Board, the board type can be selected. Do I need to specify a specific boardtype for the freakduino? or will every board with an atmega328p do?
report abuse
vote down
vote up
Votes: +0
...
written by Akiba, March 08, 2012
Ahh...the board type is important. You need to use Arduino Pro or Pro Mini (3.3V, 8 MHz) w/ATMega328. If you're using a different board setting, chances are you have the wrong baudrate. Most of the other board types use a 16 MHz clock so the baud rate is actually twice as fast as the setting.
report abuse
vote down
vote up
Votes: +0
...
written by Dave, March 09, 2012
Hi Akiba,

Well that did the job. Now it works like a charm. It did cost me a lot of hours. I feel stupid, this is such a basic error. While I've been through a lot of pages on your site I've didn't found the IDE settings telling me what board to use. Maybe this could also be the solution for other people who got the "Frame X too long (-2 bytes)" error. Anyway due to the problem I jump started into freakduino. The other minor problem, the freakduino not keeping its code after a powering cycle, is still not solved. Anyway, thanks for building this great solution and the great support. I will show my satisfaction by ordering new stuff from you soon smilies/smiley.gif
report abuse
vote down
vote up
Votes: +0
...
written by Akiba, March 09, 2012
Ha ha ha. It's in the User Manual documentation in the "Uploading Code" section and also in the "Troubleshooting" section. But don't worry about it. I think most people don't read the docs including people in Tokyo Hackerspace who were the original reason I designed the board. I just had trouble figuring out this was your problem from the initial description.
report abuse
vote down
vote up
Votes: +0
...
written by ChrisU, August 21, 2012
Hello,

Thanks for the great project.

There is a bug in the v0.51 linux version: the struct termios used to configure the terminal is uninitialized. This can lead to erratic behavior, such as IGNCR being set and so all 0x10 bytes being swallowed.

Here's a patch to resolve the issue:

--- orig/wsbridge/Linux/main.c 2011-05-19 11:50:32.000000000 -0700
wsbridge/Linux/main.c 2012-08-16 12:30:30.398323016 -0700
@@ -100,6 106,12 @@
}
else
{
if (tcgetattr(FD_com, &term;smilies/wink.gif) {
perror("serial_open: tcgetattr");
close(FD_com);
return -1;
}

// set speed of port
cfsetspeed(&term;, BAUDRATE);

@@ -109,6 121,10 @@
term.c_cflag &= ~CSIZE;
term.c_cflag |= CS8;

term.c_iflag &= ~INLCR;
term.c_iflag &= ~IGNCR;
term.c_iflag &= ~ICRNL;

term.c_cflag |= (CLOCAL | CREAD);
tcsetattr(FD_com, TCSANOW, &term;smilies/wink.gif;
report abuse
vote down
vote up
Votes: +0
linux wsbridge usage
written by ElectricEschaton, November 11, 2012
Greetings Akiba. You are a super star!

I write this as an inquiry about the above comment by ChrisU. Has this issue been resolved in the official files for download or are we expected to edit in the above code into main.c .

I love my freakduino chibi! Akiba is a superstar!
report abuse
vote down
vote up
Votes: +0
footer on wireshark
written by Dos santos, September 10, 2014
Hi!

I made a wismote sniffer (contiki OS and CC2520 chip) and I want to analyze frames on wireshark-1.6.0 on debian6. So I used your bridge adapted for my sniffer. My problem is wireshark doesn't display the footer (it displays all the fields but not the footer, it only check the CRC) and I need its for future analyse. Have you any ideas about how display it? Do you think the problem comes of wireshark dissectors or the bridge?

Thanks!
report abuse
vote down
vote up
Votes: +0

Write comment

busy