Hi Thomas,
see my comments in-line.
Best regards
Michael
On Jun 28, 2005, at 11:41 AM, Thomas Steffen wrote:
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?
There are bugs in 0.10.11 regarding reading from pipes. These
should be fixed in the svn. Could you try that version?
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.
You need a file header and a packet header. That is the libpcap format.
Probably you should write a simple application wich reads the UDP
packets and write them in libpcap format.
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?
No. In the standard libpcap format there is no field for it...
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.
The Winpcap guys have implemented such a feature.
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.
It would be better to post this to the libpcap list.
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
_______________________________________________
Ethereal-dev mailing list
Ethereal-dev@xxxxxxxxxxxx
http://www.ethereal.com/mailman/listinfo/ethereal-dev
