Process pcapng file with multiple interfaces

When processing pcapng file which have multiple interfaces, you may meet following errors:

pcap_next_ex() [an interface has a snapshot length 262144 different from the type of the first interface]

Then capinfos shows you there are multiple interfaces with different capture lengths:

$ capinfos test.pcapng
File name:           test.pcapng
File type:           Wireshark/... - pcapng
......
Number of interfaces in file: 2
Interface #0 info:
                     Encapsulation = Ethernet (1 - ether)
                     Capture length = 1600
                     Time precision = microseconds (6)
                     Time ticks per second = 1000000
                     Number of stat entries = 0
                     Number of packets = 2474
Interface #1 info:
                     Encapsulation = Ethernet (1 - ether)
                     Capture length = 262144
                     Time precision = microseconds (6)
                     Time ticks per second = 1000000
                     Number of stat entries = 0
                     Number of packets = 13

One solution is to convert the pcapng to pcap file, then libpcap can process it:

tshark -F pcap -r test.pcapng -w test.pcap

Create pcap file with all RTP header fields

I want to test my decoding RTP header code with a pcap file with all fields, but unfortunately, I can’t find one, and all lack CSRC and Header extension. So I made an artificial one. The code and original pcap file can be checked here, and beware that I hard-coded the 5th packet with be modified.

Build tshark on CentOS 7

I want to build & debug tshark on CentOS 7 (No need GUI), and the first step is installing cmake3:

$ sudo yum install cmake3

Create a build directory under Wireshark source code, and Run following commands:

$ cd build
$ cmake3 -DBUILD_wireshark=OFF -DCMAKE_BUILD_TYPE=Debug ..
$ make

That’s it!

References:
How to build and install tshark without Wireshark?;
Wireshark docs.

Enhance libunwind on illumos

In my last post, I mentioned that I used libunwind to debug a memory leak issue recently. I actually run this program on illumos too, but unfortunately met following errors:

$ cat /tmp/backtrace.log
0x401b3b: -- error(unspecified (general) error): unable to obtain symbol name for this frame
0x401b47: -- error(unspecified (general) error): unable to obtain symbol name for this frame
0x401b5e: -- error(unspecified (general) error): unable to obtain symbol name for this frame
0x401757: -- error(unspecified (general) error): unable to obtain symbol name for this frame
0x4016b8: -- error(unspecified (general) error): unable to obtain symbol name for this frame

I used gdb to do single-step debug, then found the libunwind illumos implementation just reuses the Linux APIs:

......
#include "os-linux.h" // using linux header for map_iterator implementation
......

On Linux, the map file is /proc/$pid/maps, but on illumos, the file is /proc/$pid/map. Hmm, the first step is wrong, then no need to progress further.

I tried to see what is in /proc/$pid/map:

$ cat /proc/$$/map
cat: input error on /proc/511/map: Value too large for defined data type

cat couldn’t help. Then resorted to vim:

$ vim /proc/$$/map
^@^@@^@......

Just messy code. Now that it is not plain test, how to decrypt it? Aha, since pmap can display it correctly:

$ pmap $$
511:    -bash
0000000000400000        828K r-x--  /usr/bin/bash
00000000004DE000         20K rw---  /usr/bin/bash
00000000004E3000         60K rw---  /usr/bin/bash
0000000000F09000       1872K rw---    [ heap ]
FFFFFC7FEC110000          4K rwx--    [ anon ]
......

Let me check pmap implementation. After going through pmap code, I found I should use libproc APIs to extract related information. I referred the code from pmap and implemented a total new tdep_get_elf_image API, and it worked:

$ cat /tmp/backtrace.log
0x401b3b: (foo+0x9)
0x401b47: (bar+0x9)
0x401b5e: (main+0x14)
0x401757: (_start_crt+0x87)
0x4016b8: (_start+0x18)

I submitted a Pull Request as well, and hope it can be finally merged.