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 Votes: +0

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]. Votes: +0

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. Votes: +0

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.
Votes: +1

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. Votes: +0

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? Votes: +0

I am idiot..it is written at the top of this page ...sorry .....raw 802.15.4 data frames are output via serial port (virtual COM port) to WSBridge which feeds them into Wireshark Votes: +0

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;;

tcsetattr(FD_com, TCSANOW, &term;;
}

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!
Votes: +0

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
Votes: +0

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. Votes: +0

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?
Votes: +0

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.
Votes: +0

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!

Votes: +0

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. Votes: +0

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 Votes: +0

Can it maybe caused by the serial port settings. I left this the default (115200, Parity.None, 8, StopBits.One) Votes: +0

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

Votes: +0

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? Votes: +0

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 Votes: +0

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;) {
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;;
Votes: +0

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! Votes: +0