Re: [tcpdump-workers] [tcpdump] 7 tests fail on Ubuntu 11.10 (#33)
05.10.2012, 23:07, "Michael Richardson" : >>>>>> "Marc" == Marc Abramowitz writes: > > Marc> After I observed 7 tests failing on Travis CI (which uses > Marc> Ubuntu) in #32, I tried running the tests in an Ubuntu 11.10 > Marc> virtual machine and also got 7 test failures there. > > It's likely you do not have libssl-dev installed, so tcpdump is > configured without the ability to decode ESP (IPsec) packets. > > Marc> esp1: failed. esp2: failed. esp3: failed. esp4: failed. This bug is specific to a 64-bit build. The matter is, $libdir alwayss end in "/lib" and this "lib" is later used to locate libcrypto.so (see AC_LBL_SSLEAY). This way, an installed openssl-devel is never detected by default on a 64-bit system, because the library files are in /usr/lib64. On a 32-bit system detection works fine and all tests pass. To make the configure detect openssl-devel on a 64-bit system it should be run this way: ./configure --with-crypto --libdir=/usr/lib64 After that all tests pass. -- Denis Ovsienko ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] [PATCH] Decode DHCPv6 AFTR-Name option (RFC6334)
18.11.2012, 20:05, "François-Xavier Le Bail" : > Hello, > > Please find the patch version 2 as an attachment. Neither version made it to the list. Do you have this change published as a git commit? The original tcpdump repository is here: https://github.com/mcr/tcpdump -- Denis Ovsienko ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
[tcpdump-workers] verbose decoding without assigned port number
Hello, list. There are network protocols that have an assigned port number, and there are other that don't or are commonly used on non-assigned ports, such as HTTP on port 8080. Looking at function tcp_print() in file print-tcp.c, it is clear how the former are handled, but is there any assumed way to handle the latter? I am considering adding a ZeroMQ decoder to tcpdump, to be particular. -- Denis Ovsienko ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] verbose decoding without assigned port number
> Currently the -T option is the only resort at the IP layer and UDP layer. > It could apply to TCP too, perhaps. Thanks, that seems to be OK to start with. > > It would be nice to have a way for each ULP decoders to register their > name so that it's not so switch() stmt based, and then to have a file > which can be provided to map multiple ports at the same time. I'll look if that can be done quickly. -- Denis Ovsienko ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] verbose decoding without assigned port number
> Denis> There are network protocols that have an assigned port > Denis> number, and there are other that don't or are commonly used > Denis> on non-assigned ports, such as HTTP on port 8080. Looking at > Denis> function tcp_print() in file print-tcp.c, it is clear how the > Denis> former are handled, but is there any assumed way to handle > Denis> the latter? I am considering adding a ZeroMQ decoder to > Denis> tcpdump, to be particular. > > Currently the -T option is the only resort at the IP layer and UDP layer. > It could apply to TCP too, perhaps. It looks like -T applies. I've got a working code and am producing a sample capture. The ZeroMQ decoding function is called from both tcp_print() and udp_print(), should I put it into an existing file or a new file? Which of license boilerplates then? -- Denis Ovsienko ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] verbose decoding without assigned port number
08.02.2013, 21:55, "Michael Richardson" : >>>>>> "Denis" == Denis Ovsienko writes: >>> Currently the -T option is the only resort at the IP layer and >>> UDP layer. It could apply to TCP too, perhaps. > > Denis> It looks like -T applies. I've got a working code and am > Denis> producing a sample capture. The ZeroMQ decoding function is > Denis> called from both tcp_print() and udp_print(), should I put it > Denis> into an existing file or a new file? Which of license > Denis> boilerplates then? > > New file. > 2-clause BSD please. I was wrong about print-udp.c before, ZMTP/1.0 framing is TCP-only. But anyway it's a new file (pull request #50). -- Denis Ovsienko ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] Couldn't parse filter scr port 22000: syntax error
> it output an error: Couldn't parse filter scr port 22000: syntax error "scr port 22000" (mind the typo) -- Denis Ovsienko ___ 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
> 4.4.0rc2 appears to have stuff that's in the trunk but not the > tcpdump_4_4rel0 branch, such as print-msnlb.c, print-vxlan.c, and > print-otv.c, a change to print-bgp.c, and a change to the Makefile not to > have an explicit list of tests but to run a find command to find the tests. > Is that intentional? > There are some fixes to the recent otv, vxlan and msnlb commits in tcpdump pull requests 56 and 57. -- Denis Ovsienko ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] -W options to gcc
28.03.2013, 17:55, "Michael Richardson" : >>>>>> "Gisle" == Gisle Vanem writes: > > Gisle> I compile using MingW (gcc 4.7.2) and normally I use > Gisle> -Wall -W. > > sure, I'd like to get to -Wall -Werror at some point, but for the > moment, I want to know how to include -Wgcc-things when we are using > gcc, and omit when we aren't. > This is from autoconf documentation: "Macro: AC_PROG_CC ([compiler-search-list]) [...] If using the GNU C compiler, set shell variable GCC to ‘yes’." -- Denis Ovsienko ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] moves to github
> 2) Guy Harris has run a source 2 github python script to transfer issues > from SF to github. They are at: > https://github.com/the-tcpdump-group/tcpdump/issues > (103 open, 199 closed) > > https://github.com/the-tcpdump-group/libpcap/issues > (116, 173 closed) > > We need help going through these issues. > I think we can probably come up with some markup to indicate what > is what, and I see colours and other stuff to help sort things out. > Tell me your github ID, and I'll add you to the team if necessary. > > There are lots of patches, turning them into pull requests would be > great. Many of them are likely already done. I tried closing a couple of issues, but ran into a question. Do existing tags in GitHub issues (v3.5, v3.6, ... v4.3) mean "opened against version N.N" or "fixed in version N.N"? Should the tickets in SourceForge tracker be closed now? -- Denis Ovsienko ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] moves to github
>> Should the tickets in SourceForge tracker be closed now? > > If there were an automated way to do so - with commenting closed, and a > "further comments on the issue at http://github.org/the-tcpdump-group/..."; as > the closing comment - that would make sense. > > I'm not sure anybody here wants to close 219 SourceForge comments by hand. :-) Give me 2-4 weeks and permission for SF account "infrastation" and I will take care of that. > > If you mean that when you close an issue by hand on GitHub, the corresponding > SF issue should be closed by hand, that might not be a bad idea. (I did that > for the tcpdump issue you closed on GitHub with "-W implements that".) Let's focus on having only one bug tracker, but a well-ordered one. -- Denis Ovsienko ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] moves to github
> Denis> I tried closing a couple of issues, but ran into a > Denis> question. Do existing tags in GitHub issues (v3.5, v3.6, > Denis> ... v4.3) mean "opened against version N.N" or "fixed in > Denis> version N.N"? > > let's take this to mean, opened against version N.N. I have looked through the GH issues once again, added a few tags and started labelling issues with them: bug feature request duplicate fixed in 4.3.0 web-site The last one deserves a special note, it stands for the kind of issues that I believe to belong to the tcpdump-htdocs repository. That is, the old web-site bugs will be labeled with the tag in the tcpdump repository and any new such issues should be opened in tcpdump-htdocs. I have enabled the issues feature for the tcpdump-htdocs repository and disabled the wiki feature for all 3 repositories (also checked that no wiki pages existed). -- Denis Ovsienko ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] Missing packet fields in big endian with ath9k
> Im getting DLT_IEEE802_11_RADIO. Is this ok?
Hello.
This issue with DLT_IEEE802_11_RADIO and the frame being offset by 4 octets may
have something in common with another issue:
https://github.com/the-tcpdump-group/tcpdump/issues/303
There are patches attached there that may come handy.
--
Denis Ovsienko
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] Missing packet fields in big endian with ath9k
> Hi Denis. > > In deed I've seen different output from the same code. As if the field's > position change upon different power runs. For example, one time I > successfuly got packet type, subtype and rssi values coherent with distance. > Some other run of the same code, but I'd power cycled the router, I got > packet type of 11484 for example ( packet type vary from 0 to 2). I thought - > again - I could be doing something wrong.. > > Do you think your suggestion could explain the behaviour I described? > > Thanks for your answer. I'm only an occasional user of little-endian MIPS and don't have a solid explanation for that. However, it is worth checking that the DLT_IEEE802_11_RADIO packets arrive well-formed in the first place. Does the current git master of tcpdump decode the same packets right? -- Denis Ovsienko ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
[tcpdump-workers] review request: Babel and OpenFlow
List, I am looking for someone to review the commits in pull request #312, which I have opened. It contains a few improvements to existing Babel decoder and a new OpenFlow 1.0 decoder. Both pieces work fine for me, but if you see anything that should be fixed please let me know. -- Denis Ovsienko ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
[tcpdump-workers] tcpdump pull request #313 and libpcap dependency
Hello. The Travis CI build script consists of two jobs: one with the server's libpcap-devel package and another with libpcap cloned from git and built before tcpdump. tcpdump pull request #313 adds a feature that depends on the latest libpcap to build, hence after the merge the former job will fail (see https://travis-ci.org/the-tcpdump-group/tcpdump/builds/7253755). Leaving the pull request unmerged until the code recently added to libpcap is released and propagates to the build server distribution would take a very long time. Do you see any pitfall behind disabling the libpcap-devel build job for the same period of time instead? -- Denis Ovsienko ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] tcpdump pull request #313 and libpcap dependency
[...] > I haven't figured out how to force Travis to do it's thing again. A rebased unmerged pull request triggers the build. It looked like this (https://travis-ci.org/the-tcpdump-group/tcpdump/builds/7591036): OK: BUILD_LIBPCAP=true (with current git master of libpcap) failed: BUILD_LIBPCAP=false (with local server's libpcap-devel) Since Travis requires all jobs to complete to signal a successful build, commit f4d295e removes the 2nd job and the the only remaining job now passes (https://travis-ci.org/the-tcpdump-group/tcpdump/builds/7592044). -- Denis Ovsienko ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] review request: Babel and OpenFlow
22.05.2013, 18:26, "Denis Ovsienko" : > List, > > I am looking for someone to review the commits in pull request #312, which I > have opened. It contains a few improvements to existing Babel decoder and a > new OpenFlow 1.0 decoder. Both pieces work fine for me, but if you see > anything that should be fixed please let me know. > I have additionally checked that both pieces work with packet captures other than just my own, these commits are now in the git master. -- Denis Ovsienko ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] Adding support for ETSI GeoNetworking network and BTP transport protocol
> Is this something the tcpdump community would like to have included in the
> next version of tcpdump?
> How do I proceed to contribute my source code?
Hello.
The current approach to merging code into tcpdump is through a GitHub pull
request: https://github.com/the-tcpdump-group/tcpdump
The pull requests are subject for review. Once the source code is published, it
will be better seen if it requires any fixes prior to merging. New (original)
source code files should have a 2-clause BSD license boilerplate.
Could you briefly explain your use case for these 802.11p protocols and an
estimate of who else could find this feature useful? Thank you.
--
Denis Ovsienko
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] Adding support for ETSI GeoNetworking network and BTP transport protocol
>> Could you briefly explain your use case for these 802.11p protocols and an > > estimate of who else could find > >> this feature useful? Thank you. > > Hi, > > We are using a small Geode alix2d2 Geode box running Linux with IEE802.11p > compatible cards from http://routerboard.com/R52H with the ath5k driver. > > These protocols are used in a lot of European research projects and also > field tests in France, Germany (Hessen/Frankfurt), The Netherlands > (Helmond), Austia (Wien), Norway (Trondheim) and elsewhere. There are plans > to deploy this in ordinary vehicles from 2015 and deploy hundreds of nodes > on motorways in Germany, Austria and The Netherlands. Thanks, now I see. Looking forward to see the patches/commits! -- Denis Ovsienko ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] Adding support for ETSI GeoNetworking network and BTP transport protocol
27.06.2013, 13:28, "Ola Martin Lykkja" : > Hi, > > I am kind of new to git and github. > > I think I did something useful with > https://github.com/lykkja/tcpdump/tree/geonet_and_calmfast > Can you check it out please, to see if I did it right? Hello. The git part of the job is almost finished, there is a repository forked and containing a branch with the commit implementing the new decoders. It takes pushing the right button to place a pull request, so that it will be visible in the queue. Regarding the source code, I have _briefly_ looked through and attached a few comments to the commit. May be somebody else is willing to review as well? -- Denis Ovsienko ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] Adding support for ETSI GeoNetworking network and BTP transport protocol
List, is anybody else willing to review this pull request? https://github.com/the-tcpdump-group/tcpdump/pull/324 These are quite small decoders, but I'm not familiar with the field and quite busy until the weekend. -- Denis Ovsienko ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] Adding support for ETSI GeoNetworking networkand BTP transport protocol
03.07.2013, 14:18, "Gisle Vanem" : > "Denis Ovsienko" wrote: > >> is anybody else willing to review this pull request? >> >> https://github.com/the-tcpdump-group/tcpdump/pull/324 > > I just did a build with MSVC after a new checkout of > https://github.com/the-tcpdump-group/tcpdump.git > > It didn't work out-of-the box because my MSVC (v16 from Visual C > Express 2010) isn't a C99 compiler; you cannot have code ahead of > declarations. Hence these patches should be applied: > [...] Thank you for the feedback! > > > And must go on Windows: I addressed this in a little cleaner way. The changes are in the master branch now, could you check? -- Denis Ovsienko ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] [Patch] print-nfs.c
10.07.2013, 15:18, "Gisle Vanem" : > 'int32_t' isn't 'int' for all targets. Some Windows targets have > it defined as 'signed int' in . So print-nfs.c > does not compile cleanly; conflicting definition of xid_map_find(). Should both declarations be just "int" then? The function returns either 0 or -1 and the only calling function checks the result to be >= 0. -- Denis Ovsienko ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] [Patch] print-nfs.c
11.07.2013, 16:36, "Gisle Vanem" : > "Denis Ovsienko" wrote: > >> 10.07.2013, 15:18, "Gisle Vanem" : >>> 'int32_t' isn't 'int' for all targets. Some Windows targets have >>> it defined as 'signed int' in . So print-nfs.c >>> does not compile cleanly; conflicting definition of xid_map_find(). >> Should both declarations be just "int" then? > > That could be simpler, yes. It is now in GitHub master branch, thank you! -- Denis Ovsienko ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
[tcpdump-workers] OpenSSL deprecation warnings on MacOS
Hello, list. Below are some warnings specific to MacOS 10.8.5, i686-apple-darwin11-llvm-gcc-4.2 (GCC) 4.2.1 (Based on Apple Inc. build 5658) (LLVM build 2336.11.00), would anybody be willing to troubleshoot that? ./print-esp.c: In function ‘esp_print_decrypt_buffer_by_ikev2’: ./print-esp.c:133: warning: ‘EVP_CipherInit’ is deprecated (declared at /usr/include/openssl/evp.h:598) ./print-esp.c:135: warning: ‘EVP_CipherInit’ is deprecated (declared at /usr/include/openssl/evp.h:598) ./print-esp.c:136: warning: ‘EVP_Cipher’ is deprecated (declared at /usr/include/openssl/evp.h:536) ./print-esp.c:137: warning: ‘EVP_CIPHER_CTX_cleanup’ is deprecated (declared at /usr/include/openssl/evp.h:637) ./print-esp.c: In function ‘espprint_decode_encalgo’: ./print-esp.c:251: warning: ‘EVP_get_cipherbyname’ is deprecated (declared at /usr/include/openssl/evp.h:848) ./print-esp.c:263: warning: ‘EVP_CIPHER_iv_length’ is deprecated (declared at /usr/include/openssl/evp.h:495) ./print-esp.c: In function ‘esp_init’: ./print-esp.c:489: warning: ‘OPENSSL_add_all_algorithms_noconf’ is deprecated (declared at /usr/include/openssl/evp.h:828) ./print-esp.c:490: warning: ‘OBJ_NAME_add’ is deprecated (declared at /usr/include/openssl/objects.h:997) ./print-esp.c: In function ‘esp_print’: ./print-esp.c:664: warning: ‘EVP_CipherInit’ is deprecated (declared at /usr/include/openssl/evp.h:598) ./print-esp.c:667: warning: ‘EVP_CIPHER_CTX_block_size’ is deprecated (declared at /usr/include/openssl/evp.h:501) ./print-esp.c:670: warning: ‘EVP_CipherInit’ is deprecated (declared at /usr/include/openssl/evp.h:598) ./print-esp.c:671: warning: ‘EVP_Cipher’ is deprecated (declared at /usr/include/openssl/evp.h:536) ./print-esp.c:672: warning: ‘EVP_CIPHER_CTX_cleanup’ is deprecated (declared at /usr/include/openssl/evp.h:637) ./print-tcp.c: In function ‘tcp_verify_signature’: ./print-tcp.c:769: warning: ‘MD5_Init’ is deprecated (declared at /usr/include/openssl/md5.h:113) ./print-tcp.c:774: warning: ‘MD5_Update’ is deprecated (declared at /usr/include/openssl/md5.h:114) ./print-tcp.c:775: warning: ‘MD5_Update’ is deprecated (declared at /usr/include/openssl/md5.h:114) ./print-tcp.c:776: warning: ‘MD5_Update’ is deprecated (declared at /usr/include/openssl/md5.h:114) ./print-tcp.c:777: warning: ‘MD5_Update’ is deprecated (declared at /usr/include/openssl/md5.h:114) ./print-tcp.c:780: warning: ‘MD5_Update’ is deprecated (declared at /usr/include/openssl/md5.h:114) ./print-tcp.c:784: warning: ‘MD5_Update’ is deprecated (declared at /usr/include/openssl/md5.h:114) ./print-tcp.c:785: warning: ‘MD5_Update’ is deprecated (declared at /usr/include/openssl/md5.h:114) ./print-tcp.c:787: warning: ‘MD5_Update’ is deprecated (declared at /usr/include/openssl/md5.h:114) ./print-tcp.c:789: warning: ‘MD5_Update’ is deprecated (declared at /usr/include/openssl/md5.h:114) ./print-tcp.c:790: warning: ‘MD5_Update’ is deprecated (declared at /usr/include/openssl/md5.h:114) ./print-tcp.c:791: warning: ‘MD5_Update’ is deprecated (declared at /usr/include/openssl/md5.h:114) ./print-tcp.c:793: warning: ‘MD5_Update’ is deprecated (declared at /usr/include/openssl/md5.h:114) ./print-tcp.c:810: warning: ‘MD5_Update’ is deprecated (declared at /usr/include/openssl/md5.h:114) ./print-tcp.c:816: warning: ‘MD5_Update’ is deprecated (declared at /usr/include/openssl/md5.h:114) ./print-tcp.c:820: warning: ‘MD5_Update’ is deprecated (declared at /usr/include/openssl/md5.h:114) ./print-tcp.c:821: warning: ‘MD5_Final’ is deprecated (declared at /usr/include/openssl/md5.h:115) ./signature.c: In function ‘signature_compute_hmac_md5’: ./signature.c:66: warning: ‘MD5_Init’ is deprecated (declared at /usr/include/openssl/md5.h:113) ./signature.c:67: warning: ‘MD5_Update’ is deprecated (declared at /usr/include/openssl/md5.h:114) ./signature.c:68: warning: ‘MD5_Final’ is deprecated (declared at /usr/include/openssl/md5.h:115) ./signature.c:100: warning: ‘MD5_Init’ is deprecated (declared at /usr/include/openssl/md5.h:113) ./signature.c:101: warning: ‘MD5_Update’ is deprecated (declared at /usr/include/openssl/md5.h:114) ./signature.c:102: warning: ‘MD5_Update’ is deprecated (declared at /usr/include/openssl/md5.h:114) ./signature.c:103: warning: ‘MD5_Final’ is deprecated (declared at /usr/include/openssl/md5.h:115) ./signature.c:108: warning: ‘MD5_Init’ is deprecated (declared at /usr/include/openssl/md5.h:113) ./signature.c:109: warning: ‘MD5_Update’ is deprecated (declared at /usr/include/openssl/md5.h:114) ./signature.c:110: warning: ‘MD5_Update’ is deprecated (declared at /usr/include/openssl/md5.h:114) ./signature.c:111: warning: ‘MD5_Final’ is deprecated (declared at /usr/include/openssl/md5.h:115) -- Denis Ovsienko ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] OpenSSL deprecation warnings on MacOS
25.09.2013, 17:47, "Alan DeKok" : [...] > Apple wants applications to use the Apple crypto library instead of > OpenSSL. I'm not sure that this is a good idea for pcap. > > The way to get rid of these warnings is the following code. See the > FreeRADIUS src/include/build.h include file for more examples. [...] Thank you, let me study this solution. BTW, in FreeRADIUS the USES_APPLE_RST macro is never used. -- Denis Ovsienko ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] [tcpdump] IEEE float decoded incorrectly (#333)
01.10.2013, 06:11, "Michael Richardson" : > from > https://github.com/the-tcpdump-group/tcpdump/issues/333 > > details an issue where differences in arch and compiler result in different > extractions of floating point objects in LMP packets. Guy discovers it has > something to do with assumptions about x86 SSE. > > and I think we might find more expertise on the list. List, Dmitrij Tejblum solved this with the -ffloat-store GCC flag. -- Denis Ovsienko ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] Small patch to support pcap_setdirection - change option from -P to -Q?
[...] > I'd like not to have Apple's tcpdump not have to differ from the > standard in that regard. > > Unfortunately, there aren't many options left; we really need to switch to > getopt_long() (and provide our own version for platforms that don't support > it - the main one is Windows for WinDump, and we have to supply our own > getopt() for it already; most UN*Xes support it by now). > An immediate (and quite common) solution could be managing this particular knob by means of a long option like --setdir with no single-letter synonym. Once someone resolves the getopt_long() problem it will be possible to refine things further. [...] -- Denis Ovsienko ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
[tcpdump-workers] June 10, 2012 in the change logs
Hello. Commit 3811829 in tcpdump-htdocs adds missing lines from tcpdump and libpcap repositories and discards a custom modified line in the "htdocs" version of the change logs: -Friday March 30, 2012/June 10, 2012. m...@sandelman.ca +Friday March 30, 2012. m...@sandelman.ca -Friday April 3, 2012/June 10, 2012. m...@sandelman.ca. +Friday April 3, 2012. m...@sandelman.ca. If the (now removed) 2nd date meant something important, I can make it into all files consistently. -- Denis Ovsienko ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
[tcpdump-workers] BPF optimization visualized
List, there is a very interesting pull request for libpcap: https://github.com/the-tcpdump-group/libpcap/pull/319 It translates BPF optimisation process into a series of graphs. Anybody who has an opinion on this, please post it to the list. (For instance, I see an immediate use for it in BPF issues debugging.) Thank you. -- Denis Ovsienko ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
[tcpdump-workers] on compiler optimizations and security
List, this paper explains how a compiler can eliminate from the final binary the pointer safety checks that are present in the source code: http://pdos.csail.mit.edu/~xi/papers/stack-sosp13.pdf The very first example it gives is equivalent to the contents of TTEST2 macro widely used in the source code of tcpdump. Even if subsequent 15 pages of the analysis don't apply, it may make sense to study the solutions the paper suggests. -- Denis Ovsienko ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
[tcpdump-workers] on NFS decoding improvements
List, there is some space for improvement with regard to NFS decoding. In particular, for TCP NFS tcp_print() detects NFS very early and diverts decoding to either nfsreq_print() or nfsreply_print(). This layering violation causes a few issues: 1. The two NFS-specific functions currently print (via print_nfsaddr() function) the source and destination addresses/ports of a packet. This printing does not include TCP-specific (flags, options and sequence numbers) and UDP-specific (checksum) information. 2. The print_nfsaddr() function prints message xid instead of the non-NFS UDP/TCP port. 3. The NFS-decoded TCP packets don't update the seq/ack hash table in tcp_print(). There is a git branch that fixes the TCP part of the problem with two commits: https://github.com/Longinus00/tcpdump/commits/print-tcp_nfs I have verified that these commits don't introduce regressions. The only thing that gets in the way of immediate merge is that the cleanups naturally change the output format, for example (with an extra commit not in the branch): (old, TCP NFS packets) IP 10.230.61.9.865991996 > 10.230.61.77.2049: 148 getattr fh 0,11/1370219428 IP 10.230.61.77.2049 > 10.230.61.9.865991996: reply ok 112 getattr REG 644 ids 0/0 sz 10485760 IP 10.230.61.9.882769212 > 10.230.61.77.2049: 148 getattr fh 0,11/1370219428 IP 10.230.61.77.2049 > 10.230.61.9.882769212: reply ok 112 getattr REG 644 ids 0/0 sz 10485760 (new, same packets) IP 10.230.61.9.760 > 10.230.61.77.2049: Flags [P.], seq 45328:45480, ack 9735069, win 10183, options [nop,nop,TS val 32759 ecr 30912442], length 152: NFS request xid 865991996 getattr fh 0,11/1370219428 IP 10.230.61.77.2049 > 10.230.61.9.760: Flags [P.], seq 9735069:9735185, ack 45480, win 24576, options [nop,nop,TS val 30912442 ecr 32759], length 116: NFS reply xid 865991996 reply ok 112 getattr REG 644 ids 0/0 sz 10485760 IP 10.230.61.9.760 > 10.230.61.77.2049: Flags [P.], seq 45480:45632, ack 9735185, win 10183, options [nop,nop,TS val 32759 ecr 30912442], length 152: NFS request xid 882769212 getattr fh 0,11/1370219428 IP 10.230.61.77.2049 > 10.230.61.9.760: Flags [P.], seq 9735185:9735301, ack 45632, win 24576, options [nop,nop,TS val 30912442 ecr 32759], length 116: NFS reply xid 882769212 reply ok 112 getattr REG 644 ids 0/0 sz 10485760 I intend to merge the commits in a few days unless anyone argues that the output format must be retained. Thank you. -- Denis Ovsienko ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
[tcpdump-workers] FYI: tcpdump bug tracker(s) mapping
7 | | 2693245 | bug 109 | 113 | | 2697283 |patch 89 | 248 | | 2701373 | bug 110 | 114 | | 2713195 |patch 90 | 249 | | 2796822 | bug 111 | 115 | | 2798089 |patch 91 | 250 | | 2802813 | bug 112 | 116 | | 2813234 | bug 113 | 117 | | 2821019 | bug 114 | 118 | | 2823525 | bug 115 | 119 | | 2823933 |patch 92 | 251 | | 2825019 | bug 116 | 120 | | 2826133 | bug 117 | 121 | | 2826867 | bug 118 | 122 | | 2829176 | feature request 10 | 297 | | 2845468 |patch 93 | 252 | | 2851741 | bug 119 | 123 | | 2865514 | feature request 11 | 298 | | 2876645 |patch 94 | 253 | | 2897799 |patch 95 | 254 | | 2898760 |patch 96 | 255 | | 2912420 |patch 97 | 256 | | 2923986 | bug 120 | 124 | | 2932556 |patch 98 | 257 | | 2933893 | feature request 12 | 299 | | 2940539 |patch 99 | 258 | | 2942379 | patch 100 | 259 | | 2955108 | bug 121 | 125 | | 2973272 | bug 122 | 126 | | 2976425 | bug 123 | 127 | | 2983937 | patch 101 | 260 | | 3007771 | patch 102 | 261 | | 3010571 | patch 103 | 262 | | 3012149 | bug 124 | 128 | | 3021966 | bug 125 | 129 | | 3042751 | bug 126 | 130 | | 3049027 | patch 104 | 263 | +-+-+-+ | SF old# | SF new# | GH# | +-+-+-+ | 3056372 | bug 127 | 131 | | 3075510 | bug 128 | 132 | | 3077110 | patch 105 | 264 | | 3095981 | patch 106 | 265 | | 3106340 | feature request 13 | 300 | | 3118313 | patch 107 | 266 | | 3120896 | patch 108 | 267 | | 3120897 | patch 109 | 268 | | 3171866 | bug 129 | 133 | | 3195593 | patch 110 | 269 | | 3199012 | patch 111 | 270 | | 3284802 | patch 112 | 271 | | 3287379 | bug 130 | 134 | | 3295162 | patch 113 | 272 | | 3300706 | patch 114 | 273 | | 3315714 | bug 131 | 135 | | 3316935 | bug 132 | 136 | | 3403559 | patch 115 | 274 | | 3409769 | patch 116 | 275 | | 3409772 | patch 117 | 276 | | 3409773 | patch 118 | 277 | | 3409778 | patch 119 | 278 | | 3419331 | bug 133 | 137 | | 3425286 | bug 134 | 138 | | 3425287 | bug 135 | 139 | | 3431245 | patch 120 | 279 | | 3437902 | patch 121 | 280 | | 3441654 | bug 136 | 140 | | 3444149 | bug 137 | 141 | | 3453360 | bug 138 | 142 | | 3459229 | patch 122 | 281 | | 3461436 | patch 123 | 282 | | 3467532 | feature request 14 | 301 | | 3479675 | patch 124 | 283 | | 3484394 | bug 139 | 143 | | 3487499 | patch 125 | 284 | | 3494835 | bug 140 | 144 | | 3495382 | bug 141 | 145 | | 3496135 | patch 126 | 285 | | 3509052 | bug 142 | 146 | | 3509399 | bug 143 | 147 | | 3522541 | bug 144 | 148 | | 3529867 | feature request 15 | 302 | | 3533254 | bug 145 | 149 | | 3534836 | bug 146 | 150 | | 3536524 | bug 147 | 151 | | 3540300 | bug 148 | 152 | | 3541960 | bug 149 | 153 | | 3565819 | bug 150 | 154 | | 3591874 | patch 127 | 286 | +-+-+-+ | SF old# | SF new# | GH# | +-+-+-+ | 3599633 | patch 128 | 287 | | 3602279 | bug 151 | 155 | +-+-----+-+ -- Denis Ovsienko ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] FYI: tcpdump bug tracker(s) mapping
07.11.2013, 18:36, "Denis Ovsienko" : > List, > > the table below lists all tcpdump issues (bugs, tickets) migrated from > SourceForge to GitHub earlier. "SF old#" is a tracker artifact ID that > SourceForge used to assign until 2013. "SF new#" is a tracker type+ID in use > since 2013. "GH#" is an issue number on GutHub. The mapping from old to new > SF IDs is due to SourceForge and currently happens on its own (in one > direction). The mapping between new SF IDs and GH IDs is due to the bug > tracker migration and doesn't happen on its own, yet it currently works in > both directions: each migrated issue in both trackers has a comment with a > link to the counterpart issue. > > The SourceForge tracker is now read-only and will supposedly remain around > for reference. The GitHub tracker is read-write and is currently located > here: https://github.com/the-tcpdump-group/tcpdump/issues The same now applies to libpcap as mapped in the table below. Note that the SF -> GH migration did not cover any attachments (including patches), thus the SF tracker should remain as a read-only storage for a while longer (for both tcpdump and libpcap). +-+-+-+ | SF old# | SF new# | GH# | +-+-+-+ | 570998 | bug 1 | 1 | | 573101 | bug 2 | 2 | | 573109 | patch 1 | 195 | | 573111 | patch 2 | 196 | | 573119 | bug 3 | 3 | | 586764 | bug 4 | 4 | | 597939 | patch 3 | 197 | | 599847 | bug 5 | 5 | | 599849 | bug 6 | 6 | | 599857 | bug 7 | 7 | | 600034 | patch 4 | 198 | | 600755 | bug 8 | 8 | | 603580 | bug 9 | 9 | | 605903 | bug 10 | 10 | | 608828 | feature request 1 | 271 | | 612342 | bug 11 | 11 | | 615535 | patch 5 | 199 | | 624566 | bug 12 | 12 | | 625268 | bug 13 | 13 | | 649476 | patch 6 | 200 | | 654222 | bug 14 | 14 | | 656324 | bug 15 | 15 | | 656337 | deleted | 16 | | 659407 | bug 16 | 17 | | 668545 | bug 17 | 18 | | 668578 | bug 18 | 19 | | 671914 | bug 19 | 20 | | 673260 | support request 1 | 191 | | 673958 | bug 20 | 21 | | 681857 | bug 21 | 22 | | 683637 | patch 7 | 201 | | 686105 | bug 22 | 23 | | 686170 | deleted | 24 | | 687588 | support request 2 | 192 | | 693263 | bug 23 | 25 | | 697594 | bug 24 | 26 | | 705506 | support request 3 | 193 | | 706652 | feature request 2 | 272 | | 709338 | bug 25 | 27 | | 709394 | bug 26 | 28 | | 722175 | patch 8 | 202 | | 724171 | bug 27 | 29 | | 730498 | deleted | 273 | | 735533 | bug 28 | 30 | | 744020 | bug 29 | 31 | | 747111 | bug 30 | 32 | | 766013 | bug 31 | 33 | | 769124 | bug 32 | 34 | | 776730 | bug 33 | 35 | | 781062 | patch 9 | 203 | +-+-+-+ | SF old# | SF new# | GH# | +-+-+-+ | 781115 | feature request 3 | 274 | | 793201 | bug 34 | 36 | | 803970 |patch 10 | 204 | | 814702 | bug 35 | 37 | | 836210 |patch 11 | 205 | | 846346 | deleted | 206 | | 860815 | bug 36 | 38 | | 908743 | bug 37 | 39 | | 918681 | bug 38 | 40 | | 933195 | bug 39 | 41 | | 940212 | bug 40 | 42 | | 941924 | bug 41 | 43 | | 964350 | bug 42 | 44 | | 995800 |patch 12 | 207 | | 1001240 | bug 43 | 45 | | 1008667 | bug 44 | 46 | | 1021526 | bug 45 | 47 | | 1037666 | bug 46 | 48 | | 1051449 | bug 47 | 49 | | 1055940 | bug 48 | 50 | | 1070082 |patch 13 | 208 | | 1085453 | bug 49 | 51 | | 1097494 | bug 50 | 52 | | 1112587 | bug 51 | 53 | | 1117206 |patch 14 | 209 | | 1143567 | bug 52 | 54 | | 1147627 | bug 53 | 55 | | 1159680 | bug 54 | 56 | | 1166268 | deleted | 210 | | 1173774 | bug 55 | 57 | | 1180220 | bug 56 | 58 | | 1185979 | bug 57 | 59 | | 1186270 | bug 58 | 60 | | 1212979 | bug 59 | 61 | | 1216043 | bug 60 | 62 | | 1217087 |patch 15 | 211 | | 1240474 | bug 61 | 63 | | 1257912 |
Re: [tcpdump-workers] tcpdump configure error with pcap_loop... no
23.12.2013, 21:48, "Evgheni Antropov" :
> Hello I have try to compile tcpdump-4.5.1.tar.gz with libpcap-1.5.2.tar.gz
> and receive following error:
>
> checking for pcap-config... /usr/local/bin/pcap-config
> checking for pcap_loop... no
> configure: error: Report this to tcpdump-workers@lists.tcpdump.org, and
> include the
> config.log file in your report. If you have downloaded libpcap from
> tcpdump.org, and built it yourself, please also include the config.log
> file from the libpcap source directory, the Makefile from the libpcap
> source directory, and the output of the make process for libpcap, as
> this could be a problem with the libpcap that was built, and we will
> not be able to determine why this is happening, and thus will not be
> able to fix it, without that information, as we have not been able to
> reproduce this problem ourselves.
List,
last week I ran into this issue once but could not reproduce afterwards. My
guess is this error is specific to non-straightforward builds of libpcap and/or
leftovers across multiple build attempts.
It happened once as follows (please note Sabotage uses musl instead of glibc
and libnetlink-tiny instead of libnetlink):
# (at a Linux host)
wget
http://ftp.barfooze.de/pub/sabotage/sabotage-0.9.14-i386-66f57ca1-core.img.xz
unxz sabotage-0.9.14-i386-66f57ca1-core.img.xz
VBoxManage convertfromraw sabotage-0.9.14-i386-66f57ca1-core.img
sabotage-0.9.14-i386-66f57ca1-core.vdi
VirtualBox & # add a new x86_64 VM using the .vdi disk image and powered it on
# (inside VM as root)
adduser tcpdump
passwd tcpdump
# (inside VM as tcpdump)
git clone git://github.com/the-tcpdump-group/libpcap.git
git clone git://github.com/the-tcpdump-group/tcpdump.git
Then I tried to compile libpcap without and with ("butch install autoconf" as
root) autoconf, without and with .devel, without and with the following hacks:
-
diff --git a/Makefile.in b/Makefile.in
index 31f3bdb..58f93d7 100644
--- a/Makefile.in
+++ b/Makefile.in
@@ -744,4 +744,4 @@ releasetar:
rm -rf $$name
depend:$(GENSRC) $(GENHDR) bpf_filter.c
- $(MKDEP) -c $(CC) -m $(DEPENDENCY_CFLAG) $(DEFS) $(INCLS) $(SRC)
+ $(MKDEP) -c $(CC) -m $(CFLAGS) $(DEPENDENCY_CFLAG) $(DEFS) $(INCLS)
$(SRC)
diff --git a/configure b/configure
index be87668..31a2dcc 100755
--- a/configure
+++ b/configure
@@ -5619,7 +5619,7 @@ if test "x$ac_cv_lib_nl_nl_socket_alloc" = xyes; then :
#
# Yes, we have libnl 2.x.
#
- LIBS="-lnl-genl -lnl $LIBS"
+ LIBS="-lnl $LIBS"
$as_echo "#define HAVE_LIBNL 1" >>confdefs.h
diff --git a/configure.in b/configure.in
index 2cae646..b53fb15 100644
--- a/configure.in
+++ b/configure.in
@@ -473,7 +473,7 @@ linux)
#
# Yes, we have libnl 2.x.
#
- LIBS="-lnl-genl -lnl $LIBS"
+ LIBS="-lnl $LIBS"
AC_DEFINE(HAVE_LIBNL,1,[if libnl exists])
AC_DEFINE(HAVE_LIBNL_2_x,1,[if libnl exists and
is version 2.x])
AC_DEFINE(HAVE_LIBNL_NLE,1,[libnl has
NLE_FAILURE])
-
The configure call evolved over time and became the following:
CFLAGS=`-I/usr/include/libnl-tiny` \
LDFLAGS=`pkg-config --libs-only-L libnl-tiny` \
LIBS=`pkg-config --libs-only-l libnl-tiny` \
./configure
Eventually libpcap built OK (may be on 10th attempt), I ran ./configure in
../tcpdump and observed the "Report this to tcpdump-workers@lists.tcpdump.org"
boilerplate. A few more "make clean all" passes in libpcap directory later I
checked again on the tcpdump side and the issue had vanished.
--
Denis Ovsienko
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
[tcpdump-workers] RCS/CVS keywords ($Id$, $Header$, $OpenBSD$ etc)
List, there are lines in the tcpdump source code that served a purpose with CVS and its keywords expansion feature but don't do any more with git. It is around 4 years since the CVS/git migration and perhaps it is the time to remove most of the markers. It seems to be OK to just remove the lines that essentially state "this file is a part of the tcpdump source tree and is original to it", for example: #ifndef lint static const char rcsid[] _U_ = "@(#) $Header: /tcpdump/master/tcpdump/print-ospf.c,v 1.66 2007-10-08 07:53:21 hannes Exp $ (LBL)"; #endif Please note that no such ID dates any later than end of 2008. That said, I see sense in preserving/converting the IDs that indicate the origin/relation of the source code, for example: /* $NetBSD: print-ah.c,v 1.4 1996/05/20 00:41:16 fvdl Exp $*/ Would anybody object on this change? -- Denis Ovsienko ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] RCS/CVS keywords ($Id$, $Header$, $OpenBSD$ etc)
02.01.2014, 02:41, "Michael Richardson" : > Denis Ovsienko wrote: > >> It seems to be OK to just remove the lines that essentially state "this >> file is a part of the tcpdump source tree and is original to it", for >> example: >> #ifndef lint static const char rcsid[] _U_ = "@(#) $Header: >> /tcpdump/master/tcpdump/print-ospf.c,v 1.66 2007-10-08 07:53:21 hannes >> Exp $ (LBL)"; #endif > > Remove them. Done. > Some things like: > >> /* $NetBSD: print-ah.c,v 1.4 1996/05/20 00:41:16 fvdl Exp $ */ > > could, yes, remain. Particularly in comments, rather than rcsid[]. Yet to do. > (I still miss $Id$, and the SCCS "what" command...) The command is available in GNU CSSC (which doesn't build on my Linux PC, but still). -- Denis Ovsienko ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] netmap support for libpcap now available
15.01.2014, 00:10, "Luigi Rizzo" : > since there were no takers i went ahead and did it. > > The repo at http://code.google.com/p/netmap/ has been > updated with a newer version of netmap, and the extra/ > directory contains a netmap backend for libpcap > https://code.google.com/p/netmap/source/browse/extra/libpcap-netmap.diff > > which works against a recent (Jan11) libpcap version from github Hi Luigi. Why not open a pull request to queue this change for a review and merge? -- Denis Ovsienko ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] how can i access tsval from tcp options?
15.02.2014, 18:44, "Daniel H. Bahr" : > Hello everyone, > > I'm in need of accessing the tsval value of the options field in the > tcp header... i've been checking the tcp.h and did not find anything > that helped me. > > Does any body know how to do it? Greetings. TCP options are a particular case of TLV class of encodings. This most likely implies that TCP options are opaque to libpcap. To access one or more TCP options it is necessary to have some code like that in tcpdump, print-tcp.c around line 500. -- Denis Ovsienko ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] buildbot failure in tcpdump+libpcap on Solaris-10-SPARC
14.03.2014, 09:33, "buildbot-no-re...@wireshark.org" : > The Buildbot has detected a new failure on builder Solaris-10-SPARC while > building tcpdump+libpcap. > Full details are available at: > http://buildbot.wireshark.org/tcpdump/builders/Solaris-10-SPARC/builds/17 This is due to my yesterday work. I have just committed a change that should fix the build. -- Denis Ovsienko ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] how to tell tcpdump only to capture packets that go throught iptables
19.03.2014, 06:18, "fsluck" : > how to tell tcpdump only to capture packets that go throught iptables iptables can send packets to NetFilter loggger (-j NFLOG --nflog-group 20) on which tcpdump can capture (-i nflog:20) > i want to calculate how many icmp packets are received after i setup several > iptables rules for icmp. Mere counting is possible even without tcpdump: each iptables rule has counters for bytes and packets (iptables -vnL INPUT). -- Denis Ovsienko ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] buildbot failure in tcpdump+libpcap on Solaris-10-SPARC
22.03.2014, 09:33, "buildbot-no-re...@wireshark.org" : > The Buildbot has detected a new failure on builder Solaris-10-SPARC while > building tcpdump+libpcap. > Full details are available at: > http://buildbot.wireshark.org/tcpdump/builders/Solaris-10-SPARC/builds/26 fatal: unable to connect to bpf.tcpdump.org: bpf.tcpdump.org[0: 132.213.238.6]: errno=Connection timed out bpf.tcpdump.org[1: 2001:4830:116e:2::6]: errno=Network is unreachable -- Denis Ovsienko ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] buildbot failure in tcpdump+libpcap on Ubuntu-12.04-x64
> http://buildbot.wireshark.org/tcpdump/builders/Ubuntu-12.04-x64/builds/706 This crept in because I tested yesterday's changes without libsmi. Now the issue should be gone. -- Denis Ovsienko ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] vlan handling
31.03.2014, 02:18, "Michael Richardson" :
> {For reasons I do not understand, yahoo.com doesn't even attempt to deliver
> email from Shoham to tcpdump.org. There is simply no connections in the
> logs of the spam filter system...}
>
> From Shoham:
>
> Haven't got the time to get to it. I intend to, soon.
>
> 2 questions (that are very related to each-other) to check that my work
> won't be for nothing:
>
> 1) How do you think we should document the new vlan-filter handling?
> The documentation today states:
> Note that the first vlan keyword encountered in expression changes
> the decoding offsets for the remainder of expression on
> the assumption that the packet is a VLAN packet. The vlan [vlan_id]
> expression may be used more than once, to filter on
> VLAN hierarchies. Each use of that expression increments the filter
> offsets by 4.
>
> After the pull, It'll be harder to explain why "vlan or ip and udp"
> works but "(vlan or ip) and udp" doesn't.
>
> How do you think it should be documented?
If the present behaviour was to change anyway that could be used for syntax
clarification. For example, instead of single "vlan" keyword that means
different things in different context the new syntax could be based on keywords
like below:
8021q: EtherType = 0x8100
vlanid N: EtherType = 0x8100 and VID = N in the outermost 32-bit tag
vlanid-2 M: EtherType = 0x8100 and there are at least two (Q-in-Q) 32-bit tags
and the 2nd (inner) VID = N
vlanid-3 K: EtherType = 0x8100 and there are at least three (Q-in-Q-in-Q)
32-bit tags and the 3rd (most inner) VID = K
If I got the problem wrong and/or there's a cleaner wolution, please illustrate
with examples.
Thank you.
--
Denis Ovsienko
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] tcpdump configure error with pcap_loop... no
30.12.2013, 18:08, "Denis Ovsienko" : > 23.12.2013, 21:48, "Evgheni Antropov" : > >> Hello I have try to compile tcpdump-4.5.1.tar.gz with libpcap-1.5.2.tar.gz >> and receive following error: >> >> checking for pcap-config... /usr/local/bin/pcap-config >> checking for pcap_loop... no >> configure: error: Report this to tcpdump-workers@lists.tcpdump.org, and >> include the >> config.log file in your report. If you have downloaded libpcap from >> tcpdump.org, and built it yourself, please also include the config.log >> file from the libpcap source directory, the Makefile from the libpcap >> source directory, and the output of the make process for libpcap, as >> this could be a problem with the libpcap that was built, and we will >> not be able to determine why this is happening, and thus will not be >> able to fix it, without that information, as we have not been able to >> reproduce this problem ourselves. > > List, > > last week I ran into this issue once but could not reproduce afterwards. My > guess is this error is specific to non-straightforward builds of libpcap > and/or leftovers across multiple build attempts. I don't know if that is related but a different way to trigger this failure on Solaris/SPARC is to compile libpcap in 64-bit mode and then to try compiling tcpdump in default 32-bit mode. The configure script will fail with the message and the log file will contain: configure:5774: checking for local pcap library configure:5983: result: ./../libpcap/libpcap.a configure:5987: checking for pcap-config configure:6005: found ./../libpcap/pcap-config configure:6017: result: ./../libpcap/pcap-config configure:6079: checking for pcap_loop configure:6079: gcc -o conftest -DINET6 -I/usr/inet6/include -g -O2 conftest.c ./../libpcap/libpcap.a -lsocket -lnsl -lsocket -lnsl -lsmi >&5 ld: warning: file ./../libpcap/libpcap.a(pcap.o): wrong ELF class: ELFCLASS64 Undefined first referenced symbol in file pcap_loop /var/tmp//cc63sAMt.o ld: fatal: symbol referencing errors. No output written to conftest collect2: error: ld returned 1 exit status -- Denis Ovsienko ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
[tcpdump-workers] uint_XX_t, u_int_XX_t and NFLOG test case
Greetings. After the recent u_intXX_t type elimination in tcpdump I did a test build on an OpenIndiana x86_64 VM (which identifies itself as SunOS 5.11) and suddenly it failed on the NFLOG test case. Interestingly, that test case not just used to fail on OpenCSW Solaris 10 build servers during automatic builds (linked from www.tcpdump.org), but on one of the servers it sometimes recovered on itself and then failed again. All that said, it never failed in a live shell on the same server. But now it did: Failed test: nflog-e 1,4d0 < version 0, resource ID 20, family IPv4 (2), length 180: 74.82.42.42.53 > 10.0.0.20.42585: 17265 1/0/0 A 93.184.216.119 (45) < version 0, resource ID 20, family IPv4 (2), length 192: 74.82.42.42.53 > 10.0.0.20.45190: 52954 1/0/0 2606:2800:220:6d:26bf:1447:1097:aa7 (57) < version 0, resource ID 20, family IPv4 (2), length 184: 74.82.42.42.53 > 10.0.0.20.44031: 8279 1/0/0 A 93.184.216.119 (49) < version 0, resource ID 20, family IPv4 (2), length 196: 74.82.42.42.53 > 10.0.0.20.48736: 2122 1/0/0 2606:2800:220:6d:26bf:1447:1097:aa7 (61) So, finally it had reproduced at hand and the reason for tcpdump not decoding DLT_NFLOG was that HAVE_PCAP_NFLOG_H was not defined at compile time and the following was in config.log: configure:7341: checking for pcap/nflog.h configure:7341: /usr/gcc/4.3/bin/gcc -c -DINET6 -I/usr/inet6/include -g -O2 -I./../libpcap conftest.c >&5 In file included from conftest.c:71: ./../libpcap/pcap/nflog.h:43: error: expected specifier-qualifier-list before 'u_int8_t' ./../libpcap/pcap/nflog.h:49: error: expected specifier-qualifier-list before 'u_int16_t' ./../libpcap/pcap/nflog.h:55: error: expected specifier-qualifier-list before 'u_int16_t' ./../libpcap/pcap/nflog.h:61: error: expected specifier-qualifier-list before 'u_int16_t' ./../libpcap/pcap/nflog.h:67: error: expected specifier-qualifier-list before 'u_int64_t' configure:7341: $? = 1 The checks for other libpcap headers also failed due to the same error: checking for pcap/bluetooth.h... no checking for pcap/nflog.h... no checking for pcap/usb.h... no Updating these headers to use uint_XX_t instead of u_intXX_t fixes respective detection and the NFLOG test case in particular but it seems tcpdump should tolerate the u_intXX_t types from libpcap for indefinitely longer time as there are many old libpcap installations around. Other opinions are welcome. -- Denis Ovsienko ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] tcpdump and libpcap releases, and future thoughts
>I would like to move all of the source for libnetdissect into a subdir, >and make it easier to build just that part, and finally introduce my >idea for a second main()/getopt() containing top-level program for tcpdump, >one which is not called tcpdump, but rather "pktdump". I don't fully understand the primary pro et contra of this change, but a positive side effect of this would be that the new subdir would make it easier to apply uniform updates specifically to printers' source code. Right now it is easy to miss a few .c/.h files when trying to do a uniform update. -- Denis Ovsienko ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] tcpdump and libpcap releases, and future thoughts
> How about:
> sudo pktcap - | pktdump -
Although architecturally cleaner and SMP-friendlier than now, to survive busy
everyday end-users this approach would greatly benefit from a single front-end
process that would launch the other binaries, connect them together and
properly distribute command-line options.
--
Denis Ovsienko
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] Broken links for two Bluetooth DLTs
> http://www.whiterocker.com/bt/LINKTYPE_BLUETOOTH_BREDR_BB.html
> http://www.whiterocker.com/bt/LINKTYPE_BLUETOOTH_LE_LL_WITH_PHDR.html
Those two files have backup copies in tcpdump-htdocs repository (not linked
from linktypes.html). I have just refreshed them from the original site.
--
Denis Ovsienko
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
[tcpdump-workers] v5 and v6 NetFlow captures needed
List, if anyone can contribute NetFlow v5 and/or v6 captures to fix a bug in tcpdump, could you make a comment in the following ticket? https://github.com/the-tcpdump-group/tcpdump/issues/18 Thank you. -- Denis Ovsienko ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] Official patches for CVE-2014-8767/CVE-2014-8768/CVE-2014-8769?
>I don't really want to put *all* my eggs on github. I agree that GitHub is a business and businesses are not always in a good shape and are not forever in the best case. Specifically, many projects have had a lesson from SourceForge "developments" in the recent few years. Besides that, where a project is hosted does not matter as much as if it has working backups (in this scope git provides a very convenient means to backup its own repositories). Hosting hardware and software just fail from time to time, whether the infrastructure is your own or sponsored by somebody else. So the problem is to let GitHub do its good things to tcpdump yet to protect from the bad ones. To me it seems that for the next few years the best balance between survivability and convenience would be in continuing to use both GitHub and bpf.tcpdump.org, but with one important change. The changes should normally be committed to GitHub instance only, as that's currently the environment that is most convenient for contributors of varying levels of experience. Then bpf.tcpdump.org would not experience auto-merging difficulties any more and with the two repositories being 100% identical the read-only choice between the two will become again purely theoretical and a matter of taste. A weekly backup of bpf.tcpdump.org on top of that will bring a complete peace of mind. Does that sound reasonable? -- Denis Ovsienko ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] bpf.tcpdump.org vs github
> c) there is some issue (please explain more) with bpf.tcpdump.org
> experiencing auto-merging difficulties.
When a repository exists in two copies and each copy has the same branch (i.e.
master) and some new commits go to that branch in one copy but not the other,
and also the other way around, the branches will look like this (this is how
GitHub and bpf.tcpdump.org look right now):
a-b-c-d-e-m-n-t
a-b-c-d-e-x-y-z
Then git-merge in any of the directions will not be fast-forward and will
require explicit merge commits and sometimes conflict resolution. That is
additional work for no gain. If instead the copies get converged first and then
new commits go to one copy only, the other copy will always enjoy fast-forward
pulls, making it possible to run git-pull every 15 minutes from crontab.
--
Denis Ovsienko
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] [libpcap] New DLT value Request - Wattstopper DLM (#401)
On Thu, 18 Dec 2014 06:46:10 +0200 Guy Harris wrote > > On Dec 17, 2014, at 12:04 PM, Steve Karg wrote: > > > For a few years I have been using DLT_USER0 147 (user defined) for > > capturing and saving a serial protocol used by Wattstopper Digital > > Lighting Management products (see website) and dissecting via Wireshark > > and Lua. I'm planning on adding this pcap file logging to a product, and > > would like to have a DLT defined for this usage. > > So do you have a detailed description of the protocol? Steve, if this time you are receiving this as a subscriber to the mailing list, could you describe the encoding in a way similar to one used for http://www.tcpdump.org/linktypes/ ? This is intended not to make things difficult for innovation, but to assist the people from future who might be trying to debug relevant code much later. Thank you. -- Denis Ovsienko ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
[tcpdump-workers] LINUX_SLL2
List, there is an idea to improve libpcap and tcpdump to enable the latter to print interface name (index) and direction of each packet: https://github.com/the-tcpdump-group/tcpdump/issues/296 https://github.com/the-tcpdump-group/libpcap/issues/127 It is pretty much clear how to do that: the only way would be through a new DLT, a proposal for which is made here: https://github.com/the-tcpdump-group/tcpdump-htdocs/pull/3 Let me ask for feedback on this change because the original author has issues posting to the mailing list. Paul, if you are receiving this as a list subscriber, please try to respond to the list. Thank you. -- Denis Ovsienko ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] LINUX_SLL2 - TEST REPLY
>On the cornercase offchance that the failure is caused by my MUA
>(claws-mail), here's a reply from mutt instead.
It made it to the list. Don't change anything until you have defended your
proposal.
--
Denis Ovsienko
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] RFC: DLT for "application TCP stream capture"
>Eventually, we'll be using this format to debug multi-path TCP, in which case >the IP addresses (and maybe even the IP4/IP6-ness of it) might change. Also there exists SCTP, which implements the concept of variable (0..65535) number of "streams" for each direction of an "association" between a pair of sockets (in TCP these two things are the same), so a stream_id field in the encoding (0 for TCP and UDP) could be handy for SCTP payload representation. -- Denis Ovsienko ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] Pending pull request #378
On Thu, 22 Jan 2015 03:17:35 + Stephen Donnelly wrote > Hi, I have had a pull request in the queue on github since August: > > https://github.com/the-tcpdump-group/libpcap/pull/378 > > This does include some ideally separate things, a bug fix, and some > improvements. Is there anything blocking this pull request? Is more > information required, or should I rebase and separate the items? Has > development moved to a different tree somewhere? > > I notice there quite a few open pull requests in general, are there blocking > issues with these, or insufficient resources to merge them? Hello Stephen. Guy Harris is the subject matter expert on such changes. I, for instance, don't clearly understand not only the solution, but the problem as well -- my own use case is just in a different area. Sometimes it helps to reorder the changes to make the most obvious and straightforward ones first. -- Denis Ovsienko ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
[tcpdump-workers] odd issue with Linux VLAN interface
List, some time ago I did troubleshooting on a Linux PC and that involved running tcpdump with the "not tcp" filter on a few network interfaces to put a number of background TCP connections out of scope (I was interested how other protocols' packets were making from one interface to the other). At some point I had realized that tcpdump was printing TCP packets _only_ and no other protocols (again, the filter was "not tcp"). Later I figured it out how to reproduce the problem but not the cause of it. The host has an Ethernet interface with only an IPv6 link-local address (eth0). On top of it there is a VLAN interface with VID 75 (eth0.75), IPv6 link-local address and IPv4 address 10.0.75.254/24. The difference is, when tcpdump runs with "-i eth0.75", it works as expected and displays ARP and, for instance, UDP from/to the network 10.0.75.0/24. When run with "-i eth0", it displays only TCP from/to network 10.0.75.0. This looks wrong in two ways as the tagged packets should not appear on the bearing interface in the first place and even if they appear there the filter should exclude them, but instead of this it excludes all the other packets. This is the latest build of tcpdump on kernel 3.13.0-44-generic #73-Ubuntu SMP. Not sure if I will get to find the reason myself, but if anybody sees this as a duplicate of or an additional input for one of the known bugs, please let me know. -- Denis Ovsienko ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] odd issue with Linux VLAN interface
> I.e., "tcpdump -i eth0 not tcp" prints *only* TCP packets? Yes, exactly. Just checked once again. > Just out of curiosity, what does "tcpdump -i eth0 -d not tcp" print? root@homepc:~# tcpdump -pni eth0 -d not tcp (000) ldh [12] (001) jeq #0x86dd jt 2jf 7 (002) ldb [20] (003) jeq #0x6 jt 10 jf 4 (004) jeq #0x2cjt 5jf 11 (005) ldb [54] (006) jeq #0x6 jt 10 jf 11 (007) jeq #0x800 jt 8jf 11 (008) ldb [23] (009) jeq #0x6 jt 10 jf 11 (010) ret #0 (011) ret #262144 -- Denis Ovsienko ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] odd issue with Linux VLAN interface
[...] > If IPv4 Protocol is TCP, go to 10, else go to 11 > > > (010) ret #0 > > Reject packet > > > (011) ret #262144 > > Accept packet > > So that *looks* OK. Thank you for the analysis! > > Could you run "tcpdump -i eth0 -xx not tcp" and see what the contents of the > TCP packets being accepted are? I have to correct myself: "tcpdump -pni eth0 not tcp" actually yields both TCP and everything else (ARP and UDP). It turns out that during all previous runs that "everything else" just didn't make it to the screen because of timing. Now it does, please see: root@homepc:~# tcpdump -pni eth0 -xx not tcp tcpdump: verbose output suppressed, use -v or -vv for full protocol decode listening on eth0, link-type EN10MB (Ethernet), capture size 262144 bytes 00:56:19.466860 IP 109.74.202.168.6633 > 10.0.75.2.56538: Flags [.], ack 2668283334, win 235, options [nop,nop,TS val 521910355 ecr 1688339], length 0 0x: d4ca 6d72 b1da 000f ea18 f623 8100 004b 0x0010: 0800 4500 0034 dd1d 4000 3406 dcb1 6d4a 0x0020: caa8 0a00 4b02 19e9 dcda 6f36 d02b 9f0a 0x0030: c5c6 8010 00eb b34a 0101 080a 1f1b 0x0040: b853 0019 c313 00:56:20.332325 ARP, Request who-has 10.0.75.3 tell 10.0.75.254, length 28 0x: d4ca 6d66 cf65 000f ea18 f623 8100 004b 0x0010: 0806 0001 0800 0604 0001 000f ea18 f623 0x0020: 0a00 4bfe 0a00 4b03 It looks like the filter just has no effect at all, as "tcpdump -pni eth0 not arp" also delivers a similar mix of packets including ARP. > And what does "tcpdump -v" print? Was it built with the latest libpcap? > This might be an issue with the kernel and libpcap not properly working > together to deal with VLAN tags - this commit: > > commit 04660eb1e56102e2369473cae2538e4d3d263607 > Author: Michal Sekletar > Date: Fri Oct 31 15:19:54 2014 +0100 > > Use BPF extensions in compiled filters > > libpcap will generate BPF filter code which uses BPF extensions if > target > platform supports them. Currently supported BPF extensions are > vlan_tci and > vlan_pr. > > Also to properly handle such filters when filtering in userspace > libpcap now > employs bpf_filter1. > > fixed some issues there. > It is today's master branch build of both: root@homepc:~# tcpdump --version tcpdump version 4.7.0-PRE-GIT_2015_01_28 libpcap version 1.7.0-PRE-GIT_2015_01_28 OpenSSL 1.0.1f 6 Jan 2014 This Ubuntu host has no BPF extensions: denis@homepc:~/libpcap$ fgrep -r SO_BPF_EXT /usr/include/ denis@homepc:~/libpcap$ If this is a new bug, I can file it if it helps. -- Denis Ovsienko ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] odd issue with Linux VLAN interface
On Wed, 28 Jan 2015 01:20:26 + Michael Richardson wrote > >Denis Ovsienko wrote: > > The host has an Ethernet interface with only an IPv6 link-local address > > (eth0). On top of it there is a VLAN interface with VID 75 (eth0.75), > > IPv6 link-local address and IPv4 address 10.0.75.254/24. The difference > > is, when tcpdump runs with "-i eth0.75", it works as expected and > > displays ARP and, for instance, UDP from/to the network > > 10.0.75.0/24. When run with "-i eth0", it displays only TCP from/to > > network 10.0.75.0. This looks wrong in two ways as the tagged packets > > should not appear on the bearing interface in the first place and even > > if they appear there the filter should exclude them, but instead of > > this it excludes all the other packets. > >Tagged packets do appear, and if you add -e, you'll see the entire tag there >too. At this point, it's hard to get the behaviour I think you want from >the pcap compiler, which is to filter the traffic within the VLAN from the >bearer. > >(I think that showing the tcp packets might be a fluke) You are right: root@homepc:~# tcpdump -pni eth0 -e not tcp 08:09:56.529239 00:0f:ea:18:f6:23 > d4:ca:6d:72:b1:da, ethertype 802.1Q (0x8100), length 58: vlan 75, p 0, ethertype IPv4, 109.74.202.168.6633 > 10.0.75.2.55847: Flags [R.], seq 0, ack 1992001615, win 0, length 0 Of course, "not ethertype ip and ip proto tcp" does not match and the right way to do this filtering on this interface is to filter by "vlan and not tcp" (just checked, works). Thus the behaviour is the same as it used to be for years, both on tcpdump side and on Linux side. It must be the odd timing that kept me thinking the BPF filter had somewhere flipped to do the opposite from its normal job, I had checked several times before posting. Thank you for help, Guy and Michael. -- Denis Ovsienko ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] LINUX_SLL2
On Sun, 15 Feb 2015 19:34:37 + Paul "LeoNerd" Evans wrote > On Tue, 13 Jan 2015 00:29:43 +0200 > Denis Ovsienko wrote: > > > List, > > > > there is an idea to improve libpcap and tcpdump to enable the latter > > to print interface name (index) and direction of each packet: > > > > https://github.com/the-tcpdump-group/tcpdump/issues/296 > > https://github.com/the-tcpdump-group/libpcap/issues/127 > > > > It is pretty much clear how to do that: the only way would be through > > a new DLT, a proposal for which is made here: > > https://github.com/the-tcpdump-group/tcpdump-htdocs/pull/3 > > > > Let me ask for feedback on this change because the original author > > has issues posting to the mailing list. > > So, uhm... > > Any thoughts on this so far? I'm really keen to have it applied, > because I already have a full implementation of a tcpdump-like program > that I wrote almost entirely *because* libpcap+tcpdump can't do this. > It would be great to have it supported by core after all. There are following differences of the proposed SLL2 from the existing SLL: 1. the Packet type field is 1 byte long (now as in struct sockaddr_ll) 2. same for the Link-layer address length field 3. there is a new Interface index field 4 bytes long (same as in sockaddr_ll) This makes SLL2 quite close to sockaddr_ll (except the the order of fields and the sll_family field, which is told to be equal to AF_PACKET in this case). In other words, it looks sufficiently good on paper to proceed with the implementation. -- Denis Ovsienko ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] buildbot failure in OpenCSW Buildbot on tcpdump-solaris10-sparcv9
On Sun, 22 Mar 2015 10:27:34 + wrote
>The Buildbot has detected a failed build on builder tcpdump-solaris10-sparcv9
>while building tcpdump.
It was my mistake, now it has been fixed.
--
Denis Ovsienko
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] how many stable branches to have
On Wed, 03 Jun 2015 19:12:03 +0100 Francois-Xavier Le Bail wrote > On 26/05/2015 15:33, Michal Sekletar wrote: > > On 05/26/2015 11:46 AM, Francois-Xavier Le Bail wrote: > >> I propose this: > >> We could give an "End of Life" date for each release branches. > >> This mean that after this date, the tcpdump group would not update any > >> more the branch. > > > > Having clearly defined EoL is a good idea. However I think that some > > releases should be picked and supported for longer periods of time. > > In the previous examples, I had given EoL dates allowing to have a > lifetime of support about two years. > > If it is not enough, a version, every two years approximately, could > have a superior lifetime, by example four years. > The first one of theses long-term versions could be the 1.7/4.7 ones. > > What do you think about it? To keep it working long-term it would help not to promise more commitment upfront than necessary. The terms above are more or less OK for a Linux distribution that has many users with many slow migration processes on one hand and the money/resources those users give back on the other. In such a situation it makes sense to engage, for instance, 20-50 engineers per each stable branch and let the show run. In the scope of tcpdump/libpcap it would be fair to spell a community contract of sorts that would state a baseline level like this: 1. The latest stable branch is always supported. 2. From time to time the developers find it right to start the next stable branch, which supersedes the old one after, for instance, 2 months or 2 releases. 3. Anybody who demands free support for an unsupported old stable branch (often to resell it for a price as "their" support, let me note) is welcome to spend their own time on the problem and to contribute the solution. This would be within the typical expectations from an Open Source software project and the developers would still be free to walk an extra mile when/if they want. -- Denis Ovsienko ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] buildbot failure in OpenCSW Buildbot on tcpdump-solaris10-i386
>BUILD FAILED: failed shell_2
This was expected, the next commit fixed it.
--
Denis Ovsienko
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] buildbot success in OpenCSW Buildbot on tcpdump-solaris10-i386
>Blamelist: Guy Harris
>
>Build succeeded!
Thank you for fixing this, my Internet link went down shortly after I started
to look into the failure report.
--
Denis Ovsienko
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] [pcap-ng-format] comments/edits on pcapng
[...] >So it sounds as if we can assign a number before the RFC is issued for a new >block type/link type/option code/etc., and update the registry when an I-D is >issued or updated or an RFC is issued. > >> But, it can also just be a link to http://www.company.com/technote/foo.html, >> or it can, as it says now, say, "Used by Company XYZ for Proprietary FOO" > >So presumably somebody who wants a link type would go to > >http://www.iana.org/form/protocol-assignment > >and request one. > >So does a Designated Expert for a registry get to edit whatever underlying >file or database is used to generate pages for the registry in question? I.e., >what would the Designated Expert do when adding a new block type/link >type/option/etc.? Is there a repository to which they're granted access and to >which they do a commit/push/whatever with the update? Is it a database for >which there's some Web interface to publish updates? > >Or does the Designated Expert send a request to somebody at the IANA, who >updates the file/database/whatever? > >I assume the actual underlying mechanism that implements the Protocol >Assignment registry pages is documented *somewhere*. "RFC Required" is just one possible policy and it is not expected to be the best policy for every case. RFC 5226 provides a good explanation of all the options (and is well worth its 20 pages of text overall), in its terms the practice currently established on tcpdump-workers@ is between "Expert Review" and "Specification Required" (the time available for review and requestor's motivation seeming to make the difference). Maybe it would make sense to declare "Expert Review" with a condition that requests without a specification are lowest priority? -- Denis Ovsienko ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] buildbot success in OpenCSW Buildbot on libpcap-solaris10-sparcv9
On Sat, 05 Dec 2015 19:52:04 + wrote
> The Buildbot has detected a restored build on builder
> libpcap-solaris10-sparcv9 while building libpcap.
Also back to normal on Linux and FreeBSD 10.
--
Denis Ovsienko
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] Disable address/name resolution in libpcap
On Wed, 13 Apr 2016 16:44:24 +0100 Ed Sealing wrote >We're writing an application around libpcap. The app may or may not have >DNS resolution available. We've noticed that when DNS resolution is not >available, we experience long delays when pre-testing the filters (prior to >applying them). > >Is there a way to programatically disable name resolution in libpcap >(similar to tcpdump "-n" argument)? I haven't been able to find a variable >to pass in that would accomplish this directly in the library. I'm sure it >exists, but can't seem to find it. "-n" is an option to tcpdump only, libpcap works the same way with and without it. The only case where DNS may be involved in libpcap is if the filter contains hostnames, which would need to be translated to addresses first to compile the filter. Could you post an example of the delay you are seeing? -- Denis Ovsienko ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] Disable address/name resolution in libpcap
[...] > Presumably, if pcap_compile_ex() or pcap_compile_nonameres() or whatever > were to disable name resolution, it would treat *all* host names as failing > to resolve, so > > host www.example.com > > would fail to compile. This means, of course, that the pre-test would > always fail unless you use IP addresses instead of host names. > > Wireshark's capture filter text box checks the syntax of the filter, showing > a red background if it doesn't compile and a green background if it does; it > runs the check in a separate thread and, until the thread completes doing > the name resolution, the background is yellow, meaning "I don't know yet > whether this is valid". Well, yes, but something else applies even without a separate function to avoid the timeout. As far as I understand in this case, if one really must use hostnames in the filter expression (for instance, if the A/ addresses change often or when there are multiple software instances and each of them gets a different response from the resolver), pre-testing without DNS is simply impossible. If it is more important to be able to pre-test without DNS, the filter must be changed to use no hostnames. -- Denis Ovsienko ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
[tcpdump-workers] posix_fadvise()
Hello list. As far as documentation goes, some sense may be presumed in libpcap calling posix_fadvise() with POSIX_FADV_SEQUENTIAL. This way the OS would be able to adjust the buffers better to read the .pcap file. Does anybody have any practical experience with posix_fadvise() to comment if the gain is ever visible with present day hardware and OSes? -- Denis Ovsienko ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] GUE (UDP encapsulation) pull request
On Wed, 29 Jun 2016 13:54:07 +0100 Wilmer van der Gaast wrote >I've just re-synced my pull request for adding GUE (UDP encapsulation) >dissection support to tcpdump: >https://github.com/the-tcpdump-group/tcpdump/pull/510 > >I've had no comments on it so far though (having submitted it in March). >What's the usual procedure of getting PRs merged? Hello Wilmer. You can speed it up a bit by squashing the changes in the pull request into a single pretty commit on top of the current master branch. I have also left a couple other comments in the pull request. Cheers! -- Denis Ovsienko ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] link-layer headers
On Fri, 24 Mar 2017 07:17:13 + Udit Chaudhary wrote > > Hello *, > > We were using text2pcap tool provided by Wireshark, the tool works fine with > following Headers. > > > LINKTYPE_MTP2140DLT_MTP2 > LINKTYPE_MTP3141DLT_MTP3 > LINKTYPE_SCCP142DLT_SCCP > > > Can you please help us to decode Hex Dump for LINKTYPE_M3UA i.e SIGTRAN. tcpdump can decode M3UA if that is what you mean. -- Denis Ovsienko ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
[tcpdump-workers] why tcpdump sometimes fails to link with libpcap
Hello list. Excuse me for making the same observation once again but I was compiling tcpdump recently and ran into this boilerplate once again: --- This is a bug, please follow the guidelines in CONTRIBUTING and include the config.log file in your report. If you have downloaded libpcap from tcpdump.org, and built it yourself, please also include the config.log file from the libpcap source directory, the Makefile from the libpcap source directory, and the output of the make process for libpcap, as this could be a problem with the libpcap that was built, and we will not be able to determine why this is happening, and thus will not be able to fix it, without that information, as we have not been able to reproduce this problem ourselves. --- This happens if tcpdump's ./configure has located libpcap headers and pcap-config but failed to link with libpcap from the location given by that pcap-config. This particular time the reason for this was I built libpcap with some compiler flags and then tried to build tcpdump with some other compiler flags and the linking failed because of that (cannot tell the exact combination of flags right now but I run into this from time to time building the same git working copies on the same Linux host). Also the other case where it definitely happened was a Linux distribution with musl libc and custom stripped-down version of libnetlink, there you had to supply a number of flags to libpcap configure to make it work and it was probably the lack of counterpart flags to tcpdump configure that made it fail the linking. It was quite a long time ago so I do not remember the details except doing a clean build with the right flags first in libpcap and then in tcpdump directory solved the issue. Another case of the same issue I vaguely remember was either on a Solaris host that tried to link into a libpcap repository on NFS (successfully compiled by a different Solaris host using a different compiler) or a FreeBSD host with CLang and GCC with libpcap working copy compiled with one compiler and tcpdump --- with the other. This way or another, from my point of view this seems to be caused by a user error, so would it be more helpful to say in the message something like this? "Using the libpcap prefix X and the flags suggested by "pcap-config --libs" (Y) it was not possible to link tcpdump to the libpcap library, which usually means libpcap has been compiled but in a way not compatible with the way this tcpdump build is done, for whatever reason. If you are trying to compile tcpdump against a source tree of libpcap, it usually helps to rebuild libpcap from scratch (./configure && make clean all) first and then to rebuild tcpdump from scratch (./configure && make clean all). Any configure command-line options and environment variables used in the libpcap build may have to be reproduced in the tcpdump build too. Use a good judgement and check config.log for more information. If everything fails, please file a detailed bug report along the guidelines made in the CONTRIBUTING file in the tcpdump source tree." -- Denis Ovsienko ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] Feature request - Support for EAP Dump in RADIUS Messages
On Fri, 15 Sep 2017 04:43:52 +0100 wrote >?Hi All, > >I have added support for EAP packet dumps in RADIUS Messages. Will be useful >for debugging 802.1x sessions with RADIUS. > >Pull Request - https://github.com/the-tcpdump-group/tcpdump/pull/579 > >Kindly review and let me know your views. Hello. Pull request #579 adds new C code that needs proofreading. I thought #608 would be simpler to process first but that is still in progress. -- Denis Ovsienko ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
[tcpdump-workers] record capture time period in the .pcap file
Hello list. It had recently crossed my mind that it would be useful to know when a packet capture started and when it finished. This is currently not the same as the timestamps of the first and the last packet in the file. For example, if you see a single DNS query in the file and you expect multiple queries, it helps to know that the capture actually lasted for the 3-hour period of time you are troubleshooting and not for random few seconds around that single packet, for whatever reason. Whilst it is not too late to consider this for pcapng format, in a traditional .pcap file the only reasonable way to record this information seems to be injecting two made-up packets at the beginning and the end, such that the timestamps of those packets encode the timeframe of the whole capture. Would zero-length packets be the best data units for that purpose, considering both old and new implementations? -- Denis Ovsienko ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
[tcpdump-workers] let's learn tcpdump
Hello list. Many people find man pages boring, Julia Evans has authored a more funny introduction to tcpdump and related tools here: https://jvns.ca/tcpdump-zine.pdf -- Denis Ovsienko ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] let's learn tcpdump
On Wed, 18 Oct 2017 02:59:29 +0100 Michael Richardson wrote >Denis Ovsienko wrote: > > Many people find man pages boring, Julia Evans has authored a more > > funny introduction to tcpdump and related tools here: > > https://jvns.ca/tcpdump-zine.pdf > >That's awesome... we need to link to it. >Maybe even put a link into the man page ;-) index.html now has it. -- Denis Ovsienko ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
[tcpdump-workers] tcpdump logo on GitHub
Hello list. Here is the apparently random image GitHub has assigned to the tcpdump group: https://avatars0.githubusercontent.com/u/4154908?s=200&v=4 Does it make any sense to anyone? Would the following image be better for GitHub purposes? http://www.tcpdump.org/tcpdump_100x100.png -- Denis Ovsienko ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] tcpdump logo on GitHub
>The attachment was probably deleted. Here is a link: > >https://framapic.org/Z2wN2FpnyNPg/QTrxHAaMFGwG.png Well, not bad. Looks OK scaled to 100 by 100 pixels (that's how it will appear on GitHub). -- Denis Ovsienko ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] tcpdump logo on GitHub
>https://framapic.org/Z2wN2FpnyNPg/QTrxHAaMFGwG.png
I have just uploaded it, thank you. Looks fine but you may want to make the
background transparent to make it even better.
--
Denis Ovsienko
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
[tcpdump-workers] about pcap_set_protocol()
Hello list. I have been looking at the man page for pcap_set_protocol() for some time. The man page explains the function is a Linux-specific extension. Would it be better to rename the function to something like pcap_set_linux_protocol() before it is too late? The function was added to the master branch in June 2017 (libpcap pull request #595) and it has not made it into a libpcap release yet. -- Denis Ovsienko ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] about pcap_set_protocol()
On Wed, 11 Jul 2018 06:14:41 +0100 Francois-Xavier Le Bail wrote > On 11/07/2018 04:15, Guy Harris wrote: > > On Jul 10, 2018, at 1:31 AM, Denis Ovsienko wrote: > > > >> I have been looking at the man page for pcap_set_protocol() for some > >> time. The man page explains the function is a Linux-specific extension. > >> Would it be better to rename the function to something like > >> pcap_set_linux_protocol() before it is too late? The function was added > >> to the master branch in June 2017 (libpcap pull request #595) and it has > >> not made it into a libpcap release yet. > > > > Or pcap_linux_set_protocol()/pcap_set_protocol_linux(); perhaps in cases > > where we add platform-specific functions, put the platform name after > > pcap_ or at the end of the name, to have a general pattern (it's too late > > for some of the Windows-specific ones, but many of them are either > > obsolete with generic replacements, Windows-specific because of inherent > > UN*X vs. Windows differences so it's somewhat implied, or no longer > > supported). > > I'd rather pcap_set_protocol_linux(), because we already have functions like > pcap_activate_linux(), pcap_can_set_rfmon_linux(), pcap_cleanup_linux(), > pcap_inject_linux(), > pcap_read_linux(), pcap_set_datalink_linux(), pcap_setdirection_linux(), > pcap_setfilter_linux(), > pcap_stats_linux(). Alright, commit 697b1f7 does that. -- Denis Ovsienko ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] LINKTYPE_LINUX_SLL2 implementation (libpcap & tcpdump)
> [1] https://www.tcpdump.org/linktypes/LINKTYPE_LINUX_SLL2.html > [2] https://www.tcpdump.org/linktypes/LINKTYPE_LINUX_SLL.html > [3] https://github.com/the-tcpdump-group/libpcap/issues/127 JFYI, I remember the beginning of this story from January 2015 well. Paul Evans suggested the original idea and he was going to implement it in code. I did not understand why he specified SLL2 so clearly but didn't implement it, so about a year ago I made an attempt to get some running code along those lines, and I was _not_ successful at that. SLL2 may be one of those problems that are easy to state but difficult to solve, so I would suggest to focus on a working prototype first, then the required props around it can be added as necessary. So far it is a well documented solution that does not exist. -- Denis Ovsienko ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] LINKTYPE_LINUX_SLL2 implementation (libpcap & tcpdump)
On Wed, 11 Jul 2018 19:41:06 +0100 Guy Harris wrote > Currently > > https://www.tcpdump.org/linktypes/LINKTYPE_LINUX_SLL2.html > > has a 2-octet field followed immediately by a 4-octet field. > > This means the 4-octet field isn't aligned on a 4-octet boundary; I'm going > to update the LINKTYPE_LINUX_SLL2 specification to put a 2-byte reserved > field after it. Could the 4-octet field (ifindex) be at the beginning? -- Denis Ovsienko ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] [RFC LIBPCAP PATCH 0/1] LINKTYPE_LINUX_SLL2 implementation
On Thu, 12 Jul 2018 19:53:57 +0100 Guy Harris wrote > On Jul 12, 2018, at 11:02 AM, Petr Vorel wrote: > > > Unfortunately I haven't found a way how to coexist in runtime library > > both LINKTYPE_LINUX_SLL and LINKTYPE_LINUX_SLL2, > > See libpcap commit 8cff296dc7c321c76933359d586dbde5b580ce8c, which adds > DLT_LINUX_SLL2/LINKTYPE_LINUX_SLL2 support. > > Both DLT_LINUX_SLL and DLT_LINUX_SLL2 are supported if the PACKET_RESERVE > socket option is supported, with DLT_LINUX_SLL being, for now, the default. > I have just checked in a tcpdump change, > 51c1da63e40e046b6b4620edb1ac1ba8b2707182, to support DLT_LINUX_SLL2, > although it currently makes no use of the interface index. Once Wireshark > support for DLT_LINUX_SLL2 is also added, perhaps that's the time to make it > the default, although choosing DLT_LINUX_SLL2 may make other programs that > support DLT_LINUX_SLL but not DLT_LINUX_SLL2 unable to read captures. Awesome. As one of the end users, I've been wanting to _just_ _see_ the interface name for years. Of course it is possible to work around with multiple capture sessions, whether parallel or consecutive. But far from convenient. As one of the maintainers, having looked through the commits I am convinced I would not be able to do this anytime soon. -- Denis Ovsienko ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] [RFC TCPDUMP PATCH 2/2] Add sll_ifindex into sll_header + use it to print ifname
On Thu, 12 Jul 2018 20:38:08 +0100 Guy Harris wrote
> On Jul 12, 2018, at 11:33 AM, Petr Vorel wrote:
>
> > +#ifdef PCAP_SUPPORT_SLL_V2
> > +char ifname[IF_NAMESIZE];
> > +if (if_indextoname(EXTRACT_BE_U_6(sllp->sll_ifindex), ifname))
> > +ND_PRINT("IFNAME %s ", ifname);
> > +#endif
>
> What happens if you capture traffic on machine A and print it on machine B,
> where machines A and B have different sets of network interfaces?
>
> (This is why pcapng has Interface Description Blocks - so that the list of
> interfaces is part of the file, so you use *that*, rather than the
> configuration of interfaces on the machine running the program reading the
> capture, to get interface names.)
What if the MBZ field of SLL2 encoding was first, and its values meant the
following:
* 0x: the rest of the packet structure is a packet (like it is now)
* 0x0001: interface X exists, has name Y and is up (down) and is (is not) in
promiscuous mode
* 0x0002: interface X no longer exists
Then in future it will be possible to interleave packet events with interface
events. At the start of the capture it will be possible to have a sequence of
interface declarations before any packets, and later on it will be possible to
encode the interface name changes in the middle of the packet events. Then it
will be possible to record the sequence of the events and interface names more
or less accurately (less the synchronization between the capture buffer and the
netlink socket), and to replay later.
I am not saying it should be implemented anytime soon, just making the point it
is easy to make the space for this future extension in the SLL2 encoding right
now.
> Perhaps this should be done *only* for live captures, *not* for reading
> savefiles.
--
Denis Ovsienko
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
[tcpdump-workers] fixing -Wformat-truncation
Hello list. I have just committed a small change to squelch a couple warnings generated by -Wformat-truncation in libpcap, here is a good technical article that was useful in understanding the problem in the first place, if anybody is interested: https://dzone.com/articles/detecting-string-truncation-with-gcc-8 -- Denis Ovsienko ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] About LINKTYPE_LINUX_SLL / LINKTYPE_LINUX_SLL2
On Fri, 13 Jul 2018 18:00:03 +0100 Francois-Xavier Le Bail wrote > Hello, > > In http://www.tcpdump.org/linktypes/LINKTYPE_LINUX_SLL.html and > http://www.tcpdump.org/linktypes/LINKTYPE_LINUX_SLL2.html, there is: > > "If there are more than 8 bytes, only the first 8 bytes are present, and if > there are fewer than 8 > bytes, there are padding bytes after the address to pad the field to 8 > bytes." > > Does anyone know why the 8 bytes limit ? My guess is it is because of the 16 byte default limit on the header length, as Guy mentioned a couple days ago. > Should we add that the padding is done with '\0' bytes ? As far as encodings typically go, if the padding bytes are always discarded, it does not make difference. But it will not hurt to say the customary "MBZ". -- Denis Ovsienko ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] [RFC TCPDUMP PATCH 2/2] Add sll_ifindex into sll_header + use it to print ifname
On Fri, 13 Jul 2018 08:40:47 +0100 Denis Ovsienko
wrote
> On Thu, 12 Jul 2018 20:38:08 +0100 Guy Harris
> wrote
> > On Jul 12, 2018, at 11:33 AM, Petr Vorel wrote:
> >
> > > +#ifdef PCAP_SUPPORT_SLL_V2
> > > +char ifname[IF_NAMESIZE];
> > > +if (if_indextoname(EXTRACT_BE_U_6(sllp->sll_ifindex), ifname))
> > > +ND_PRINT("IFNAME %s ", ifname);
> > > +#endif
> >
> > What happens if you capture traffic on machine A and print it on machine
> B, where machines A and B have different sets of network interfaces?
> >
> > (This is why pcapng has Interface Description Blocks - so that the list
> of interfaces is part of the file, so you use *that*, rather than the
> configuration of interfaces on the machine running the program reading the
> capture, to get interface names.)
>
> What if the MBZ field of SLL2 encoding was first, and its values meant the
> following:
>
> * 0x: the rest of the packet structure is a packet (like it is now)
> * 0x0001: interface X exists, has name Y and is up (down) and is (is not) in
> promiscuous mode
> * 0x0002: interface X no longer exists
>
> Then in future it will be possible to interleave packet events with
> interface events. At the start of the capture it will be possible to have a
> sequence of interface declarations before any packets, and later on it will
> be possible to encode the interface name changes in the middle of the packet
> events. Then it will be possible to record the sequence of the events and
> interface names more or less accurately (less the synchronization between
> the capture buffer and the netlink socket), and to replay later.
>
> I am not saying it should be implemented anytime soon, just making the point
> it is easy to make the space for this future extension in the SLL2 encoding
> right now.
In addition to the above:
* 0x0003: start of capture mark (possibly with an ASCII copy of the filter
expression)
* 0x0004: end of capture mark
...or simply:
* 0x0003: timestamp mark
(as proposed a few months ago, such that it is possible to tell what exact time
span a .pcap file covers, not just what the timestamps of the first and the
last packets are)
--
Denis Ovsienko
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] [tcpdump-security] [libpcap] Problem with version 1.9.0
On Mon, 23 Jul 2018 21:33:00 +0100 Dagobert Michelsen
wrote
> Hi Jan,
>
> Am 23.07.2018 um 22:04 schrieb Jan Stary :
> >
> > From both a sysadmin and user perspective, I find the GNU autotools
> > amd CMake a major annoyance. Would you please consider doing what e.g.
> > http://mandoc.bsd.lv/cgi-bin/cvsweb/configure does?
> >
> > A simple, hand written shell script, with a set of obvious
> > {test,compat}-*.c helpers. No dependency on anything, orders
> > of multitude smaller and faster then a auto*-generated configure.
>
> No - please! Handwritten configure scripts are the worst nightmare for
> downstream packages as each package uses its own way to configure flags
> for compilation, linkage, install relocation etc. This makes
> packaging stuff hard as it requires specific adjustments of build
> procedures. I maintain roughly 1600 packages and this would not be
> possible when there were no standards. Autotools is far from perfect,
> but it is a standard and after you figured something out it works for
> hundreds of builds in the same way.
You had this exact discussion 2 weeks ago, didn't you? For the avoidance of
doubt, this thread isn't about voting.
Autotools has historically been the build solution because tcpdump originates
from the UNIX world, and used to compile and work on much more flavors than a
typical modern software. AIX, HP-UX and Solaris are still around and configure
works there.
Guy has [relatively] recently added cmake as an alternative build solution
because, as far as I understand, it also supports Windows in a way that is
simpler to maintain than autotools. I do not build any software on Windows and
I do not use cmake to build any software, so this is my interpretation, feel
free to correct.
Perhaps if someone had written down, in plain English, which specific steps it
takes to compile tcpdump/libpcap, it would be easier to see if it can be done
with a simple shell script.
--
Denis Ovsienko
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
[tcpdump-workers] PCAP_ERROR/PCAP_ERROR_BREAK or -1/-2?
Hello list. Roughly a half of the libpcap man pages text uses the values -1 and -2 to discuss the return value of particular libpcap functions, the other half uses PCAP_ERROR and PCAP_ERROR_BREAK. Is there a good reason to keep it this way instead of using PCAP_ERROR/PCAP_ERROR_BREAK consistently in all man pages? -- Denis Ovsienko ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] PCAP_ERROR/PCAP_ERROR_BREAK or -1/-2?
On Wed, 25 Jul 2018 09:11:23 +0100 Guy Harris wrote > On Jul 25, 2018, at 12:57 AM, Denis Ovsienko wrote: > > > Roughly a half of the libpcap man pages text uses the values -1 and -2 to > > discuss the return value of particular libpcap functions, the other half > > uses PCAP_ERROR and PCAP_ERROR_BREAK. > > > > Is there a good reason to keep it this way instead of using > > PCAP_ERROR/PCAP_ERROR_BREAK consistently in all man pages? > > About the only reason for *code* not to use PCAP_ERROR and PCAP_ERROR_BREAK > would be if it has to compile with versions of libpcap prior to 1.0. > > The only reason not to use PCAP_ERROR and PCAP_ERROR_BREAK in man pages for > APIs existing in pre-1.0 releases would be to discourage people from writing > code that wouldn't compile with pre-1.0 releases. > > However, they could *also* just do > > #ifndef PCAP_ERROR > #define PCAP_ERROR-1 > #endif > #ifndef PCAP_ERROR_BREAK > #define PCAP_ERROR_BREAK-2 > #endif > > in the files that use them with those APIs, or in a header file included by > those files, so I'm not sure that's a strong enough reason not to just use > them uniformly. > > And if they're making calls to APIs *not* present in pre-1.0 releases, their > code won't compile with a pre-1.0 release anyway, so Thank you for explaining, Guy. Now I see it as follows. If someone is writing a program for an old libpcap version, they should use the man pages that come with that old version, which say -1 and -2, so that's what they should put in the source code, so they do not even need the #define workaround. If someone is compiling such an old program with new libpcap, the constants remain the same, so the only issue will be the code style. If someone is writing a program for a new libpcap version, the #define comes with the library. So it looks like there is no good reason to keep using -1 and -2 in the current man pages. -- Denis Ovsienko ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
[tcpdump-workers] if anyone wanted to practice fixing compiler warnings in tcpdump...
Building (configure+gcc) tcpdump master branch with libpcap 0.6.1 yields the
following compiler warnings, some of which are as easy as decorating a variable
declaration with #ifdef:
./tcpdump.c: In function ‘open_interface’:
./tcpdump.c:1382:22: warning: passing argument 1 of ‘pcap_open_live’ discards
‘const’ qualifier from pointer target type [-Wdiscarded-qualifiers]
pc = pcap_open_live(device, ndo->ndo_snaplen, !pflag, 1000, ebuf);
^~
In file included from ./tcpdump.c:97:0:
../libpcap/pcap.h:136:9: note: expected ‘char *’ but argument is of type ‘const
char *’
pcap_t *pcap_open_live(char *, int, int, int, char *);
^~
./tcpdump.c: At top level:
./tcpdump.c:221:22: warning: ‘show_tstamp_types_and_exit’ declared ‘static’ but
never defined [-Wunused-function]
static NORETURN void show_tstamp_types_and_exit(pcap_t *, const char *device);
^~
./tcpdump.c:195:12: warning: ‘Uflag’ defined but not used [-Wunused-variable]
static int Uflag; /* "unbuffered" output of dump files */
^
./tcpdump.c:190:12: warning: ‘jflag’ defined but not used [-Wunused-variable]
static int jflag = -1; /* packet time stamp source */
^
./tcpdump.c:155:12: warning: ‘Bflag’ defined but not used [-Wunused-variable]
static int Bflag; /* buffer size */
^
./print.c: In function ‘get_if_printer’:
./print.c:304:13: warning: implicit declaration of function
‘pcap_datalink_val_to_name’; did you mean ‘pcap_datalink’?
[-Wimplicit-function-declaration]
dltname = pcap_datalink_val_to_name(type);
^
pcap_datalink
./print.c:304:11: warning: assignment makes pointer from integer without a cast
[-Wint-conversion]
dltname = pcap_datalink_val_to_name(type);
^
./print-juniper.c: In function ‘juniper_parse_header’:
./print-juniper.c:1203:14: warning: unused variable ‘control_word’
[-Wunused-variable]
uint32_t control_word;
^~~~
At top level:
./print-juniper.c:1197:1: warning: ‘juniper_parse_header’ defined but not used
[-Wunused-function]
juniper_parse_header(netdissect_options *ndo,
^~~~
./print-juniper.c:1079:1: warning: ‘juniper_ppp_heuristic_guess’ defined but
not used [-Wunused-function]
juniper_ppp_heuristic_guess(netdissect_options *ndo,
^~~
./print-juniper.c:441:25: warning: ‘juniper_protocol_values’ defined but not
used [-Wunused-const-variable=]
static const struct tok juniper_protocol_values[] = {
^~~
./print-juniper.c:67:25: warning: ‘juniper_ipsec_type_values’ defined but not
used [-Wunused-const-variable=]
static const struct tok juniper_ipsec_type_values[] = {
^
./util-print.c: In function ‘ts_format.isra.0’:
./util-print.c:265:27: warning: ‘%06u’ directive output may be truncated
writing between 6 and 10 bytes into a region of size between 5 and 12
[-Wformat-truncation=]
format = "%02d:%02d:%02d.%06u";
^~~~
./util-print.c:265:11: note: using the range [0, 4294967295] for directive
argument
format = "%02d:%02d:%02d.%06u";
^
In file included from /usr/include/stdio.h:862:0,
from ./util-print.c:50:
/usr/include/x86_64-linux-gnu/bits/stdio2.h:64:10: note:
‘__builtin___snprintf_chk’ output between 16 and 27 bytes into a destination of
size 21
return __builtin___snprintf_chk (__s, __n, __USE_FORTIFY_LEVEL - 1,
^~~~
__bos (__s), __fmt, __va_arg_pack ());
~~~~~
--
Denis Ovsienko
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
[tcpdump-workers] Fwd: about bits and frequencies
Let's see if my message makes it through the filters this time... Forwarded message From : Denis Ovsienko To : "tcpdump-workers" Date : Tue, 24 Jul 2018 14:07:58 +0100 Subject : about bits and frequencies Forwarded message > Hello list. > > I cannot recall the exact discussion, but I vaguely remember a couple years > ago somebody (Guy Harris?) writing something like: > > - In this encoding this field tells, in units of x kHz, the frequency of the > wireless channel, this is the maximum frequency (20GHz???) it can represent > given this amount of bits, is it enough or should it be bigger? > > ...and I answered something like: > > - Off-the-shelf WiFi runs on 5GHz, satellite downlinks are 10-20 GHz and I > read about people experimenting in the bands up to 100GHz, so it would be > future-proof to have more bits in that field. > > Recently I have seen $100 wireless access points in the 60GHz band, so some > of those additional bits already can be put to a good use. > > -- > Denis Ovsienko > > -- Denis Ovsienko ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] if anyone wanted to practice fixing compiler warnings in tcpdump...
On Mon, 30 Jul 2018 02:08:51 +0100 Guy Harris wrote > On Jul 29, 2018, at 5:48 AM, Denis Ovsienko wrote: > > > Building (configure+gcc) tcpdump master branch with libpcap 0.6.1 yields > > the following compiler warnings, some of which are as easy as decorating a > > variable declaration with #ifdef: > > > > ./tcpdump.c: In function ‘open_interface’: > > ./tcpdump.c:1382:22: warning: passing argument 1 of ‘pcap_open_live’ > > discards ‘const’ qualifier from pointer target type > > [-Wdiscarded-qualifiers] > > pc = pcap_open_live(device, ndo->ndo_snaplen, !pflag, 1000, ebuf); > > ^~ > > In file included from ./tcpdump.c:97:0: > > ../libpcap/pcap.h:136:9: note: expected ‘char *’ but argument is of type > > ‘const char *’ > > pcap_t *pcap_open_live(char *, int, int, int, char *); > > ^~ > > Libpcap *should* have had it as const since the beginning, but const was new > back when libpcap was introduced; we later added const to a bunch of > argument declarations. > > In this particular case, we could make the argument to open_interface() a > "char *" rather than a "const char *" - it's just a routine internal to > tcpdump, so it's not as if we're claiming "hey, we might modify this" to > code using it. Well, that, and a comment, looks a little better than a compiler warning. Thank you for fixing the other warnings. Though I initially hoped some bored hacker would pick the easy warnings first, then do more difficult ones and eventually warm up to the point where they would close a few bugs on the issue tracker. My imagination was too powerful this time... -- Denis Ovsienko ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] [RFC TCPDUMP PATCH 2/2] Add sll_ifindex into sll_header + use it to print ifname
On Fri, 13 Jul 2018 08:40:47 +0100 Denis Ovsienko
wrote
> On Thu, 12 Jul 2018 20:38:08 +0100 Guy Harris
> wrote
> > On Jul 12, 2018, at 11:33 AM, Petr Vorel wrote:
> >
> > > +#ifdef PCAP_SUPPORT_SLL_V2
> > > +char ifname[IF_NAMESIZE];
> > > +if (if_indextoname(EXTRACT_BE_U_6(sllp->sll_ifindex), ifname))
> > > +ND_PRINT("IFNAME %s ", ifname);
> > > +#endif
> >
> > What happens if you capture traffic on machine A and print it on machine
> B, where machines A and B have different sets of network interfaces?
> >
> > (This is why pcapng has Interface Description Blocks - so that the list
> of interfaces is part of the file, so you use *that*, rather than the
> configuration of interfaces on the machine running the program reading the
> capture, to get interface names.)
>
> What if the MBZ field of SLL2 encoding was first, and its values meant the
> following:
>
> * 0x: the rest of the packet structure is a packet (like it is now)
> * 0x0001: interface X exists, has name Y and is up (down) and is (is not) in
> promiscuous mode
> * 0x0002: interface X no longer exists
>
> Then in future it will be possible to interleave packet events with
> interface events. At the start of the capture it will be possible to have a
> sequence of interface declarations before any packets, and later on it will
> be possible to encode the interface name changes in the middle of the packet
> events. Then it will be possible to record the sequence of the events and
> interface names more or less accurately (less the synchronization between
> the capture buffer and the netlink socket), and to replay later.
>
It would be right to attribute the idea of events interleaving properly: the
suggestion above is very close to or the same as what Paul Evans suggested
before me on 11 April 2018 in
https://github.com/the-tcpdump-group/tcpdump/issues/296
It could have been made even before that elsewhere, but I do not have exact
information at this time.
--
Denis Ovsienko
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] [the-tcpdump-group/tcpdump] Added RADIUS attributes from RFC 5447 (#636)
On Thu, 02 Aug 2018 15:06:50 +0100 Herwin
wrote
> @herwinw commented on this pull request.
>
> In print-radius.c:
> > @@ -569,6 +597,8 @@ static struct attrtype { { "Digest-HA1",
> NULL, 0, 0, print_attr_string }, { "SIP-AOR",
>NULL, 0, 0, print_attr_string }, { "Delegated-IPv6-Prefix",
> NULL, 0, 0, print_attr_netmask6 },+ { "MIP6-Feature-Vector",
> NULL, 0, 0, print_attr_vector64 },+ { "MIP6-Home-Link-Prefix",
> NULL, 0, 0, print_attr_netmask6 }, fun fact: freeradius and
> wireshark both use the same format as Framed-IPv6-Prefix and
> Delegated-IPv6-Prefix for this structure. This might require some "be
> liberal in what you accept" to make it work.
The IANA RADIUS Types registry currently lists 6 types with the "ipv6prefix"
type:
```
170 Route-IPv6-Information [RFC6911]
152 PMIP6-Visited-HN-Prefix [RFC6572]
151 PMIP6-Home-HN-Prefix [RFC6572]
125 MIP6-Home-Link-Prefix [RFC5447]
123 Delegated-IPv6-Prefix [RFC4818]
97 Framed-IPv6-Prefix [RFC3162]
```
The type 125 (MIP6-Home-Link-Prefix) is the only one that has the encoding
clearly different from the rest. This is how RFC 5447 defines it, and the
current list of errata for this RFC does not concern this difference, which
looks intentional as Section 4.2.4 of the spec says: "The MIP6-Home-Link-Prefix
AVP (AVP Code 125) is of type OctetString" and the IANA Considerations section
does not mention the type explicitly.
It looks like the allocation in the IANA registry was done incorrectly for type
125, perhaps because the attribute has "prefix" in its name. Then, if the
authors of respective Wireshark and FreeRADIUS code took the attribute type
from the registry and did not check it thoroughly in RFC 5447, that would
explain why that code (incorrectly) handles MIP6-Home-Link-Prefix as an IPv6
prefix attribute (whereas it is OctetString) -- it just copies the error in the
registry allocation.
I do not see a good way to accept both encodings for this attribute, given the
way each encoding is defined. Are you aware of any other code that has copied
this error, especially in the network devices firmware?
--
Denis Ovsienko
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] Should the tcpdump tests be run with TZ=GMT0, or should the AFS printer print time stamps in UTC?
On Sat, 04 Aug 2018 08:41:10 +0100 Francois-Xavier Le Bail wrote > On 04/08/2018 09:03, Guy Harris wrote: > > On Aug 3, 2018, at 6:44 PM, Michael Richardson wrote: > > > >> Guy Harris wrote: > >>> Currently, the tcpdump tests for AFS fail if you're not in the time > >>> zone where the .out files were generated, because AFS time stamps are > >>> printed as local time rather than as UTC. > >> > >> That's broken > > Why broken ? it's just local time. The problem is to make the printed value unambiguous (i.e. for any valid binary value VP1 from the packet there is exactly one printed string value VS, and VS can be parsed into exactly one binary value VP2, and VP1 == VP2). If the VS value uses local clock time, the format should tell the timezone, such that the output of tcpdump made in one time zone can be correctly understood by the user in another (less human errors). One problem with setting TZ before running is that tcpdump output does not tell what timezone it uses, and even if it does, some users will get different output for the same input by default. Another is that the test will require a custom script because at the moment the tests in TESTLIST either all use a custom TZ, or none of them (as it is now). That said, if the output uses UTC, it could be helpful to use an unambiguous format as well, as in commit 99412d6. > > So we should just change it to use gmtime() rather than localtime(). > > I think an user prefer have the local time. -- Denis Ovsienko ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
