> Hey guys...don't know if this would be the right place to ask about this but
> I figure you can probably help me or point me in the right direction.
>
> I am working on a project that interacts with a lot of alternative devices
> (proprietary modems,etc) that speak some of the common protocols (IP, TCP,
> UDP,etc) and was wondering how difficult is it to support these devices.
>
> Is it just as simple as putting /dev/my_modem or /dev/modem for the device
> to capture from?
No.
Ethereal currently captures using libpcap, which only captures from
devices the OS thinks of as networking devices.
If you're talking over a serial port that's *not* plugged into the OS's
PPP networking driver - for example, if some code is just opening
"/dev/modem" and writing data to and reading data from it, independently
of the OS's networking stack - libpcap won't help you.
> Would this be something that I would need to look more to the libpcap and/or
> tcpdump guys?
If you wanted to get libpcap to support stuff other than
networking devices, yes. Whether they'd be amenable to that is another
matter.
> And along those lines, are there any mailing lists relating
> to these two products?
tcpdump-workers@xxxxxxxxxxx, although, in order to mail to it, you have
to subscribe to it.
See
http://www.tcpdump.org/
> Ethereal uses libpcap
Correct.
> which outputs to tcpdump format correct?
Correct - *but* we use only libpcap's mechanism for supplying us with
packets from a capture device; we don't use its mechanism for writing
packets to a file, we use our own, which is capabile of writing tcpdump
format *and* some other formats.
> Other than
> the common library, it does not rely on tcpdump for anything correct?
Correct. We're an separate packet analyzer from tcpdump.
> When we are capturing data, all the packets in question are sent to a dump
> file. In the dump file the individual information is timestamped by the
> capturing (not the actuall packets).
The time stamp on a packet is the time stamp supplied by libpcap, which
is the time that the OS received (note that, as we run in promiscuous
mode, we may "receive" packets not intended for the machine on which
we're running) or transmitted the link-layer packet.
> I have used a little bit the "Follow the TCP" functionality and was
> wondering if something along those lines is possible with IP and/or UDP.
It depends on what sort of "something along those lines" you want.
In the case of TCP, the sequence numbers impose an order on packets that
isn't necessarily the order in which they appear on the wire; "Follow
TCP Stream", when it constructs the payload display, puts stuff into the
display based on sequence numbers, not on time stamps.
Neither IP nor UDP have any such notion; packets may show up on the wire
in some order other than the order in which the sending
application/protocol delivered them to the UDP or IP code for
transmission, and there's no way the UDP or IP code can put them back in
the right order.
> How does it indentify the start and end of the TCP stream. I am guessing
> that is ultimately part of the TCP packet header informatio, correct?
Correct.
There are actually two TCP streams - the order of the data within each
stream is based on the sequence numbers, but there's no
sequence-number-based ordering between packets in one direction and
packets in the other (except maybe based on ACKs).
The start of a stream is the packet with the SYN bit set; a TCP
connection is set up by:
connector sends a packet with SYN;
connectee responds with a packet with SYN, and with ACK to
acknowledge receipt of the connector's SYN;
connector responds with a packet with ACK to acknowledge receipt
of the connectee's SYN.
The end of a stream is the packet with the FIN bit set; to close one of
the streams (a connection can be open in one direction but not in the
other), the sender sends a packet with FIN, meaning "I have no more data
to send to you after the data in this segment", and the recipient
responds with an ACK.
