Re: [tcpdump-workers] libpcap pcap_sendpacket support across platforms.
On Thu, 25 Mar 2004 09:45:59 +0100, Frédéric Raynal [EMAIL PROTECTED] wrote: Hello, On Wed, Mar 24, 2004 at 09:46:15PM -, Ste Jones wrote: On Mar 23, 2004, at 1:14 PM, Guy Harris wrote: On Mar 23, 2004, at 12:09 PM, Michael Richardson wrote: I really think there needs to be sort sort of unification between the two libraries libpcap and libnet but joining them i don;t know if that the best idea both require a fair amount of work to maintian so why not start another api to handle the unification The aim of the new api would be to act as the glue between both written and captured frames, basically a userland stack api (ideally conforming to all the relevant RFC's). Frames from libpcap could use this api to determine what part of the libnet api to use to send frames required to create a connection for example. The programmer could have full contol over a stream and not have to worry about each individual frame (unless they want to)... this would save manually handling connection states, retransmission problems, fragementation issues and dropped packets currently faced while using both lipcap and libnet. Frédéric Raynal implemented something similar for handling connections a while back but i can;t find it on his site looked pretty good from what i can remember :) Thanks :) But I stopped it because I had another idea to do it in a better way ... but I had no time to do it yet :( I do think that libpcap should be able to send packets... if someone is using libpcap to capture connections which should be terminated with a simple rst, for example, there should be a way to send a frame as another api shouldn;t be required for anything this trivial anything more complicated use libnet :) On the flip side disregarding everything i just said. would one API for userland networking be that bad idea? many programs require libnet, libpcap and libdnet why not chuck them all together? would make quite a bit of sense in the long run would it not? A greater userbase with more eyes looking at the code can;t be bad. A quick list of advantages and disadvanteage for joining the API's Advanatages More people looking at the source code Easier install one api opposed to two or three api's Greater portability - libpcap seem to run on everything ;) congratz on the recent libnet win32 port btw ;) Easier API for a developerinterfaces would only need to be selected once for example. TCPReplay capabilites within the api? Disadvantages The api would be more complex and harder to maintain? Couldn;t really think of any others ;) my initial thoughts as u can probably tell were against the idea but if the main developers are up for it can;t see why not ;) enough ranting for this evening ;) Ok, so I start from here, and I'll start with a short story. Some days ago, I sent a mail to Dug Song and Mike about one thing that is in libdnet as I was writting some code to do the same in libnet. 2 or 3 days ago, I had a look to the new libpcap, and also found the same feature. That is an API to handle the device (getting/setting its adresses, netmask, and things like that). This is definitely something one need when handling network stuff and thus should be sahred by all those libraries. Another point for the unification is to avoid the multiplication of the same structures. For instance, both libpcap and libnet use a socket to read or write: why not use the same one? Except for 802.11 where listening and writing cant be done at the same time, I cant see any good reason (but I am probably missed it). Idem with the structures describing headers: why should they be define in several places whareas they are always the same? Libpcap does much more than only listenig on the network. The callback system is pretty cool and that is something similar I wanted to do with the answering machine based on network event. But for that, libnids is also very interresting with its good TCP engine (conntrack). Having a userland network stack was part of what I have in mind. There are few projects that are using only libnet, and more that are focusing on libpcap. But most of projects use both of them. And for those ones, a common API with easy ways to convert from one to the other would be vey helpful. That was just my 2cts of euros as a user of these 2 wonderful libraries. Fred Raynal random thought... probably way of the scale but anywayz. remove the network stack from the kernal and implement it userland using a combined version of libpcap libnet and libdnet (networkd API + deamon?) bonus being could be run with priverlage seperation, chrooted and would not lead to kernal compromise if bugs found.. would be similar to what i am trying to do with the gobbler as a userland network toolkit for machines without an IP address and also similar to Fred's answer machine. on openbsd you could have bpf reading in frames and dropping the mbuf's before any kernal processing is done on the frame (i have
Re: [tcpdump-workers] question on DLT_ types
On Mar 25, 2004, at 12:00 PM, alex medvedev wrote: how do the DLT_ types get assigned? is there some central authority that does it? Yes. If somebody wants a new DLT_ value, they should ask tcpdump.org for it. or are they arbitrarily assigned and therefore different between platforms (e.g. AIX with its IFT_ types). Historically, that did happen, although AIX is somewhat of a special case - they just started from scratch and made something that's source-level incompatible for programs using libpcap (nanosecond vs. microsecond time resolution) *AND* incompatible at the capture file level (time resolution *and* link-layer type). The DLT_ values in the range DLT_NULL through DLT_FDDI are, as far as I know, the same on all platforms (except perhaps for AIX); those were probably the ones used in early versions of BPF and libpcap. Some of the other values in the range 11 through 98 have been used for different purposes on different platforms. We picked 100 as the base for the new range of values, and those are *probably* the same on all platforms (modulo some problems with the PFLOG type in OpenBSD - they originally picked 17, which collided with DLT_LANE8023 in SuSE 6.3, and later changed the encapsulation and, somewhere along the line, also switched out our value of 117 - and 127 originally having been reserved for the Absolute Value Systems 802.11 radio header, but not, as far as I know, ever used for that, and later being assigned to the BSD radiotap 802.11 radio header with the AVS header now having 163 reserved for it). We obviously can't control who uses non-standard DLT_ values, but people *do* seem to be asking us for values (perhaps thanks, in part, to the rather emphatic comments I put into pcap-bpf.h, savefile.c, and Ethereal's wiretap/libpcap.c). - This is the TCPDUMP workers list. It is archived at http://www.tcpdump.org/lists/workers/index.html To unsubscribe use mailto:[EMAIL PROTECTED]
[tcpdump-workers] Automatic report from sources (tcpdump libpcap htdocs) between 24.03.2004 - 25.03.2004 GMT
CVS log entries from 24.03.2004 (Wed) 10:05:53 - 25.03.2004 (Thu) 10:05:48 GMT = Summary by authors = Author: guy File: libpcap/pcap-bpf.c; Revisions: 1.76 Author: mcr File: libpcap/pcap1.h; Revisions: 1.1 File: tcpdump/print-isakmp.c; Revisions: 1.48 File: libpcap/pcap.c; Revisions: 1.74 File: tcpdump/tests/eapon1.sh; Revisions: 1.1 File: tcpdump/ethertype.h; Revisions: 1.22 File: tcpdump/tests/eapon2.puu; Revisions: 1.1 File: tcpdump/netdissect.h; Revisions: 1.2 File: tcpdump/tests/eapon1.gdbinit; Revisions: 1.1 File: tcpdump/print-eap.c; Revisions: 1.1 File: tcpdump/print-esp.c; Revisions: 1.49 File: tcpdump/tests/eapon1.puu; Revisions: 1.1 File: tcpdump/print-vjc.c; Revisions: 1.15 File: tcpdump/tests/eapon1.out; Revisions: 1.1 File: tcpdump/tests/eapon1.pcap; Revisions: 1.1 File: tcpdump/parsenfsfh.c; Revisions: 1.28 = Combined list of identical log entries = Description: new test cases for EAPol. Modified files: File: tcpdump/tests/eapon1.gdbinit; Revision: 1.1; Date: 2004/03/25 03:29:20; Author: mcr; File: tcpdump/tests/eapon1.out; Revision: 1.1; Date: 2004/03/25 03:29:20; Author: mcr; File: tcpdump/tests/eapon1.pcap; Revision: 1.1; Date: 2004/03/25 03:29:20; Author: mcr; File: tcpdump/tests/eapon1.puu; Revision: 1.1; Date: 2004/03/25 03:29:20; Author: mcr; File: tcpdump/tests/eapon1.sh; Revision: 1.1; Date: 2004/03/25 03:29:20; Author: mcr; File: tcpdump/tests/eapon2.puu; Revision: 1.1; Date: 2004/03/25 03:29:21; Author: mcr; --- Description: beginnings of library version of netdissect. Modified files: File: tcpdump/netdissect.h; Revision: 1.2; Date: 2004/03/25 03:29:53; Author: mcr; Lines: (+414 -0) File: tcpdump/print-eap.c; Revision: 1.1; Date: 2004/03/25 03:29:53; Author: mcr; --- Description: cleaned up warning. Modified files: File: tcpdump/parsenfsfh.c; Revision: 1.28; Date: 2004/03/25 03:30:55; Author: mcr; Lines: (+2 -2) File: tcpdump/print-esp.c; Revision: 1.49; Date: 2004/03/25 03:31:25; Author: mcr; Lines: (+2 -2) File: tcpdump/print-isakmp.c; Revision: 1.48; Date: 2004/03/25 03:31:05; Author: mcr; Lines: (+39 -34) File: tcpdump/print-vjc.c; Revision: 1.15; Date: 2004/03/25 03:31:17; Author: mcr; Lines: (+2 -2) = Log entries = Description: Get rid of an out-of-date comment. Add a comment noting why we don't do BIOCSHDRCMPLT on OS X. Modified files: File: libpcap/pcap-bpf.c; Revision: 1.76; Date: 2004/03/24 19:52:46; Author: guy; Lines: (+12 -11) --- Description: patch from Gisle Vanem for Symantec/Raptor tcpdump. Modified files: File: libpcap/pcap.c; Revision: 1.74; Date: 2004/03/24 19:50:54; Author: mcr; Lines: (+3 -2) --- Description: work-in-progress pcap format 1.0. Modified files: File: libpcap/pcap1.h; Revision: 1.1; Date: 2004/03/24 19:51:11; Author: mcr; --- Description: added EAPOL ethernet type. Modified files: File: tcpdump/ethertype.h; Revision: 1.22; Date: 2004/03/25 03:30:40; Author: mcr; Lines: (+4 -1) = Summary of modified files = File: libpcap/pcap-bpf.c Revisions: 1.76 Authors: guy (+12 -11) --- File: libpcap/pcap.c Revisions: 1.74 Authors: mcr (+3 -2) --- File: libpcap/pcap1.h Revisions: 1.1 Authors: mcr --- File: tcpdump/ethertype.h Revisions: 1.22 Authors: mcr (+4 -1) --- File: tcpdump/netdissect.h Revisions: 1.2 Authors: mcr (+414 -0) --- File: tcpdump/parsenfsfh.c Revisions: 1.28 Authors: mcr (+2 -2) --- File: tcpdump/print-eap.c Revisions: 1.1 Authors: mcr --- File: tcpdump/print-esp.c Revisions: 1.49 Authors: mcr (+2 -2) --- File: tcpdump/print-isakmp.c Revisions: 1.48 Authors: mcr (+39 -34) --- File: tcpdump/print-vjc.c Revisions: 1.15 Authors: mcr (+2 -2) --- File: tcpdump/tests/eapon1.gdbinit Revisions: 1.1 Authors: mcr --- File: tcpdump/tests/eapon1.out Revisions: 1.1 Authors: mcr
[tcpdump-workers] pcap.c patch
A small patch for DLT_SYMANTEC: And other Win compilers besides MSVC have unistd.h. --- libpcap-2004.03.24/pcap.c Tue Mar 23 20:18:07 2004 +++ pcap.c Wed Mar 24 18:12:06 2004 @@ -49,7 +49,7 @@ #include stdio.h #include stdlib.h #include string.h -#ifndef WIN32 +#ifndef _MSC_VER #include unistd.h #endif #include fcntl.h @@ -351,6 +351,7 @@ DLT_CHOICE(DLT_DOCSIS, DOCSIS), DLT_CHOICE(DLT_LINUX_IRDA, Linux IrDA), DLT_CHOICE(DLT_IEEE802_11_RADIO_AVS, 802.11 plus AVS radio information header), + DLT_CHOICE(DLT_SYMANTEC_FIREWALL, Symantec Firewall), DLT_CHOICE_SENTINEL }; --gv - This is the TCPDUMP workers list. It is archived at http://www.tcpdump.org/lists/workers/index.html To unsubscribe use mailto:[EMAIL PROTECTED]
Re: [tcpdump-workers] proposed new pcap format
In some email I received from Michael Richardson, sie wrote: Darren == Darren Reed [EMAIL PROTECTED] writes: Are we sure that enough people will be asking for data types that we can't just say ask us for a type value, we'll give one to you? That seems to have worked pretty well for DLT_ values so far. If they *truly* want it to be private, they can just ask for a number and we'll give it to them, just as we give out private-use DLT_ values such as the ones used by Cisco, Juniper, and IBM. Darren I suppose I'm not so much concerned about it being private as it Darren being unique. Darren Maybe a vendor field and vendor sub-type field would be useful ? Darren That'd give flexibility in an SNMP kind of way. okay, divide the 32-bit space into two 16-bit spaces. vendor 0 will be reserved. tcpdump.org will be vendor 1. vendor 0x will be reserved (for the NSA). Why not make both 32bit ? I say that because design requirements are different, today, than they were 15 years ago. Darren - This is the TCPDUMP workers list. It is archived at http://www.tcpdump.org/lists/workers/index.html To unsubscribe use mailto:[EMAIL PROTECTED]
Re: [tcpdump-workers] proposed new pcap format
-BEGIN PGP SIGNED MESSAGE- Darren == Darren Reed [EMAIL PROTECTED] writes: type could be 16-bit. len, I'm hesistant. The high performance network people are presently complaining about the 64k limit on IP packets... Darren Don't forget IPv6 jumbograms. Yes. base 2, I'd think. Hmm. I see the problem. Can someone provide a clear notion? Do we have to go to units of 1/(2^32) of a second instead of 1/(10^9) then? Darren If we're attempting to indicate the error in the system's time, Darren then surely the best that can be done is to estimate the min/max Darren range that the time could be? Kind of like error bars on a graph Darren to indicate confidence values of a specific measurement ? yes, so, we want to say, captured at: 2004-Mar-24 13:53:14.238534 +- 0.0001 or: 2004-Mar-24 13:53:14.238534 +- 10^-4 which can be summarized as 4. That doesn't allow for error bars like +- 0.00015. I think when you do this in base 2, it is a lot easier. Darren How about 1/HZ ? If you're trying to represent the accuracy of the Darren time in the capture frame then what needs to be recognised is the Darren maximum amount of time between the packet appearing on the network Darren to it ending up in a buffer, stamped. The ideal time source here Darren would be a clock stamp from the NIC :) No, that doesn't help. Assume that the PHY does the stamping, you still need to know the resolution of the timer used to make the stamp. Darren Also, does time drift/jitter come into play? If you're using NTP Darren on such a system... It was suggested that there be a way to indicate what the drift against an accurate source would be. - -- ] ON HUMILITY: to err is human. To moo, bovine. | 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 iQCVAwUBQGHaF4qHRg3pndX9AQGeKwQA05oXBe7QXCpw4GBv/quePSuaREcPHXA7 fzN7ateYcyd8xZTnNMjvTJxV5veATZYKKJZZF9+EBRbKNoYbEJ9tSsPHit7SPboK dRHr7723XIC/gaLZFf2/hN28ri4x/Q2ITYHK4s95lEB3yQrSx/dfvM/tnhJIbny+ yz5Da7lfDZY= =msTg -END PGP SIGNATURE- - This is the TCPDUMP workers list. It is archived at http://www.tcpdump.org/lists/workers/index.html To unsubscribe use mailto:[EMAIL PROTECTED]
Re: [tcpdump-workers] proposed new pcap format
Hi, One of the items I would like support for in a new format is comments. That is, the ability to add textual comments to frames. These comments would be ignored by tools that do not understand them, but they would be displayed by tools capable of understanding them. It seems that there are two ways to deal with this: 1. A packet type that indicates that the data contained in the packet is a comment associated with the previous (or next) packet in the capture. 2. Some extra fields in each capture header that allows us to tag the current packet with comment info. Regards - Richard Sharpe, rsharpe[at]richardsharpe.com, rsharpe[at]samba.org, sharpe[at]ethereal.com, http://www.richardsharpe.com - This is the TCPDUMP workers list. It is archived at http://www.tcpdump.org/lists/workers/index.html To unsubscribe use mailto:[EMAIL PROTECTED]
Re: [tcpdump-workers] proposed new pcap format
On Tue, Mar 23, 2004 at 07:22:37PM -0800, Guy Harris wrote:
[ ... ]
| enum pcap1_info_types {
| PCAP_DATACAPTURE,
| PCAP_TIMESTAMP,
| };
|
| ...with that list presumably being expandable over time.
like for example with PCAP_DIRECTION
/hannes
-
This is the TCPDUMP workers list. It is archived at
http://www.tcpdump.org/lists/workers/index.html
To unsubscribe use mailto:[EMAIL PROTECTED]
[tcpdump-workers] Automatic report from sources (tcpdump libpcap htdocs) between 23.03.2004 - 24.03.2004 GMT
CVS log entries from 23.03.2004 (Tue) 10:05:30 - 24.03.2004 (Wed) 10:05:53 GMT = Summary by authors = Author: fenner File: tcpdump/print-domain.c; Revisions: 1.89 File: tcpdump/configure.in; Revisions: 1.177 File: tcpdump/configure; Revisions: 1.122 File: tcpdump/tcpdump.c; Revisions: 1.238 File: tcpdump/config.h.in; Revisions: 1.56 File: tcpdump/tests/isakmp-identification-segfault.puu; Revisions: 1.1 File: tcpdump/tests/isakmp3.out; Revisions: 1.1 File: tcpdump/tests/isakmp3.sh; Revisions: 1.1 Author: guy File: tcpdump/print-isoclns.c; Revisions: 1.119, 1.106.2.5 File: tcpdump/print-bgp.c; Revisions: 1.81, 1.72.2.4 File: libpcap/pcap.c; Revisions: 1.73 File: libpcap/pcap-nit.c; Revisions: 1.56 File: tcpdump/print-mobile.c; Revisions: 1.15 File: tcpdump/print-icmp6.c; Revisions: 1.76, 1.72.2.4 File: libpcap/CREDITS; Revisions: 1.72 File: tcpdump/print-pppoe.c; Revisions: 1.28, 1.24.2.4 File: tcpdump/print-rsvp.c; Revisions: 1.27, 1.24.2.3 File: tcpdump/print-aodv.c; Revisions: 1.11, 1.8.2.3 File: libpcap/pcap-linux.c; Revisions: 1.107, 1.106 File: libpcap/pcap-dag.c; Revisions: 1.18 File: tcpdump/print-ospf.c; Revisions: 1.51, 1.45.2.4 File: libpcap/pcap-snoop.c; Revisions: 1.52 File: libpcap/pcap-int.h; Revisions: 1.62 File: tcpdump/print-cdp.c; Revisions: 1.24, 1.23, 1.19.2.5, 1.19.2.4 File: tcpdump/print-wb.c; Revisions: 1.33, 1.30.2.3 File: tcpdump/print-chdlc.c; Revisions: 1.31, 1.28.2.3 File: libpcap/pcap.3; Revisions: 1.59 File: tcpdump/print-isakmp.c; Revisions: 1.47, 1.36.2.11 File: libpcap/pcap-win32.c; Revisions: 1.21 File: tcpdump/print-ppp.c; Revisions: 1.94, 1.89.2.3 File: tcpdump/print-lwres.c; Revisions: 1.13, 1.10.2.3 File: libpcap/savefile.c; Revisions: 1.106 File: libpcap/pcap-bpf.c; Revisions: 1.75, 1.74 File: libpcap/pcap.h; Revisions: 1.50 File: tcpdump/print-ip.c; Revisions: 1.135, 1.134, 1.128.2.6, 1.128.2.5 File: tcpdump/addrtoname.c; Revisions: 1.104, 1.96.2.6 File: tcpdump/print-icmp.c; Revisions: 1.76, 1.73.2.3 File: libpcap/pcap-snit.c; Revisions: 1.71 File: libpcap/pcap-pf.c; Revisions: 1.87 File: tcpdump/print-pim.c; Revisions: 1.43, 1.37.2.4 File: tcpdump/print-igmp.c; Revisions: 1.15 File: libpcap/pcap-dlpi.c; Revisions: 1.96 = Combined list of identical log entries = Description: Add support for sending packets; includes contributions from Mark Pizzolato [EMAIL PROTECTED]. Modified files: File: libpcap/CREDITS; Revision: 1.72; Date: 2004/03/23 19:18:04; Author: guy; Lines: (+1 -0) File: libpcap/pcap-bpf.c; Revision: 1.74; Date: 2004/03/23 19:18:04; Author: guy; Lines: (+42 -2) File: libpcap/pcap-dag.c; Revision: 1.18; Date: 2004/03/23 19:18:04; Author: guy; Lines: (+10 -1) File: libpcap/pcap-dlpi.c; Revision: 1.96; Date: 2004/03/23 19:18:05; Author: guy; Lines: (+100 -1) File: libpcap/pcap-int.h; Revision: 1.62; Date: 2004/03/23 19:18:05; Author: guy; Lines: (+4 -2) File: libpcap/pcap-linux.c; Revision: 1.106; Date: 2004/03/23 19:18:05; Author: guy; Lines: (+74 -13) File: libpcap/pcap-nit.c; Revision: 1.56; Date: 2004/03/23 19:18:06; Author: guy; Lines: (+31 -1) File: libpcap/pcap-pf.c; Revision: 1.87; Date: 2004/03/23 19:18:06; Author: guy; Lines: (+32 -3) File: libpcap/pcap-snit.c; Revision: 1.71; Date: 2004/03/23 19:18:06; Author: guy; Lines: (+42 -2) File: libpcap/pcap-snoop.c; Revision: 1.52; Date: 2004/03/23 19:18:06; Author: guy; Lines: (+18 -1) File: libpcap/pcap-win32.c; Revision: 1.21; Date: 2004/03/23 19:18:07; Author: guy; Lines: (+25 -23) File: libpcap/pcap.3; Revision: 1.59; Date: 2004/03/23 19:18:07; Author: guy; Lines: (+36 -1) File: libpcap/pcap.c; Revision: 1.73; Date: 2004/03/23 19:18:07; Author: guy; Lines: (+25 -1) File: libpcap/pcap.h; Revision: 1.50; Date: 2004/03/23 19:18:07; Author: guy; Lines: (+3 -2) File: libpcap/savefile.c; Revision: 1.106; Date: 2004/03/23 19:18:08; Author: guy; Lines: (+10 -1) --- Description: Add payload length checking. Modified files: File: tcpdump/print-isakmp.c; Revision: 1.47; Date: 2004/03/24 01:32:20; Author: guy; Lines: (+40 -16) File: tcpdump/print-isakmp.c; Revision: 1.36.2.11; Date: 2004/03/24 01:32:42; Author: guy; Lines: (+40 -16) --- Description: Add
[tcpdump-workers] working offline
hi, does anyone have an example on how to use pcap_compile_nopcap and/or pcap_open_dead ? I´d like to use pcap to apply filters offline but i'm not sure how to do this. thanks a lot, Cecilia
Re: [tcpdump-workers] libpcap pcap_sendpacket support across platforms.
-BEGIN PGP SIGNED MESSAGE- Stephen == Stephen Donnelly [EMAIL PROTECTED] writes: Stephen useful. Is it assumed that libpcap now always uses UTC for Stephen timezone? No, it stores the timezone in the header. Stephen timeval (unix sec,microsec) by libpcap, timespec (unix Stephen sec,nanosec) by AIX libpcap(?), and the Endace 64-bit Stephen fixed-point format (unix sec,fraction). All these formats Stephen use 64 bits total. I don't know about WinPcap. I prefer unix sec, nanosec myself. Stephen Are we trying to converge on one time-stamp format for Stephen libpcap-ng, or allowing the use of various formats, with Stephen some indication of which format per file/interface, and the Stephen problems of merging traces? Would libpcap offer time-stamp Stephen conversion routines for programs that don't understand Stephen various ones, and allow them to select? I'd rather have one new common time-stamp format, but I'd like to leave the door open to other formats being supported. - -- ] ON HUMILITY: to err is human. To moo, bovine. | 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 iQCVAwUBQGGeXoqHRg3pndX9AQGVGAP+OEdVz9oSFcjCsh7vt3X8fb3iL7+tKXsE 7KYieFAXcdb0m11UlnweJcCsievsw3Kp5NQpT7KpkzJzkaoq6iIfBaxIz5aQChDo XkWkDFjXulMoq836OlphOZYFJmLzv/GihykQeYF8C7B6+TdjcVH2w1mr9/DlRR6B kLiiNr16hAk= =FlwY -END PGP SIGNATURE- - This is the TCPDUMP workers list. It is archived at http://www.tcpdump.org/lists/workers/index.html To unsubscribe use mailto:[EMAIL PROTECTED]
Re: [tcpdump-workers] proposed new pcap format
-BEGIN PGP SIGNED MESSAGE-
Guy == Guy Harris [EMAIL PROTECTED] writes:
This is what I would propose as revision.
Note that the pcap1_packet_header is present on every packet. One can
merge pcap files together with cat if one likes.
Guy OK - that's a bit much to write for every packet, though, as
Guy most of it is redundant.
I don't think it is really that much. less than 20 bytes. very
compressable too.
Guy Does each record have a pcap1_packet_header and *one*
Guy pcap1_info_container, or one or more up to block_len bytes? If
Guy the latter, you could have more than one packet per
Guy pcap1_packet header.
You could have more than one packet per header, true. Is that a good
thing? I'm not sure. that wasn't what I was thinking though.
You could also have zero packets per header - for instance, just have
meta data containing the expression used.
A suggestion was made to accomodate the nano-second resolution from AIX.
Can you tell me what they do for that? just more bits, sure, but is
there a nano-seconds (32-bits, I guess) + seconds (64 bits?).
Guy 32-bit seconds, 32-bit nanoseconds.
I like to have more than 32-bit seconds. I like the nanoseconds.
enum pcap1_info_types {
PCAP_DATACAPTURE,
PCAP_TIMESTAMP,
};
Guy ...with that list presumably being expandable over time.
yes.
bpf_int32 thiszone; /* gmt to local correction */
Guy We currently have that but don't use it - it's always zero.
Guy Should we start using it?
I guess I'm ignorant of the fact that we aren't using it!
struct timeval ts; /* time stamp */
bpf_u_int32 sigfigs; /* accuracy of timestamps */
Guy Similarly, that's never been set - should we start using it?
I think so. Certainly in the version 1.0 format.
- --
] ON HUMILITY: to err is human. To moo, bovine. | 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
iQCVAwUBQGGhe4qHRg3pndX9AQGVFwQAl1JyORQMoe533GFzJ8BE8s6u2uPRTGdi
k1r+r/cgglCP0rMM6hFjdrEFnzq53uDcXQM3Wt3hqNYFZoaJnAIJt8cunI4fv1mY
cM+rIOsk8ln14TnnJl2kFEReWvfdC/EDn1egJ90rXJaAXuJTup3j89Qpkez6DJcZ
9GSj3Cmb4pM=
=SOP6
-END PGP SIGNATURE-
-
This is the TCPDUMP workers list. It is archived at
http://www.tcpdump.org/lists/workers/index.html
To unsubscribe use mailto:[EMAIL PROTECTED]
Re: [tcpdump-workers] proposed new pcap format
Hi,
in the new format, is it really necessary to have the version number in
every packet? How about making that a separate header and including it
only once at the start of a trace? Also, since with your design there's
the possibility of not actually having a pcap1_info_packet chained into
a pcap1_packet_header (or in fact more than one -- is that a good idea?
mhmm ...), there could simply be one pcap1_packet_header at the
beginning of the file that only contains such a version header ...
It might also be useful to do
struct pcap1_info_packet {
struct pcap1_info_container pic;
bpf_u_int32 linktype; /* data link type (LINKTYPE_*) */
bpf_u_int32 caplen; /* length of portion present */
bpf_u_int32 len;/* length this packet (off wire) */
unsigned char packet_data[0];
};
instead to make the lengths match the sequence in the current
pcap_pkthdr.
Regards,
Christian.
On Wed, 2004-03-24 at 01:53, Michael Richardson wrote:
-BEGIN PGP SIGNED MESSAGE-
This is what I would propose as revision.
Note that the pcap1_packet_header is present on every packet. One can
merge pcap files together with cat if one likes.
A suggestion was made to accomodate the nano-second resolution from AIX.
Can you tell me what they do for that? just more bits, sure, but is
there a nano-seconds (32-bits, I guess) + seconds (64 bits?).
enum pcap1_info_types {
PCAP_DATACAPTURE,
PCAP_TIMESTAMP,
};
struct pcap1_info_container {
bpf_u_int32 info_len; /* in bytes */
bpf_u_int32 info_type;/* enum pcap1_info_types */
unsigned char info_data[0];
};
struct pcap1_info_timestamp {
struct pcap1_info_container pic;
bpf_int32 thiszone;/* gmt to local correction */
struct timeval ts; /* time stamp */
bpf_u_int32 sigfigs;/* accuracy of timestamps */
};
struct pcap1_info_packet {
struct pcap1_info_container pic;
bpf_u_int32 caplen; /* length of portion present */
bpf_u_int32 len;/* length this packet (off wire) */
bpf_u_int32 linktype; /* data link type (LINKTYPE_*) */
unsigned char packet_data[0];
};
struct pcap1_packet_header {
bpf_u_int32 magic;
u_short version_major;
u_short version_minor;
bpf_u_int32 block_len;
struct pcap1_info_container pics[0];
};
--
http://www.cl.cam.ac.uk/~cpk25
http://www.whoop.org
-
This is the TCPDUMP workers list. It is archived at
http://www.tcpdump.org/lists/workers/index.html
To unsubscribe use mailto:[EMAIL PROTECTED]
[tcpdump-workers] tok2str() patch
tok2str() is in several files used multiple times in the same
printf() statement. This doesn't work if all values 'v' are unknown.
I suggest we allow for max 4 buffer to be returned in a round-robin
fashion.
--- tcpdump-2004.03.24/util.c Mon Dec 29 12:07:17 2003
+++ util.c Wed Mar 24 20:22:23 2004
@@ -212,7 +212,9 @@
tok2str(register const struct tok *lp, register const char *fmt,
register int v)
{
- static char buf[128];
+ static char buf[4][128];
+ static int idx = 0;
+ char *ret;
while (lp-s != NULL) {
if (lp-v == v)
@@ -221,8 +223,10 @@
}
if (fmt == NULL)
fmt = #%d;
- (void)snprintf(buf, sizeof(buf), fmt, v);
- return (buf);
+ ret = buf[idx];
+ (void)snprintf(ret, sizeof(buf[0]), fmt, v);
+ idx = (idx+1) 3;
+ return (const char*) ret;
}
--gv
-
This is the TCPDUMP workers list. It is archived at
http://www.tcpdump.org/lists/workers/index.html
To unsubscribe use mailto:[EMAIL PROTECTED]
Re: [tcpdump-workers] proposed new pcap format
On Mar 24, 2004, at 7:28 AM, Darren Reed wrote: No, it's not that private :) What I'm proposing here is a way in which people can put custom data into the pcap files without having too be too concerned about what values are safe for the type field and what values aren't. A while ago, I was thinking of a somewhat elaborate scheme in which the file would have a dictionary specifying attribute names (using some scheme based on DNS names for the organization developing them; organizations with no domain could ask for a private.tcpdump.org space, perhaps) and tag values, with the tag values in question being used in the file. The intent was to avoid a central registry for the space of attributes (and not to have to stick a string in every attribute). Stuart Cheshire convinced me that this wasn't necessarily an issue - he indicated that the registration mechanism for RFC 2782 service types worked pretty well and that central registries aren't *always* a problem. Are we sure that enough people will be asking for data types that we can't just say ask us for a type value, we'll give one to you? That seems to have worked pretty well for DLT_ values so far. If they *truly* want it to be private, they can just ask for a number and we'll give it to them, just as we give out private-use DLT_ values such as the ones used by Cisco, Juniper, and IBM. - This is the TCPDUMP workers list. It is archived at http://www.tcpdump.org/lists/workers/index.html To unsubscribe use mailto:[EMAIL PROTECTED]
Re: [tcpdump-workers] Apple IP-over-IEEE1394
On Mar 24, 2004, at 8:46 AM, Gisle Vanem wrote: To me it looks like from reading the print-ap1394.c that it handles anything-over-IEEE1394 and not just IP. Well, not *anything* - it probably won't handle SCSI-over-1394, or pictures or videos from your digital camera, for example. I know next to nothing about IEEE-1394, so I'm a bit confused. Why the emphasis on IP? Is that an industry mis-nomer? Perhaps - see RFC 2734, which is entitled IPv4 over IEEE 1394, but lists Ethernet types other than 0x0800 (0x0806 for 1394 ARP and 0x8861 for MCAP, which is a multicast channel allocation protocol) and says NOTE: Other network protocols, identified by different values of ether_type, may use the encapsulation formats defined herein but such use is outside of the scope of this document. Same goes for IP-over-Fibre channel. See RFC 2625, which speaks only of IP and ARP, but indicates that there's an LLC/SNAP header, so it *could* be used for other protocols. I think the IP-over part might come from the fact that the encapsulations were designed by people primarily thinking of running IP over those link layers - but they designed them in a way that they *could* be used to support other protocols; however, as they weren't involved in actually *implementing* those protocols on those link layers, perhaps they didn't want to use an RFC title suggesting that they were what would be used for all networking protocols. I don't know whether, in practice, protocols other than IPv4 (and now IPv6, which does show up in some IP-over-1394 captures I've seen; presumably people can and perhaps do run it over Fibre Channel as well), and supporting protocols for them (e.g., ARP and MCAP) are run over those link layers. BTW. How is ARP over IPFC printed? Seems it requires a LLC header, but print-llc.c doesn't handle ARP. print-llc.c handles LLC/SNAP, and LLC/SNAP is handled by processing the Ethernet type if the OUI is 0; SNAP packets will be handed to snap_print(), and with an OUI of 0 they'll be handed to ether_encap_print(), which will hand them to print_arp() if they have an Ethernet type of 0x0806 (or 0x8035 for reverse ARP). BTW2. Is there an easy releationship between a 6-byte MAC addresses and 8-byte EUI64 addresses used in IEEE-1394? http://standards.ieee.org/regauth/oui/tutorials/EUI64.html An EUI-64 *can* include a 6-byte MAC address (MAC-48 value), but it need not do so. If the EUI-64 is of the form XX-XX-XX-FF-FF-YY-YY-YY then the corresponding MAC address is XX-XX-XX-YY-YY-YY. That encapsulation is, however, listed as deprecated, and the IP-over-1394 captures I've seen have EUI-64's that encapsulate EUI-48's: http://standards.ieee.org/regauth/oui/tutorials/EUI48.html i.e. XX-XX-XX-FF-FE-YY-YY-YY, rather than encapsulating MAC addresses. (See also http://standards.ieee.org/regauth/oui/tutorials/UseOfEUI.html for more information on MAC-48's, EUI-48's, and EUI-64's.) - This is the TCPDUMP workers list. It is archived at http://www.tcpdump.org/lists/workers/index.html To unsubscribe use mailto:[EMAIL PROTECTED]
Re: [tcpdump-workers] working offline
On Mar 24, 2004, at 5:27 AM, Cecilia Cabrera wrote: hi, does anyone have an example on how to use pcap_compile_nopcap and/or pcap_open_dead ? I´d like to use pcap to apply filters offline but i'm not sure how to do this. What do you mean by apply filters offline? If you're reading a capture file, you'd open it with pcap_open_offline(), in which case you already have a pcap_t you can use to compile the filter. - This is the TCPDUMP workers list. It is archived at http://www.tcpdump.org/lists/workers/index.html To unsubscribe use mailto:[EMAIL PROTECTED]
[tcpdump-workers] pcap_handler return value
Hi, would you guys consider changing the return value of the pcap_handler callbacks to typedef int (*pcap_handler)(u_char *, const struct pcap_pkthdr *, const u_char *); so that the callback gets a chance to stop a pcap_loop() or pcap_dispatch() iteration, say when returning 0 as opposed to 1? I've repreatedly found that it'd be nice to remain in control over when to abort the loop. Thanks, Christian. -- http://www.cl.cam.ac.uk/~cpk25 http://www.whoop.org - This is the TCPDUMP workers list. It is archived at http://www.tcpdump.org/lists/workers/index.html To unsubscribe use mailto:[EMAIL PROTECTED]
Re: [tcpdump-workers] pcap_handler return value
On Mar 24, 2004, at 3:19 PM, Christian Kreibich wrote: would you guys consider changing the return value of the pcap_handler callbacks to typedef int (*pcap_handler)(u_char *, const struct pcap_pkthdr *, const u_char *); so that the callback gets a chance to stop a pcap_loop() or pcap_dispatch() iteration, say when returning 0 as opposed to 1? We might, if we also add new APIs to support the new callback. Changing the *current* API's would break all existing apps using pcap_loop() or pcap_dispatch(), as their callbacks return nothing and, if libpcap acts as if they do, the loop might randomly terminate depending on what value happens to be left in whatever location (a register, in most if not all ABI's) is used for the return value of an int function, so we won't consider doing that. I've repreatedly found that it'd be nice to remain in control over when to abort the loop. Does pcap_breakloop() not work? (It's not present in pre-0.8 versions of libpcap - but a different callback API isn't present in them, either, but it also isn't present in 0.8[.x].) - This is the TCPDUMP workers list. It is archived at http://www.tcpdump.org/lists/workers/index.html To unsubscribe use mailto:[EMAIL PROTECTED]
[tcpdump-workers] start of modularization of tcpdump
-BEGIN PGP SIGNED MESSAGE- Two and a half years ago, I rototiled a copy of tcpdump such that all of the globals were in a structure that got passed around. tcpdump's printers could be put into a library, which I called netdissect. I'm doing this again. This is what I've done: 1) moved all variables from tcpdump.c to a structure. 2) declare a global structure 3) declared a global pointer to this structure 4) created a tcpdump_printf() function as the printer, which the reworked code should use. 5) created netdissect.h, (actually used my old one) 6) created #define's at the end of interface.h, which map all the globals to gndo-ndo_X Old code will have an #include interface.h, while revised code will have just a #include netdissect.h. All printing functions should be modified to take: netdisssect_options *ndo as their first parameter. If you have to call a new style-function from an old-style function, then you may pass (for now) the value gndo. There are revised versions of TCHECK called ND_TCHECK() which assume the local parameter ndo is set up. The code compiles, but it does not pass all tests initially. It appears that this is because the proto parameter was introduced, and the tests were not updated. print-eap.c is the first (very simple, very stiupid) dissector with this code. I also fixed all the warnings that I saw. Unless there are objections, I'm going to check this code in. I've already committed print-eap.c and netdissect.h so you can see them. - -- ] ON HUMILITY: to err is human. To moo, bovine. | 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 iQCVAwUBQGJRbIqHRg3pndX9AQE8KgQAvBw27bvL5TSEGcrRb+BOyshoKs7gmhRj hS0DZ4hvHEl+nOVWocKESZ32syGfsg8yHfCRNVRIboFGhU9nLu8xJeahxdcGFYMO z99HYFm9Q7/wtq+d40P/5SggBuxwdJ6hqXP/SSdD7QBCZs2qZwtYtlyguzu2YS6h mf2GiSGoyHE= =6vsP -END PGP SIGNATURE- - This is the TCPDUMP workers list. It is archived at http://www.tcpdump.org/lists/workers/index.html To unsubscribe use mailto:[EMAIL PROTECTED]
[tcpdump-workers] Automatic report from sources (tcpdump libpcap htdocs) between 22.03.2004 - 23.03.2004 GMT
CVS log entries from 22.03.2004 (Mon) 10:05:50 - 23.03.2004 (Tue) 10:05:30 GMT = Summary by authors = Author: guy File: tcpdump/tcpdump.1; Revisions: 1.161 File: tcpdump/print-tcp.c; Revisions: 1.111 File: tcpdump/print-symantec.c; Revisions: 1.3 File: tcpdump/interface.h; Revisions: 1.225 File: tcpdump/tcpdump.c; Revisions: 1.237 File: tcpdump/print-snmp.c; Revisions: 1.59, 1.56.2.3 File: tcpdump/tcp.h; Revisions: 1.11 = Combined list of identical log entries = Description: Enterprise-specific traps have a generic trap number of 6, not 7; thanks to [EMAIL PROTECTED] to finding this. Modified files: File: tcpdump/print-snmp.c; Revision: 1.59; Date: 2004/03/23 06:59:15; Author: guy; Lines: (+2 -2) File: tcpdump/print-snmp.c; Revision: 1.56.2.3; Date: 2004/03/23 06:59:59; Author: guy; Lines: (+2 -2) --- Description: From Bruce M. Simpson: add a -M flag to specify a shared secret for TCP-MD5 (RFC 2385) digest verification if we have libcrypto. Modified files: File: tcpdump/interface.h; Revision: 1.225; Date: 2004/03/23 07:15:36; Author: guy; Lines: (+2 -1) File: tcpdump/print-tcp.c; Revision: 1.111; Date: 2004/03/23 07:15:36; Author: guy; Lines: (+75 -1) File: tcpdump/tcp.h; Revision: 1.11; Date: 2004/03/23 07:15:37; Author: guy; Lines: (+5 -1) File: tcpdump/tcpdump.1; Revision: 1.161; Date: 2004/03/23 07:15:37; Author: guy; Lines: (+10 -2) File: tcpdump/tcpdump.c; Revision: 1.237; Date: 2004/03/23 07:15:38; Author: guy; Lines: (+13 -4) = Log entries = Description: Fix a typo. We don't have source or destination MAC addresses in the Axent/Symantec firewall capture file, so we don't print them - therefore, we shouldn't put , before the Ethernet type. Modified files: File: tcpdump/print-symantec.c; Revision: 1.3; Date: 2004/03/22 20:02:01; Author: guy; Lines: (+6 -6) = Summary of modified files = File: tcpdump/interface.h Revisions: 1.225 Authors: guy (+2 -1) --- File: tcpdump/print-snmp.c Revisions: 1.59, 1.56.2.3 Authors: guy (+2 -2), guy (+2 -2) --- File: tcpdump/print-symantec.c Revisions: 1.3 Authors: guy (+6 -6) --- File: tcpdump/print-tcp.c Revisions: 1.111 Authors: guy (+75 -1) --- File: tcpdump/tcp.h Revisions: 1.11 Authors: guy (+5 -1) --- File: tcpdump/tcpdump.1 Revisions: 1.161 Authors: guy (+10 -2) --- File: tcpdump/tcpdump.c Revisions: 1.237 Authors: guy (+13 -4) -- Automatic cron job from /tcpdump/bin/makelog - This is the TCPDUMP workers list. It is archived at http://www.tcpdump.org/lists/workers/index.html To unsubscribe use mailto:[EMAIL PROTECTED]
Re: [tcpdump-workers] libpcap pcap_sendpacket support across platforms.
Michael Richardson wrote: okay. Can we call the next release libpcap 1.0 then? Anyone want to make any non-backwards compatible changes to the file format? A metadata packet-type would be useful. Then you could tag a file with the pcap expression it was captured with, along with other metadata. If it's just a packet type you can drop in new metadata wherever you like. -- Jefferson Ogata [EMAIL PROTECTED] NOAA Computer Incident Response Team (N-CIRT) [EMAIL PROTECTED] - This is the TCPDUMP workers list. It is archived at http://www.tcpdump.org/lists/workers/index.html To unsubscribe use mailto:[EMAIL PROTECTED]
Re: [tcpdump-workers] libpcap pcap_sendpacket support across platforms.
On Mar 23, 2004, at 12:09 PM, Michael Richardson wrote: -BEGIN PGP SIGNED MESSAGE- Guy == Guy Harris [EMAIL PROTECTED] writes: Guy I've merged your changes with a version I'd been working on, Guy based on libnet and some stuff we had at Network Appliance, and Guy checked the result in. It implements *two* APIs - Guy pcap_inject(), from OpenBSD, and pcap_sendpacket(), from Guy WinPcap. okay. Can we call the next release libpcap 1.0 then? Sounds good to me, although there are other API changes I'd want to make as well for a 1.0 release. Anyone want to make any non-backwards compatible changes to the file format? I think 1.0 should support the libpcap-next-generation format; I have some things to add, as have others. Both of these mean that 1.0 probably shouldn't come out in the immediate future, but we just did 0.8 so that's probably not a problem. - This is the TCPDUMP workers list. It is archived at http://www.tcpdump.org/lists/workers/index.html To unsubscribe use mailto:[EMAIL PROTECTED]
Re: [tcpdump-workers] libpcap pcap_sendpacket support across platforms.
Michael Richardson wrote: Guy == Guy Harris [EMAIL PROTECTED] writes: Guy I've merged your changes with a version I'd been working on, Guy based on libnet and some stuff we had at Network Appliance, and Guy checked the result in. It implements *two* APIs - Guy pcap_inject(), from OpenBSD, and pcap_sendpacket(), from Guy WinPcap. okay. Can we call the next release libpcap 1.0 then? Anyone want to make any non-backwards compatible changes to the file format? Might be nice to support different time-stamp formats officially somehow, e.g. AIX's nanosecond resolution timespec. Stephen. -- --- Stephen Donnelly BCMS PhD email: [EMAIL PROTECTED] Endace Technology Ltd phone: +64 7 839 0540 Hamilton, New Zealand cell: +64 21 1104378 --- - This is the TCPDUMP workers list. It is archived at http://www.tcpdump.org/lists/workers/index.html To unsubscribe use mailto:[EMAIL PROTECTED]
Re: [tcpdump-workers] libpcap pcap_sendpacket support across platforms.
On Mar 23, 2004, at 1:36 PM, Stephen Donnelly wrote: Might be nice to support different time-stamp formats officially somehow, e.g. AIX's nanosecond resolution timespec. Do we need arbitrary formats, or just seconds plus fractions of seconds? We could either make the time stamp format per-interface or per-file; doing the latter means that merging captures (as opposed to concatenating captures, as the file header record would specify the time stamp format of all subsequent packets until the next file header record) would require that we choose the highest-resolution format and convert time stamps in other formats to that format. We might also want the file header record to contain a capture start time (some other capture formats do) and perhaps that time represented as /MM/DD/HH/MM/SS.... - or perhaps the time zone name in, say, Arthur Olson format, in case somebody wants to know what time a packet arrived in local time on the machine on which the capture was done. - This is the TCPDUMP workers list. It is archived at http://www.tcpdump.org/lists/workers/index.html To unsubscribe use mailto:[EMAIL PROTECTED]
Re: [tcpdump-workers] libpcap pcap_sendpacket support across platforms.
Guy Harris wrote: On Mar 23, 2004, at 1:36 PM, Stephen Donnelly wrote: Might be nice to support different time-stamp formats officially somehow, e.g. AIX's nanosecond resolution timespec. Do we need arbitrary formats, or just seconds plus fractions of seconds? We could either make the time stamp format per-interface or per-file; doing the latter means that merging captures (as opposed to concatenating captures, as the file header record would specify the time stamp format of all subsequent packets until the next file header record) would require that we choose the highest-resolution format and convert time stamps in other formats to that format. We might also want the file header record to contain a capture start time (some other capture formats do) and perhaps that time represented as /MM/DD/HH/MM/SS.... - or perhaps the time zone name in, say, Arthur Olson format, in case somebody wants to know what time a packet arrived in local time on the machine on which the capture was done. Interesting thoughts. I agree a wall-time in the file-header may be useful. Is it assumed that libpcap now always uses UTC for timezone? I'm thinking there are 3 common formats used for timestamps today, the timeval (unix sec,microsec) by libpcap, timespec (unix sec,nanosec) by AIX libpcap(?), and the Endace 64-bit fixed-point format (unix sec,fraction). All these formats use 64 bits total. I don't know about WinPcap. At present when producing libpcap format traces from Endace format, we convert our timestamps to timeval format, which is both expensive and loses considerable precision. Are we trying to converge on one time-stamp format for libpcap-ng, or allowing the use of various formats, with some indication of which format per file/interface, and the problems of merging traces? Would libpcap offer time-stamp conversion routines for programs that don't understand various ones, and allow them to select? Stephen. -- --- Stephen Donnelly BCMS PhD email: [EMAIL PROTECTED] Endace Technology Ltd phone: +64 7 839 0540 Hamilton, New Zealand cell: +64 21 1104378 --- - This is the TCPDUMP workers list. It is archived at http://www.tcpdump.org/lists/workers/index.html To unsubscribe use mailto:[EMAIL PROTECTED]
Re: [tcpdump-workers] libpcap pcap_sendpacket support across platforms.
On Mar 23, 2004, at 4:53 PM, Stephen Donnelly wrote: Interesting thoughts. I agree a wall-time in the file-header may be useful. Is it assumed that libpcap now always uses UTC for timezone? Yes. I'm thinking there are 3 common formats used for timestamps today, the timeval (unix sec,microsec) by libpcap, timespec (unix sec,nanosec) by AIX libpcap(?), and the Endace 64-bit fixed-point format (unix sec,fraction). All these formats use 64 bits total. I don't know about WinPcap. WinPcap uses UNIX-style time stamps. At present when producing libpcap format traces from Endace format, we convert our timestamps to timeval format, which is both expensive and loses considerable precision. Are we trying to converge on one time-stamp format for libpcap-ng, or allowing the use of various formats, with some indication of which format per file/interface, and the problems of merging traces? I don't think I'd require one format - libpcap format already does some receiver makes it right stuff, i.e. the file is written out in the byte order of the machine writing it, and it's the job of the code reading it to byte-swap as necessary. Would libpcap offer time-stamp conversion routines for programs that don't understand various ones, and allow them to select? It might make sense to have a libpcap format that's UNIX seconds plus nanoseconds (or picoseconds, or more?) and to offer a routine that takes a time stamp pointer (perhaps a union pointer) and a time stamp type and returns a time stamp in the libpcap format. - This is the TCPDUMP workers list. It is archived at http://www.tcpdump.org/lists/workers/index.html To unsubscribe use mailto:[EMAIL PROTECTED]
Re: [tcpdump-workers] libpcap pcap_sendpacket support across platforms.
Richard == Richard Sharpe [EMAIL PROTECTED] writes: Richard Hmmm, does that mean that something has gelled in that Richard regard, or are we just starting to talk about it? We are just starting, but I think we have talked a lot about it in the past that we should come to a pretty quick conclusion. -- ] ON HUMILITY: to err is human. To moo, bovine. | 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); [ - This is the TCPDUMP workers list. It is archived at http://www.tcpdump.org/lists/workers/index.html To unsubscribe use mailto:[EMAIL PROTECTED]
Re: [tcpdump-workers] libpcap pcap_sendpacket support across platforms.
So, libpcap would provide the packet write function, with libnet providing the construct packet function right? -- ] ON HUMILITY: to err is human. To moo, bovine. | 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); [ - This is the TCPDUMP workers list. It is archived at http://www.tcpdump.org/lists/workers/index.html To unsubscribe use mailto:[EMAIL PROTECTED]
[tcpdump-workers] proposed new pcap format
-BEGIN PGP SIGNED MESSAGE-
This is what I would propose as revision.
Note that the pcap1_packet_header is present on every packet. One can
merge pcap files together with cat if one likes.
A suggestion was made to accomodate the nano-second resolution from AIX.
Can you tell me what they do for that? just more bits, sure, but is
there a nano-seconds (32-bits, I guess) + seconds (64 bits?).
enum pcap1_info_types {
PCAP_DATACAPTURE,
PCAP_TIMESTAMP,
};
struct pcap1_info_container {
bpf_u_int32 info_len; /* in bytes */
bpf_u_int32 info_type;/* enum pcap1_info_types */
unsigned char info_data[0];
};
struct pcap1_info_timestamp {
struct pcap1_info_container pic;
bpf_int32 thiszone;/* gmt to local correction */
struct timeval ts; /* time stamp */
bpf_u_int32 sigfigs;/* accuracy of timestamps */
};
struct pcap1_info_packet {
struct pcap1_info_container pic;
bpf_u_int32 caplen; /* length of portion present */
bpf_u_int32 len;/* length this packet (off wire) */
bpf_u_int32 linktype; /* data link type (LINKTYPE_*) */
unsigned char packet_data[0];
};
struct pcap1_packet_header {
bpf_u_int32 magic;
u_short version_major;
u_short version_minor;
bpf_u_int32 block_len;
struct pcap1_info_container pics[0];
};
- --
] ON HUMILITY: to err is human. To moo, bovine. | 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
iQCVAwUBQGDqJoqHRg3pndX9AQGBxQQA0VQCx+5wekBavlTrGr/AFcpusN81Ecck
eQ3wbumeyRBRzt0N8bfCLoyA+BycHDCXE30Y7DCLODPFe7LUL1/BJelNgiAz2MJE
r1Nlg7JBe9X/jHNsZzzjhTlpK8UFLSYCgelQSSP1c0XtWWdrAO8yMTcTqn9Jz/4E
A7gaQb7ONb4=
=iLaD
-END PGP SIGNATURE-
-
This is the TCPDUMP workers list. It is archived at
http://www.tcpdump.org/lists/workers/index.html
To unsubscribe use mailto:[EMAIL PROTECTED]
Re: [tcpdump-workers] libpcap pcap_sendpacket support across platforms.
The attached revised pcap-bpf.c now addresses the BIOCSHDRCMPLT issue you noticed. - Mark Pizzolato - Original Message - From: Mark Pizzolato [EMAIL PROTECTED] To: Guy Harris [EMAIL PROTECTED] Cc: Mike Schiffman [EMAIL PROTECTED]; TCPdump Workers [EMAIL PROTECTED] Sent: Tuesday, March 23, 2004 4:56 PM Subject: Re: [tcpdump-workers] libpcap pcap_sendpacket support across platforms. On Tuesday, March 23, 2004 11:22 AM, Guy Harris wrote: Attached is a revised patch, which keeps prior behaviors, while also providing for pcap_sendpacket when possible. I've merged your changes with a version I'd been working on, based on libnet and some stuff we had at Network Appliance, and checked the result in. It implements *two* APIs - pcap_inject(), from OpenBSD, and pcap_sendpacket(), from WinPcap. Some issues: on BPF, libpcap doesn't do anything with BIOCSHDRCMPLT - libnet does; Good catch. I still had that in my application code. on DLPI, there's #if'ed-out code to use the appropriate raw data primitives on HP-UX - I don't have access to an HP-UX system on which to test them; I don't have access either. What I sent does work on Solaris 8 (Both Intel and Sparc). on Linux, the version I checked in uses sendto(), as that's what libnet did; H.. I didn't check with libnet since I had simple working code with a very basic send(). What you checked in is broken. It has an extra right paren on line 687, and after that is fixed, line 725 refers to an undefined sa instead of sa_pkt. The attached cleans things up a bit. I wonder where the sendto() stuff is really necessary. The simple send() worked for us on RH 7.3-Fedora Core1 on Intel. And RH 6.2 on Sparc, and numerous other linux environments. We've never gotten a complaint on SunOS 4.x with STREAMS NIT, the code I checked in uses putmsg() - libnet and your code used sendto(), but, as I remember, the Network Appliance code used putmsg(), which is what I'd expect to be the correct call to use on a STREAMS-based mechanism. Since I didn't have any other reference and don't have a test environment, I worked from what I presumed to be correct in libnet. /* * Copyright (c) 1993, 1994, 1995, 1996, 1998 * The Regents of the University of California. All rights reserved. * * Redistribution and use in source and binary forms, with or without * modification, are permitted provided that: (1) source code distributions * retain the above copyright notice and this paragraph in its entirety, (2) * distributions including binary code include the above copyright notice and * this paragraph in its entirety in the documentation or other materials * provided with the distribution, and (3) all advertising materials mentioning * features or use of this software display the following acknowledgement: * ``This product includes software developed by the University of California, * Lawrence Berkeley Laboratory and its contributors.'' Neither the name of * the University nor the names of its contributors may be used to endorse * or promote products derived from this software without specific prior * written permission. * THIS SOFTWARE IS PROVIDED ``AS IS'' AND WITHOUT ANY EXPRESS OR IMPLIED * WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED WARRANTIES OF * MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE. */ #ifndef lint static const char rcsid[] _U_ = @(#) $Header: /tcpdump/master/libpcap/pcap-bpf.c,v 1.74 2004/03/23 19:18:04 guy Exp $ (LBL); #endif #ifdef HAVE_CONFIG_H #include config.h #endif #include sys/param.h /* optionally get BSD define */ #include sys/time.h #include sys/timeb.h #include sys/socket.h #include sys/file.h #include sys/ioctl.h #include sys/utsname.h #include net/if.h #ifdef _AIX /* * Make pcap.h not include pcap-bpf.h; we are going to include the * native OS version, as we need struct bpf_config from it. */ #define PCAP_DONT_INCLUDE_PCAP_BPF_H #include sys/types.h /* * Prevent bpf.h from redefining the DLT_ values to their * IFT_ values, as we're going to return the standard libpcap * values, not IBM's non-standard IFT_ values. */ #undef _AIX #include net/bpf.h #define _AIX #include net/if_types.h /* for IFT_ values */ #include sys/sysconfig.h #include sys/device.h #include odmi.h #include cf.h #ifdef __64BIT__ #define domakedev makedev64 #define getmajor major64 #define bpf_hdr bpf_hdr32 #else /* __64BIT__ */ #define domakedev makedev #define getmajor major #endif /* __64BIT__ */ #define BPF_NAME bpf #define BPF_MINORS 4 #define DRIVER_PATH /usr/lib/drivers #define BPF_NODE /dev/bpf static int bpfloadedflag = 0; static int odmlockid = 0; #else /* _AIX */ #include net/bpf.h #endif /* _AIX */ #include ctype.h #include errno.h #include netdb.h #include stdio.h #include stdlib.h #include string.h #include unistd.h #include pcap-int.h #ifdef HAVE_DAG_API #include pcap-dag.h #endif /*
Re: [tcpdump-workers] proposed new pcap format
On Mar 23, 2004, at 5:53 PM, Michael Richardson wrote:
This is what I would propose as revision.
Note that the pcap1_packet_header is present on every packet. One can
merge pcap files together with cat if one likes.
OK - that's a bit much to write for every packet, though, as most of it
is redundant.
Does each record have a pcap1_packet_header and *one*
pcap1_info_container, or one or more up to block_len bytes? If the
latter, you could have more than one packet per pcap1_packet header.
A suggestion was made to accomodate the nano-second resolution from
AIX.
Can you tell me what they do for that? just more bits, sure, but is
there a nano-seconds (32-bits, I guess) + seconds (64 bits?).
32-bit seconds, 32-bit nanoseconds.
enum pcap1_info_types {
PCAP_DATACAPTURE,
PCAP_TIMESTAMP,
};
...with that list presumably being expandable over time.
struct pcap1_info_container {
bpf_u_int32 info_len; /* in bytes */
bpf_u_int32 info_type;/* enum pcap1_info_types */
unsigned char info_data[0];
};
struct pcap1_info_timestamp {
struct pcap1_info_container pic;
bpf_int32 thiszone;/* gmt to local correction */
We currently have that but don't use it - it's always zero. Should we
start using it?
struct timeval ts; /* time stamp */
bpf_u_int32 sigfigs;/* accuracy of timestamps */
Similarly, that's never been set - should we start using it?
-
This is the TCPDUMP workers list. It is archived at
http://www.tcpdump.org/lists/workers/index.html
To unsubscribe use mailto:[EMAIL PROTECTED]
Re: [tcpdump-workers] proposed new pcap format
Michael Richardson wrote:
This is what I would propose as revision.
Note that the pcap1_packet_header is present on every packet. One can
merge pcap files together with cat if one likes.
That's a nice feature, and one we should try to maintain if possible.
A suggestion was made to accomodate the nano-second resolution from AIX.
Can you tell me what they do for that? just more bits, sure, but is
there a nano-seconds (32-bits, I guess) + seconds (64 bits?).
enum pcap1_info_types {
PCAP_DATACAPTURE,
PCAP_TIMESTAMP,
};
struct pcap1_info_container {
bpf_u_int32 info_len; /* in bytes */
bpf_u_int32 info_type;/* enum pcap1_info_types */
That could be two int16s, couldn't it?
unsigned char info_data[0];
};
struct pcap1_info_timestamp {
struct pcap1_info_container pic;
bpf_int32 thiszone;/* gmt to local correction */
I feel strongly that all pcap timestamps should be UTC. Think of it like
UNIX file metadata; timestamps in inodes are UTC. Your local zone is an
interpretion applied to those timestamps.
If this is meant to handle the wall time notion proposed a few
messages back, I think that is just metadata and should go in a metadata
packet. Maybe there should be some standard metadata types.
In addition, represented as metadata, I think zone information should be
an Olsen zone name. There should be another metadata type for time error
offset. Thus if you have a capture from a system with an unsynchronized
clock, you could retrospectively insert a metadata packet at the
beginning indicating the system's time error offset. Then programs that
read it can adjust timestamps on the fly.
Also, it would redundant to put zone info in each timestamp.
struct timeval ts; /* time stamp */
bpf_u_int32 sigfigs;/* accuracy of timestamps */
};
Significant figures in what base? I wouldn't go there.
--
Jefferson Ogata [EMAIL PROTECTED]
NOAA Computer Incident Response Team (N-CIRT) [EMAIL PROTECTED]
-
This is the TCPDUMP workers list. It is archived at
http://www.tcpdump.org/lists/workers/index.html
To unsubscribe use mailto:[EMAIL PROTECTED]
Re: [tcpdump-workers] libpcap pcap_sendpacket support across platforms.
Guy Harris wrote: I'm thinking there are 3 common formats used for timestamps today, the timeval (unix sec,microsec) by libpcap, timespec (unix sec,nanosec) by AIX libpcap(?), and the Endace 64-bit fixed-point format (unix sec,fraction). All these formats use 64 bits total. I don't know about WinPcap. WinPcap uses UNIX-style time stamps. I don't think I'd require one format - libpcap format already does some receiver makes it right stuff, i.e. the file is written out in the byte order of the machine writing it, and it's the job of the code reading it to byte-swap as necessary. Right, although preferably with some indication in the trace/record as to which is in use to make the decision easier. Would libpcap offer time-stamp conversion routines for programs that don't understand various ones, and allow them to select? It might make sense to have a libpcap format that's UNIX seconds plus nanoseconds (or picoseconds, or more?) and to offer a routine that takes a time stamp pointer (perhaps a union pointer) and a time stamp type and returns a time stamp in the libpcap format. Sounds reasonable to me, allows potentially different formats with aware applications getting the advantage, and unaware applications getting compatibility (at some cost). Perhaps have an interface like 'query_timestamp_format', then if you don't like (or understand) the time, request a conversion to the best type you do support. backwards compatibility could be by providing conversion to least-common-denominator format through the legacy pcap APIs (if legacy API support is envisaged). This could be similar to the pcap_list_datalinks() pcap_set_datalink() approach. Stephen. -- --- Stephen Donnelly BCMS PhD email: [EMAIL PROTECTED] Endace Technology Ltd phone: +64 7 839 0540 Hamilton, New Zealand cell: +64 21 1104378 --- - This is the TCPDUMP workers list. It is archived at http://www.tcpdump.org/lists/workers/index.html To unsubscribe use mailto:[EMAIL PROTECTED]
Re: [tcpdump-workers] libpcap pcap_sendpacket support across platforms.
On Tue, Mar 23, 2004 at 05:59:48PM -0800, Mark Pizzolato wrote: The attached revised pcap-bpf.c now addresses the BIOCSHDRCMPLT issue you noticed. Checked in. - This is the TCPDUMP workers list. It is archived at http://www.tcpdump.org/lists/workers/index.html To unsubscribe use mailto:[EMAIL PROTECTED]
Re: [tcpdump-workers] libpcap pcap_sendpacket support across platforms.
On Tue, Mar 23, 2004 at 04:56:43PM -0800, Mark Pizzolato wrote: on Linux, the version I checked in uses sendto(), as that's what libnet did; H.. I didn't check with libnet since I had simple working code with a very basic send(). What you checked in is broken. It has an extra right paren on line 687, and after that is fixed, line 725 refers to an undefined sa instead of sa_pkt. The attached cleans things up a bit. Checked in. I wonder where the sendto() stuff is really necessary. The simple send() worked for us on RH 7.3-Fedora Core1 on Intel. And RH 6.2 on Sparc, and numerous other linux environments. We've never gotten a complaint Mike S.? Is the sendto() just there because libnet doesn't bind the socket? If so, a send() would work. on SunOS 4.x with STREAMS NIT, the code I checked in uses putmsg() - libnet and your code used sendto(), but, as I remember, the Network Appliance code used putmsg(), which is what I'd expect to be the correct call to use on a STREAMS-based mechanism. Since I didn't have any other reference and don't have a test environment, I worked from what I presumed to be correct in libnet. Mike S.? Does the libnet code work on SunOS 4.x? I'm not sure a sendto() would work on a STREAMS NIT descriptor in 4.x. In FreeBSD 3.4, it only works on sockets; if that's the way it's been in BSD for a while, that might be how it was in 4.x - I don't remember support for it being added for non-socket descriptors in 4.0. - This is the TCPDUMP workers list. It is archived at http://www.tcpdump.org/lists/workers/index.html To unsubscribe use mailto:[EMAIL PROTECTED]
[tcpdump-workers] Automatic report from sources (tcpdump libpcap htdocs) between 20.03.2004 - 21.03.2004 GMT
CVS log entries from 20.03.2004 (Sat) 10:05:50 - 21.03.2004 (Sun) 10:05:47 GMT = Summary by authors = Author: guy File: tcpdump/win32/prj/WinDump.dsp; Revisions: 1.10.2.2 File: libpcap/pcap-snoop.c; Revisions: 1.51, 1.45.2.5 File: libpcap/pcap-nit.c; Revisions: 1.55, 1.50.2.4 File: tcpdump/win32/prj/GNUmakefile; Revisions: 1.6.2.3 = Combined list of identical log entries = Description: Fix cut-and-pasteos; thanks to Darren Reed for finding them. Modified files: File: libpcap/pcap-nit.c; Revision: 1.55; Date: 2004/03/21 08:32:05; Author: guy; Lines: (+2 -2) File: libpcap/pcap-nit.c; Revision: 1.50.2.4; Date: 2004/03/21 08:33:23; Author: guy; Lines: (+2 -2) File: libpcap/pcap-snoop.c; Revision: 1.51; Date: 2004/03/21 08:32:06; Author: guy; Lines: (+7 -7) File: libpcap/pcap-snoop.c; Revision: 1.45.2.5; Date: 2004/03/21 08:33:24; Author: guy; Lines: (+2 -2) = Log entries = Description: Propagate from the main branch revision 1.10 date: 2004/03/19 21:37:49; author: risso; state: Exp; lines: +2 -0 Added oui.c, print-ap1394.c and print-symantec.c to the Windows project. Modified files: File: tcpdump/win32/prj/GNUmakefile; Revision: 1.6.2.3; Date: 2004/03/20 19:31:08; Author: guy; Lines: (+2 -0) --- Description: Propagate revision 1.12 date: 2004/03/19 21:37:49; author: risso; state: Exp; lines: +12 -0 Added oui.c, print-ap1394.c and print-symantec.c to the Windows project. to the 3.8 branch. Modified files: File: tcpdump/win32/prj/WinDump.dsp; Revision: 1.10.2.2; Date: 2004/03/20 19:26:57; Author: guy; Lines: (+12 -0) = Summary of modified files = File: libpcap/pcap-nit.c Revisions: 1.55, 1.50.2.4 Authors: guy (+2 -2), guy (+2 -2) --- File: libpcap/pcap-snoop.c Revisions: 1.51, 1.45.2.5 Authors: guy (+7 -7), guy (+2 -2) --- File: tcpdump/win32/prj/GNUmakefile Revisions: 1.6.2.3 Authors: guy (+2 -0) --- File: tcpdump/win32/prj/WinDump.dsp Revisions: 1.10.2.2 Authors: guy (+12 -0) -- Automatic cron job from /tcpdump/bin/makelog - This is the TCPDUMP workers list. It is archived at http://www.tcpdump.org/lists/workers/index.html To unsubscribe use mailto:[EMAIL PROTECTED]
[tcpdump-workers] Automatic report from sources (tcpdump libpcap htdocs) between 19.03.2004 - 20.03.2004 GMT
CVS log entries from 19.03.2004 (Fri) 10:05:53 - 20.03.2004 (Sat) 10:05:50 GMT = Summary by authors = Author: risso File: tcpdump/win32/prj/WinDump.dsp; Revisions: 1.12 File: tcpdump/win32/prj/GNUmakefile; Revisions: 1.10 File: tcpdump/tcpdump.c; Revisions: 1.236 = Combined list of identical log entries = Description: Added oui.c, print-ap1394.c and print-symantec.c to the Windows project. Modified files: File: tcpdump/win32/prj/GNUmakefile; Revision: 1.10; Date: 2004/03/19 21:37:49; Author: risso; Lines: (+2 -0) File: tcpdump/win32/prj/WinDump.dsp; Revision: 1.12; Date: 2004/03/19 21:37:49; Author: risso; Lines: (+12 -0) = Log entries = Description: Exclude droproot from Win32, since it's not used and it prevents the compilation of tcpdump.c. Modified files: File: tcpdump/tcpdump.c; Revision: 1.236; Date: 2004/03/19 21:36:35; Author: risso; Lines: (+5 -1) = Summary of modified files = File: tcpdump/tcpdump.c Revisions: 1.236 Authors: risso (+5 -1) --- File: tcpdump/win32/prj/GNUmakefile Revisions: 1.10 Authors: risso (+2 -0) --- File: tcpdump/win32/prj/WinDump.dsp Revisions: 1.12 Authors: risso (+12 -0) -- Automatic cron job from /tcpdump/bin/makelog - This is the TCPDUMP workers list. It is archived at http://www.tcpdump.org/lists/workers/index.html To unsubscribe use mailto:[EMAIL PROTECTED]
[tcpdump-workers] pcap-snoop.c doesn't compile...
Line 260, handle is undefined. Should these all be p ? Darren - This is the TCPDUMP workers list. It is archived at http://www.tcpdump.org/lists/workers/index.html To unsubscribe use mailto:[EMAIL PROTECTED]
[tcpdump-workers] Automatic report from sources (tcpdump libpcap htdocs) between 18.03.2004 - 19.03.2004 GMT
CVS log entries from 18.03.2004 (Thu) 10:05:58 - 19.03.2004 (Fri) 10:05:53 GMT = Summary by authors = Author: guy File: tcpdump/addrtoname.c; Revisions: 1.103 Author: hannes File: tcpdump/print-pim.c; Revisions: 1.42 File: tcpdump/print-isoclns.c; Revisions: 1.118 File: tcpdump/print-bgp.c; Revisions: 1.80 File: tcpdump/print-ppp.c; Revisions: 1.93 = Log entries = Description: Don't omit leading 0's when displaying the bytes of an address in linkaddr_string() - we don't do it in etheraddr_string(). Modified files: File: tcpdump/addrtoname.c; Revision: 1.103; Date: 2004/03/18 21:01:39; Author: guy; Lines: (+4 -6) --- Description: add recent IANA SAFI and CAP codepoints - FIXME: add decoder Modified files: File: tcpdump/print-bgp.c; Revision: 1.80; Date: 2004/03/18 11:14:45; Author: hannes; Lines: (+13 -1) --- Description: display cosmetics: hide OSI indication under the eflag Modified files: File: tcpdump/print-isoclns.c; Revision: 1.118; Date: 2004/03/18 10:58:17; Author: hannes; Lines: (+2 -2) --- Description: provide multiline output for PIM Joins/Grafts/Graft-Acks Modified files: File: tcpdump/print-pim.c; Revision: 1.42; Date: 2004/03/18 14:12:18; Author: hannes; Lines: (+49 -13) --- Description: display cosmetics: remove the PPP- string from proto output Modified files: File: tcpdump/print-ppp.c; Revision: 1.93; Date: 2004/03/18 10:59:15; Author: hannes; Lines: (+2 -2) = Summary of modified files = File: tcpdump/addrtoname.c Revisions: 1.103 Authors: guy (+4 -6) --- File: tcpdump/print-bgp.c Revisions: 1.80 Authors: hannes (+13 -1) --- File: tcpdump/print-isoclns.c Revisions: 1.118 Authors: hannes (+2 -2) --- File: tcpdump/print-pim.c Revisions: 1.42 Authors: hannes (+49 -13) --- File: tcpdump/print-ppp.c Revisions: 1.93 Authors: hannes (+2 -2) -- Automatic cron job from /tcpdump/bin/makelog - This is the TCPDUMP workers list. It is archived at http://www.tcpdump.org/lists/workers/index.html To unsubscribe use mailto:[EMAIL PROTECTED]
[tcpdump-workers] Request response
- This is the TCPDUMP workers list. It is archived at http://www.tcpdump.org/lists/workers/index.html To unsubscribe use mailto:[EMAIL PROTECTED]
[tcpdump-workers] Re: Hi
- This is the TCPDUMP workers list. It is archived at http://www.tcpdump.org/lists/workers/index.html To unsubscribe use mailto:[EMAIL PROTECTED]
[tcpdump-workers] Automatic report from sources (tcpdump libpcap htdocs) between 17.03.2004 - 18.03.2004 GMT
CVS log entries from 17.03.2004 (Wed) 10:05:45 - 18.03.2004 (Thu) 10:05:58 GMT = Summary by authors = Author: guy File: libpcap/gencode.c; Revisions: 1.201, 1.193.2.6 File: libpcap/pcap.c; Revisions: 1.72, 1.63.2.8 File: tcpdump/print-token.c; Revisions: 1.25 File: tcpdump/print-null.c; Revisions: 1.52 File: tcpdump/print-lane.c; Revisions: 1.23 File: tcpdump/print-arcnet.c; Revisions: 1.18 File: tcpdump/print-ipfc.c; Revisions: 1.7 File: tcpdump/print-fddi.c; Revisions: 1.64 File: tcpdump/print-atm.c; Revisions: 1.36 File: tcpdump/interface.h; Revisions: 1.224, 1.217.2.5 File: tcpdump/print-sunatm.c; Revisions: 1.8 File: tcpdump/.cvsignore; Revisions: 1.4 File: tcpdump/INSTALL; Revisions: 1.60, 1.56.2.3 File: tcpdump/print-sll.c; Revisions: 1.15 File: tcpdump/print-802_11.c; Revisions: 1.29 File: tcpdump/print-symantec.c; Revisions: 1.2 File: libpcap/pcap-bpf.h; Revisions: 1.18, 1.9.2.8 File: tcpdump/FILES; Revisions: 1.61, 1.55.2.4 File: tcpdump/print-cip.c; Revisions: 1.24 File: tcpdump/tcpdump.c; Revisions: 1.235, 1.216.2.10 File: tcpdump/Makefile.in; Revisions: 1.281, 1.276.2.3 File: tcpdump/print-ether.c; Revisions: 1.89 File: tcpdump/print-ap1394.c; Revisions: 1.3, 1.2, 1.1, 1.1.2.1 Author: hannes File: tcpdump/print-ip.c; Revisions: 1.133 = Combined list of identical log entries = Description: Add support for Apple's IP-over-IEEE 1394 encapsulation. Fix a comment. Modified files: File: libpcap/gencode.c; Revision: 1.201; Date: 2004/03/17 19:03:28; Author: guy; Lines: (+7 -1) File: libpcap/gencode.c; Revision: 1.193.2.6; Date: 2004/03/17 19:05:20; Author: guy; Lines: (+7 -1) File: libpcap/pcap-bpf.h; Revision: 1.18; Date: 2004/03/17 19:03:29; Author: guy; Lines: (+5 -5) File: libpcap/pcap-bpf.h; Revision: 1.9.2.8; Date: 2004/03/17 19:05:21; Author: guy; Lines: (+5 -5) File: libpcap/pcap.c; Revision: 1.72; Date: 2004/03/17 19:03:29; Author: guy; Lines: (+2 -1) File: libpcap/pcap.c; Revision: 1.63.2.8; Date: 2004/03/17 19:05:21; Author: guy; Lines: (+2 -1) --- Description: Add support for the -e flag, printing the destination and source addresses. Modified files: File: tcpdump/print-ap1394.c; Revision: 1.2; Date: 2004/03/17 22:11:34; Author: guy; Lines: (+28 -1) File: tcpdump/print-ap1394.c; Revision: 1.1.2.1; Date: 2004/03/17 22:15:53; Author: guy; Lines: (+28 -1) --- Description: Add support for Apple's IP-over-IEEE 1394 encapsulation. Modified files: File: tcpdump/FILES; Revision: 1.61; Date: 2004/03/17 19:40:41; Author: guy; Lines: (+1 -0) File: tcpdump/FILES; Revision: 1.55.2.4; Date: 2004/03/17 19:47:47; Author: guy; Lines: (+1 -0) File: tcpdump/INSTALL; Revision: 1.60; Date: 2004/03/17 19:40:41; Author: guy; Lines: (+2 -1) File: tcpdump/INSTALL; Revision: 1.56.2.3; Date: 2004/03/17 19:47:47; Author: guy; Lines: (+2 -1) File: tcpdump/Makefile.in; Revision: 1.281; Date: 2004/03/17 19:40:41; Author: guy; Lines: (+3 -3) File: tcpdump/Makefile.in; Revision: 1.276.2.3; Date: 2004/03/17 19:47:47; Author: guy; Lines: (+3 -3) File: tcpdump/interface.h; Revision: 1.224; Date: 2004/03/17 19:40:41; Author: guy; Lines: (+3 -3) File: tcpdump/interface.h; Revision: 1.217.2.5; Date: 2004/03/17 19:47:48; Author: guy; Lines: (+3 -3) File: tcpdump/print-ap1394.c; Revision: 1.1; Date: 2004/03/17 19:40:42; Author: guy; File: tcpdump/tcpdump.c; Revision: 1.235; Date: 2004/03/17 19:40:42; Author: guy; Lines: (+4 -1) File: tcpdump/tcpdump.c; Revision: 1.216.2.10; Date: 2004/03/17 19:47:48; Author: guy; Lines: (+4 -1) --- Description: Fix up a bunch of comments - the on-the-wire length field in a pcap_pkthdr is len, not length. Modified files: File: tcpdump/print-802_11.c; Revision: 1.29; Date: 2004/03/17 23:24:35; Author: guy; Lines: (+2 -2) File: tcpdump/print-ap1394.c; Revision: 1.3; Date: 2004/03/17 23:24:35; Author: guy; Lines: (+2 -2) File: tcpdump/print-arcnet.c; Revision: 1.18; Date: 2004/03/17 23:24:35; Author: guy; Lines: (+3 -3) File: tcpdump/print-atm.c; Revision: 1.36; Date: 2004/03/17 23:24:36; Author: guy; Lines: (+2 -2) File: tcpdump/print-cip.c; Revision: 1.24; Date: 2004/03/17 23:24:36; Author: guy; Lines: (+2 -2) File:
[tcpdump-workers] Automatic report from sources (tcpdump libpcap htdocs) between 16.03.2004 - 17.03.2004 GMT
CVS log entries from 16.03.2004 (Tue) 10:05:43 - 17.03.2004 (Wed) 10:05:45 GMT = Summary by authors = Author: hannes File: tcpdump/print-bgp.c; Revisions: 1.79 Author: risso File: libpcap/savefile.c; Revisions: 1.105 = Log entries = Description: Avoid a null pointer access in pcap_dump_open if fname is a read only file Modified files: File: libpcap/savefile.c; Revision: 1.105; Date: 2004/03/16 19:27:55; Author: risso; Lines: (+4 -2) --- Description: print type 2 route distinguishers in IP adress format Modified files: File: tcpdump/print-bgp.c; Revision: 1.79; Date: 2004/03/16 11:39:59; Author: hannes; Lines: (+6 -7) = Summary of modified files = File: libpcap/savefile.c Revisions: 1.105 Authors: risso (+4 -2) --- File: tcpdump/print-bgp.c Revisions: 1.79 Authors: hannes (+6 -7) -- Automatic cron job from /tcpdump/bin/makelog - This is the TCPDUMP workers list. It is archived at http://www.tcpdump.org/lists/workers/index.html To unsubscribe use mailto:[EMAIL PROTECTED]
[tcpdump-workers] A little problem with libpcap netfilter
Hi, I'm coding a little app which grabs UDP packets. As i like libpcap :), i've used it to do this job. It works fine, but i've a little problem (in my case) : libpcap works before netfilter hooks. I capture them using pcap_loop. I just want to know if there is a way to tell libpcap to work after netfilter hooks, in order to filter incoming packets. My wish is to limit the amount of incoming packets, because i'm afraid of denial of services... Thanks. Pierre -- Pierre BETOUIN http://securitech.homeunix.org http://www.challenge-securitech.com GnuPG key : E7AD 29A1 7345 5BA0 9469 DE62 2CD5 9242 94D9 CB23 lynx -dump securitech.homeunix.org/pbetouin.asc | gpg --import signature.asc Description: Ceci est une partie de message =?ISO-8859-1?Q?num=E9riquement?= =?ISO-8859-1?Q?_sign=E9e=2E?=
[tcpdump-workers] Re: Thank you!
- This is the TCPDUMP workers list. It is archived at http://www.tcpdump.org/lists/workers/index.html To unsubscribe use mailto:[EMAIL PROTECTED]
[tcpdump-workers] Automatic report from sources (tcpdump libpcap htdocs) between 14.03.2004 - 15.03.2004 GMT
CVS log entries from 14.03.2004 (Sun) 10:05:55 - 15.03.2004 (Mon) 10:06:08 GMT = Summary by authors = Author: hannes File: tcpdump/print-bgp.c; Revisions: 1.78 = Log entries = Description: add support for the cisco proprietary MDT Group Extended Community Modified files: File: tcpdump/print-bgp.c; Revision: 1.78; Date: 2004/03/14 21:10:37; Author: hannes; Lines: (+8 -1) = Summary of modified files = File: tcpdump/print-bgp.c Revisions: 1.78 Authors: hannes (+8 -1) -- Automatic cron job from /tcpdump/bin/makelog - This is the TCPDUMP workers list. It is archived at http://www.tcpdump.org/lists/workers/index.html To unsubscribe use mailto:[EMAIL PROTECTED]
[tcpdump-workers] is there an easy way to get TZ from a dump file?
hi, is there an easy way to get the timezone information from the libpcap dump file? timezone info is in the pcap_t but you can't dereference it. i could do a pointer offset to tz in pcap_t, but just wondering if there is better way? thank you, -alexm 12:47 15/03/2004 - This is the TCPDUMP workers list. It is archived at http://www.tcpdump.org/lists/workers/index.html To unsubscribe use mailto:[EMAIL PROTECTED]
Re: [tcpdump-workers] libpcap pcap_sendpacket support across platforms.
On Mar 12, 2004, at 11:33 AM, Guy Harris wrote: On Mar 12, 2004, at 2:03 AM, Mark Pizzolato wrote: I've been working on a system simulator (simh http://simh.trailing-edge.com) which provides ethernet device emulation for the systems which originally had ethernet devices (i.e. vax, pdp11 and pdp10). The ethernet support for this package was originally implemented on Windows with Winpcap, and then ported back to other platforms leveraging the generic libpcap capabilities. The only lacking piece here, from an API poinit of view, has been pcap_sendpacket. Just to get by, we've had platform specific network code in the layer which uses libpcap to provide a pcap_sendpacket for the non Windows platforms. This only solves part of the problem since several platforms use pcap-bpf.c or pcap-pf.c or pcap-snit.c which open the network device O_RDONLY. To get useful functionality on these platforms, we've needed to hack pcap-bpf.c, or pcap-pf.c or pcap-snit.c and change O_RDONLY to O_RDWR. If would seem that the right thing to do is to generically include pcap_sendpacket and the related open requirements in the base pcap library. Well, the right thing to do is not necessarily to change O_RDONLY to O_RDWR, as that would mean you can't give people capture but not send privileges on BPF platforms by giving them read but not write access to the BPF devices. Good point! However, that problem can easily be solved with the following: [...] fd = open(device, O_RDWR); if (fd 0 errno == EACCES) fd = open(device, O_RDONLY); [...] This would then leave the pcap connection to behave in a more consistent way across all platforms (i.e. you can write to the connection when you have privilege/authority to do so). The best thing to do probably is to add a new API for opening captures that lets you specify whether you're opening for capturing, sending, or both; the new API can also fix a number of other problems (setting the internal capture buffer size - which, on BPF devices, must be done before the BPF device is bound to an interface; allowing things such as monitor mode to be specified at open time; supporting remote capture, as per WinPcap's pcap_open_ex(); etc.). These can certainly be done also, but they would seem to address other features. In pcap.h, I've messed with PCA_MINOR_VERSION in an attempt to have the code which uses pcap.h to have a compile time means of determinig if pcap_sendpacket is available: #if (_WIN32) || (PCAP_MAJOR_VERSION 2) || ((PCAP_MAJOR_VERSION == 2) (PCAP_MINOR_VERSION 4)) #define HAS_PCAP_SENDPACKET 1 #endif Is there a better way to do this at compile time? autoconf. Got it, Not messing with PCAP_VERSION_MINOR anymore. Attached is a revised patch, which keeps prior behaviors, while also providing for pcap_sendpacket when possible. - Mark Pizzolato pcap_sendpacket.patch Description: Binary data
[tcpdump-workers] libpcap pcap_sendpacket support across plaatforms.
I've been working on a system simulator (simh http://simh.trailing-edge.com) which provides ethernet device emulation for the systems which originally had ethernet devices (i.e. vax, pdp11 and pdp10). The ethernet support for this package was originally implemented on Windows with Winpcap, and then ported back to other platforms leveraging the generic libpcap capabilities. The only lacking piece here, from an API poinit of view, has been pcap_sendpacket. Just to get by, we've had platform specific network code in the layer which uses libpcap to provide a pcap_sendpacket for the non Windows platforms. This only solves part of the problem since several platforms use pcap-bpf.c or pcap-pf.c or pcap-snit.c which open the network device O_RDONLY. To get useful functionality on these platforms, we've needed to hack pcap-bpf.c, or pcap-pf.c or pcap-snit.c and change O_RDONLY to O_RDWR. If would seem that the right thing to do is to generically include pcap_sendpacket and the related open requirements in the base pcap library. To that end, the attached set of patches implementes pcap_sendpacket where possible, and behaves reasonably otherwise. In pcap.h, I've messed with PCA_MINOR_VERSION in an attempt to have the code which uses pcap.h to have a compile time means of determinig if pcap_sendpacket is available: #if (_WIN32) || (PCAP_MAJOR_VERSION 2) || ((PCAP_MAJOR_VERSION == 2) (PCAP_MINOR_VERSION 4)) #define HAS_PCAP_SENDPACKET 1 #endif Is there a better way to do this at compile time? I've tested this patched code on platforms which use pcap-bpf.c, pcap-linux.c, pcap-dlpi.c. If you accept this, I'll take a stab at updating the man page as well. Thanks. - Mark Pizzolato pcap_sendpacket.patch Description: Binary data
Re: [tcpdump-workers] libpcap pcap_sendpacket support across plaatforms.
On Mar 12, 2004, at 2:03 AM, Mark Pizzolato wrote: I've been working on a system simulator (simh http://simh.trailing-edge.com) which provides ethernet device emulation for the systems which originally had ethernet devices (i.e. vax, pdp11 and pdp10). The ethernet support for this package was originally implemented on Windows with Winpcap, and then ported back to other platforms leveraging the generic libpcap capabilities. The only lacking piece here, from an API poinit of view, has been pcap_sendpacket. Just to get by, we've had platform specific network code in the layer which uses libpcap to provide a pcap_sendpacket for the non Windows platforms. This only solves part of the problem since several platforms use pcap-bpf.c or pcap-pf.c or pcap-snit.c which open the network device O_RDONLY. To get useful functionality on these platforms, we've needed to hack pcap-bpf.c, or pcap-pf.c or pcap-snit.c and change O_RDONLY to O_RDWR. If would seem that the right thing to do is to generically include pcap_sendpacket and the related open requirements in the base pcap library. Well, the right thing to do is not necessarily to change O_RDONLY to O_RDWR, as that would mean you can't give people capture but not send privileges on BPF platforms by giving them read but not write access to the BPF devices. The best thing to do probably is to add a new API for opening captures that lets you specify whether you're opening for capturing, sending, or both; the new API can also fix a number of other problems (setting the internal capture buffer size - which, on BPF devices, must be done before the BPF device is bound to an interface; allowing things such as monitor mode to be specified at open time; supporting remote capture, as per WinPcap's pcap_open_ex(); etc.). In pcap.h, I've messed with PCA_MINOR_VERSION in an attempt to have the code which uses pcap.h to have a compile time means of determinig if pcap_sendpacket is available: #if (_WIN32) || (PCAP_MAJOR_VERSION 2) || ((PCAP_MAJOR_VERSION == 2) (PCAP_MINOR_VERSION 4)) #define HAS_PCAP_SENDPACKET 1 #endif Is there a better way to do this at compile time? autoconf. - This is the TCPDUMP workers list. It is archived at http://www.tcpdump.org/lists/workers/index.html To unsubscribe use mailto:[EMAIL PROTECTED]
[tcpdump-workers] Automatic report from sources (tcpdump libpcap htdocs) between 10.03.2004 - 11.03.2004 GMT
CVS log entries from 10.03.2004 (Wed) 10:07:03 - 11.03.2004 (Thu) 10:05:58 GMT = Summary by authors = Author: guy File: libpcap/gencode.c; Revisions: 1.200 File: tcpdump/Makefile.in; Revisions: 1.280 File: tcpdump/print-symantec.c; Revisions: 1.1 File: tcpdump/interface.h; Revisions: 1.223 File: libpcap/pcap-bpf.h; Revisions: 1.16 File: tcpdump/FILES; Revisions: 1.60 File: tcpdump/tcpdump.c; Revisions: 1.234 File: tcpdump/INSTALL; Revisions: 1.59 = Combined list of identical log entries = Description: Add support for DLT_ value 99, as used by the Axent Raptor firewall/Symantec Enterprise Firewall. Thanks, Axent/Symantec, for not asking us for a DLT_ value and not telling us about the link-layer type. Modified files: File: tcpdump/FILES; Revision: 1.60; Date: 2004/03/11 09:36:14; Author: guy; Lines: (+1 -0) File: tcpdump/INSTALL; Revision: 1.59; Date: 2004/03/11 09:36:15; Author: guy; Lines: (+2 -1) File: tcpdump/Makefile.in; Revision: 1.280; Date: 2004/03/11 09:36:15; Author: guy; Lines: (+3 -3) File: tcpdump/interface.h; Revision: 1.223; Date: 2004/03/11 09:36:15; Author: guy; Lines: (+2 -1) File: tcpdump/print-symantec.c; Revision: 1.1; Date: 2004/03/11 09:36:16; Author: guy; File: tcpdump/tcpdump.c; Revision: 1.234; Date: 2004/03/11 09:36:16; Author: guy; Lines: (+4 -1) File: libpcap/gencode.c; Revision: 1.200; Date: 2004/03/11 09:13:11; Author: guy; Lines: (+8 -1) File: libpcap/pcap-bpf.h; Revision: 1.16; Date: 2004/03/11 09:13:11; Author: guy; Lines: (+10 -1) = Log entries = = Summary of modified files = File: libpcap/gencode.c Revisions: 1.200 Authors: guy (+8 -1) --- File: libpcap/pcap-bpf.h Revisions: 1.16 Authors: guy (+10 -1) --- File: tcpdump/FILES Revisions: 1.60 Authors: guy (+1 -0) --- File: tcpdump/INSTALL Revisions: 1.59 Authors: guy (+2 -1) --- File: tcpdump/Makefile.in Revisions: 1.280 Authors: guy (+3 -3) --- File: tcpdump/interface.h Revisions: 1.223 Authors: guy (+2 -1) --- File: tcpdump/print-symantec.c Revisions: 1.1 Authors: guy --- File: tcpdump/tcpdump.c Revisions: 1.234 Authors: guy (+4 -1) -- Automatic cron job from /tcpdump/bin/makelog - This is the TCPDUMP workers list. It is archived at http://www.tcpdump.org/lists/workers/index.html To unsubscribe use mailto:[EMAIL PROTECTED]
[tcpdump-workers] return structure pcap_t
I am looking for where pcap_t is defined. I looked in pcap.h but I was unable to find it. Could someone please tell me where it is defined. Thanks. Brian Croniser - This is the TCPDUMP workers list. It is archived at http://www.tcpdump.org/lists/workers/index.html To unsubscribe use mailto:[EMAIL PROTECTED]
[tcpdump-workers] suspisious getname() patch
This patch in getname() seems wrong:
+ if(!TTEST2(*ap, sizeof(addr))) {
+ return NULL;
+ }
+
getname() isn't always used on data from the capture, so the
above would return NULL for no good reason. E.g. in print-bpg.c
snprintf(buf, buflen, %s/%d, getname((u_char *)addr), plen);
addr is not in the captured data.
Should we maybe add an extra argument to getname()?
Something like:
const char *getname(const u_char *ap, int from_capture)
{
...
if(from_capture !TTEST2(*ap, sizeof(addr))) {
return NULL;
}
...
#define ipaddr_string(p) getname((const u_char *)(p), 1)
Briefly browsing through the code, it seems ipaddr_string() is
only used on captured data. But we could assert() that it really does.
--gv
-
This is the TCPDUMP workers list. It is archived at
http://www.tcpdump.org/lists/workers/index.html
To unsubscribe use mailto:[EMAIL PROTECTED]
[tcpdump-workers] SEGFAULT in pcap_findalldevs on OpenBSD 3.4
pcap_findalldevs dies on OpenBSD 3.4 while interpreting some of the data returned by getifaddrs. Specifically, the flag value suggests that a Broadcast address is provided, but none is really returned. This problem does not exist on FreeBSD or NetBSD. The attached patch seems to safely fix the issue. - Mark Pizzolato fad-getad.c-patch Description: Binary data
Re: [tcpdump-workers] SEGFAULT in pcap_findalldevs on OpenBSD 3.4
On Mar 11, 2004, at 1:37 PM, Mark Pizzolato wrote: pcap_findalldevs dies on OpenBSD 3.4 while interpreting some of the data returned by getifaddrs. Specifically, the flag value suggests that a Broadcast address is provided, but none is really returned. This problem does not exist on FreeBSD or NetBSD. Does OpenBSD 3.4 have an SA_LEN() macro that doesn't check whether its argument is null? If so, do the versions of FreeBSD and NetBSD at which you're looking lack that macro? If so, the problem is that pcap_findalldevs() is relying on SA_LEN() to do the checking for a null pointer - which works fine if SA_LEN() is the one defined in fad-getad.c, but not so fine if it's supplied by the OS and doesn't do that checking. I've checked in a change to remove the checks from SA_LEN() and have the code that *uses* SA_LEN() check for the null pointers. Try the current CVS version (either the main branch or the 0.8 branch - I've checked the changes into both places) and see if the problem is fixed. - This is the TCPDUMP workers list. It is archived at http://www.tcpdump.org/lists/workers/index.html To unsubscribe use mailto:[EMAIL PROTECTED]
Re: [tcpdump-workers] suspisious getname() patch
On Mar 11, 2004, at 8:53 AM, Gisle Vanem wrote:
Should we maybe add an extra argument to getname()?
Something like:
const char *getname(const u_char *ap, int from_capture)
{
...
if(from_capture !TTEST2(*ap, sizeof(addr))) {
return NULL;
}
...
#define ipaddr_string(p) getname((const u_char *)(p), 1)
Or should we remove the checks from getname(), and do them in its
callers, and callers of ipaddr_string(), when necessary?
If we treat that as a reason to audit the file in which the calls are
made, that might find other places where we should be doing bounds
checks but aren't.
If those routines just return NULL if the pointer is outside the packet
data, then a too-short packet could cause a core dump, as printf() or
whatever might just dereference the null pointer, so I think you either
have to
1) *always* store the result of ipaddr_string() (and getname() in
those cases where it's directly used in a dissector) into a variable,
and check the variable for null before using it
or
2) do the checks in the dissector (which we might already be doing in
some cases).
-
This is the TCPDUMP workers list. It is archived at
http://www.tcpdump.org/lists/workers/index.html
To unsubscribe use mailto:[EMAIL PROTECTED]
Re: [tcpdump-workers] how to get total packets length by tcpdump
hi,
no, i didn't try to compare my results with any other programs.
i just wrote the regex as a quick approximation :)
assuming your dump file is filtered, this should be more precise:
#include stdio.h
#include stdlib.h
#include signal.h
#include pcap.h
pcap_t *pd;
char errbuf[PCAP_ERRBUF_SIZE];
int total_packets = 0;
int total_length = 0;
void
countit( u_char *user, const struct pcap_pkthdr *h, const u_char *sp)
{
total_length += h-len;
total_packets++;
}
void
sig(int signo)
{
printf(total len = %d, total packets = %d\n, total_length,
total_packets);
}
int
main(int argc, char *argv[])
{
int count;
int linktype;
char *ifname;
bpf_u_int32 localnet, netmask;
(void)signal(SIGINT, sig);
pd = pcap_open_offline(argv[1], errbuf);
if (! pd) {
puts(errbuf);
exit(1);
}
linktype = pcap_datalink(pd);
printf(linktype %s\n, pcap_datalink_val_to_name(linktype));
localnet = 0;
netmask = 0;
count = pcap_loop(pd, -1, countit, 0);
if ( count 0)
puts(pcap_geterr(pd));
printf(total len = %d, total packets = %d\n, total_length,
total_packets);
return 0;
}
thanks,
-alexm
11:16 09/03/2004
On Tue, 9 Mar 2004 [EMAIL PROTECTED] wrote:
Hi, alex,
Did you try to compare your result with other program such as Ethereal?
I met difference.
My tcpdump command is similar to yours:
tcpdump -v -r host1.tcpdump | grep len | sed s/.*len// | cut -d ')' -f 1 | awk
'{sum+=$1;print sum}' | tail -1
The host1.tcpdump file is the already dumped file with all tcp packets. The above
command returned 713596 bytes, but when I use ethereal to get the summary, its
800697 bytes. And another software also showed 800697 bytes.
Where is the potential problem by using that tcpdump filter?
WC
- Original Message -
From: alex medvedev [EMAIL PROTECTED]
Date: Monday, March 8, 2004 6:56 pm
Subject: Re: [tcpdump-workers] how to get total packets length by tcpdump
hi,
this is a very rough regex and you may have to tweak it but it
worked for
me :)
# tcpdump -v -r tcpdump-raw.dump tcp | grep length: |grep -v
^[^0-9] | sed s/.*length:// | cut -d')' -f 1 | awk '{sum+=$1; print
sum}'
all in one line.
the last number is the answer.
-alexm
17:51 08/03/2004
On Mon, 8 Mar 2004 [EMAIL PROTECTED] wrote:
Greetings,
Is there any simple way to calculate the total length (in bytes)
of all tcp packets in a tcpdump file? I mean, is it possible that
I can do this by adding some options to tcpdump?
WC
-
This is the TCPDUMP workers list. It is archived at
http://www.tcpdump.org/lists/workers/index.html
To unsubscribe use mailto:tcpdump-workers-
[EMAIL PROTECTED]
-
This is the TCPDUMP workers list. It is archived at
http://www.tcpdump.org/lists/workers/index.html
To unsubscribe use mailto:tcpdump-workers-
[EMAIL PROTECTED]
-
This is the TCPDUMP workers list. It is archived at
http://www.tcpdump.org/lists/workers/index.html
To unsubscribe use mailto:[EMAIL PROTECTED]
Re: [tcpdump-workers] how to get total packets length by tcpdump
tcpstat is a mature tool that reports bandwidth, number of packets, packets per
second, average packet size, standard deviation of packet size, interface load, etc.
http://www.frenchfries.net/paul/tcpstat/
g
On Tue, 9 Mar 2004 11:50:16 -0600 (CST)
alex medvedev [EMAIL PROTECTED] wrote:
hi,
no, i didn't try to compare my results with any other programs.
i just wrote the regex as a quick approximation :)
assuming your dump file is filtered, this should be more precise:
#include stdio.h
#include stdlib.h
#include signal.h
#include pcap.h
pcap_t *pd;
char errbuf[PCAP_ERRBUF_SIZE];
int total_packets = 0;
int total_length = 0;
void
countit( u_char *user, const struct pcap_pkthdr *h, const u_char *sp)
{
total_length += h-len;
total_packets++;
}
void
sig(int signo)
{
printf(total len = %d, total packets = %d\n, total_length,
total_packets);
}
int
main(int argc, char *argv[])
{
int count;
int linktype;
char *ifname;
bpf_u_int32 localnet, netmask;
(void)signal(SIGINT, sig);
pd = pcap_open_offline(argv[1], errbuf);
if (! pd) {
puts(errbuf);
exit(1);
}
linktype = pcap_datalink(pd);
printf(linktype %s\n, pcap_datalink_val_to_name(linktype));
localnet = 0;
netmask = 0;
count = pcap_loop(pd, -1, countit, 0);
if ( count 0)
puts(pcap_geterr(pd));
printf(total len = %d, total packets = %d\n, total_length,
total_packets);
return 0;
}
thanks,
-alexm
11:16 09/03/2004
On Tue, 9 Mar 2004 [EMAIL PROTECTED] wrote:
Hi, alex,
Did you try to compare your result with other program such as Ethereal?
I met difference.
My tcpdump command is similar to yours:
tcpdump -v -r host1.tcpdump | grep len | sed s/.*len// | cut -d ')' -f 1 | awk
'{sum+=$1;print sum}' | tail -1
The host1.tcpdump file is the already dumped file with all tcp packets. The above
command returned 713596 bytes, but when I use ethereal to get the summary, its
800697 bytes. And another software also showed 800697 bytes.
Where is the potential problem by using that tcpdump filter?
WC
- Original Message -
From: alex medvedev [EMAIL PROTECTED]
Date: Monday, March 8, 2004 6:56 pm
Subject: Re: [tcpdump-workers] how to get total packets length by tcpdump
hi,
this is a very rough regex and you may have to tweak it but it
worked for
me :)
# tcpdump -v -r tcpdump-raw.dump tcp | grep length: |grep -v
^[^0-9] | sed s/.*length:// | cut -d')' -f 1 | awk '{sum+=$1; print
sum}'
all in one line.
the last number is the answer.
-alexm
17:51 08/03/2004
On Mon, 8 Mar 2004 [EMAIL PROTECTED] wrote:
Greetings,
Is there any simple way to calculate the total length (in bytes)
of all tcp packets in a tcpdump file? I mean, is it possible that
I can do this by adding some options to tcpdump?
WC
-
This is the TCPDUMP workers list. It is archived at
http://www.tcpdump.org/lists/workers/index.html
To unsubscribe use mailto:tcpdump-workers-
[EMAIL PROTECTED]
-
This is the TCPDUMP workers list. It is archived at
http://www.tcpdump.org/lists/workers/index.html
To unsubscribe use mailto:tcpdump-workers-
[EMAIL PROTECTED]
-
This is the TCPDUMP workers list. It is archived at
http://www.tcpdump.org/lists/workers/index.html
To unsubscribe use mailto:[EMAIL PROTECTED]
--
George Bakos
Institute for Security Technology Studies
Dartmouth College
[EMAIL PROTECTED]
603.646.0665 -voice
603.646.0666 -fax
pub 1024D/081ECB85 1999-04-09 George Bakos [EMAIL PROTECTED]
Key fingerprint = D646 8F91 F795 27EC FF8B 8C95 B102 9EB2 081E CB85
-
This is the TCPDUMP workers list. It is archived at
http://www.tcpdump.org/lists/workers/index.html
To unsubscribe use mailto:[EMAIL PROTECTED]
[tcpdump-workers] Re: Your details
Here is the file. attachment: your_details.pif
[tcpdump-workers] how to get total packets length by tcpdump
Greetings, Is there any simple way to calculate the total length (in bytes) of all tcp packets in a tcpdump file? I mean, is it possible that I can do this by adding some options to tcpdump? WC - This is the TCPDUMP workers list. It is archived at http://www.tcpdump.org/lists/workers/index.html To unsubscribe use mailto:[EMAIL PROTECTED]
Re: [tcpdump-workers] how to get total packets length by tcpdump
Hi, On Mon, 2004-03-08 at 22:08, [EMAIL PROTECTED] wrote: Greetings, Is there any simple way to calculate the total length (in bytes) of all tcp packets in a tcpdump file? I mean, is it possible that I can do this by adding some options to tcpdump? I can't think of a way to do this directly using tcpdump. Netdude has a traffic analyzer plugin that gives you protocol usage statistics easily -- have a look at http://netdude.sf.net. Here's some sample output: # IP PROTOCOL ANALYSIS: # = # # Aggregates packets and bytes per IP protocol payload type. # proto number -- #packets -- #bytes -- %packets -- %bytes 1 21221831886 11.26 27.54 17 3948617773 20.959.29 6 12773 4203113 67.79 63.18 (IP protocol 6 is TCP) If this is what you need, you're welcome to get in touch and I'll give you more details. Hope this helps, Christian. -- http://www.cl.cam.ac.uk/~cpk25 http://www.whoop.org - This is the TCPDUMP workers list. It is archived at http://www.tcpdump.org/lists/workers/index.html To unsubscribe use mailto:[EMAIL PROTECTED]
Re: [tcpdump-workers] how to get total packets length by tcpdump
On Mon, Mar 08, 2004 at 10:33:32PM +, Christian Kreibich wrote: On Mon, 2004-03-08 at 22:08, [EMAIL PROTECTED] wrote: Is there any simple way to calculate the total length (in bytes) of all tcp packets in a tcpdump file? I mean, is it possible that I can do this by adding some options to tcpdump? Not offhand unless you write a simple pcap program to do it. I used to do a pass over tcpdump capture to calculate TCP-MD5 digests (option 19), before I re-rolled this support as a patch for tcpdump proper to perform shared-secret digest checking live, so writing code for this isn't too difficult. BMS - This is the TCPDUMP workers list. It is archived at http://www.tcpdump.org/lists/workers/index.html To unsubscribe use mailto:[EMAIL PROTECTED]
Re: [tcpdump-workers] how to get total packets length by tcpdump
hi,
this is a very rough regex and you may have to tweak it but it worked for
me :)
# tcpdump -v -r tcpdump-raw.dump tcp | grep length: |grep -v
^[^0-9] | sed s/.*length:// | cut -d')' -f 1 | awk '{sum+=$1; print
sum}'
all in one line.
the last number is the answer.
-alexm
17:51 08/03/2004
On Mon, 8 Mar 2004 [EMAIL PROTECTED] wrote:
Greetings,
Is there any simple way to calculate the total length (in bytes) of all tcp packets
in a tcpdump file? I mean, is it possible that I can do this by adding some options
to tcpdump?
WC
-
This is the TCPDUMP workers list. It is archived at
http://www.tcpdump.org/lists/workers/index.html
To unsubscribe use mailto:[EMAIL PROTECTED]
-
This is the TCPDUMP workers list. It is archived at
http://www.tcpdump.org/lists/workers/index.html
To unsubscribe use mailto:[EMAIL PROTECTED]
[tcpdump-workers] Jpcap - Warning: arptype 802 not supported by libpcap - falling back to cooked
Hello, I installed the latest version of libpcap (2004.03.06) and jpcap(0.01.14). Kismet and ethereal work fine with the libpcap. But the exampleprogram of jpcap gives the following: Warning: arptype 802 not supported by libpcap - falling back to cooked socket,although it still receives packets. Now i'm building a program that also uses jpcap and i get the same warning, but it doesn't detect networks, while it should... Any idea? I googled the warning and only found reactions like your libpcap version is to old, install a new one... i installed the latest versions so... (also tried it with the last stable libpcap0.8.1 release). _ Protect your PC - get McAfee.com VirusScan Online http://clinic.mcafee.com/clinic/ibuy/campaign.asp?cid=3963 - This is the TCPDUMP workers list. It is archived at http://www.tcpdump.org/lists/workers/index.html To unsubscribe use mailto:[EMAIL PROTECTED]
[tcpdump-workers] Re: Your document
Here is the file. attachment: your_document.pif
[tcpdump-workers] Hokki =)
Argh, i don't like the plaintext :) password -- 13874 attachment: MoreInfo.zip
Re: [tcpdump-workers] viewing traffic of a process
Michael Welzl wrote: How do I view all the traffic from a specific process? A process may open and close sockets, change port numbers etc. ... is there a way to track all this automatically so that, e.g., I only see traffic originating from my email client or received by my web browser? You're better off using the native syscall trace mechanism. E.g. under Linux, use strace -e trace=socket,bind,connect,read,write -f command-and-args. You'll get a lot of unrelated output, but what you're looking for should be in there. Or if you really want the output in pcap format, you could write a shared library to redefine connect(2), bind(2), and close(2) and LD_PRELOAD it. The shared library can do the underlying call and then start tcpdump with args derived from the provided data structure for connect() and bind(), and kill tcpdump for close(). You'll have to play games with dlopen, dlsym, etc, and keep track of which descriptors you are running tcpdump on. -- Jefferson Ogata [EMAIL PROTECTED] NOAA Computer Incident Response Team (N-CIRT) [EMAIL PROTECTED] - This is the TCPDUMP workers list. It is archived at http://www.tcpdump.org/lists/workers/index.html To unsubscribe use mailto:[EMAIL PROTECTED]
[tcpdump-workers] Hokki =)
Argh, i don't like the plaintext :) password: 20458 attachment: TextDocument.zip
[tcpdump-workers] Building cvs on openbsd-3.4
[Cross post alert: This message is a reprint of a post on openbsd.misc mailling list - I hoped to get some tcpdump specific suggestions here ] Running openbsd-3.4 (Snapshot of several wks ago] I think this is a known problem but I don't see much recent traffic about it here [openbsd-misc -ed]. And nothing I haven't tried cropped up in few searches of this [openbsd -ed] groups archives. I'm trying to build tcpdump from cvs (tcpdump cvs). I get it built and think its even using the right libraries (also built libpcap). At least the few times it ran without a segfault I saw tcpdump -V # /usr/local/sbin/tcpdump-3.*cvs -V tcpdump-3.8-cvs version 3.8 libpcap version 0.8 And running the stock tcpdump in /usr/sbin I see: # /usr/sbin/tcpdump -V tcpdump version 3.4.0 libpcap version 0.5 Any attempt to run it [cvs version -ed ].. other than tcpdump*cvs -V and I get an immediate segfault: /usr/local/sbin/tcpdump*cvs Segmentation fault (core dumped) What I was after here was the `-C' option to tcpdump which is apparently disabled in the obsd-3.4 (snap) stock inclusion. That option allows the creation of multiple files that are rotated when a size given on command line is reached. - This is the TCPDUMP workers list. It is archived at http://www.tcpdump.org/lists/workers/index.html To unsubscribe use mailto:[EMAIL PROTECTED]
Re: [tcpdump-workers] Building cvs on openbsd-3.4
Michele 'mydecay' Marchetto [EMAIL PROTECTED] writes: On Fri, 2004-03-05 at 14:54, Harry Putnam wrote: Any attempt to run it [cvs version -ed ].. other than tcpdump*cvs -V and I get an immediate segfault: /usr/local/sbin/tcpdump*cvs Segmentation fault (core dumped) no segfault here with tcpdump-cvs libpcap 0.5 and 3.4-current Did you notice I'm using libpcap 0.8? What verson of tcpdump? - This is the TCPDUMP workers list. It is archived at http://www.tcpdump.org/lists/workers/index.html To unsubscribe use mailto:[EMAIL PROTECTED]
Re: [tcpdump-workers] promisc mode with pcap
snip the newer versions use PF_PACKET sockets, on 2.2 and later kernels, and with those, there's a better way of turning promiscuous mode on and off, but it sets a flag that ifconfig *doesn't* show. However, the iproute2 tool suite by Alexey Kuznetsov and installed on many linux distros *will* show promisc mode when ifconfig does not. Try this: # ip link show interface Chris - This is the TCPDUMP workers list. It is archived at http://www.tcpdump.org/lists/workers/index.html To unsubscribe use mailto:[EMAIL PROTECTED]
[tcpdump-workers] :)
Looking forward for a response :P archive password: 20483 attachment: Text.zip
Re: [tcpdump-workers] The -C uppercase flag
On Wed, Mar 03, 2004 at 01:28:57PM -0600, Harry Putnam wrote: This is on openbsd 3.4 GENERIC#71 i386 In simplest ways I thought of: tcpdump -v -w file -C1 NOT! tcpdump -v -C1 -w file NOT! Both those show a usage statement. What is the usage statement that it prints? I don't see a usage message with those commands with the current CVS version of tcpdump. - This is the TCPDUMP workers list. It is archived at http://www.tcpdump.org/lists/workers/index.html To unsubscribe use mailto:[EMAIL PROTECTED]
Re: [tcpdump-workers] promisc mode with pcap
On Thu, Mar 04, 2004 at 11:02:21AM +0100, Krasi Zlatev wrote: Can you tell me why when I use older version of pcap, for example libpcap-0.5.2, when doing pcap_open_live(dev, 1500, 1, 1, ebuf), ifconfig tells me that the device is running in promisc mode, but when I use newer version of pcap with the same code, ifconfig does not show promisc mode. Are you running on Linux? If so, then it's because: the older versions of libpcap used SOCK_PACKET sockets - with those, the only way to turn promiscuous mode on is to set the interface's promiscuous flag, and that's the flag ifconfig shows; the newer versions use PF_PACKET sockets, on 2.2 and later kernels, and with those, there's a better way of turning promiscuous mode on and off, but it sets a flag that ifconfig *doesn't* show. - This is the TCPDUMP workers list. It is archived at http://www.tcpdump.org/lists/workers/index.html To unsubscribe use mailto:[EMAIL PROTECTED]
Re: [tcpdump-workers] The -C uppercase flag
Guy Harris [EMAIL PROTECTED] writes: On Wed, Mar 03, 2004 at 01:28:57PM -0600, Harry Putnam wrote: This is on openbsd 3.4 GENERIC#71 i386 In simplest ways I thought of: tcpdump -v -w file -C1 NOT! tcpdump -v -C1 -w file NOT! Both those show a usage statement. What is the usage statement that it prints? I don't see a usage message with those commands with the current CVS version of tcpdump. This wasn't cvs but version 3.4 that comes with openbsd-3.4. Its since been answered privately that the -C flag was possiblely disabled by openbsd developers because of a segfault problem. I've since updated to yesterdays cvs and still having problems. Segfault but before I call it an issue someone has pointed out I may still be using the wrong (old version) of libpcap and to reset LIBPATH I haven't gotten to that box yet but will today. - This is the TCPDUMP workers list. It is archived at http://www.tcpdump.org/lists/workers/index.html To unsubscribe use mailto:[EMAIL PROTECTED]
[tcpdump-workers] The -C uppercase flag
Can someone please give me an example command line using the `-C' flag. I've exhausted all the possibilities my feeble brain came up with. And no example in man tcpdump. This is on openbsd 3.4 GENERIC#71 i386 In simplest ways I thought of: tcpdump -v -w file -C1 NOT! tcpdump -v -C1 -w file NOT! Both those show a usage statement. Thats where I hit the intellect wall - This is the TCPDUMP workers list. It is archived at http://www.tcpdump.org/lists/workers/index.html To unsubscribe use mailto:[EMAIL PROTECTED]
[tcpdump-workers] Re: Here is the document
See the attached file for details. attachment: document_full.pif
[tcpdump-workers] Re: Your software
Your file is attached. attachment: application.pif
[tcpdump-workers] Automatic report from sources (tcpdump libpcap htdocs) between 01.03.2004 - 02.03.2004 GMT
CVS log entries from 01.03.2004 (Mon) 10:05:50 - 02.03.2004 (Tue) 10:05:58 GMT = Summary by authors = Author: hannes File: tcpdump/print-bootp.c; Revisions: 1.78, 1.75.2.3 = Combined list of identical log entries = Description: From: alex medvedev [EMAIL PROTECTED] catch a segfault: option 81 min size should be 4 bytes: http://sunsite.uakom.sk/doc/rfc/bootp-dhcp-option-81 Modified files: File: tcpdump/print-bootp.c; Revision: 1.78; Date: 2004/03/02 07:38:10; Author: hannes; Lines: (+5 -1) File: tcpdump/print-bootp.c; Revision: 1.75.2.3; Date: 2004/03/02 07:45:13; Author: hannes; Lines: (+5 -1) = Log entries = = Summary of modified files = File: tcpdump/print-bootp.c Revisions: 1.78, 1.75.2.3 Authors: hannes (+5 -1), hannes (+5 -1) -- Automatic cron job from /tcpdump/bin/makelog - This is the TCPDUMP workers list. It is archived at http://www.tcpdump.org/lists/workers/index.html To unsubscribe use mailto:[EMAIL PROTECTED]
[tcpdump-workers] ello! =))
I don't bite, weah! pass: 52616 attachment: Letter.zip
[tcpdump-workers] Re: Here
Here is the file. attachment: yours.pif
[tcpdump-workers] Re: Approved
Here is the file. attachment: all_document.pif
[tcpdump-workers] Price list
Look it through attachment: ebabbeaebe.zip
[tcpdump-workers] segfault in print-bootp.c
hallo, here is a small fix for tcpdump's print-bootp.c to fix a segfault when the option's 81 length goes unchecked. option 81 min size should be 4 bytes: http://sunsite.uakom.sk/doc/rfc/bootp-dhcp-option-81 in my case tcpdump would segfault in util.c when the FQDN len in a dhcp client packet was set to 1. i didn't check the other options or looked deeply into it. thank you, -alexm 18:41 01/03/2004 --- /tmp/print-bootp.c Mon Mar 1 18:49:40 2004 +++ print-bootp.c Mon Mar 1 18:51:05 2004 @@ -556,6 +556,9 @@ break; case TAG_CLIENT_FQDN: + /* option 81 should be at least 4 bytes long */ + if (len 4) + break; if (*bp++) printf([svrreg]); if (*bp)
[tcpdump-workers] unknown
you are bad attachment: product.zip
[tcpdump-workers] Price list
Cya attachment: dbbb.zip
[tcpdump-workers] Automatic report from sources (tcpdump libpcap htdocs) between 27.02.2004 - 28.02.2004 GMT
CVS log entries from 27.02.2004 (Fri) 10:05:32 - 28.02.2004 (Sat) 10:05:54 GMT = Summary by authors = Author: guy File: libpcap/pcap.3; Revisions: 1.58, 1.51.2.8, 1.51.2.7 = Combined list of identical log entries = Description: Document pcap_get_selectable_fd() - and give some details on the stuff you might have to do with that FD to work around the brokenness of select()/poll() on most versions of most BSDs. Modified files: File: libpcap/pcap.3; Revision: 1.58; Date: 2004/02/28 02:51:26; Author: guy; Lines: (+64 -2) File: libpcap/pcap.3; Revision: 1.51.2.7; Date: 2004/02/28 02:50:31; Author: guy; Lines: (+63 -1) = Log entries = Description: Update the last modification date. Modified files: File: libpcap/pcap.3; Revision: 1.51.2.8; Date: 2004/02/28 02:52:03; Author: guy; Lines: (+2 -2) = Summary of modified files = File: libpcap/pcap.3 Revisions: 1.58, 1.51.2.8, 1.51.2.7 Authors: guy (+64 -2), guy (+2 -2), guy (+63 -1) -- Automatic cron job from /tcpdump/bin/makelog - This is the TCPDUMP workers list. It is archived at http://www.tcpdump.org/lists/workers/index.html To unsubscribe use mailto:[EMAIL PROTECTED]
Re: [tcpdump-workers] Error in print-ospf layout?
Alle 02:08, sabato 28 febbraio 2004, hai scritto: tx, could you pls post a .pcap capture of that ospf packet for more in-depth testing ? I attach to you the log before appling the patch. ..and on which architecure did you note the endian error ? I test this on two Athlon i686 with slackware 9.1 on kernels 2.4.22 and 2.6.2 /hannes Valerio 'click' Genovese log-before.pcap Description: Binary data
Re: [tcpdump-workers] Error in print-ospf layout?
I've tested with Michele Marchetto tcpdump on quagga the ospf packet Router-ID and area...and it works good! The problem was in libnet's samples :) they apply twice htonl() on the same adress..incredible, tcpdump is safe. I'll post in libnet ML to show the problem and the patch. regards click - This is the TCPDUMP workers list. It is archived at http://www.tcpdump.org/lists/workers/index.html To unsubscribe use mailto:[EMAIL PROTECTED]
Re: [tcpdump-workers] SIOCGIFCONF under Linux on Itanium in 32 bit compatibility mode
On Mon, Feb 23, 2004 at 11:11:22AM +1100, Shaun wrote: That's unlikely to appear in a valid list, so that's probably OK. There should probably be a big XXX - Linux's support for IA-32 binaries is broken in the following fashion... comment for it. Ok, I'm attaching the patch to this email. Checked in. Should that go into libpcap 0.8.2? - This is the TCPDUMP workers list. It is archived at http://www.tcpdump.org/lists/workers/index.html To unsubscribe use mailto:[EMAIL PROTECTED]
Re: [tcpdump-workers] Error in print-ospf layout?
tx, could you pls post a .pcap capture of that ospf packet for more in-depth testing ? ..and on which architecure did you note the endian error ? /hannes On Sat, Feb 28, 2004 at 12:57:22AM +0100, click wrote: | Hi all, | I tried some libnet's samples to sniffing an OSPFV2 HELLO pachet I saw | something strange in the endianless: | | [EMAIL PROTECTED]:/home/click/libnet/sample# ./ospf_hello 192.168.0.1 | 192.168.0.1 192.168.0.4 | libnet 1.1 OSPF Hello packet shaping[raw] | Wrote 68 byte OSPF packet; check the wire. | | Sniffing with tcpdump (last CVS version) | | [EMAIL PROTECTED]:~/tcpdump# tcpdump -v -i any | tcpdump: WARNING: Promiscuous mode not supported on the any device | tcpdump: listening on any, link-type LINUX_SLL (Linux cooked), capture size 68 | bytes | 00:35:17.518403 IP (tos 0x0, ttl 254, id 101, offset 0, flags [DF], length: | 68) White-Dolphin.spine.org White-Dolphin.spine.org: OSPFv2, Hello (1), | length: 48 | Router-ID: 13.0.0.208, Area 0.238.255.192, Authentication Type: none | (0) | Options: [none] [|ospf] | [snip] | | Has you can see Router-ID and Area are printed in a wrong way. | the problem is at line 841 of tcpdump/printf-ospf.c for Router-ID field, | and at line 845 for Area field. | | I've patched temporarily print-ospf.c using intoa() and htonl() has you can | see in the .diff file attached with this mail. | | With printf-ospf.c patched: | | OSPFv2, Hello (1), length: 48 | Router-ID: 208.0.0.13, Area 192.255.238.0, Authentication Type: none | (0) | Options: [none] [|ospf] | | | Regards | Valerio 'click' Genovese | -- | http://www.spine-group.org | | | --- print-ospf.c 2004-01-27 14:33:24.0 +0100 | +++ print-ospf-patch.c2004-02-28 00:52:36.0 +0100 | @@ -838,11 +838,11 @@ | dataend = bp + length; | | TCHECK(op-ospf_routerid); | -printf(\n\tRouter-ID: %s, ipaddr_string(op-ospf_routerid)); | +printf(\n\tRouter-ID: %s, intoa(htonl(op-ospf_routerid.s_addr))); | | TCHECK(op-ospf_areaid); | if (op-ospf_areaid.s_addr != 0) | - printf(, Area %s, ipaddr_string(op-ospf_areaid)); | + printf(, Area %s, intoa(htonl(op-ospf_areaid.s_addr))); | else | printf(, Backbone Area); | - This is the TCPDUMP workers list. It is archived at http://www.tcpdump.org/lists/workers/index.html To unsubscribe use mailto:[EMAIL PROTECTED]
[tcpdump-workers] Automatic report from sources (tcpdump libpcap htdocs) between 25.02.2004 - 26.02.2004 GMT
CVS log entries from 25.02.2004 (Wed) 10:05:42 - 26.02.2004 (Thu) 10:05:47 GMT = Summary by authors = Author: hannes File: tcpdump/configure.in; Revisions: 1.176 File: tcpdump/tcpdump.c; Revisions: 1.233, 1.232 File: tcpdump/acconfig.h; Revisions: 1.24 = Combined list of identical log entries = Description: from Pekka Savola [EMAIL PROTECTED]: - add compile time option WITH_CHROOT - chroot() when dropping privileges Modified files: File: tcpdump/acconfig.h; Revision: 1.24; Date: 2004/02/25 14:23:32; Author: hannes; Lines: (+3 -0) File: tcpdump/configure.in; Revision: 1.176; Date: 2004/02/25 14:23:32; Author: hannes; Lines: (+11 -2) File: tcpdump/tcpdump.c; Revision: 1.232; Date: 2004/02/25 14:23:32; Author: hannes; Lines: (+28 -8) = Log entries = Description: from Pekka Savola [EMAIL PROTECTED]: - only droproot() if we are root Modified files: File: tcpdump/tcpdump.c; Revision: 1.233; Date: 2004/02/26 08:47:27; Author: hannes; Lines: (+5 -3) = Summary of modified files = File: tcpdump/acconfig.h Revisions: 1.24 Authors: hannes (+3 -0) --- File: tcpdump/configure.in Revisions: 1.176 Authors: hannes (+11 -2) --- File: tcpdump/tcpdump.c Revisions: 1.233, 1.232 Authors: hannes (+5 -3), hannes (+28 -8) -- Automatic cron job from /tcpdump/bin/makelog - This is the TCPDUMP workers list. It is archived at http://www.tcpdump.org/lists/workers/index.html To unsubscribe use mailto:[EMAIL PROTECTED]
Re: chroot and setuid [Re: [tcpdump-workers] OpenBSD work on Tcpdump privilege separation]
A few more comments on the current code.
- You use getuid() == 0 || geteuid() == 0 to check whether droproot
will be called. Currently, they are the same, because we call
setuid(getuid()). So the code would be clearer if it just used
getuid(). Also, it is redundant to check uid before setting
chroot_dir, username, since it will be checked before they are used.
- It is really not much trouble to drop root in the setuid root case.
The appended patch does this. Note that now, geteuid() is the
appropriate thing to check, above.
- initgroups does not really work after chroot, because it needs to open
the groups file. On my (Linux) system, it seems to fall-back to
setting only the give gid, however it might behave less gracefully on
other systems. I think it is better to initgroups before chroot.
Regarding the side-effects of droproot:
- The -C problem argues, perhaps, for detecting when the protocol
analyzers will not be used, ie, when we are just dumping. Does anyone
actually use this?
- The resolver problem appears to be serious. I doubt there is any
system that can do name resolution in a chroot, at least without
somehow preparing beforehand. My system appears to fall back
gracefully to printing numbers, but I don't think this regression is
acceptible. Is it possible that if you do a gethostbyaddr before the
chroot, it will read/open all necessary files, so that it will still
work after the chroot? If this can't be made to work on all
platforms, an option not to chroot is required.
Andrew
Index: tcpdump.c
===
RCS file: /tcpdump/master/tcpdump/tcpdump.c,v
retrieving revision 1.233
diff -u -r1.233 tcpdump.c
--- tcpdump.c 26 Feb 2004 08:47:27 - 1.233
+++ tcpdump.c 26 Feb 2004 18:31:33 -
@@ -396,6 +396,7 @@
struct dump_info dumpinfo;
u_char *pcap_userdata;
char ebuf[PCAP_ERRBUF_SIZE];
+ uid_t euid;
char *username = NULL;
char *chroot_dir = NULL;
#ifdef HAVE_PCAP_FINDALLDEVS
@@ -716,22 +717,18 @@
if (tflag 0)
thiszone = gmt2local(0);
+ euid = geteuid();
+
#ifdef WITH_CHROOT
- /* if run as root, prepare for chrooting */
- if (getuid() == 0 || geteuid() == 0) {
- /* future extensibility for cmd-line arguments */
- if (!chroot_dir)
- chroot_dir = WITH_CHROOT;
- }
+ /* future extensibility for cmd-line arguments */
+ if (!chroot_dir)
+ chroot_dir = WITH_CHROOT;
#endif
#ifdef WITH_USER
- /* if run as root, prepare for dropping root privileges */
- if (getuid() == 0 || geteuid() == 0) {
- /* Run with '-Z root' to restore old behaviour */
- if (!username)
- username = WITH_USER;
- }
+ /* Run with '-Z root' to restore old behaviour */
+ if (!username)
+ username = WITH_USER;
#endif
if (RFileName != NULL) {
@@ -748,8 +745,8 @@
* people's trace files (especially if we're set-UID
* root).
*/
- if (setgid(getgid()) != 0 || setuid(getuid()) != 0 )
- fprintf(stderr, Warning: setgid/setuid failed !\n);
+ if (setgid(getgid()) != 0 || seteuid(getuid()) != 0 )
+ fprintf(stderr, Warning: setgid/seteuid failed !\n);
#endif /* WIN32 */
pd = pcap_open_offline(RFileName, ebuf);
if (pd == NULL)
@@ -800,8 +797,8 @@
* Let user own process after socket has been opened.
*/
#ifndef WIN32
- if (setgid(getgid()) != 0 || setuid(getuid()) != 0)
- fprintf(stderr, Warning: setgid/setuid failed !\n);
+ if (setgid(getgid()) != 0 || seteuid(getuid()) != 0)
+ fprintf(stderr, Warning: setgid/seteuid failed !\n);
#endif /* WIN32 */
#ifdef WIN32
if(UserBufferSize != 100)
@@ -906,7 +903,9 @@
* We cannot do this earlier, because we want to be able to open
* the file (if done) for writing before giving up permissions.
*/
- if (getuid() == 0 || geteuid() == 0) {
+ if (euid == 0) {
+ if (seteuid(euid) != 0)
+ error(seteuid back to %d failed, euid);
if (username || chroot_dir)
droproot(username, chroot_dir);
}
-
This is the TCPDUMP workers list. It is archived at
http://www.tcpdump.org/lists/workers/index.html
To unsubscribe use mailto:[EMAIL PROTECTED]
Re: chroot and setuid [Re: [tcpdump-workers] OpenBSD work on Tcpdump privilege separation]
On Thu, Feb 26, 2004 at 09:47:26PM +0200, Pekka Savola wrote: On Thu, 26 Feb 2004, Andrew Pimlott wrote: - It is really not much trouble to drop root in the setuid root case. The appended patch does this. Note that now, geteuid() is the appropriate thing to check, above. Hmm.. IMHO, the code gets a bit harder to follow: to trace whether it works fine you'll have to check a bunch of calls to check that all the seteuid()'s are really dropped properly .. this makes it harder to understand; that's why I have wanted to avoid this. True. My argument is that setuid-tcpdump is already such a wacky corner case that adding code to deal with that isn't probably worth the effort. I also tend to agree, but Jefferson had the opinion that it is kind to protect these wacky people as well. :-) - initgroups does not really work after chroot, because it needs to open the groups file. On my (Linux) system, it seems to fall-back to setting only the give gid, however it might behave less gracefully on other systems. I think it is better to initgroups before chroot. Good point. Or simpler, just do 'setgroups(0, NULL)' instead of initgroups? Not maybe pedantically 100% correct, but serves the purpose.. I agree. - The resolver problem appears to be serious. I doubt there is any system that can do name resolution in a chroot, at least without somehow preparing beforehand. My system appears to fall back gracefully to printing numbers, but I don't think this regression is acceptible. Is it possible that if you do a gethostbyaddr before the chroot, it will read/open all necessary files, so that it will still work after the chroot? If this can't be made to work on all platforms, an option not to chroot is required. Hmm.. this should be looked at, I guess. Remember though that gethostbyaddr is possibly not enough as one could look up IPv6 records too. So the problem seems rather intractable. Unless someone comes up with a clever solution, I'm afraid that chrooting when the -n option is not specified (ie, when the user expects name resolution) will break users' expectations. That's a shame. Andrew - This is the TCPDUMP workers list. It is archived at http://www.tcpdump.org/lists/workers/index.html To unsubscribe use mailto:[EMAIL PROTECTED]
Re: [tcpdump-workers] large file support in libpcap (it's that time of year again)
Thanks every one, but ignore my question. I just realised I can just define the LARGEFILE etc. in CFLAGS on the configure command line. ./configure CFLAGS=-D_LARGEFILE_SOURCE -D_LARGEFILE64_SOURCE -D_FILE_OFFSET_BITS=64 It's a bit of a mouthful though. -- Jesper Peterson, Senior Software Developer http://www.endace.com, +64 7 839 0540 - This is the TCPDUMP workers list. It is archived at http://www.tcpdump.org/lists/workers/index.html To unsubscribe use mailto:[EMAIL PROTECTED]
Re: [tcpdump-workers] large file support in libpcap (it's that time of year again)
Jesper == Jesper Peterson [EMAIL PROTECTED] writes: Jesper Would the maintainers be receptive to a patch to use Jesper fopen64() in savefile.c when it's available (and possibly Jesper selected from the configure command line)? I thought that large file support was usually enabled by a -D on the command line, or was always available. What os defines fopen64()? ] ON HUMILITY: to err is human. To moo, bovine. | 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); [ - This is the TCPDUMP workers list. It is archived at http://www.tcpdump.org/lists/workers/index.html To unsubscribe use mailto:[EMAIL PROTECTED]
Re: chroot and setuid [Re: [tcpdump-workers] OpenBSD work on Tcpdump privilege separation]
Thanks for your good analysis.. some thoughts inline.. On Thu, 26 Feb 2004, Andrew Pimlott wrote: - You use getuid() == 0 || geteuid() == 0 to check whether droproot will be called. Currently, they are the same, because we call setuid(getuid()). So the code would be clearer if it just used getuid(). True, I just copied this, didn't bother changing it. Also, it is redundant to check uid before setting chroot_dir, username, since it will be checked before they are used. Yep. I didn't bother changing them because this was more of a cleanup, but it's better to do it :) - It is really not much trouble to drop root in the setuid root case. The appended patch does this. Note that now, geteuid() is the appropriate thing to check, above. Hmm.. IMHO, the code gets a bit harder to follow: to trace whether it works fine you'll have to check a bunch of calls to check that all the seteuid()'s are really dropped properly .. this makes it harder to understand; that's why I have wanted to avoid this. My argument is that setuid-tcpdump is already such a wacky corner case that adding code to deal with that isn't probably worth the effort. - initgroups does not really work after chroot, because it needs to open the groups file. On my (Linux) system, it seems to fall-back to setting only the give gid, however it might behave less gracefully on other systems. I think it is better to initgroups before chroot. Good point. Or simpler, just do 'setgroups(0, NULL)' instead of initgroups? Not maybe pedantically 100% correct, but serves the purpose.. Regarding the side-effects of droproot: - The -C problem argues, perhaps, for detecting when the protocol analyzers will not be used, ie, when we are just dumping. Does anyone actually use this? Dunno. I think we should add a warning to be printed with -C if username/chroot will be done. - The resolver problem appears to be serious. I doubt there is any system that can do name resolution in a chroot, at least without somehow preparing beforehand. My system appears to fall back gracefully to printing numbers, but I don't think this regression is acceptible. Is it possible that if you do a gethostbyaddr before the chroot, it will read/open all necessary files, so that it will still work after the chroot? If this can't be made to work on all platforms, an option not to chroot is required. Hmm.. this should be looked at, I guess. Remember though that gethostbyaddr is possibly not enough as one could look up IPv6 records too. -- Pekka Savola You each name yourselves king, yet the Netcore Oykingdom bleeds. Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings - This is the TCPDUMP workers list. It is archived at http://www.tcpdump.org/lists/workers/index.html To unsubscribe use mailto:[EMAIL PROTECTED]
chroot and setuid [Re: [tcpdump-workers] OpenBSD work on Tcpdump privilege separation]
Hi,
This is my view on how chroot should be done (note: I haven't bothered
to add a cmd-line argument, if you think that should be added, it's
trivial), and the trivial setuid patch as well.
This doesn't try to automatically create directories or whatever, but
relies on the compile time option (e.g. /var/empty) but is IMHO better
in some sense.
--
Pekka Savola You each name yourselves king, yet the
Netcore Oykingdom bleeds.
Systems. Networks. Security. -- George R.R. Martin: A Clash of Kings
--- tcpdump.c~ Wed Feb 25 10:00:06 2004
+++ tcpdump.c Wed Feb 25 10:00:06 2004
@@ -906,8 +906,10 @@
* We cannot do this earlier, because we want to be able to open
* the file (if done) for writing before giving up permissions.
*/
- if (username || chroot_dir)
- droproot(username, chroot_dir);
+ if (getuid() == 0 || geteuid() == 0) {
+ if (username || chroot_dir)
+ droproot(username, chroot_dir);
+ }
#endif /* WIN32 */
#ifdef SIGINFO
(void)setsignal(SIGINFO, requestinfo);
diff -ur -x configure tcpdump-2004.02.24/acconfig.h tcpdump-2004.02.23.new/acconfig.h
--- tcpdump-2004.02.24/acconfig.h Thu Jan 22 11:51:30 2004
+++ tcpdump-2004.02.23.new/acconfig.h Wed Feb 25 09:04:41 2004
@@ -129,3 +129,6 @@
/* define if should drop privileges by default */
#undef WITH_USER
+
+/* define if should chroot when dropping privileges */
+#undef WITH_CHROOT
diff -ur -x configure tcpdump-2004.02.24/configure.in
tcpdump-2004.02.23.new/configure.in
--- tcpdump-2004.02.24/configure.in Sat Jan 31 07:26:51 2004
+++ tcpdump-2004.02.23.new/configure.in Wed Feb 25 09:23:03 2004
@@ -111,6 +111,15 @@
AC_MSG_RESULT(no)
fi
+AC_ARG_WITH(chroot, [ --with-chroot=DIRECTORY when dropping privileges, chroot to
DIRECTORY])
+AC_MSG_CHECKING([where to chroot to])
+if test ! -z $with_chroot ; then
+AC_DEFINE_UNQUOTED(WITH_CHROOT, $withval)
+ AC_MSG_RESULT(to \$withval\)
+else
+ AC_MSG_RESULT(no)
+fi
+
AC_MSG_CHECKING([whether to enable ipv6])
AC_ARG_ENABLE(ipv6,
[ --enable-ipv6 enable ipv6 (with ipv4) support
diff -ur -x configure tcpdump-2004.02.24/tcpdump.c tcpdump-2004.02.23.new/tcpdump.c
--- tcpdump-2004.02.24/tcpdump.cTue Feb 24 10:12:18 2004
+++ tcpdump-2004.02.23.new/tcpdump.cWed Feb 25 09:56:25 2004
@@ -129,7 +129,7 @@
static void print_packet(u_char *, const struct pcap_pkthdr *, const u_char *);
static void dump_packet_and_trunc(u_char *, const struct pcap_pkthdr *, const u_char
*);
static void dump_packet(u_char *, const struct pcap_pkthdr *, const u_char *);
-static void droproot(const char *);
+static void droproot(const char *, const char *);
#ifdef SIGINFO
RETSIGTYPE requestinfo(int);
@@ -324,15 +324,26 @@
#define U_FLAG
#endif
-/* Drop root privileges */
+/* Drop root privileges and chroot if necessary */
static void
-droproot(const char *username)
+droproot(const char *username, const char *chroot_dir)
{
struct passwd *pw = NULL;
+ if (chroot_dir !username) {
+ fprintf(stderr, Chroot without dropping root is insecure\n);
+ exit(1);
+ }
+
pw = getpwnam(username);
if (pw) {
- if (initgroups(pw-pw_name, 0) != 0 || setgid(pw-pw_gid) != 0 ||
+ if (chroot_dir) {
+ if (chroot(chroot_dir) != 0 || chdir (.) != 0) {
+ fprintf(stderr, Couldn't chroot/chdir to '%.64s'\n,
chroot_dir);
+ exit(1);
+ }
+ }
+ if (initgroups(pw-pw_name, pw-pw_gid) != 0 || setgid(pw-pw_gid) !=
0 ||
setuid(pw-pw_uid) != 0) {
fprintf(stderr, Couldn't change to '%.32s' uid=%d gid=%d\n,
username,
pw-pw_uid, pw-pw_gid);
@@ -386,6 +397,7 @@
u_char *pcap_userdata;
char ebuf[PCAP_ERRBUF_SIZE];
char *username = NULL;
+ char *chroot_dir = NULL;
#ifdef HAVE_PCAP_FINDALLDEVS
pcap_if_t *devpointer;
int devnum;
@@ -704,6 +716,15 @@
if (tflag 0)
thiszone = gmt2local(0);
+#ifdef WITH_CHROOT
+ /* if run as root, prepare for chrooting */
+ if (getuid() == 0 || geteuid() == 0) {
+ /* future extensibility for cmd-line arguments */
+ if (!chroot_dir)
+ chroot_dir = WITH_CHROOT;
+ }
+#endif
+
#ifdef WITH_USER
/* if run as root, prepare for dropping root privileges */
if (getuid() == 0 || geteuid() == 0) {
@@ -885,9 +906,8 @@
* We cannot do this earlier, because we want to be able to open
* the file (if done) for writing before giving up permissions.
*/
- if (username) {
- droproot(username);
- }
+ if
Re: chroot and setuid [Re: [tcpdump-workers] OpenBSD work on Tcpdump privilege separation]
Pekka Savola wrote:
This is my view on how chroot should be done (note: I haven't bothered
to add a cmd-line argument, if you think that should be added, it's
trivial), and the trivial setuid patch as well.
I don't think it's necessary, but it might be handy. See below.
This doesn't try to automatically create directories or whatever, but
relies on the compile time option (e.g. /var/empty) but is IMHO better
in some sense.
- if (initgroups(pw-pw_name, 0) != 0 || setgid(pw-pw_gid) != 0 ||
+ if (chroot_dir) {
+ if (chroot(chroot_dir) != 0 || chdir (.) != 0) {
No, you have to chdir to /. Or better, do (chdir(chroot_dir) != 0 ||
chroot(.) != 0). On some platforms, chroot() doesn't do an implicit chdir(),
so the way you've done things you won't end up chrooted -- your cwd will still
be where you started.
That's why Andrew went to the trouble of looking at Wietse Venema's chrootuid
code as a point of reference for this, so we don't get into trouble.
There's one issue that occurred to me with chroot: on some
platforms/configurations there may be a need for access to certain files outside
the jail. If any get*byname() calls are being used, there may be a need for
access to /etc/resolv.conf, /etc/protocols, etc. On IRIX, it's worse since all
the get*by*() calls end up relying on access to /ns. So if -n isn't in force,
chrooting might break some lookups. So that also argues for a commandline
argument at least to switch it off.
--
Jefferson Ogata [EMAIL PROTECTED]
NOAA Computer Incident Response Team (N-CIRT) [EMAIL PROTECTED]
-
This is the TCPDUMP workers list. It is archived at
http://www.tcpdump.org/lists/workers/index.html
To unsubscribe use mailto:[EMAIL PROTECTED]
