Re: [Ethereal-dev] Issues reading from a pipe

[Michael Tuexen <Michael.Tuexen@xxxxxxxxxxxxxxxxx>]

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