[tcpdump-workers] dealing with collisions, dropped packets
Hi all, Recently I've been investigating why tcpdump on my IDS shows quite a few packets as being dropped. I think this is because my traffic to the IDS is fed through a hub where I know there are many collisions (there may be too many packets per second for the little soho 10/100 hub to handle). I'm not sure how tcpdump handles collisions, and so I don't know if this is even a problem or not. Is there a way to get more fine grained statistics on why packets are dropped, and would collisions coming in off a hub be shown as dropped? I'm seeing a traffic feed of roughly 4000-5000 packets per second and about 1000 collisions per minute, so I don't think that the rate of traffic is the cause of my problem. If the dropped packets being displayed are just the collisions from the hub then it's no big deal, but if it's something else I'd like to try and fix it of course. Thanks, Matt - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] dealing with collisions, dropped packets
A few comments: 1) I doubt that collisions are the cause. A collision will actually prevent tcpdump from seeing the packet and reduce the throughput of the network, thus tcpdump should drop fewer packets. 2) You can check the number of collisions on most Unix/Linux boxes using ifconfig. You'll see a collisions counter which will increment over time. Other errors and statistics are also available. Regards, Aaron On Mon, Nov 01, 2004 at 03:01:46PM -0500, Matt Van Mater wrote: > Hi all, > > Recently I've been investigating why tcpdump on my IDS shows quite a > few packets as being dropped. I think this is because my traffic to > the IDS is fed through a hub where I know there are many collisions > (there may be too many packets per second for the little soho 10/100 > hub to handle). I'm not sure how tcpdump handles collisions, and so I > don't know if this is even a problem or not. > > Is there a way to get more fine grained statistics on why packets are > dropped, and would collisions coming in off a hub be shown as dropped? > I'm seeing a traffic feed of roughly 4000-5000 packets per second and > about 1000 collisions per minute, so I don't think that the rate of > traffic is the cause of my problem. > > If the dropped packets being displayed are just the collisions from > the hub then it's no big deal, but if it's something else I'd like to > try and fix it of course. > > Thanks, > Matt > > > - > This is the tcpdump-workers list. > Visit https://lists.sandelman.ca/ to unsubscribe. -- Aaron Turner http://synfin.net/ They that can give up essential liberty to obtain a little temporary safety deserve neither liberty nor safety. -- Benjamin Franklin All emails are PGP signed; a lack of a signature indicates a forgery. signature.asc Description: Digital signature
Re: [tcpdump-workers] dealing with collisions, dropped packets
Matt Van Mater wrote: Recently I've been investigating why tcpdump on my IDS shows quite a few packets as being dropped. Probably because it's receiving so many packets that it can't keep up. Drops, as reported by tcpdump, are drops due to the buffer in the packet capture mechanism overflowing due to tcpdump not being able to read packets fast enough. I think this is because my traffic to the IDS is fed through a hub where I know there are many collisions (there may be too many packets per second for the little soho 10/100 hub to handle). I'm not sure how tcpdump handles collisions, It doesn't. It wouldn't even know about them unless the packet capture mechanism libpcap uses supplies that in a form libpcap can use in "pcap_stats()" (which I'm not sure is the case on any OS), and, even then, it doesn't report the "ps_ifdrop" statistic. If you want to know how many collisions an interface sees, you'd probably have to use some other program that gets a collision count from the network adapter. I also don't know whether it'd report collisions other than those from packets being sent on the adapter. Is there a way to get more fine grained statistics on why packets are dropped, That depends on the OS - there might be a command, or GUI tool, to get those statistics from the driver. and would collisions coming in off a hub be shown as dropped? They wouldn't be reported as dropped by tcpdump. Tcpdump would report only drops due to the buffer in the packet capture mechanism overflowing due to tcpdump not being able to read packets fast enough. As for other programs to report packet statistics, I don't know. A "collision coming in off a hub" is presumably a packet being transmitted by another machine on the network that gets stomped on by some third machine transmitting; I don't know whether an adapter would recognize and report that as a collision other than some other type of packet error, and don't know how they'd be reported. - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] dealing with collisions, dropped packets
> Recently I've been investigating why tcpdump on my IDS shows quite a few > packets as being dropped. I think this is because my traffic to the IDS is > fed through a hub where I know there are many collisions (there may be too > many packets per second for the little soho 10/100 hub to handle). I'm not > sure how tcpdump handles collisions, and so I don't know if this is even a > problem or not. I sense some fundamental misunderstandings here. Basically: A collision on half duplex media (such as a hub) is a *normal* and *expected* occurence, and does *not* cause a packet to be dropped. Note that this does not apply to "late collisions" which are quite different - late collisions are signs of *error* (for instance a duplex mismatch). > Is there a way to get more fine grained statistics on why packets are > dropped, and would collisions coming in off a hub be shown as dropped? I'm > seeing a traffic feed of roughly 4000-5000 packets per second and about 1000 > collisions per minute, so I don't think that the rate of traffic is the > cause of my problem. 1000 collisions per minute with 4000-5000 pps is a very *low* collision rate. > If the dropped packets being displayed are just the collisions from the hub > then it's no big deal, but if it's something else I'd like to try and fix it > of course. I expect your dropped packets are due to something else. But you should definitely check for late collisions. Steinar Haug, Nethelp consulting, [EMAIL PROTECTED] - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] dealing with collisions, dropped packets
-BEGIN PGP SIGNED MESSAGE-
> "Matt" == Matt Van Mater <[EMAIL PROTECTED]> writes:
Matt> Recently I've been investigating why tcpdump on my IDS shows
Matt> quite a few packets as being dropped. I think this is because
Matt> my traffic to the IDS is fed through a hub where I know there
Matt> are many collisions (there may be too many packets per second
Matt> for the little soho 10/100 hub to handle). I'm not sure how
Matt> tcpdump handles collisions, and so I don't know if this is
Matt> even a problem or not.
neither tcpdump nor your NIC card even see the collision.
AFAIK, only transmitters see them, and it causes them to back off and
retransmit.
Matt> Is there a way to get more fine grained statistics on why
Matt> packets are dropped, and would collisions coming in off a hub
Matt> be shown as dropped? I'm seeing a traffic feed of roughly
Well, you need to ask your operating system about that.
tcpdump runs on about a dozen different systems.
- --
] "Elmo went to the wrong fundraiser" - The Simpson | firewalls [
] Michael Richardson,Xelerance Corporation, Ottawa, ON|net architect[
] [EMAIL PROTECTED] http://www.sandelman.ottawa.on.ca/mcr/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.2 (GNU/Linux)
Comment: Finger me for keys
iQCVAwUBQYat7YqHRg3pndX9AQGL3QQApYNeH5nC2/19yhrYFI3yHeqoEEXVKZC7
CwX9AZ34GgyoGY3HLx+G3bLwSoREuOMlK8srGJQqzsTEA7UMGR7lIhsaQk7N9i2g
q9sUbj5jkPYUf2E3Nq/ltOcbEBTBkOBU5nJBkeBj3QslYT4QRtqCpI0np13DPcLd
CJnVBbOvZW0=
=F5+J
-END PGP SIGNATURE-
-
This is the tcpdump-workers list.
Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] dealing with collisions, dropped packets
-BEGIN PGP SIGNED MESSAGE-
> "Aaron" == Aaron Turner <[EMAIL PROTECTED]> writes:
Aaron> 2) You can check the number of collisions on most Unix/Linux
Aaron> boxes using ifconfig. You'll see a collisions counter which
Aaron> will increment over time. Other errors and statistics are
Aaron> also available.
Those are transmit side collisions.
- --
] "Elmo went to the wrong fundraiser" - The Simpson | firewalls [
] Michael Richardson,Xelerance Corporation, Ottawa, ON|net architect[
] [EMAIL PROTECTED] http://www.sandelman.ottawa.on.ca/mcr/ |device driver[
] panic("Just another Debian GNU/Linux using, kernel hacking, security guy"); [
-BEGIN PGP SIGNATURE-
Version: GnuPG v1.2.2 (GNU/Linux)
Comment: Finger me for keys
iQCVAwUBQYau6YqHRg3pndX9AQEb6gQAmMrg4JivUszRgJOsSeOJSe8Tg1EoBDwc
AHPdSnXdmmDHhEmkPBMlPYBYrgBXxAU1ok+ywHZ2SXGuatuFKhGU7PxqWnnnilkx
YV4o9aJyIFs7tkgKwtqweA/7gStoB/YiwSvQOehTj8Lc/brI6BJcy/RD/tzbxOkW
uUlQpNC/ivU=
=v6Qt
-END PGP SIGNATURE-
-
This is the tcpdump-workers list.
Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] Can I excude a protocol?
On Oct 31, 2004, at 6:15 PM, Pete Wilson wrote: although do you want to exclude TCP or exclude everything but UDP (or exclude everything but port-161 and port-162 UDP traffic)? Well, since you ask :-) Yes, sure. Then that's where the If you want to see all UDP traffic to and from particular hosts *on a particular UDP port*, use "(ip host node1 or node2 or node3) and udp port N". If you want, for example, UDP traffic to or from port 161, do "(ip host node1 or node2 or node3) and udp port 161" - but, in that case, you can probably say "udp port snmp" rather than "udp port 161". If you want traffic to or from two particular ports, use "(ip host node1 or node2 or node3) and (udp port port1 or port2)" - which can probably be "udp port snmp or udp port snmptrap" if you want ports 161 and 162. from my earlier message would be used - that'd show only UDP port-161 and port-162 traffic (i.e., only putative SNMP traffic, although there could, I guess, be SNMP traffic on non-standard ports, or non-SNMP traffic on the official SNMP ports). If you want to exclude everything but UDP (which would give you non-SNMP traffic), that's where the If you want to see all *UDP* traffic to and from particular hosts, use "(ip host node1 or node2 or node3) and udp". from my earlier message would be used. - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
[tcpdump-workers] Question about "promiscuous" mode
Hi, Sorry to bother you. I want to know in what situations the machine's network is set to "promiscuous" mode. For example, I know when I execute "tcpdump" on my machine, it's set to be in promiscuous mode. Any other cases? And is it correct that without "tcpcump", the network is not in promiscuous mode? Thanks. xiaofang __ Do you Yahoo!? Check out the new Yahoo! Front Page. www.yahoo.com - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] Question about "promiscuous" mode
Kathy Chen a écrit : Hi, Sorry to bother you. I want to know in what situations the machine's network is set to "promiscuous" mode. For example, I know when I execute "tcpdump" on my machine, it's set to be in promiscuous mode. Any other cases? Yes, that's program's that decide to put your NIC into promicious mode. And is it correct that without "tcpcump", the network is not in promiscuous mode? Depend's on what programs are running on your box. Under linux you can watch to you /var/log/messages to see kernel messages show you when your box enter, or leave promicious mode. Thanks. xiaofang Regards, Seb - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] Question about "promiscuous" mode
Thanks for your reply! xiaofang > >I want to know in what situations the machine's > >network is set to "promiscuous" mode. For example, > I > >know when I execute "tcpdump" on my machine, it's > set > >to be in promiscuous mode. Any other cases? > > > > > Yes, that's program's that decide to put your NIC > into promicious mode. > > >And is it correct that without "tcpcump", the > network > >is not in promiscuous mode? > > > > > Depend's on what programs are running on your box. > Under linux you can watch to you /var/log/messages > to see > kernel messages show you when your box enter, or > leave promicious > mode. > > >Thanks. > >xiaofang > > > > > Regards, > > Seb __ Do you Yahoo!? Check out the new Yahoo! Front Page. www.yahoo.com - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
[tcpdump-workers] Question about "pcap_next()"
Hi, all, When I call u_char *packet = pcap_next(handle, &header); I can get the packet length value, but I can't really get the "packet" data (Using printf(..., packet)). Even if I call this "pcap_next()" continuously, the same problem exist. Could any of you point out the reason for me? From the source code, it seems "recvfrom(...)" should return sth. Thanks. kathy __ Do you Yahoo!? Check out the new Yahoo! Front Page. www.yahoo.com - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] Question about "pcap_next()"
We can't help you without source code. Regards, Seb :) Kathy Chen a écrit : Hi, all, When I call u_char *packet = pcap_next(handle, &header); I can get the packet length value, but I can't really get the "packet" data (Using printf(..., packet)). Even if I call this "pcap_next()" continuously, the same problem exist. Could any of you point out the reason for me? From the source code, it seems "recvfrom(...)" should return sth. Thanks. kathy __ Do you Yahoo!? Check out the new Yahoo! Front Page. www.yahoo.com - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe. - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] Question about "promiscuous" mode
(Blah blah blah once again I forgot to set the from line yes I know I should set up my sonic address as an alias but if I sent from my mit address replies get to me at work and at home so I can respond from either site blah blah blah.) Kathy Chen wrote: I want to know in what situations the machine's network is set to "promiscuous" mode. It's put into promiscuous mode if an application requests that the interface be put into promiscuous mode. For example, I know when I execute "tcpdump" on my machine, it's set to be in promiscuous mode. Only if you run tcpdump without the "-p" flag; the default is promiscuous mode, but "-p" causes tcpdump not to put the interface into promiscuous mode. Any other cases? Ethereal and Tethereal will also put the interface into promiscuous mode by default; you'd have to use "-p" as a command-line argument to Tethereal (or Ethereal, if you start the capture from the command line), or turn off the promiscuous mode option in the Ethereal GUI, not to run in promiscuous mode. Some other applications, such as snoop on Solaris (and possibly some other OSes), or Analyzer (on Windows), or other network analyzers, might put the interface into promiscuous mode as well. And is it correct that without "tcpcump", the network is not in promiscuous mode? No. Another program might put the interface into promiscuous mode. - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] Question about "promiscuous" mode
(Blah blah blah oops I did it again blah blah blah avoid duplicate message detection blah blah blah.) Kathy Chen wrote: I want to know in what situations the machine's network is set to "promiscuous" mode. It's put into promiscuous mode if an application requests that the interface be put into promiscuous mode. For example, I know when I execute "tcpdump" on my machine, it's set to be in promiscuous mode. Only if you run tcpdump without the "-p" flag; the default is promiscuous mode, but "-p" causes tcpdump not to put the interface into promiscuous mode. Any other cases? Ethereal and Tethereal will also put the interface into promiscuous mode by default; you'd have to use "-p" as a command-line argument to Tethereal (or Ethereal, if you start the capture from the command line), or turn off the promiscuous mode option in the Ethereal GUI, not to run in promiscuous mode. Some other applications, such as snoop on Solaris (and possibly some other OSes), or Analyzer (on Windows), or other network analyzers, might put the interface into promiscuous mode as well. And is it correct that without "tcpcump", the network is not in promiscuous mode? No. Another program might put the interface into promiscuous mode. - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] Question about "pcap_next()"
(Blah blah blah another wrong from line blah blah blah avoid the duplicate message detector blah blah blah.) Kathy Chen wrote: When I call u_char *packet = pcap_next(handle, &header); I can get the packet length value, but I can't really get the "packet" data (Using printf(..., packet)). The packet data isn't a text string. It's raw binary data. Extract the separate fields from the raw packet data, and print that. (See tcpdump as an example of a program that dissects raw binary packet data.) - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
