Tuesday, November 18, 2008

How to count number of bits set in a DWORD

This small function is very useful in the industrial automation field and any low level program in C/C++. You also can find the exactly same one on the Internet. Here I would like to share one of the widely used function, and it's complexity. I will post more algorithms later and do a comparison.
Complexity : O(n) Where n = number of bits set in the DWORD actually.

An approach to sniff packets without having a hub

As everybody knows, when you are designing a brand new protocol, you probably want to have a protocol analyzer to test if you send all of packets correctly. Usually, we have a very good protocol analyzer: Wireshark. It is open source, cross-platform, and it's free to use. But there are some limitations for Wireshark:
1. It doesn't allow you to define your own protocol. If you are designing a new protocol, it won't help you any more.
2. It only captures packets locally. If you don't have a hub, you can only get packets destined to your machine or broadcast packets. And, it is very hard to get a hub now.
3. It's not possible to run Wireshark on an embedded device.

Now, it's time to create your own packet sniffer when you really get stuck.

We can use client/server architecture, put our sniffer to where you want to listen, as a server. We can use our client on any Linux box to connect to our server. The architecture is as follow:

Let's assume that the Server and the embedded Linux devices are our application environment. All embedded Linux devices communicate with the server and there is no human interfaces on both sides (Server and all embedded devices). Our sniffing system includes a spy daemon which can reside in all of entities including the server and all devices. It depends what are you interested in. For example, if you only want to get packets going through one of the device, you can load the spy daemon on the device which you are interested in. If you want to see all packets going through all devices and the server, you should load the spy daemon into the server machine.

Next we need to connect our client program to one of the spy daemon. The spy daemon uses the libpcap library to catch packets locally and in my case, I am using callback mechanism in libpcap library. When the library routine gets a packet from the data link layer, the packet will be passed to the registered call back function. In the call back function, the captured packet will be wrapped up and sent to any connected client though TCP connection. The whole captured packet will be sent as a payload of TCP.

The client program is a QT based GUI tool which shows you any captured packets in exactly the same way as Wireshark does. Here why I choose QT is that I can create a GUI application very quickly, and it's cross-platform. In this little tool, I use QTNetwork module to receive captured packets from the spy, and send all packets as a signal to the main GUI thread for display. Here is a screen shot of the client:

By the way, this client tool also has the capability to send out packets with spoofed source Ip address, and the users are able to edit what they want to send. Here is the screenshot:

Thursday, November 6, 2008

Remote debugging – an approach to debug embedded programs

In most cases, developers debug their programs locally. They run their code with debugger on the same machine. What if there is no mouse and keyboard on the target machine, such as a device, a POS terminal with a touch screen? You also want to see what happened behind the scene right? Remote debugging can give you the capability to do such a thing. I have an example which I have used for almost half a year and willing to share with you all.

This example is based on Linux ( Embedded Linux for the target machine, any Linux distribution for the debugger )

System requirement:

Target machine: gdbserver and the target application on Linux

Debugger machine: ddd with any Linux distribution

Steps to do:

Target machine: ( You need to have your app on this machine )

  1. ssh to the target machine

  2. gdbserver TARGET_IP:PORT TARGET_APP

Debugger machine: ( You need to have both source code and executable on this machine )

  1. ddd TARGET_APP

  2. In ddd command line, connect to the target:
    target remote TARGET_IP:PORT
    Turn off the following signals:
    handle SIG32 noprint nostop
    handle SIGPIPE noprint nostop
    handle SIGTRAP noprint nostop

  3. On the tool box of ddd, press CONT button to start the program

Now, you should be able to debug your program remotely.