[tcpdump-workers] Automatic report from sources (tcpdump libpcap htdocs) between 28.12.2004 - 29.12.2004 GMT

[Automatic cvs log generator /tcpdump/bin/makelog]

CVS log entries from 28.12.2004 (Tue) 10:06:45 - 29.12.2004 (Wed) 10:06:48 GMT
=
Summary by authors
=
Author: guy
File: tcpdump/tcpdump.1; Revisions: 1.167
File: tcpdump/print-smb.c; Revisions: 1.40, 1.39, 1.38, 1.37, 1.36, 1.35
File: tcpdump/smbutil.c; Revisions: 1.34, 1.33, 1.32, 1.31
File: tcpdump/smb.h; Revisions: 1.9

=
Combined list of identical log entries
=
Description:
Add format options to save the value fetched and to later use that value
for counted strings, and use them where appropriate.
Modified files:
File: tcpdump/print-smb.c; Revision: 1.40;
Date: 2004/12/29 03:10:24; Author: guy; Lines: (+7 -7)
File: tcpdump/smbutil.c; Revision: 1.33;
Date: 2004/12/29 03:10:25; Author: guy; Lines: (+134 -32)
---
Description:
Correctly dissect LockingAndX requests - there's a flag bit that
indicates whether the offsets and lengths are 32 bit or 64 bit.
Modified files:
File: tcpdump/print-smb.c; Revision: 1.36;
Date: 2004/12/28 20:38:27; Author: guy; Lines: (+43 -6)
File: tcpdump/smbutil.c; Revision: 1.31;
Date: 2004/12/28 20:38:27; Author: guy; Lines: (+17 -1)
---
Description:
Correctly handle Unicode strings - skip padding to put them on a 2-byte
boundary, and base the Unicode-vs-non-Unicode decision on the strings
are Unicode bit in Flags2, except for those few strings that are always
ASCII, rather than doing a heuristic check.

Fix the padding in FindFirst2 requests.
Modified files:
File: tcpdump/print-smb.c; Revision: 1.37;
Date: 2004/12/28 22:29:44; Author: guy; Lines: (+73 -63)
File: tcpdump/smb.h; Revision: 1.9;
Date: 2004/12/28 22:29:44; Author: guy; Lines: (+2 -2)
File: tcpdump/smbutil.c; Revision: 1.32;
Date: 2004/12/28 22:29:45; Author: guy; Lines: (+20 -19)
=
Log entries
=
Description:
Correctly dissect GetBackupList and BackupListResponse.
Modified files:
File: tcpdump/print-smb.c; Revision: 1.39;
Date: 2004/12/29 02:43:24; Author: guy; Lines:  (+3 -3)
---
Description:
The transaction name doesn't seem to be in any Transaction2 requests
I've seen; get rid of it.

Do, however, show the byte count.
Modified files:
File: tcpdump/print-smb.c; Revision: 1.38;
Date: 2004/12/29 00:06:28; Author: guy; Lines:  (+6 -3)
---
Description:
Don't print byte data if the byte count is 0.

In print_smb(), Don't go past the passed-in length when printing the
word data.

The andX command is 1 byte, not 2 bytes.

Check that the andX offset is after the offset of the previous SMB
information, so we don't get caught in a loop if there's a bogus andX
offset.
Modified files:
File: tcpdump/print-smb.c; Revision: 1.35;
Date: 2004/12/28 11:18:29; Author: guy; Lines:  (+43 -30)
---
Description:
Add some additional bounds checking.
Modified files:
File: tcpdump/smbutil.c; Revision: 1.34;
Date: 2004/12/29 05:27:27; Author: guy; Lines:  (+46 -16)
---
Description:
We now *do* auto-detect Unicode strings, so we no longer check the
USE_UNICODE environment variable.
Modified files:
File: tcpdump/tcpdump.1; Revision: 1.167;
Date: 2004/12/28 22:31:25; Author: guy; Lines:  (+1 -6)
=
Summary of modified files
=
File: tcpdump/print-smb.c
Revisions: 1.40, 1.39, 1.38, 1.37, 1.36, 1.35
Authors: guy (+7 -7), guy (+3 -3), guy (+6 -3), guy (+73 -63), guy (+43 -6), 
guy (+43 -30)
---
File: tcpdump/smb.h
Revisions: 1.9
Authors: guy (+2 -2)
---
File: tcpdump/smbutil.c
Revisions: 1.34, 1.33, 1.32, 1.31
Authors: guy (+46 -16), guy (+134 -32), guy (+20 -19), guy (+17 -1)
---
File: tcpdump/tcpdump.1
Revisions: 1.167
Authors: guy (+1 -6)
-- 
Automatic cron job from /tcpdump/bin/makelog
-
This is the tcpdump-workers list.
Visit https://lists.sandelman.ca/ to unsubscribe.

Re: [tcpdump-workers] newbie question

[Guy Harris]

durung_lulus wrote:
I want to make simple sniffer, but having question in mind,
Could we loose any packet that we try to grab with 
pcap_loop/pcap_dispatch?
Yes.
And if we do, what are the causes?
It'd be caused by the sniffer not being able to read packets fast enough 
that whatever buffer the OS uses in the capture mechanism doesn't fill 
up so that packets don't arrive when there's no room left in the buffer.

The application should try to do as little processing as it can; 
however, there's also OS and libpcap code involved.

Making the buffer larger might help, although, unfortunately, there's 
currently no API in libpcap for doing that (the problem is that, on 
systems using BPF such as the BSDs, you can't set the buffer size once 
the BPF device is bound to a network interface, and that happens when 
you open with pcap_open_live(), so the API would have to be a new API 
for opening devices - we'll probably have such an API in the future).

On some platforms you could probably write platform-dependent code to 
increase the buffer size - for example, on Linux you could try 
increasing the socket buffer size using the file descriptor returned by 
pcap_fileno() (on Linux, capturing is done with a socket).

If you don't need the entire packet - if, for example, you're only 
inteested in protocol information up to the TCP layer - you could set a 
snapshot length long enough to capture only the link-layer header and 
the headers you're interested in, so that less data is buffered and less 
data is copied; on most platforms, that'd make it less likely that you'd 
lose packets.

If you don't need all the packets on the network on which you're 
capturing - if, for example, you're only interested in HTTP traffic - 
you could use a packet filter to limit which packets are captured; on 
many platforms, that'd make it less likely that you'd lose packets.
-
This is the tcpdump-workers list.
Visit https://lists.sandelman.ca/ to unsubscribe.

Re: [tcpdump-workers] newbie question

[Navis]

Hi, sory if I'm asking again since I'm rather confuse with the
explanation. 

You said about buffer, could you explain about what this buffer is?

Is it pcap reads from this buffer as soon the packet arrive or pcap
reads the buffer after the buffer full, is it having any correlation
with to_ms parameter on pcap_open_live()?

And is it the packet always come in the right sequence, or we must
arrange coming packets on the right order if we want to read all of the
connection session?

Thankyou before


-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Guy Harris
Sent: Thursday, December 30, 2004 3:42 AM
To: tcpdump-workers@lists.tcpdump.org
Subject: Re: [tcpdump-workers] newbie question

It'd be caused by the sniffer not being able to read packets fast enough

that whatever buffer the OS uses in the capture mechanism doesn't fill 
up so that packets don't arrive when there's no room left in the buffer.



-
This is the tcpdump-workers list.
Visit https://lists.sandelman.ca/ to unsubscribe.