On Fri, Feb 16, 2001 at 01:35:15PM -0800, Faisal Zakaria Siddiqi wrote:
> Where in the printing code does tcpdump print ">" or "<"
> depending upon incoming or outgoing packet?
In "print-sll.c"; only the fake header used for the "any" device on
Linux 2.2 and later kernels contains an incoming/outgoing indication
that tcpdump reports. (Some versions of PPP may supply that, but
tcpdump doesn't currently print that.)
The only OSes I know of where the packet capture mechanism supplies
packet indicators of that sort are:
Linux (where it's actually more than just "incoming vs.
outgoing" - the possibilities are:
packet was sent to us
packet was broadcast by somebody else
packet was multicast by somebody else
packet was sent by somebody else to somebody else and we
saw it because we were in promiscuous mode
packet was sent *by* us)
Digital UNIX/Tru64 UNIX (where it's not "incoming vs. outgoing"
- the per-packet header supplied by the OS includes flags
specifying
packet was sent to somebody else and we saw it because
we were in promiscuous mode
packet was broadcast by somebody else
packet was multicast by somebody else
and presumably if none of those are set it was either sent to us
by somebody else or sent by us to somebody else - I see nothing
to indicate whether it was sent by us or received by us)
IRIX (where it's not "incoming vs. outgoing" - the per-packet
header supplied by the OS includes flags that specify
packet was not destined for this interface - I don't
know whether that applies to packets sent by this host
or not, assuming that IRIX "snoop" sockets see packets
sent by the host)
There is a comment in the tcpdump "print-fddi.c" that indicates that
the folks at LBL considered adding a similar mechanism to BPF:
* Based in part on code by Van Jacobson, which bears this note:
*
* NOTE: This is a very preliminary hack for FDDI support.
* There are all sorts of wired in constants & nothing (yet)
* to print SMT packets as anything other than hex dumps.
* Most of the necessary changes are waiting on my redoing
* the "header" that a kernel fddi driver supplies to bpf: I
* want it to look like one byte of 'direction' (0 or 1
* depending on whether the packet was inbound or outbound),
* two bytes of system/driver dependent data (anything an
* implementor thinks would be useful to filter on and/or
* save per-packet, then the real 21-byte FDDI header.
* Steve McCanne & I have also talked about adding the
* 'direction' byte to all bpf headers (e.g., in the two
* bytes of padding on an ethernet header). It's not clear
* we could do this in a backwards compatible way & we hate
* the idea of an incompatible bpf change. Discussions are
* proceeding.
*
* Also, to really support FDDI (and better support 802.2
* over ethernet) we really need to re-think the rather simple
* minded assumptions about fixed length & fixed format link
* level headers made in gencode.c. One day...
*
* - vj
but that was never done.
> In other words how can I know if a captured packet is incoming or outgoing.
Check the destination MAC address, and compare it against the address or
addresses on the interface on which the packet was received.
-
This is the TCPDUMP workers list. It is archived at
http://www.tcpdump.org/lists/workers/index.html
To unsubscribe use mailto:[EMAIL PROTECTED]?body=unsubscribe
