Re: [tcpdump-workers] [tcpdump] New feature to limit capture file size (#464)
On Jun 10, 2015, at 7:35 AM, Darren Reed darr...@netbsd.org wrote: On 10/06/2015 5:42 AM, Michael Richardson wrote: re: https://github.com/the-tcpdump-group/tcpdump/pull/464 Guy writes: We have the -C option, giving a file size in megabytes (real megabytes, i.e. 1,000,000 bytes, not 1,048,576 bytes); once the file gets that big, tcpdump switches to a new file. This adds another file size option, with a different syntax for the size option, and with tcpdump stopping rather than rotating files when it reaches that size. We also have the -G option, to rotate files based on time rather than size. We might want to consider cleaning up these options a bit, so that we can specify stop vs. rotate and file size rather than capture time independently. thoughts? I'm happy to accept the patch once sane, and then clean it up as Guy suggests. Maybe it is time to work out how this should interact now... Why is there even a need to have -G and -C? Aren't both really just the same feature? (file rotation) But with a different parameter? Why can't it be -C 1h,500M? (rotate after 500M or 1h) ... and so on. I think the We might want to... paragraph is right but that more thought is needed. Whatever the decision is can we be sure that the various options (-G, -C and -W) are kept for backwards compatibility for a long time? I ask because I know of some places which are using -G to write packets in time sliced files and changing the semantics of that flag would cause mass chaos. What has never been clear to me is how -G, -C and -W work together, so any way to simplify things there and make it clearer is welcome by me. -- WXS ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] -C option not working? FreeBSD 10.1
I've got a patch for this at https://github.com/wxsBSD/tcpdump/commit/84998745a29a0ffb3a680c29692c15426a1ce960. Seems to work well but I would appreciate any testing anyone can do. I'm also going to make sure this is right from the capsicum perspective as I have no experience with that. Once I discuss it with those folks I'll send a pull request. On a somewhat related note, how is -G, -W and -C supposed to work together. The man page makes it sound like you can use all three together, but I'm not able to get anything to work. I would expect to do this: tcpdump -i em0 -G 5 -W 5 -C 1 -w foo.pcap and get foo.pcap0, foo.pcap1, foo.pcap2, foo.pcap3, foo.pcap4. Each output file should have 5 seconds worth of packets in them and then rotated. I can't seem to get this behavior. -- WXS On Feb 18, 2015, at 12:38 AM, SJP Lists sjp.li...@flashbsd.net wrote: Hello all, Firstly, apologies if I missed info about this from a FAQ, documentation, source README and CHANGES and Google or if I am just doing something silly. I looked at the man page and performed a Google and case sensitive searches via casesensitivesearch.com (to avoid all the -c results) but did not find any info about this issue I am having. I have built a host for circular recording of WAN traffic onto 2TB worth of storage, in order to hopefully catch pcaps after an event of intermittent issues we are not able to replicate. Hoping that when a user complains and gives us the time of the issue, I can just grab a copy of the pre-recorded pcap which should contain the traffic associated with their issue. I've used FreeBSD 10.1 for this. With the following tcpdump syntax as an example, run as root: tcpdump -C 1 -W 10 -w filename -i em0 and I am finding that filename0 is created and captured to, but the capture does not roll over to the next file and instead continues to capture to the first file beyond the limit I thought would be imposed with -C 1, until I kill the process. I have tried the -Z option with -Z root, in case the issue was that a new file cannot be created once privs are dropped, but I get the same result. Thank you for reading and any help that you can give! Shane ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] -C option not working? FreeBSD 10.1
Thanks! I've submitted a pull request (please ignore my first one, it was made on the master branch of my fork). https://github.com/the-tcpdump-group/tcpdump/pull/433 I'm still not clear how -G, -C and -W are meant to work together though. The manage is a bit unclear to me. Any pointers on how it is supposed to work so I can try and make sure that is true would be appreciated. -- WXS On Feb 18, 2015, at 4:23 PM, Guy Harris g...@alum.mit.edu wrote: On Feb 18, 2015, at 10:18 AM, Wesley Shields w...@freebsd.org wrote: I've got a patch for this at https://github.com/wxsBSD/tcpdump/commit/84998745a29a0ffb3a680c29692c15426a1ce960. I've checked into the trunk a change to check for pcap_dump_ftell() failing (which it should *always* have done; had it done that, the symptoms of this problem would have been a bit less obscure), so your changes might at least need to get the indentation readjusted. ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] -C option not working? FreeBSD 10.1
Looks like the call to pcap_dump_ftell() is always returning -1 and setting errno to 93 (ENOTCAPABLE). This makes sense since I can only trigger it on FreeBSD, and if I disable capsicum support in config.h and rebuild then -C works as expected. I'll take a look at this and send a PR, but you may be better off building it yourself and disabling capsicum for now. -- WXS On Feb 18, 2015, at 12:38 AM, SJP Lists sjp.li...@flashbsd.net wrote: Hello all, Firstly, apologies if I missed info about this from a FAQ, documentation, source README and CHANGES and Google or if I am just doing something silly. I looked at the man page and performed a Google and case sensitive searches via casesensitivesearch.com (to avoid all the -c results) but did not find any info about this issue I am having. I have built a host for circular recording of WAN traffic onto 2TB worth of storage, in order to hopefully catch pcaps after an event of intermittent issues we are not able to replicate. Hoping that when a user complains and gives us the time of the issue, I can just grab a copy of the pre-recorded pcap which should contain the traffic associated with their issue. I've used FreeBSD 10.1 for this. With the following tcpdump syntax as an example, run as root: tcpdump -C 1 -W 10 -w filename -i em0 and I am finding that filename0 is created and captured to, but the capture does not roll over to the next file and instead continues to capture to the first file beyond the limit I thought would be imposed with -C 1, until I kill the process. I have tried the -Z option with -Z root, in case the issue was that a new file cannot be created once privs are dropped, but I get the same result. Thank you for reading and any help that you can give! Shane ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] -C option not working? FreeBSD 10.1
I don't have an answer to your original question other than to say I just duplicated it on a FreeBSD host but not on OS X. Smells like a bug to me. I've done something similar in the past using -G and writing to something like /packets/%Y/%m/%d/%H%M%S.pcap (assuming those directories exist). This way when you are given a time when the problem occurred you can jump to that specific file much easier. Though, if you have to find the start of the session it may be in an earlier file. tcpdump -G 300 -w /packets/%Y/%m/%d/%H%M%S.pcap -- WXS On Feb 18, 2015, at 12:38 AM, SJP Lists sjp.li...@flashbsd.net wrote: Hello all, Firstly, apologies if I missed info about this from a FAQ, documentation, source README and CHANGES and Google or if I am just doing something silly. I looked at the man page and performed a Google and case sensitive searches via casesensitivesearch.com (to avoid all the -c results) but did not find any info about this issue I am having. I have built a host for circular recording of WAN traffic onto 2TB worth of storage, in order to hopefully catch pcaps after an event of intermittent issues we are not able to replicate. Hoping that when a user complains and gives us the time of the issue, I can just grab a copy of the pre-recorded pcap which should contain the traffic associated with their issue. I've used FreeBSD 10.1 for this. With the following tcpdump syntax as an example, run as root: tcpdump -C 1 -W 10 -w filename -i em0 and I am finding that filename0 is created and captured to, but the capture does not roll over to the next file and instead continues to capture to the first file beyond the limit I thought would be imposed with -C 1, until I kill the process. I have tried the -Z option with -Z root, in case the issue was that a new file cannot be created once privs are dropped, but I get the same result. Thank you for reading and any help that you can give! Shane ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] File rotation every x seconds AND max file count
I believe daemonlogger can do this. It's been a while since I looked at it but I believe that is what I added support for years ago. http://sourceforge.net/projects/daemonlogger/ -- WXS On Thu, Oct 16, 2014 at 01:21:57AM -0700, Cosmin T wrote: Hello, I wanted to create a pcap buffer of 2 hours based on 60 second slices. I hoped to achieve this by specifying -G 60 -W 120 (1 file every minute, 120 minutes). But of course, after reaching the 120 file count, tcpdump exits. Do you plan on implementing a way of doing the above? Thank you, Cosmin ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
[tcpdump-workers] Extend libpcap tcpflags definition
I've been trying to come up with a good way to finish the work done in this pull request: https://github.com/the-tcpdump-group/libpcap/pull/300 I've been having a hard time coming up with a way that works, and I'm curious if anyone else has suggestions. We can always commit the definitions for tcp-ece and tcp-cwr, but if we want to be able to reference tcp-ns (the last bit of the 12th byte of a TCP header) we will have to change tcpflags to 12:2 (it is currently 13th byte). Another option is to define an ext-tcpflags (or some other name, I really don't care) as the 12th byte and reference it as tcp[ext-tcpflags:2] if you want to look at tcp-ns. At this point I'm open to suggestions. -- WXS ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
[tcpdump-workers] website not updated
If tcpdump 4.4.0 and libpcap 1.4.0 are done should the webpage be updated or are they in some kind of beta form? I'll happily fix it on github if that's the right place to do it. -- WXS ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] tcpdump 4.4 release candidate 1
On Mon, Mar 25, 2013 at 02:42:07PM -0400, Wesley Shields wrote: On Sun, Mar 24, 2013 at 05:52:51PM -0400, Michael Richardson wrote: Romain == Romain Francoise rom...@orebokech.com writes: please expect a new release candidate on 2013-03-09, assuming I can get enough Internet in St.Johns. Romain Not sure if this was St John's in Antigua or St John's in Romain Canada, hopefully the former this time of year (but most Romain likely the latter). :-) It was a 7000km of air travel for a 2300km trip thanks to snow at LGA. Very tiring. Romain In any case the rc2 tarballs are nowhere to be found. Can we Romain get an update, please? http://www.ca.tcpdump.org/beta/ Picking a random spot in this thread to chime in but I've heard reports via co-workers that hitting ^C while handling multiple input files via 'find | tcpdump -V -' doesn't work as expected. I'm trying to find time to look into this before the 4.4.0 release. Hopefully it's not too late to get https://github.com/mcr/tcpdump/pull/60 merged in to 4.4.0. Prior to the fix mentioned above if you hit ^C while doing find /pcaps -type f | tcpdump -V - -w foo.pcap it would stop processing the current file and move on to the next one in the list. With this fix it stops processing the entire list and exits normally. -- WXS ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] tcpdump 4.4 release candidate 1
On Sun, Mar 24, 2013 at 05:52:51PM -0400, Michael Richardson wrote: Romain == Romain Francoise rom...@orebokech.com writes: please expect a new release candidate on 2013-03-09, assuming I can get enough Internet in St.Johns. Romain Not sure if this was St John's in Antigua or St John's in Romain Canada, hopefully the former this time of year (but most Romain likely the latter). :-) It was a 7000km of air travel for a 2300km trip thanks to snow at LGA. Very tiring. Romain In any case the rc2 tarballs are nowhere to be found. Can we Romain get an update, please? http://www.ca.tcpdump.org/beta/ Picking a random spot in this thread to chime in but I've heard reports via co-workers that hitting ^C while handling multiple input files via 'find | tcpdump -V -' doesn't work as expected. I'm trying to find time to look into this before the 4.4.0 release. -- WXS ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] why the ethernet and ip header of packets, which are captured by libpcap function, are distorted
On Thu, Mar 21, 2013 at 01:03:56PM -0400, Bill Fenner wrote: On Mon, Mar 18, 2013 at 11:08 PM, Wesley Shields w...@freebsd.org wrote: On Fri, Mar 15, 2013 at 06:37:25PM -0700, Guy Harris wrote: On Mar 15, 2013, at 2:45 PM, Michael Richardson m...@sandelman.ca wrote: wen == wen lui esolvepol...@gmail.com writes: wen I used libpcap function pcap_next() to capture some tcp packets wen I checked the bytes of the captured packets and notice that the wen ethernet and ip header of packets are distorted, in a mess with wen a lot 0's but the TCP header is fine wen what are potential reasons for this? if you capture on Linux with the cooked mode interface. That probably won't happen if you're capturing on an Ethernet device, but it *will* happen if you capture on the any device. However, yes, *NO* program using libpcap/WinPcap should simply *assume* it's getting Ethernet packets; if it's looking at the packets, not just blindly writing them to a file without examining the contents, then, if it doesn't need to handle 802.11 and PPP and so on, just Ethernet, it should at least call pcap_datalink() and fail if the return value isn't DLT_EN10MB. (If it's writing them to a pcap file, pcap_dump_open() will call pcap_datalink() for you, to put the right link-layer header type in the file header.) (Should we change libpcap so that if pcap_datalink() isn't called at least once before calling pcap_next(), pcap_next_ex(), pcap_dispatch(), or pcap_loop(), it prints a message to the standard error saying you're probably assuming all the world is Ethernet, aren't you? and calls abort(). :-)) As I'm not sure if you're serious or not I decided to look into this to satisfy my own curiosity. In case you are serious: https://github.com/wxsBSD/libpcap/commit/70cbe36e2bd12498ca1622349ecb1716a874c376 If you are serious and want this I'll submit a pull request. Since pcap_compile() calls pcap_datalink(), I don't think that this will have as much affect as Guy was imagining. I noticed that. I think I mentioned it in commit. (Now introduce an argument to pcap_datalink() that says I'm calling you from pcap_compile(), and ... ;-) That would be breaking a lot of existing applications. -- WXS ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] why the ethernet and ip header of packets, which are captured by libpcap function, are distorted
On Fri, Mar 15, 2013 at 06:37:25PM -0700, Guy Harris wrote: On Mar 15, 2013, at 2:45 PM, Michael Richardson m...@sandelman.ca wrote: wen == wen lui esolvepol...@gmail.com writes: wen I used libpcap function pcap_next() to capture some tcp packets wen I checked the bytes of the captured packets and notice that the wen ethernet and ip header of packets are distorted, in a mess with wen a lot 0's but the TCP header is fine wen what are potential reasons for this? if you capture on Linux with the cooked mode interface. That probably won't happen if you're capturing on an Ethernet device, but it *will* happen if you capture on the any device. However, yes, *NO* program using libpcap/WinPcap should simply *assume* it's getting Ethernet packets; if it's looking at the packets, not just blindly writing them to a file without examining the contents, then, if it doesn't need to handle 802.11 and PPP and so on, just Ethernet, it should at least call pcap_datalink() and fail if the return value isn't DLT_EN10MB. (If it's writing them to a pcap file, pcap_dump_open() will call pcap_datalink() for you, to put the right link-layer header type in the file header.) (Should we change libpcap so that if pcap_datalink() isn't called at least once before calling pcap_next(), pcap_next_ex(), pcap_dispatch(), or pcap_loop(), it prints a message to the standard error saying you're probably assuming all the world is Ethernet, aren't you? and calls abort(). :-)) As I'm not sure if you're serious or not I decided to look into this to satisfy my own curiosity. In case you are serious: https://github.com/wxsBSD/libpcap/commit/70cbe36e2bd12498ca1622349ecb1716a874c376 If you are serious and want this I'll submit a pull request. -- WXS ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] Decoding the unencrypted part(s) of SSL/TLS?
On Mon, Dec 10, 2012 at 11:38:29PM -0500, Michael Richardson wrote: Rick == Rick Jones rick.jon...@hp.com writes: Rick Is there a version of tcpdump in the works which will decode Rick the unecrypted Rick portions of an SSL/TLS session? Or do I need to look Rick elsewhere? Are you asking if there is a decoder for the SSL/TLS handshakes or are you asking if there is something that will, given a private key, decrypt the SSL? Yes/no. You have, in general, to do TCP reassembly as TLS blocks might span TCP segments. Fortunately, you can use: http://www.rtfm.com/ssldump/ to do exactly that. There are some problems with ssldump when building on newer-ish systems (at least I think there were last time I tried to use it). If you can get it to work it is good. It takes pcap files. It even decrypts if you give it the keys. Another option is to use tshark. I'm not a fan of it but it does work in a pinch. -- WXS ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] Multifile patch
On Thu, Sep 06, 2012 at 02:46:30PM -0400, Wesley Shields wrote: On Mon, Sep 03, 2012 at 10:13:57PM -0400, Michael Richardson wrote: Wesley, is fopen(/dev/stdin) really the most portal way to get a reference to stdin? I'd have thought that doing: VFile=stdin; was the best way? I fixed this and your other comment about refactoring reading from the file. Please see my latest commit on github. https://github.com/wxsBSD/tcpdump/commit/4c2790a43252b9cac1fe7f6b50b51c3c55d2370a No further comments so I issued a pull request. -- WXS ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] Multifile patch
On Mon, Sep 03, 2012 at 10:13:57PM -0400, Michael Richardson wrote: Wesley, is fopen(/dev/stdin) really the most portal way to get a reference to stdin? I'd have thought that doing: VFile=stdin; was the best way? I fixed this and your other comment about refactoring reading from the file. Please see my latest commit on github. https://github.com/wxsBSD/tcpdump/commit/4c2790a43252b9cac1fe7f6b50b51c3c55d2370a -- WXS ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] Multifile patch
On Thu, Aug 23, 2012 at 01:27:33PM -0400, Michael Richardson wrote: Wesley == Wesley Shields w...@freebsd.org writes: Since pcap files have no end of file marker, and each file has a header on it, do you look at the beginning of each packet, and see if there is a pcap magic number? Wesley I'm not sure I'm parsing this right but... Wesley I am using pcap_open_offline() on each file, which should be validating Wesley that I'm operating on a pcap file. I also check to ensure Wesley that the DLT Ah, sorry, you wrote: find /pcaps -type f | tcpdump -V - -w out.pcap so you are reading a list of files rather than concatenating them. I had read: find /pcaps -type f | xargs cat | tcpdump -V - -w out.pcap so you'd have a byte stream with multiple pcap headers inline. Do we support multipe -r flags... no... maybe that's a better fix? I don't recall that being supported. I'm not sure what it would take to do that either. My approach seemed easy enough to implement. -- WXS ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] Multifile patch
On Tue, Aug 21, 2012 at 08:36:12PM -0400, Michael Richardson wrote: Wesley, it seems like a good idea. I can't look at your patch from the cottage, since I squirt out bits only once a day by walking down the road to where there is some wifi. No worries, I'm in no rush on this. Enjoy your time away from the internet. Since pcap files have no end of file marker, and each file has a header on it, do you look at the beginning of each packet, and see if there is a pcap magic number? I'm not sure I'm parsing this right but... I am using pcap_open_offline() on each file, which should be validating that I'm operating on a pcap file. I also check to ensure that the DLT of every subsequent file matches the DLT of the first file when using this option in conjunction with -w, since we don't want to generate one output file with multiple input DLTs. -- WXS ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] post-commit emailing
On Tue, Sep 13, 2011 at 01:36:00PM -0400, Michael Richardson wrote: Rick == Rick Jones rick.jon...@hp.com writes: I think that this is a bit low, so double it. Rick While that would be considerably higher than the current Rick tcpdump-workers email rate (as I perceive it, not actually Rick measured) it does not strike me as an onerous level of emails. okay, so it's done. The email will be sent by the person committing, so there may be some list moderation that has to occur. I haven't seen any of these yet. Am I missing something here? -- WXS - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] pcap anonymizer
On Wed, May 04, 2011 at 09:44:55AM -0400, Michael Richardson wrote: Aaron == Aaron Turner synfina...@gmail.com writes: Aaron On Fri, Apr 29, 2011 at 12:20 AM, Andrej van der Zee Aaron andrejvander...@gmail.com wrote: With tcprewrite you can change ips too. Not sure if it updates checksums though... Andrej Aaron Yes, tcprewrite updates the relevant checksums for all edits. Aaron It will also edit MAC addresses in case you care that someone Aaron can figure out what vendor's hardware you're using. Aaron One thing people need to think about when writing these kind Aaron of tools is how many protocols expose host identities. HTTP, Aaron SMTP, FTP, almost every Microsoft protocol, etc. Some are Aaron *usually* just host names (HTTP Host Header for example), So, I care mostly about IP addresses in the tests/ directory. I'd like to make it easier for people to submit test cases. Among the others mentioned, I believe bittwist can do that. http://bittwist.sourceforge.net/ -- WXS - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
[tcpdump-workers] Fix print-pflog.c
Looks like commit e8b523758959c1854689d71c7a4686c631e5501c broke tcpdump on FreeBSD (and probably any other system with PF). The attached patch fixes the build. -- WXS --- ./print-pflog.c.orig 2010-03-31 00:12:46.197152894 -0400 +++ ./print-pflog.c 2010-03-31 00:13:00.429070083 -0400 @@ -42,6 +42,7 @@ #include stdio.h #include pcap.h +#include extract.h #include interface.h #include addrtoname.h - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] Fix print-pflog.c
On Wed, Mar 31, 2010 at 11:00:25AM -0700, Guy Harris wrote: On Mar 31, 2010, at 9:15 AM, Michael Richardson wrote: Two questions: 1) is there anything preventing us from processing pflog format pcap files on any system (i.e. a header I'm missing on non-BSD systems)? The fact that the header for packets in a DLT_PFLOG file can be (and has been) changed by the pflog developers, without a version number in the header and without asking for a new DLT_ value every time it changes, and we decided not to even try to follow that, so we get the packet header format from net/if_pflog.h (and other stuff from net/pfvar.h)? 2) can you give us a .pcap file and test case to process that file, so that this does not happen again? The problem was presumably that tcpdump probably didn't even *build* on FreeBSD or OpenBSD. Yes, this was it exactly. Thank you for pushing the fix in. -- WXS - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] Release schedule?
On Tue, Mar 30, 2010 at 03:21:50PM -0400, Michael Richardson wrote: Gianluca == Gianluca Varenni gianluca.vare...@cacetech.com writes: Gianluca What happened to the release? Oh, oops, I did'nt move the release from the /beta to the release dir. my bad. The links on http://www.tcpdump.org are broken. -- WXS - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] pcap_findalldevs() failing on FreeBSD 7.2
On Tue, Oct 27, 2009 at 12:00:04PM -0700, Aaron Turner wrote:
On Tue, Oct 27, 2009 at 11:55 AM, Jung-uk Kim j...@freebsd.org wrote:
On Friday 25 September 2009 01:18 am, Aaron Turner wrote:
I've got a user of tcpreplay having issues where his interfaces are
not being returned via pcap_findalldevs() under FreeBSD 7.2 using
libpcap 0.9.7. ?I don't have much more information unfortunately,
but I do know he has an nVIDIA nForce 10/100/1000 Ethernet NIC as
well as the obvious loopback.
I've confirmed he is running as root and the interface is up:
nfe0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0
mtu 1500
options=19bRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,TSO4
ether 00:1e:8c:b1:de:91
? ? ? ? inet 192.168.1.111 netmask 0xff00 broadcast
192.168.1.255 media: Ethernet autoselect (100baseTX
full-duplex,flag0,flag1) status: active
Actually, none of his interfaces are being returned (nfe0, nfe1 and
lo0). ?I looked in the change log and don't see any mention of any
improvements/fixes in pcap_finalldevs() since 0.9.7 so I figured
I'd mention it.
It's working fine for me:
%uname -mrs
FreeBSD 9.0-CURRENT amd64
%tcpdump -D
1.re0
2.lo0
%tcpdump -c 10 -w /dev/null
tcpdump: listening on re0, link-type EN10MB (Ethernet), capture size
96 bytes
10 packets captured
18 packets received by filter
0 packets dropped by kernel
Note tcpdump -D is using pcap_findalldevs() as well:
tcpdump.c:
--
#ifdef HAVE_PCAP_FINDALLDEVS
? ?case 'D':
? ? ? ?if (pcap_findalldevs(devpointer, ebuf) 0)
? ? ? ? ? ?error(%s, ebuf);
? ? ? ?else {
? ? ? ? ? ?for (i = 0; devpointer != 0; i++) {
? ? ? ? ? ? ? ?printf(%d.%s, i+1, devpointer-name);
? ? ? ? ? ? ? ?if (devpointer-description != NULL)
? ? ? ? ? ? ? ? ? ?printf( (%s), devpointer-description);
? ? ? ? ? ? ? ?printf(\n);
? ? ? ? ? ? ? ?devpointer = devpointer-next;
? ? ? ? ? ?}
? ? ? ?}
? ? ? ?return 0;
--
Jung-uk Kim
I notice you're using FreeBSD 9.0... what version of libpcap? I
wonder if this is a libpcap bug or something in FreeBSD?
I have two machines with identical hardware. They both have an nfe and
bge interface. I don't use the nfe one at all.
w...@syn wxs % uname -sr
FreeBSD 7.1-RELEASE-p5
w...@syn wxs % ifconfig -l
bge0 fwe0 fwip0 nfe0 lo0 pflog0
w...@syn wxs % ifconfig nfe0
nfe0: flags=8802BROADCAST,SIMPLEX,MULTICAST metric 0 mtu 1500
options=10bRXCSUM,TXCSUM,VLAN_MTU,TSO4
ether 00:e0:81:5b:6b:4f
media: Ethernet autoselect (none)
status: no carrier
w...@syn wxs % sudo tcpdump -D
1.bge0
2.lo0
w...@syn wxs % sudo ifconfig nfe0 192.168.3.100/24
w...@syn wxs % sudo tcpdump -D
1.bge0
2.nfe0
3.lo0
w...@syn wxs % tcpdump -V
tcpdump version 3.9.8
libpcap version 0.9.8
I get the same results on a 9-CURRENT machine.
That is with tcpdump version 4.0.0 and libpcap version 1.0.0.
-- WXS
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] pcap_findalldevs() failing on FreeBSD 7.2
On Wed, Oct 28, 2009 at 10:57:33AM -0400, Wesley Shields wrote:
On Tue, Oct 27, 2009 at 12:00:04PM -0700, Aaron Turner wrote:
On Tue, Oct 27, 2009 at 11:55 AM, Jung-uk Kim j...@freebsd.org wrote:
On Friday 25 September 2009 01:18 am, Aaron Turner wrote:
I've got a user of tcpreplay having issues where his interfaces are
not being returned via pcap_findalldevs() under FreeBSD 7.2 using
libpcap 0.9.7. ?I don't have much more information unfortunately,
but I do know he has an nVIDIA nForce 10/100/1000 Ethernet NIC as
well as the obvious loopback.
I've confirmed he is running as root and the interface is up:
nfe0: flags=8843UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST metric 0
mtu 1500
options=19bRXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,TSO4
ether 00:1e:8c:b1:de:91
? ? ? ? inet 192.168.1.111 netmask 0xff00 broadcast
192.168.1.255 media: Ethernet autoselect (100baseTX
full-duplex,flag0,flag1) status: active
Actually, none of his interfaces are being returned (nfe0, nfe1 and
lo0). ?I looked in the change log and don't see any mention of any
improvements/fixes in pcap_finalldevs() since 0.9.7 so I figured
I'd mention it.
It's working fine for me:
%uname -mrs
FreeBSD 9.0-CURRENT amd64
%tcpdump -D
1.re0
2.lo0
%tcpdump -c 10 -w /dev/null
tcpdump: listening on re0, link-type EN10MB (Ethernet), capture size
96 bytes
10 packets captured
18 packets received by filter
0 packets dropped by kernel
Note tcpdump -D is using pcap_findalldevs() as well:
tcpdump.c:
--
#ifdef HAVE_PCAP_FINDALLDEVS
? ?case 'D':
? ? ? ?if (pcap_findalldevs(devpointer, ebuf) 0)
? ? ? ? ? ?error(%s, ebuf);
? ? ? ?else {
? ? ? ? ? ?for (i = 0; devpointer != 0; i++) {
? ? ? ? ? ? ? ?printf(%d.%s, i+1, devpointer-name);
? ? ? ? ? ? ? ?if (devpointer-description != NULL)
? ? ? ? ? ? ? ? ? ?printf( (%s), devpointer-description);
? ? ? ? ? ? ? ?printf(\n);
? ? ? ? ? ? ? ?devpointer = devpointer-next;
? ? ? ? ? ?}
? ? ? ?}
? ? ? ?return 0;
--
Jung-uk Kim
I notice you're using FreeBSD 9.0... what version of libpcap? I
wonder if this is a libpcap bug or something in FreeBSD?
I have two machines with identical hardware. They both have an nfe and
bge interface. I don't use the nfe one at all.
w...@syn wxs % uname -sr
FreeBSD 7.1-RELEASE-p5
w...@syn wxs % ifconfig -l
bge0 fwe0 fwip0 nfe0 lo0 pflog0
w...@syn wxs % ifconfig nfe0
nfe0: flags=8802BROADCAST,SIMPLEX,MULTICAST metric 0 mtu 1500
options=10bRXCSUM,TXCSUM,VLAN_MTU,TSO4
ether 00:e0:81:5b:6b:4f
media: Ethernet autoselect (none)
status: no carrier
w...@syn wxs % sudo tcpdump -D
1.bge0
2.lo0
w...@syn wxs % sudo ifconfig nfe0 192.168.3.100/24
w...@syn wxs % sudo tcpdump -D
1.bge0
2.nfe0
3.lo0
w...@syn wxs % tcpdump -V
tcpdump version 3.9.8
libpcap version 0.9.8
I get the same results on a 9-CURRENT machine.
That is with tcpdump version 4.0.0 and libpcap version 1.0.0.
Sorry if another one comes through but my first attempt at this message
never made it through.
nfe0 doesn't need to have an IP address, just be up. Maybe that is what
is going on?
-- WXS
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.
