[tcpdump-workers] About DLT_LANE8023 and lane_if_print()
--- Begin Message ---
On Aug 4, 2020, at 1:28 PM, Francois-Xavier Le Bail
wrote:
> lane_if_print() in print-lane.c
> (Added by 77b2a4405561467f66a3dfb0f8ce2b0eaa5ebaf9 in Sun Nov 21 1999 "print
> of ATM LanEmulation")
> is called for DLT_LANE8023:
>
> print.c-56-#ifdef DLT_LANE8023
> print.c:57: { lane_if_print,DLT_LANE8023 },
> print.c-58-#endif
> (Added by 777892a591065d32fb8744675574f9214398283a in Sun Nov 21 1999 "add
> lane and cip printing")
>
> But DLT_LANE8023 was never defined in libpcap nor tcpdump.
A comment in pcap/dlt.h says:
/*
* 17 was used for DLT_PFLOG in OpenBSD; it no longer is.
*
* It was DLT_LANE8023 in SuSE 6.3, so we defined LINKTYPE_PFLOG
* as 117 so that pflog captures would use a link-layer header type
* value that didn't collide with any other values. On all
* platforms other than OpenBSD, we defined DLT_PFLOG as 117,
* and we mapped between LINKTYPE_PFLOG and DLT_PFLOG.
*
* OpenBSD eventually switched to using 117 for DLT_PFLOG as well.
*
* Don't use 17 for anything else.
*/
However, I downloaded ISO disk 6 from
https://archive.org/download/SuSE6.3-full
mounted it (macOS diskimages-helper for the win!), copied libpcap-0.4a6.spm,
turned it into a cpis file with rpm2cpio, and extracted the contents; I can't
see DLT_LANE8023 in either the source (which may be a vanilla version of
libpcap 0.4a6, often mistakenly thought to be the last libpcap from LBL - 0.4
non-alpha was) or in the SuSE patch, so either
1) there was no DLT_LANE8023 in SuSE 6.3;
2) there was, but it wasn't in libpcap;
3) there was, but it wasn't in *that* libpcap, it was in some *other*
libpcap (but I couldn't find any other libpcap);
4) that's not an image of SuSE 6.3.
So I checked my mailbox, and found a message from 2000(!) to the ethereal-dev
mailing list:
https://www.wireshark.org/lists/ethereal-users/28/msg00159.html
in which, among other things, I said:
> So I downloaded an RPM from SuSE's Web site, and the "bpf.h" in it says:
>
> /* Warning: not binary compatible with ANK libpcap !!! */
> #define DLT_LANE802317 /* LANE 802.3(Ethernet) */
> #define DLT_CIP 18 /* ATM Classical IP */
and
> And then, in Linuxland:
>
> We have Alexey's patches - which may just have picked stuff up
> from elsewhere - which add
>
> #define DLT_LANE802315 /* LANE 802.3(Ethernet) */
> #define DLT_CIP 16 /* ATM Classical IP */
>
> We have the ISDN4Linux patches, which add
>
> #define DLT_I4L_RAWIP 15 /* isdn4linux: rawip */
> #define DLT_I4L_IP 16 /* isdn4linux: ip */
>
> And now we have SuSE's, which add the ISDN4Linux stuff, and then
> add the stuff from Alexey's patches *but with different
> numbers from the ones in his patches*.
I'm not sure what RPM that was, but the idea was, presumably, that *if* you
built tcpdump on a system that *did* define DLT_LANE8023 in *its* libpcap, and
used *its* libpcap, it could print packets that used DLT_LANE8023.
("Alexey"/"ANK" is Alexey Kuznetzov who, among other things, created the
"turbopacket" patch to the Linux PF_PACKET socket code; that eventually got
into the mainline kernel - the "T" in "TPACKET_V[123]" stands, I think, for
"turbo".)
> What to do with this?
As far as I know, neither DLT_LANE8023 nor DLT_CIP are still around in any
Linux distribution, so nuking support for that's OK with me. I'm not seeing
any support for either of them in Wireshark.
Current OpenSuSe Leap 15.2 does not have DLT_LANE8023 or DLT_CIP.
Is there any reason to keep the code to handle those DLT_ values around?--- End Message ---
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
[tcpdump-workers] pcap_compile_nopcap() not in man pages
--- Begin Message --- Hello list. It turns out, pcap_compile_nopcap() has been a part of the libpcap API since version 0.5 (June 2000), but it is not even mentioned anywhere in the man pages. The existing pcap_compile.3pcap man page seems to be the best place to add this information, since the two functions are similar. Would it be the right thing to do? -- Denis Ovsienko --- End Message --- ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
[tcpdump-workers] Using libnetdissect in other code, outside tcpdump source tree
--- Begin Message --- Hi, Is there a plan for a public face for libnetdissect? I've tried teasing it out, and I ended up having to install: funcattrs.h print.h config.h netdissect.h ip.h ip6.h compiler-tests.h status-exit-codes.h in /usr/include/tcpdump/ in order to compile a libnetdissect-using program outside of the tcpdump source tree. Also, netdissect.h likes to #define min() and max() macros, which makes life interesting when you have, say, a struct with min and max elements. Any pro tips from others who are reusing libnetdissect as a library? Thanks, Bill --- End Message --- ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
[tcpdump-workers] tcpslice releases, branches and tags
--- Begin Message --- Hello all. Here is what I managed to establish from the LBL tcpslice tarballs and the-tcpdump-group/tclslice git repository: * The master branch has only one commit that at least loosely corresponds to an LBL release, that is 9d55298 and tcpslice-1.1a3.tar.Z respectively. * The "lbl" branch used to be a strict subset of the master branch, in that it had just two commits: the initial commit and the almost-1.1a3 commit above. I have added 4 commits and 4 tags to it, so it is no longer a strict subset (the two branches have diverged), and now the tags correspond exactly to the tarballs released by LBL (1.1a3, 1.2a1, 1.2a2, 1.2a3). * It is still not clear which of the post-1.1a3 LBL changes had made it into the master branch, there was at least one attempt to forward-port (commit 13324e4 "tcpslice 1.2a1 from Vern"), but it was difficult for me to compare the non-LBL git history with the tarballs. Hopefully it will be easier now. * The "tcpslice_1_2" branch is not a strict subset of the master branch, but the only reason is because after the branches diverge at commit e22e768, tcpslice_1_2 has a single commit (bb425ec), which makes the same changes as the commit 1100607 in master after the two "#undef const" commits. In other words, in practical sense tcpslice_1_2 is a subset of master and has no work that isn't present in master. I am going to delete the "tcpslice_1_2" branch so it does not mislead whoever is looking into this history next. Cheers. -- Denis Ovsienko --- End Message --- ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
[tcpdump-workers] pcap_compile_nopcap() not in man pages (2nd attempt)
--- Begin Message --- Hello list. It turns out, pcap_compile_nopcap() has been a part of the libpcap API since version 0.5 (June 2000), but it is not even mentioned anywhere in the man pages. The existing pcap_compile.3pcap man page seems to be the best place to add this information, since the two functions are similar. Would it be the right thing to do? -- Denis Ovsienko --- End Message --- ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
[tcpdump-workers] tcpslice releases, branches and tags (2nd attempt)
--- Begin Message --- Hello all. Here is what I managed to establish from the LBL tcpslice tarballs and the-tcpdump-group/tclslice git repository: * The master branch has only one commit that at least loosely corresponds to an LBL release, that is 9d55298 and tcpslice-1.1a3.tar.Z respectively. * The "lbl" branch used to be a strict subset of the master branch, in that it had just two commits: the initial commit and the almost-1.1a3 commit above. I have added 4 commits and 4 tags to it, so it is no longer a strict subset (the two branches have diverged), and now the tags correspond exactly to the tarballs released by LBL (1.1a3, 1.2a1, 1.2a2, 1.2a3). * It is still not clear which of the post-1.1a3 LBL changes had made it into the master branch, there was at least one attempt to forward-port (commit 13324e4 "tcpslice 1.2a1 from Vern"), but it was difficult for me to compare the non-LBL git history with the tarballs. Hopefully it will be easier now. * The "tcpslice_1_2" branch is not a strict subset of the master branch, but the only reason is because after the branches diverge at commit e22e768, tcpslice_1_2 has a single commit (bb425ec), which makes the same changes as the commit 1100607 in master after the two "#undef const" commits. In other words, in practical sense tcpslice_1_2 is a subset of master and has no work that isn't present in master. I am going to delete the "tcpslice_1_2" branch so it does not mislead whoever is looking into this history next. Cheers. -- Denis Ovsienko --- End Message --- ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] pcap_compile_nopcap() not in man pages
--- Begin Message --- (Your first attempt seems to have worked - finally. Perhaps Michael cleared the backlog?) On Aug 10, 2020, at 4:24 AM, Denis Ovsienko via tcpdump-workers wrote: > It turns out, pcap_compile_nopcap() has been a part of the libpcap API > since version 0.5 (June 2000), but it is not even mentioned anywhere in > the man pages. The existing pcap_compile.3pcap man page seems to be the > best place to add this information, since the two functions are > similar. Would it be the right thing to do? The problem with pcap_compile_nopcap() is that it provides no way to return an error message if it fails, unlike pcap_open_dead() combined with pcap_compile(), where you can use pcap_geterr() before closing the pcap_t. An additional problem is that NetBSD fixed this by adding an error-buffer pointer argument, but that meant that NetBSD's pcap_compile_nopcap() was unfixably incompatible with the one in other OSes. They've shifted to the compatible API, at the cost of not being able to get an error string. So, for now, my inclination is to 1) deprecate pcap_compile_nopcap() (complete with marking it as deprecated, so code that uses it gets a compile-time warning on compilers where the deprecation macro is supported) and 2) not document it.--- End Message --- ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] Using libnetdissect in other code, outside tcpdump source tree
--- Begin Message --- On Aug 11, 2020, at 4:55 AM, Bill Fenner via tcpdump-workers wrote: > Is there a plan for a public face for libnetdissect? At some point we should probably do that. (Back in the late '90's, I discovered a program called tcpview, which was a Motif(!)-based GUI network analyzer based on modified tcpdump code, so people *have* used tcpdump's dissection code in their own programs.) > I've tried teasing it > out, and I ended up having to install: > funcattrs.h print.h config.h netdissect.h ip.h ip6.h compiler-tests.h > status-exit-codes.h > in /usr/include/tcpdump/ in order to compile a libnetdissect-using program > outside of the tcpdump source tree. netdissect.h is the library's main API-declaration header. print.h also declares functions that I'd consider part of libnetdissect's API; status-exit-codes.h is also part of that API. For funcattrs.h and compiler-tests.h, libpcap installs equivalents in the include/pcap directory, for use by pcap.h. We should probably have an include/libnetdissect directory in which we install netdissect.h and the headers it requires. However, API-declaring headers should *NEVER* require config.h (there was a particularly horrible case with OpenBSD's version of libz, forcing a painful workaround in Wireshark: /* * OK, now this is tricky. * * At least on FreeBSD 3.2, "/usr/include/zlib.h" includes * "/usr/include/zconf.h", which, if HAVE_UNISTD_H is defined, * #defines "z_off_t" to be "off_t", and if HAVE_UNISTD_H is * not defined, #defines "z_off_t" to be "long" if it's not * already #defined. * * In 4.4-Lite-derived systems such as FreeBSD, "off_t" is * "long long int", not "long int", so the definition of "z_off_t" - * and therefore the types of the arguments to routines such as * "gzseek()", as declared, with prototypes, in "zlib.h" - depends * on whether HAVE_UNISTD_H is defined prior to including "zlib.h"! * * It's not defined in the FreeBSD 3.2 "zlib", so if we include "zlib.h" * after defining HAVE_UNISTD_H, we get a misdeclaration of "gzseek()", * and, if we're building with "zlib" support, anything that seeks * on a file may not work. * * Other BSDs may have the same problem, if they haven't done something * such as defining HAVE_UNISTD_H in "zconf.h". * * "config.h" defines HAVE_UNISTD_H, on all systems that have it, and all * 4.4-Lite-derived BSDs have it. Therefore, given that "zlib.h" is included * by "file_wrappers.h", that means that unless we include "zlib.h" before * we include "config.h", we get a misdeclaration of "gzseek()". * * Unfortunately, it's "config.h" that tells us whether we have "zlib" * in the first place, so we don't know whether to include "zlib.h" * until we include "config.h" * * A similar problem appears to occur with "gztell()", at least on * NetBSD. * * To add further complication, on recent versions, at least, of OpenBSD, * the Makefile for zlib defines HAVE_UNISTD_H. * * So what we do is, on all OSes other than OpenBSD, *undefine* HAVE_UNISTD_H * before including "wtap-int.h" (it handles including "zlib.h" if HAVE_ZLIB * is defined, and it includes "wtap.h", which we include to get the * WTAP_ERR_ZLIB values), and, if we have zlib, make "file_seek()" and * "file_tell()" subroutines, so that the only calls to "gzseek()" and * "gztell()" are in this file, which, by dint of the hackery described * above, manages to correctly declare "gzseek()" and "gztell()". * * On OpenBSD, we forcibly *define* HAVE_UNISTD_H if it's not defined. * * Hopefully, the BSDs will, over time, remove the test for HAVE_UNISTD_H * from "zconf.h", so that "gzseek()" and "gztell()" will be declared * with the correct signature regardless of whether HAVE_UNISTD_H is * defined, so that if they change the signature we don't have to worry * about making sure it's defined or not defined. * * DO NOT, UNDER ANY CIRCUMSTANCES, REMOVE THE FOLLOWING LINES, OR MOVE * THEM AFTER THE INCLUDE OF "wtap-int.h"! Doing so will cause any program * using Wiretap to read capture files to fail miserably on a FreeBSD * 3.2 or 3.3 system - and possibly some other BSD systems - if zlib is * installed. If you *must* have HAVE_UNISTD_H defined before including * "wtap-int.h", put "file_error()" into a file by itself, which can * cheerfully include "wtap.h" and get "gzseek()" misdeclared, and include * just "zlib.h" in this file - *after* undefining HAVE_UNISTD_H. */ Furthermore, the result of config.h may *also* reflect: the compiler being used when it was generated, which means that it may not be appropriate on platforms with multiple compilers that would produce different config.h results, if you're compiling with a compiler other than the one used to generate config.h; the instruction set used as the target when config.h was generated, which means that it may not be appropriate on platforms that support fat binaries, such as macOS (Apple now only support little-e
Re: [tcpdump-workers] Using libnetdissect in other code, outside tcpdump source tree
--- Begin Message --- On Aug 12, 2020, at 1:31 PM, Guy Harris via tcpdump-workers wrote: > We should probably have an include/libnetdissect directory in which we > install netdissect.h and the headers it requires. Or include/netdissect. > However, API-declaring headers should *NEVER* require config.h (there was a > particularly horrible case with OpenBSD's version of libz, forcing a painful > workaround in Wireshark: ... > so if anything in netdissect.h depends on config.h definitions, we should try > to fix that. It looks like it's just declaring replacements for strlcat(), strlcpy(), strdup(), and strsep() if the platform doesn't provide them. That should be done in a non-public header. > That leaves ip.h and ip6.h; I'd have to check to see whether they should be > considered part of the API or not. The comments are: #include "ip.h" /* struct ip for nextproto4_cksum() */ #include "ip6.h" /* struct ip6 for nextproto6_cksum() */ so what should probably be done is have a header for *users* of libnetdissect and a separate header for *components* of libnetdissect; the latter can define more things. (The latter would be a non-public header, unless we decide to support third-party dissector plugins; that would also mean we'd probably want to have something like Wireshark's dissector tables to which those plugins would add themselves.)--- End Message --- ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
