Thanks a lot, Micheal, reading from a pipe is now working. However, I
found quite a few issues with this approach. Some are conceptual,
other are probably just bugs.
What I do is this: in the network application, I write every packet
that comes in or goes out to a UDP port on my development machine. On
the development machine, I capture the data and pipe it into ethereal.
My C code is:
static void trace_all_data(uint8 direction, const uint8 *msu, uint16 msu_len)
{
static uint8_t buf[2000];
struct timeval ts; /* time stamp */
struct pcap_pkthdr {
uint32_t time_high;
uint32_t time_low;
uint32_t caplen; /* length of portion present */
uint32_t len; /* length this packet (off wire) */
} hdr;
printf("Trace %i bytes\n", msu_len);
assert(msu_len < 1000);
gettimeofday(&ts, NULL);
hdr.time_high = ts.tv_sec;
hdr.time_low = ts.tv_usec;
hdr.caplen = msu_len;
hdr.len = msu_len;
memcpy(buf, &hdr, sizeof(hdr));
memcpy(buf + sizeof(hdr), msu, msu_len);
trace_all_send(buf, sizeof(hdr) + msu_len);
}
where trace_all_send() puts it on the network socket. Then I do (in
bash syntax):
ethereal -k -i <(cat /tmp/header <(nc -u -l -p 1234)) ; killall -9 nc
which works like a charm. If you want to debug a networking
application and can't capture the interface, this is the way to go :-)
But there are some problems, too.
1. Reading from a pipe does not work with a recent ethereal. At least
it is broken in debian version 0.10.11-1 (libpcap 0.8.3). It does work
with my home compiled version 0.10.5 with debian libpcap 0.7.2. The
error is "Error reading from pipe: Bad address" at receiving the first
packet. Is this a debian bug? a libpcap bug? an ethereal bug?
2. Obviously, you can't start another capture, without restarting cat
to get a new header. That is quite annoying. Any idea to get a
"headerless" format? If it were legal to include the file header
before every packet, I would do so, but it does not work.
3. I can't specify the direction of the packet: coming or going. Is
there a way to include that information in the trace? I guess there
would be a wrapper for it, like the linux pseudo device creates it.
Where is that documented?
4. I think it would be very convenient if Ethereal could connect to a
network port and read the trace from there. Pipe or socket is not a
big different for reading, and the connection code should not be
difficult to write either. This could also solve the restart problem.
5. Libpcap has a 64bit bug. It uses struct timeval ts in the file
header, while contains two "long" variables. On a 64bit system, these
are going to be 64bit. So libpcap should use uint32_t, as shown above.
Any ideas concerning these? I am not personally worried about 4 and 5,
but if I could solve 1-3, that would be very useful.
Thomas