[tcpdump-workers] print_llc code question
Hi,
Maybe the following question is pretty obvious but since I'm not an
802.2/LLC expert, I can't find a response for it.
I was reading print_llc.c code and in llc_print() function, I found
something that I don't really understand.
At lines 247 to 251, one has :
if (ssap == LLCSAP_IP && dsap == LLCSAP_IP &&
control == LLC_UI) {
ip_print(gndo, p+4, length-4);
return (1);
}
Why is ip_print() called with p+4 and length-4 when just a few lines
above for the LLCSAP_8021D case or a few lines below for the LLCSAP_IPX
case, we have stp_print(p+3, length-3) and ipx_print(p+3, length-3)
respectively?
The control field is 1 byte long in this case, isn't it? The LLC header
should be only 3 bytes long, so I don't understand why it's not
ip_print(gndo, p+3, length-3). What's the reason for the extra byte?
Thank you for your help.
J-L Charton
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.
[tcpdump-workers] bpf.tcpdump.org
Last week I moved bpf.tcpdump.org to a machine at my new employer, credil.org.
Alas, IP address mgmt not what it should be, the wrong one was assigned
to me. It has been fixed in DNS, and the old IP will get removed
tomorrow.
Nothing else has changed... I hope that everyone fails to notice
this issue, or also fails to notice that the machine doesn't go offline
now and then.
--
] He who is tired of Weird Al is tired of life! | firewalls [
] Michael Richardson, Sandelman Software Works, Ottawa, ON|net architect[
] m...@sandelman.ottawa.on.ca http://www.sandelman.ottawa.on.ca/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [PATCH] Re: [tcpdump-workers] Bug: Counting dropped packets in
On Aug 30, 2009, at 8:26 PM, Stephen Donnelly wrote: The current 'drop' count in libpcap is not intuitive, and frequently arguably undercounts since it does not include 'rx buffer overflow' and similar interface/OS specific packet loss. OTOH, the documentation is quite clear about what it does count I think. I would not recommend changing the definition or Linux implementation at this point. It would change the behaviour for existing applications and would only cause further confusion. Counting interface drops in ps_drop would definitely be wrong, because it doesn't do so on other platforms, and there's already a ps_ifdrop field to count interface drops. I think the current libpcap statistics interface is not very useful because it is underspecified and varies too much between platforms. Hopefully for pcap-ng (the portable packet capture library, not the file format) we can get a better live statistics interface which is more tightly defined and can conserve meaning across platforms. We should add to libpcap an API that supplies a pcap-ng Interface Statistics Block, so that 1) it can supply only those statistics that are available on the platform in question, explicitly indicating which ones it's supplying; 2) the set of statistics it supplies can be extended (so we don't have to anticipate, when we initially design the API, all possible packet statistics that could ever be obtained from any current or future platform and that an application would want); 3) we don't end up with two *separate* ways of doing that, requiring that a "libpcap interface statistics block" be translated to a "PCAP- NG Interface Statistics Block" before being written to a file. - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [PATCH] Re: [tcpdump-workers] Bug: Counting dropped packets in linux
On Aug 28, 2009, at 1:24 PM, Dustin Spicuzza wrote: Dustin Spicuzza wrote: So after reading the libpcap and kernel source, I see that this is actually how its supposed to work. But it *seems* like it would be quite nice if we could grab the interface driver drop statistics as well as drops resulting from the capture buffer filling up. I'm looking for a way to query the kernel about this number -- should I bother submitting a patch if I can get it, or is the current behavior more desired? It appears that the only way to get this number is by looking at /proc/stats/dev, so I added something that can parse it for the correct interface, and get the drop stats from there. Since those are cumulative over the boot time of the system, it stores a number and does incremental updates of the number. It doesn't do this when not in promiscuous mode however, since that doesn't make any sense. It works for me, let me know what you think. I think that + handle->md.stat.ps_drop += (handle->md.proc_dropped - if_dropped); and + stats->ps_drop = handle->md.stat.ps_drop; are wrong, because ps_drop is supposed to reflect the number of packets dropped by the packet capture mechanism because they arrived faster than the app could consume them, but not the number of packets dropped by the adapter or adapter driver before they even made it to the capture mechanism. ps_ifdrop is for the latter (and the comment about it being unimplemented is false on Tru64 UNIX, for example, so don't let that comment scare you off). - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] [PATCH 1/3] Add getnameinfo support to getname
On Sun, Aug 30, 2009 at 06:54:34PM -0700, Guy Harris wrote: > What's the advantage to using getnameinfo() rather than gethostbyaddr(). I'm not sure there are any real advantages, it's just that gethostbyaddr() is marked as obsolete on some systems. -- Miroslav Lichvar - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [PATCH] Re: [tcpdump-workers] Bug: Counting dropped packets in
Stephen Donnelly wrote:
> Dustin Spicuzza wrote:
>
>>> So after reading the libpcap and kernel source, I see that this is
>>> actually how its supposed to work. But it *seems* like it would be quite
>>> nice if we could grab the interface driver drop statistics as well as
>>> drops resulting from the capture buffer filling up.
>>>
>>> I'm looking for a way to query the kernel about this number -- should I
>>> bother submitting a patch if I can get it, or is the current behavior
>>> more desired?
>>
>> It appears that the only way to get this number is by looking at
>> /proc/stats/dev, so I added something that can parse it for the correct
>> interface, and get the drop stats from there. Since those are cumulative
>> over the boot time of the system, it stores a number and does
>> incremental updates of the number. It doesn't do this when not in
>> promiscuous mode however, since that doesn't make any sense.
>>
>> It works for me, let me know what you think.
>
> The current 'drop' count in libpcap is not intuitive, and frequently
> arguably undercounts since it does not include 'rx buffer overflow' and
> similar interface/OS specific packet loss. OTOH, the documentation is
> quite clear about what it does count I think.
No, its not; its actually quite vague. From the man page:
"pcap_stats() fills in the pcap_stat structure pointed to by its second
argument. The values represent packet statistics from the start of the
run to the time of the call."
The code has a few comments as to what it counts, and *that* is quite
clear. However, I would imagine not too many people will read that
unless they're using pcap from source.
And, after looking at it, there *is* support for drops by the interface
in pcap_stat(), its just currently not used by very many platforms. I
didn't see this previously, but looking at pcap.h:
/*
* As returned by the pcap_stats()
*/
struct pcap_stat {
u_int ps_recv; /* number of packets received */
u_int ps_drop; /* number of packets dropped */
u_int ps_ifdrop;/* drops by interface XXX not yet
supported */
#ifdef WIN32
u_int bs_capt; /* number of packets that reach the
application */
#endif /* WIN32 */
};
So... I've changed my patch to populate ps_ifdrop instead, and it should
be good to go, without screwing with current applications. I suppose the
man page should be updated to mention that ps_ifdrop is only supported
on a few platforms (I noticed that grep shows one or two instances where
it is used).
Dustin
--
Innovation is just a problem away
diff --git a/pcap-int.h b/pcap-int.h
index a548220..5786ea5 100644
--- a/pcap-int.h
+++ b/pcap-int.h
@@ -139,6 +139,7 @@ struct pcap_md {
u_int tp_version; /* version of tpacket_hdr for mmaped ring */
u_int tp_hdrlen; /* hdrlen of tpacket_hdr for mmaped ring */
u_char *oneshot_buffer; /* buffer for copy of packet */
+ longproc_dropped; /* packets reported dropped by /proc/net/dev */
#endif /* linux */
#ifdef HAVE_DAG_API
diff --git a/pcap-linux.c b/pcap-linux.c
index 25208f6..c529d56 100644
--- a/pcap-linux.c
+++ b/pcap-linux.c
@@ -891,6 +891,60 @@ pcap_can_set_rfmon_linux(pcap_t *handle)
return 0;
}
+/* grabs the number of dropped packets by the interface from /proc/net/dev */
+static
+long int linux_if_drops(const char * if_name)
+{
+ char buffer[512];
+ char * bufptr;
+ FILE * file;
+ int field_to_convert = 3, if_name_sz = strlen(if_name);
+ long int dropped_pkts = 0;
+
+ file = fopen("/proc/net/dev", "r");
+ if (!file)
+ return 0;
+
+ while (!dropped_pkts && fgets( buffer, sizeof(buffer), file ))
+ {
+ /* search for 'bytes' -- if its in there, then
+ that means we need to grab the fourth field. otherwise
+ grab the third field. */
+ if (field_to_convert != 4 && strstr(buffer, "bytes"))
+ {
+ field_to_convert = 4;
+ continue;
+ }
+
+ /* find iface and make sure it actually matches -- space before
the name and : after it */
+ if ((bufptr = strstr(buffer, if_name)) &&
+ (bufptr == buffer || *(bufptr-1) == ' ') &&
+ *(bufptr + if_name_sz) == ':')
+ {
+ bufptr = bufptr + if_name_sz + 1;
+
+ /* grab the nth field from it */
+ while( --field_to_convert && *bufptr != '\0')
+ {
+ while (*bufptr != '\0' && *(bufptr++) == ' ');
+ while (*bufptr != '\0' && *(bufptr++) != ' ');
+ }
+
+ /* get rid of any final spaces */
+ while (*bufptr != '\0' && *bufptr == ' ') bufptr
Re: [tcpdump-workers] print_llc code question
On Sep 1, 2009, at 6:55 AM, Jean-Louis CHARTON wrote:
Maybe the following question is pretty obvious but since I'm not an
802.2/LLC expert, I can't find a response for it.
I was reading print_llc.c code and in llc_print() function, I found
something that I don't really understand.
At lines 247 to 251, one has :
if (ssap == LLCSAP_IP && dsap == LLCSAP_IP &&
control == LLC_UI) {
ip_print(gndo, p+4, length-4);
return (1);
}
Why is ip_print() called with p+4 and length-4 when just a few lines
above for the LLCSAP_8021D case or a few lines below for the
LLCSAP_IPX
case, we have stp_print(p+3, length-3) and ipx_print(p+3, length-3)
respectively?
The control field is 1 byte long in this case, isn't it? The LLC
header
should be only 3 bytes long, so I don't understand why it's not
ip_print(gndo, p+3, length-3). What's the reason for the extra byte?
I don't know.
Hannes Gredler added that code in 2002:
revision 1.51
date: 2002-11-13 08:08:39 -0800; author: hannes; state: Exp;
lines: +6 -1;
added processing of LLC_SAPIP
RFC 948, "Two methods for the transmission of IP datagrams over IEEE
802.3 networks", describes, well, two methods for the transmission of
IP datagrams over IEEE 802.3 networks. The first of them is "transmit
them the standard Ethernet way, because for all type fields with
values > 1500, you can tell the difference between an "Ethernet II"
packet and an "802.3" packet by looking at the value of the type/
length field. The second of them is "use 802.2 and a DSAP and SSAP
for IP"; it says:
IP datagrams are transmitted in standard 802.2/802.3 LLC Type 1
Unnumbered Information format with the DSAP and SSAP fields of the
802.2 header set to 96, the IEEE assigned global SAP value for IP
[8]. The data field contains the IP header followed immediately by
the IP data.
and later seems to indicate that the old Ethernet way will go away in
favor of the 802.2 way. In reality, of course, that didn't exactly
happen
As for non-Ethernet networks using 802.2, RFC 1042, "Standard for the
transmission of IP datagrams over IEEE 802 networks" replaced that
scheme with a scheme using SNAP headers with the standard Ethertype
for IP.
So I don't know who actually *used* an 802.2 header without a SNAP
header when sending IP datagrams.
In any case, that seems to indicate that you'd have a standard 3-octet
802.2 LLC Type 1 UI header, followed *immediately* by the IP packet.
Hannes? Was somebody adding an extra byte in there? Perhaps they
were the *only* people using an 802.2 header without a SNAP header to
transmit IP datagrams, so, even if they weren't doing it the way RFC
948 implied they should, they're the only implementation that actually
matters. (This might be the first time anybody noticed the extra
byte; perhaps that's another indication that next to nobody ever sent
IP datagrams out with an 802.2 header and no SNAP header.)
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.
