[tcpdump-workers] dealing with collisions, dropped packets

2004-11-01 Thread Matt Van Mater
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

2004-11-01 Thread Aaron Turner
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

2004-11-01 Thread Guy Harris
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

2004-11-01 Thread sthaug
> 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

2004-11-01 Thread Michael Richardson
-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

2004-11-01 Thread Michael Richardson
-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?

2004-11-01 Thread Guy Harris
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

2004-11-01 Thread Kathy Chen
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

2004-11-01 Thread Sebastien Vincent
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

2004-11-01 Thread Kathy Chen
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()"

2004-11-01 Thread Kathy Chen
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()"

2004-11-01 Thread Sebastien Vincent
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

2004-11-01 Thread Guy Harris
(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

2004-11-01 Thread Guy Harris
(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()"

2004-11-01 Thread Guy Harris
(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.