Re: [tcpdump-workers] [tcpdump] 7 tests fail on Ubuntu 11.10 (#33)
05.10.2012, 23:07, Michael Richardson m...@sandelman.ca: Marc == Marc Abramowitz notificati...@github.com 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 fx.leb...@yahoo.com: 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
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] 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 m...@sandelman.ca: Gisle == Gisle Vanem gva...@broadpark.no 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 infrastat...@yandex.ru: 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 ola.lyk...@q-free.com: 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] [Patch] print-nfs.c
10.07.2013, 15:18, Gisle Vanem gva...@broadpark.no: 'int32_t' isn't 'int' for all targets. Some Windows targets have it defined as 'signed int' in win32/Include/bittypes.h. 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 gva...@broadpark.no: Denis Ovsienko infrastat...@yandex.ru wrote: 10.07.2013, 15:18, Gisle Vanem gva...@broadpark.no: 'int32_t' isn't 'int' for all targets. Some Windows targets have it defined as 'signed int' in win32/Include/bittypes.h. 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 al...@deployingradius.com: [...] 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 m...@sandelman.ca: 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
[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
| | 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 infrastat...@yandex.ru: 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 | bug 62 | 64 | | 1339980 | bug 63 | 65 | | 1450506 | bug 64
Re: [tcpdump-workers] tcpdump configure error with pcap_loop... no
23.12.2013, 21:48, Evgheni Antropov aid...@gmail.com: 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 m...@sandelman.ca: Denis Ovsienko infrastat...@yandex.ru 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 ri...@iet.unipi.it: 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 dhb...@gmail.com: 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 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 linuxl...@163.com: 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 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] tcpdump configure error with pcap_loop... no
30.12.2013, 18:08, Denis Ovsienko infrastat...@yandex.ru: 23.12.2013, 21:48, Evgheni Antropov aid...@gmail.com: 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] 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] 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 msekl...@redhat.com 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
[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
On Wed, 28 Jan 2015 01:20:26 + Michael Richardson wrote Denis Ovsienko de...@ovsienko.info 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] Pending pull request #378
On Thu, 22 Jan 2015 03:17:35 + Stephen Donnellystephen.donne...@emulex.com 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] 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] [libpcap] New DLT value Request - Wattstopper DLM (#401)
On Thu, 18 Dec 2014 06:46:10 +0200 Guy Harrisg...@alum.mit.edu wrote On Dec 17, 2014, at 12:04 PM, Steve Karg notificati...@github.com 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
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] LINUX_SLL2
On Sun, 15 Feb 2015 19:34:37 + Paul LeoNerd Evansleon...@leonerd.org.uk wrote On Tue, 13 Jan 2015 00:29:43 +0200 Denis Ovsienko de...@ovsienko.info 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] how many stable branches to have
On Wed, 03 Jun 2015 19:12:03 +0100 Francois-Xavier Le Baildevel.fx.leb...@orange.fr 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 success in OpenCSW Buildbot on tcpdump-solaris10-i386
>Blamelist: Guy Harris <g...@alum.mit.edu>
>
>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] 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] [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
[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] 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
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] 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] 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
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
[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
[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
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] 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
Re: [tcpdump-workers] Should the tcpdump tests be run with TZ=GMT0, or should the AFS printer print time stamps in UTC?
On Sun, 05 Aug 2018 14:12:31 +0100 Francois-Xavier Le Bail wrote > On 05/08/2018 14:46, Denis Ovsienko wrote: > > 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. > > There are two cases: > > 1) As a user, when I run a capture, I prefer the printing of local time for > all time display. > If, for any reason, I want to change this I can use: (TZ=... ; tcpdump ...) It works in an interactive session; but as soon as the output makes it to the Internet and stays there long enough, people will no longer understand what the printed time was in their local time or UTC. The value of TZ influences the output, but remains invisible. > 2) For tests in TESTLIST, we could build and check the output with TZ=GMT0 > (in TESTrun.sh and > update-test.sh). > Like that, we could run the tests without the '-t' option and get > problems/changes in time printing > functions. Need an update to the current tests outputs (I can do it). I understand what you are suggesting, and your description is correct, but it does not solve the problem of interpreting tcpdump output correctly in a place or time different from the original. That said, I can live with print-rx.c using local time and being imperfect, it has worked like this many years. Still, I think local time should not be the norm for other decoders. I can make the AFS test a custom test run with a nailed-down timezone if that makes everybody happy. -- 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
Re: [tcpdump-workers] Should the tcpdump tests be run with TZ=GMT0, or should the AFS printer print time stamps in UTC?
On Sun, 05 Aug 2018 18:21:47 +0100 John Hawkinson wrote > Denis Ovsienko wrote on Sun, 5 Aug 2018 > at 17:05:20 +0100 in > <1650ad5fd29.b5d2798f311917.536858429581803...@ovsienko.info>: > > > It works in an interactive session; but as soon as the output makes > > it to the Internet and stays there long enough, people will no > > longer understand what the printed time was in their local time or > > UTC. The value of TZ influences the output, but remains invisible. > > I think this is not a real problem; in practice it's rare that long-lived > non-.pcap tcpdump decodings have significant meaning associates with the > time zone of time outputs from printers. One could imagine printing the > local time zone adjacent to the "listening on" output at startup, but it > seems unnecessary. > > But it's important not to let theoretical issues make the tool worse for > actual users. Thank you for your input John. When a network protocol has a timestamp and defines it in UTC (which is often the case), to me it looks consistent if the host in the middle of the exchange (or completely out of the exchange, if that is a .pcap file) prints it in UTC as well. Such as, for example somebody in time zone A decoding NTP packets between hosts in time zones B and C --- why would the man in the middle need to translate the timestamps to any of those timezones when NTP encodes and operates UTC in the first place? The protocol terminating software would be more likely to need to translate UTC to a local timezone to verify or action it. Opposed to that, a protocol decoder just tells you what's on the wire. I accept my point of view may make less sense to other people. > > I understand what you are suggesting, and your description is > > correct, but it does not solve the problem of interpreting tcpdump > > output correctly in a place or time different from the > > original. That said, I can live with print-rx.c using local time and > > being imperfect, it has worked like this many years. Still, I think > > local time should not be the norm for other decoders. > > Doesn't this argument apply for other decoders as well? Whatever is done > should not make the output of decoders harder for the diagnostic users of > tcpdump to interpret, or unnecessarily change the output format. The factor of consistency does indeed apply, and some decoders use UTC already, whilst some others seem to use local time and to fail the tests from time to time. Which reminds us that at the end of the day somebody will need to fix the AFS test, whatever is the consensus. > One could imagine having all of these printers respect -tt, , and > conceivably adding an option to force decoder time printing to be UTC; but > such an option would be tantamount to setting TZ=UTC, and generally the Unix > Way is not to duplicate such OS functionality. > > p.s.: Using GMT or GMT0 is deprecated, please use UTC instead. > > --jh...@mit.edu > John Hawkinson > -- 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 Mon, 06 Aug 2018 09:51:36 +0100 John Hawkinson wrote > Denis Ovsienko wrote on Mon, 6 Aug 2018 > at 09:42:16 +0100 in > <1650e66b5ad.12b3ab99e15597.8336631397456496...@ovsienko.info>: > > > When a network protocol has a timestamp and defines it in UTC (which > > is often the case), to me it looks consistent if the host in the > > middle of the exchange (or completely out of the exchange, if that > > is a .pcap file) prints it in UTC as well. Such as, for example > > somebody in time zone A decoding NTP packets between hosts in time > > zones B and C --- why would the man in the middle need to translate > > the timestamps to any of those timezones when NTP encodes and > > operates UTC in the first place? > > I think most of the time people who look at the output of decoders are doing > so from the perspective of one of the two hosts, such as debugging > application layer software. In such cases, the man in the middle perspective > is really a strawman. This is one of the popular use cases and I definitely have experience with it. However, another experience of mine was such troubleshooting sessions that involved engineers and hosts spread across several time zones. As the network engineer I was effectively the man in the middle, having to analyze traffic that was forwarded rather than terminated, and one of the things you want to keep out of scope are local timezones. I acknowledge this is not the most popular use case, but for me it is a valid experience to consider. > > The protocol terminating software would be more likely to need to > > translate UTC to a local timezone to verify or action it. Opposed to > > that, a protocol decoder just tells you what's on the wire. > > Under normal usage, tcpdump prints the local time at the beginning of the > line. A person looking at timestamps on the wire frequently wants to > correlate those timestamps to the time of packet receipt. If they are in > different timezones, that can be more challenging (although not always, > since often we only care about the minutes and seconds). You have a point, but let me remind that the host that makes the capture may be badly off in terms of both clock (because NTP is broken) and time zone (because it was deployed with a wrong configuration or the daylight saving rules have changed), so the capture timestamps should be taken with a grain of salt. Anyway, as I explained, I can live with either format so long as it is unambiguous. -- 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 Sun, 12 Aug 2018 20:35:36 +0100 Guy Harris wrote > On Aug 12, 2018, at 7:06 AM, Francois-Xavier Le Bail > wrote: > > > Should we add the "Z" suffix (for UTC) ? > > strftime(time_buf, sizeof (time_buf), "%Y-%m-%dT%H:%M:%SZ", tm); That's a good point, I used to think the "T" is both mandatory and indicates the zero offset, but having looked up the spec those are actually properties of the (missing) "Z", whereas "T" (in the RFC version) may be replaced with a space. > Should we do so in ts_date_hmsfrac_print() as well, if time_flag isn't > LOCAL_TIME? Looks like so. -- Denis Ovsienko ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] Packet sanitization and IP masking (PR #615)
On Wed, 13 Dec 2017 15:48:32 + alice-cyberreboot wrote > Hello again, > > Here's a new update/summary of my PR: > > - Removed short options in favor of long ones for three features - > zeroing out TCP/UDP payload in IPv4 packets (--zero-tcpudp-payload), > removing said payloads completely (--no-tcpudp-payload), and masking > external IP addresses to a given substitute IP (--mask-external-address > mask_ip); > > - manpage documentation has been updated; > > - commits related to this PR have been consolidated into one commit > message; > > - at the moment, currently up to date with upstream/master, > including modifications resulting from ether.h being unavailable. > > Hope that at this stage, the PR is now ready for proper review. > > And again, if I can assist with work on fixing CVE-related issues, please > let me know. Hello all. I have been thinking about the proposed design (making masking happen at the capture time in the same binary), and there is a possible design issue that bothers me. Consider an end user with a really high rate/bandwidth capture rig. Their first objective would be to copy the packets from the wire to the storage, as quickly as possible to minimize the drops caused by the rig performance. The first problem is, with the additional per-packet processing the performance will drop, is that going to be visible? The second objective would be to hand the capture over with masked endpoints, but what if they have more than one receiver with different mask length, or the mask length is later found to discard too many meaningful bits? It likely does not mean they have to make a new capture each time they need a different mask length. I agree in some cases it is best to mask the endpoints right at the capture time, but do you see the use case for offline masking (as in "tcpdump -r infile.pcap -w outfile.pcap ")? -- Denis Ovsienko ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] issue with -e in IEEE802_11_RADIO mode
On Wed, 04 Apr 2018 21:14:56 +0100 Peter J. Philipp
wrote
> Hi,
>
> I get a totally bogus output with -e and -X flags set on a wlan0
> interface in monitor mode. I have spent a lot of time looking into this
> and I have finally figured out what I needed to do here. Last I'll
> paste my patch, it's easy. I know it isn't via github but I don't have
> a github login and can't even write an issue wihtout having logged in,
> so I resorted to this sane historical way.
Hello Peter.
Thank you for sending the proposed bug fix. If it requires a specific 802.11
frame to reproduce, could you post a sample .pcap file?
> I want to show you the outputs of tcpdump with the -e flag (which is now
> correct):
>
> root@epsilon:/home/pi/tcpdump/tcpdump-4.9.2# ./tcpdump -X -e -c 1 -n
> -s 100 -i
> wlan0 -l 'ether[10] == 0x18 and ether[2] == 0x0 and ether[3] ==
> 0x0'
> tcpdump: verbose output suppressed, use -v or -vv for full protocol
> decode
> listening on wlan0, link-type IEEE802_11_RADIO (802.11 plus radiotap
> header), ca
> pture size 100
> bytes
> 21:57:51.598450 1.0 Mb/s 2472 MHz 11b -58dBm signal antenna 0
> BSSID:18:d6:c7:51:
> 55:86 DA:ff:ff:ff:ff:ff:ff SA:18:d6:c7:51:55:86 Beacon () [1.0* 2.0 5.5
> 11.0 6.0
> 9.0 12.0 18.0 Mbit] IBSS CH:
> 13[|802.11]
> 0x: 8000 18d6 c751 5586
> .QU.
> 0x0010: 18d6 c751 5586 c0fa 8061 bb4b 0200
> ...QUa.K
> 0x0020: 6400 0108 8204 0b16 0c12 1824 d..$
> 0x0030: 0301 0d05 0401 0200 0032 0430 4860 6c2d .2.0H`l-
> 0x0040: 1aee 111b ff00 ..
> 1 packet captured
> 1 packet received by filter
> 0 packets dropped by kernel
I understand you are saying the above is now correct.
> and without the -e flag (which is probably everythign after the wlan
> header):
>
> root@epsilon:/home/pi/tcpdump/tcpdump-4.9.2# ./tcpdump -X -c 1 -n -s
> 100 -i wl
> an0 -l 'ether[10] == 0x18 and ether[2] == 0x0 and ether[3] ==
> 0x0'
> tcpdump: verbose output suppressed, use -v or -vv for full protocol
> decode
> listening on wlan0, link-type IEEE802_11_RADIO (802.11 plus radiotap
> header), ca
> pture size 100
> bytes
> 21:58:05.627380 1.0 Mb/s 2472 MHz 11b -58dBm signal antenna 0 Beacon ()
> [1.0* 2.
> 0 5.5 11.0 6.0 9.0 12.0 18.0 Mbit] IBSS CH:
> 13[|802.11]
> 0x: 8071 914c 0200 6400 0108
> .q.Ld...
> 0x0010: 8204 0b16 0c12 1824 0301 0d05 0400 0200
> ...$
> 0x0020: 0032 0430 4860 6c2d 1aee 111b ff00 .2.0H`l-
> 0x0030: ..
> 1 packet captured
> 2 packets received by filter
> 0 packets dropped by kernel
I understand the above is now correct as well, right? What is the incorrect
version? Is it incorrect for both "-X -e" and "-e" or just for one of those
cases?
> Lastly as indicated here is my small patch:
>
> --- print-802_11.c.old 2018-04-04 19:40:56.458530097
> +0200
> +++ print-802_11.c 2018-04-04 21:44:15.494773874
> +0200
> @@ -3349,7 +3360,18 @@
> ieee802_11_radio_if_print(netdissect_options
> *ndo,
>const struct pcap_pkthdr *h, const u_char
> *p)
> {
> - return ieee802_11_radio_print(ndo, p, h->len,
> h->caplen);
> + const struct ieee80211_radiotap_header
> *hdr;
> + u_int hdrlen, len;
> +
> +hdr = (const struct ieee80211_radiotap_header
> *)p;
> +len =
> EXTRACT_LE_16BITS(>it_len);
> +
> + hdrlen = ieee802_11_radio_print(ndo, p, h->len,
> h->caplen);
> + if (ndo->ndo_eflag && hdrlen > len)
> {
> + return len;
> + }
> +
> + return hdrlen;
> }
>
> /*
--
Denis Ovsienko
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] [tcpdump] Truncated strings
(moving this to tcpdump-workers)
On Tue, 08 May 2018 14:41:13 +0100 Francois-Xavier Le Bail
wrote
> On 02/05/2018 14:28, Francois-Xavier Le Bail wrote:
> > After the longjmp change, most of the truncated messages will be based on
> > ndo->ndo_protocol field (like: ND_PRINT("[|%s]", ndo->ndo_protocol) in Guy
> > proposal).
> >
> > To harmonize with other truncated prints, based or not on "tstr" strings,
> > I think we need to update
> > them with a new function like:
> >
> > /* Print the truncated string based on ndo_protocol */
> > void nd_print_trunc(netdissect_options *ndo)
> > {
> > ND_PRINT("[|%s]", ndo->ndo_protocol);
> > }
> >
> > And replace:
> > ND_PRINT("%s", tstr) -> nd_print_trunc(ndo)
> > ND_PRINT("\n\t[|EAP]"); -> nd_print_trunc(ndo)
> >
> > In some cases, an old printing in uppercase will go lowercase.
> > In some cases, we will remove some '\n' or '\t' not essential.
>
> I work on this and I commit HEAD~3..HEAD for first steps.
>
> But, it seems we could have site effects with this process.
>
> e.g.:
> proto1_print(...)
> {
> ndo->ndo_protocol = "proto1";
> ...
> proto2_print(...);
> ...
> }
>
> proto2_print(...)
> {
> ndo->ndo_protocol = "proto2";
> ...
> }
>
> If proto2_print, a "final protocol" (don't call another function with
> ndo_protocol assignment), need
> to print truncated string with/without longjmp process: no problem.
>
> If no truncated case occurs in proto2_print, after return, the proto1_print
> function take the
> control and if truncated case occurs in proto1_print it will print
> "[|proto2]".
>
> Thus after all calls of function with ndo_protocol assignment, we will need
> a ndo_protocol re-assign
> like:
>
> proto1_print(...)
> {
> ndo->ndo_protocol = "proto1";
> ...
> proto2_print(...);
> ndo->ndo_protocol = "proto1";
> ...
> }
>
> It can bring errors (forgetting...).
>
> Could we do things differently ?
With things done this way it looks like this issue could happen, although it
would result in incorrect labeling, not incorrect behaviour.
A possible solution could be some stack structure and a macro to call the next
function, which macro would take care to update the stack before and after the
function call. But to me such a solution looks more complicated than the
problem, I would rather proof-read the source code once and leave it to work.
--
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
[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] [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] 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
Re: [tcpdump-workers] base directory for bluez
On Thu, 25 Oct 2018 14:57:48 +0100 Martin Kaiser wrote > Dear all, > > I'm trying to cross-compile libpcap and enable bluetooth support for it. > I've already cross-compiled bluez and installed it into a local > directory hierarchy (not under the cross-compiler's sysroot). > > Unfortunately, the configure script uses an on/off switch for bluetooth > and tries to detect bluez in the default system directories. Would it > make sense to convert this to --with-bluetooth[=DIR]? > > Or is there already a mechanism to say that the bluetooth includes are > under $bluetooth_base/include and the libs are under > $bluetooth-base/lib? Hello Martin. Existing arrangements for DAG and SNF provide additional options to specify the libs and headers paths in addition to the library path, if required: --with-dag[=DIR]include Endace DAG support (located in directory DIR, if supplied). [default=yes, if present] --with-dag-includes=IDIR Endace DAG include directory, if not DIR/include --with-dag-libraries=LDIR Endace DAG library directory, if not DIR/lib --with-snf[=DIR]include Myricom SNF support (located in directory DIR, if supplied). [default=yes, if present] --with-snf-includes=IDIR Myricom SNF include directory, if not DIR/include --with-snf-libraries=LDIR Myricom SNF library directory, if not DIR/lib Do you think the same would work best for cross-compiling with bluetooth support? On a related note, since libpcap now uses both configure and cmake, the change to the options should be made in a similar way in both build props. -- Denis Ovsienko ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
[tcpdump-workers] proposed change: make tcpdump -n and tcpdump -nn behave differently
Hello list. At https://github.com/the-tcpdump-group/tcpdump/pull/702 there is a simple proposed change, which seems to be an improvement: - Subject: Introduce -nn option This changes the semantics on -n option so only namelookups are skipped. Port numbers *are* translated to their string representations. Option -nn then has the same semantics as -n had originally. This is a partial upstreaming of tcpdump-4.9.2-3 used in CentOs 7.5. - If anybody sees how this change isn't an improvement, please make your point on 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] [tcpdump] Remove --enable-smb/--disable-smb configure options ?
On Sat, 27 Oct 2018 14:34:30 +0100 Francois-Xavier Le Bail wrote > [not seen on the list, sent again] > > Hello, > > Denis had removed a useless warning about the SMB decoder. > (commit 415b70b6cedadb4a08b7e873385226f0a7b68076) > > Is it time to remove --enable-smb/--disable-smb (enable possibly-buggy SMB > printer) code ? To me the flag mainly serves as a reminder to merge tcpdump pull request #518. -- Denis Ovsienko ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] CVE-2018-19519 ("a stack-based buffer over-read exists in the print_prefix function of print-hncp.c")
On Wed, 20 Feb 2019 08:46:08 + Thomas De Schampheleire wrote > Hello, > > I would like to inquire about the status of CVE-2018-19519 [1] which > was reported end of 2018 but for which no patch seems to be applied in > the tcpdump repository. I also see no reference to this issue in the > mailing list archives. > > The issue is described by the reporter Zeng Yingpei at [2] and a > proposed solution is mentioned (initializing 'buf'). > > Are the tcpdump developers aware of this issue? > Has a patch been proposed / is someone looking at it? Both the report and the CVE allocation are duplicate. The reporter decided to jump ahead. The problem will be fixed. -- Denis Ovsienko ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
[tcpdump-workers] Re: Pcap debug at runtime
On Tue, 14 Mar 2023 08:33:40 +0100 Francois-Xavier Le Bail wrote: > After an update based on a Denis's idea, the configuration use now an > environment variable instead of configurations files. > If the environment variable INSTRUMENT is > - unset or set to an empty string, print nothing, like with no > instrumentation > - set to "all" or "a", print all the functions names > - set to "global" or "g", print only the global functions names > > Note that before the change, the default was to print all functions. > Now it is to print nothing. For posterity, this is where the idea originates: $ LD_DEBUG=help date Valid options for the LD_DEBUG environment variable are: libsdisplay library search paths reloc display relocation processing files display progress for input file symbols display symbol table processing bindingsdisplay information about symbol binding versionsdisplay version dependencies scopes display scope information all all previous options combined statistics display relocation statistics unused determined unused DSOs helpdisplay this help message and exit To direct the debugging output into a file instead of standard output a filename can be specified using the LD_DEBUG_OUTPUT environment variable. -- Denis Ovsienko ___ tcpdump-workers mailing list -- tcpdump-workers@lists.tcpdump.org To unsubscribe send an email to tcpdump-workers-le...@lists.tcpdump.org %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
[tcpdump-workers] Tru64 UNIX
Hello all. I hope this finds you well. After quite a few rounds of cleanups the "lbl" directory exists only in libpcap, and the only file there is os-osf5.h, which stands for Tru64 UNIX 5.x. If anyone has such a system running and would like libpcap to support it and can provide resources to enable such support, please shout before long. Otherwise notions of Tru64/Digital/OSF will be removed where they get in the way of present day development and maintenance. The OS vendor finished Tru64 support 10 years ago. -- Denis Ovsienko ___ tcpdump-workers mailing list -- tcpdump-workers@lists.tcpdump.org To unsubscribe send an email to tcpdump-workers-le...@lists.tcpdump.org %(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
[tcpdump-workers] Re: TCP Header Flags
On Sun, 26 Feb 2023 15:46:56 +0100
Francois-Xavier Le Bail wrote:
[...]
> >> I wonder if there would be any other incurred future maintenance.
>
> The proposed patch is:
>
> diff --git a/pcap-filter.manmisc.in b/pcap-filter.manmisc.in
> index 10aeb42d..864cd238 100644
> --- a/pcap-filter.manmisc.in
> +++ b/pcap-filter.manmisc.in
> @@ -1027,7 +1027,7 @@ The following ICMPv6 type field values are
> available: .BR \%icmp6-multicastrouterterm .
> .IP
> The following TCP flags field values are available: \fBtcp-fin\fP,
> -\fBtcp-syn\fP, \fBtcp-rst\fP, \fBtcp-push\fP,
> +\fBtcp-syn\fP, \fBtcp-rst\fP, \fBtcp-psh\fP (or \fBtcp-push\fP),
> \fBtcp-ack\fP, \fBtcp-urg\fP, \fBtcp-ece\fP,
> \fBtcp-cwr\fP.
> .LP
> diff --git a/scanner.l b/scanner.l
> index 85fe395a..7cc39f77 100644
> --- a/scanner.l
> +++ b/scanner.l
> @@ -475,6 +475,7 @@ tcp-fin { yylval->h = 0x01;
> return NUM; } tcp-syn{ yylval->h = 0x02;
> return NUM; } tcp-rst{ yylval->h = 0x04;
> return NUM; } tcp-push { yylval->h = 0x08; return NUM; }
> +tcp-psh{ yylval->h = 0x08; return NUM; }
> tcp-ack{ yylval->h = 0x10; return NUM; }
> tcp-urg{ yylval->h = 0x20; return NUM; }
> tcp-ece{ yylval->h = 0x40; return NUM; }
>
> (the tcpdump man page will need an update too.)
Obviously, the change would be easy to make. But what comes to my mind
is next 5 or 10 years of answering the same question: "Why tcp-psh is in
the man page/my new book/stackoverflow/whatever and it works in my
development environment, but some production servers reject the syntax?
These are on a very expensive long term support contract, so everything
is supposed just to work, right? Right?"
You could argue that there would be a note in the "backward
compatibility" section, but I could argue that only a fraction of users
ever reads any documentation that comes directly with the software. It
would be better to have some other problems solved before looking at
this discrepancy again.
Specifically, I wonder if it would be practicable to process all
remaining longjmp() backlog in the next few months. The script reports
35 not yet converted files ranging from 110 to 2755 CLOC each.
--
Denis Ovsienko
___
tcpdump-workers mailing list -- tcpdump-workers@lists.tcpdump.org
To unsubscribe send an email to tcpdump-workers-le...@lists.tcpdump.org
%(web_page_url)slistinfo%(cgiext)s/%(_internal_name)s
