Packets capturing with ASUS SL1200
Frames capturing by sniffers has become a good tradition in the network engineers’ community. Probably, the most commonly used network analyzer is Ethereal, which was renamed into Wireshark in 2006. But there are some conditions when using a computer or a notebook with such programs is impossible, so traffic capturing for the further analyzing can be made via internal functions in some routers. For this purpose Asus SL1200 can be used. This functionality is accessible in the command prompt only (telnet or console port). It is significant that SL1200 is not a full-function hardware sniffer, but the router. It means that packets capturing is an additional function and cannot be considered as a complete solution. Packets capturing with logins and passwords (Telnet, FTP, IRC etc) is the main aim this device can be used for. The user periodically resends such packets, so sooner or later these packets would be captured.
We used PuTTy (version 0.6) for accessing to the console-port. Also we used a computer with Microsoft Windows Vista, so all used programs were windows-based.
The traffic capturing function can be enabled or disabled. This can be done in the privileged mode via commands “deb s” and “no deb s”.
Printing captured data can be produced into the telnet-session or console-port. You can use command “sho p” in the privileged mode for viewing traffic. One captured frame from the WAN-port is shown below.
We have copied captured data from the PuTTy window into the text-file one_frame_original.txt and now we are going to modify this file to make it understandable for Wireshark. Let’s open it in Microsoft Word.
Let’s replace all paragraph marks with space symbols. So we have just one line in the file, which contained captured data. Each byte was two hex digests. Such “bytes” were separated by spaces.
For the further conversion let’s determine all demands for the text2pcap.exe utility, which is embedded in the Wireshark install package. These demands are listed in the help-file text2pcap.html
It’s necessary to insert a number correspond with a displacement in the file into each line. As we have only one frame, it’s enough to add «000000» in the very beginning of the file. Corrected data is in the file one_frame_edited.txt.
Now it’s time to run text2pcap.exe utility for the final file conversion from text format to Wireshark binary.
File one_frame.bin is ready for analyzing now, let’s open it via Wireshark.
Well, we have converted one frame. But it’s too monotonous to convert data packet by packet, so we decided to convert several Ethernet frames simultaneously. At first, we tried to receive data via console (by analyzing PuTTy log-file putty_original.log). We trimmed PuTTy log-file so that there were only frame records and then we added first empty line (putty_edited_lite.log).
We used system command «find /V "ID" putty_edited_lite.log > putty_edited.log» in the directory with the file putty_edited_lite.log for the strings with the information about packets deleting, for example such strings as “ID = 158, Captured from LAN, Packet size = 242”. The beginning of this file is listed below.
Let’s remove the record «---------- PUTTY_EDITED_LITE.LOG» and two empty lines from the file beginning. New file putty_edited.log we opened in the text processor Microsoft Word and replaced all doubled paragraph marks by manual line breaks. Then we deleted single paragraph marks and then replaced line feeds by groups, contained “displacement” (000000) and paragraph mark, which are needed for the correct work of the text2pcap.exe utility. First string should be corrected manually.
So we got a file for conversion to TCPDUMP format. We converted it as shown above. If the whole work was done correctly then the output of the text2pcap.exe would look like the text shown below.
After such conversion the file putty_edited.bin appeared. Let’s open this binary-file in Wireshark.
The only problem we faced during the data transmission via com port is its bandwidth. It’s obvious that speed of 9600 Kbit/s is not sufficient for the realtime data delivering from SL1200 to the computer. Of course this problem can be solved via telnet session, but we can’t consider the efficiency adequate. Let’s try to send captured frames to the server by FTP protocol. Such scheme makes available the script at SL1200 for the automatic data delivering to the FTP server. It’s a pity, we failed to get captured packets otherwise but by command “sho p”, so file /configs/commands.fox was created. It is shown below. This file contains several commands for the console program to show the captured frames.
We used “ps” command, which pointed to the real console application.
To make sure that our suggestion is right we launched the corresponding file with the listed arguments.
Let’s launch the file of the console application and send commands to it, which were written to file (commands.fox) beforehand, and output data would be saved in the file /configs/packets.fox. We use “&” symbol at the command line end for the background mode launching.
As we can see file packets.fox contains captured frames. Now we can send it to the FTP-server.
This file can be edited as shown above.
All listed actions can be produced via Windows scripts only, but we decided not to overload our readers with the details of shell-coding, but to illustrate these procedures using well-known text processor.
During capturing telnet or FTP data transmission, we had to turn off the sniffer because this session would be captured too. It can be avoided manually (by script of course) by captured-data file editing, but it looks as an exhausting work. Also sniffer buffer must be cleared by console command “cle b” in the privileged mode after each file transmission.
So, it is important to emphasize that even the problem of packets capturing can be solved with the help of SL1200 it should be kept in mind that this device is first and foremost a router and cannot be used as a a full functional sniffer.
The author would like to thank Homutov Vladimir for his invaluable technical help over the whole life of the project. I would also like to acknowledge the help of Andreeva Maria, who corrected the english version of the article.