Re: [tcpdump-workers] Bug in print-ppp.c
Darren Reed <[EMAIL PROTECTED]> writes:
> We've come here from handle_ppp() which calls handl_ctrl_proto() for
> PPP_IPV6CP.
> *** print-ppp.c 8 Jul 2004 11:10:37 - 1.2
> --- print-ppp.c 13 Jul 2004 05:01:15 -
> ***
> *** 447,452
> --- 447,454
> pfunc = NULL;
> break;
> }
> + if (pfunc == NULL)
> + break;
> if ((j = (*pfunc)(tptr, len)) == 0)
> break;
> x -= j;
This looks like Debian bug #255179, I fixed it differently by not trying
to analyze IPV6CP, a comment in print-ppp.c says that it's not supported
(yet).
http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=255179&archive=yes
Corresponding fix currently in the Debian package (notice how the IPV6CP
case is outside #ifdef INET6, too):
diff -urNad tcpdump-3.8.3/print-ppp.c tcpdump-3.8.3/print-ppp.c
--- tcpdump-3.8.3/print-ppp.c 2004-04-17 00:25:32.0 +0200
+++ tcpdump-3.8.3/print-ppp.c 2004-06-19 14:54:40.0 +0200
@@ -1056,7 +1056,6 @@
case PPP_IPCP:
case PPP_OSICP:
case PPP_MPLSCP:
- case PPP_IPV6CP:
case PPP_CCP:
case PPP_BACP:
handle_ctrl_proto(proto, p, length);
@@ -1077,6 +1076,7 @@
#ifdef INET6
case ETHERTYPE_IPV6:/*XXX*/
case PPP_IPV6:
+ case PPP_IPV6CP:
ip6_print(p, length);
break;
#endif
--
,''`.
: :' :Romain Francoise <[EMAIL PROTECTED]>
`. `' http://people.debian.org/~rfrancoise/
`-
-
This is the tcpdump-workers list.
Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] Bug in print-ppp.c
Darren Reed <[EMAIL PROTECTED]> writes: > While this does solve the problem for IPV6CP, there are now other ways > for the code to reach this point - i.e other protocols - and just applying > this check would leave tcpdump vulnerable to crashing if it encountered > one of those. That's very possible; I might apply your patch to the Debian package if 3.8.4 doesn't happen sometime soon. -- ,''`. : :' :Romain Francoise <[EMAIL PROTECTED]> `. `' http://people.debian.org/~rfrancoise/ `- - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] (3) tcpdump infinite loop bugs... (2 fixed
Can someone request CAN numbers for these? Michael? -- ,''`. : :' :Romain Francoise <[EMAIL PROTECTED]> `. `' http://people.debian.org/~rfrancoise/ `- - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] (3) tcpdump infinite loop bugs... (2 fixed
Hannes Gredler <[EMAIL PROTECTED]> writes: > for software [3.9,cvs] that has not even been released yet ? All the exploits mention tcpdump 3.8.x as being affected. I didn't run them to check that it's really the case, though... did you? -- ,''`. : :' :Romain Francoise <[EMAIL PROTECTED]> `. `' http://people.debian.org/~rfrancoise/ `- - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] (3) tcpdump infinite loop bugs... (2 fixed
Hannes Gredler <[EMAIL PROTECTED]> writes: > you're right for 3.8 it makes sense ... i did check meanwhile and both > isis and rsvp are affected [just committed the outstanding 3.8 fix for > rsvp] Okay, thanks. I have fixes for isis and rsvp but bgp and ldp are more problematic, they're said to be fixed in 3.9/CVS but the versions have diverged so much since 3.8 that I don't really know what's relevant... Do you plan to merge fixes in the 3.8 branch or should I hack things myself? Thanks, -- ,''`. : :' :Romain Francoise <[EMAIL PROTECTED]> `. `' http://people.debian.org/~rfrancoise/ `- - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] (3) tcpdump infinite loop bugs... (2 fixed
Hannes Gredler <[EMAIL PROTECTED]> writes: > i have checked in fixes for ldp/bgp plus testfiles for the 3.8 branch; You rock! Many thanks to you (and Guy) for providing the fixes. > so all 4 reported exploits are fixed now in the 3.8 branch; I also checked tcpdump 3.6 (current version in Debian stable) and it's not vulnerable to the isis, ldp or rsvp infloops. It is vulnerable to the bgp one and the fix you committed to the 3.8 branch can be trivially translated in 3.6 so I did just that. Thanks again, -- ,''`. : :' :Romain Francoise <[EMAIL PROTECTED]> `. `' http://people.debian.org/~rfrancoise/ `- - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] detecting libpcap 0.9
Guy Harris <[EMAIL PROTECTED]> writes:
> If the interface doesn't change (so that the new version of the library
> is binary backwards-compatible with the old version, even if it's not
> forwards-compatible, i.e. new APIs were added or new capabilities were
> added to existing APIs), the version number shouldn't be incremented and
> the soname shouldn't change.
Yeah, the fact that libpcap 0.9 uses a new soname in Debian is
accidental, I assumed it wouldn't be compatible (like 0.8 vs. 0.7) but
it turns out that it is. Not a big deal...
By the way, icheck has the following to say about 0.9 vs. 0.8, it might
come in handy to whoever will be writing the changes file:
| API addition: typedef direction_t is new
| is now defined at /usr/include/pcap.h:123:
| typedef enum
| {
| D_INOUT = 0,
| D_IN = 1,
| D_OUT = 2,
| } direction_t;
|
| API and ABI addition: identifier pcap_dump_fopen is new
| is now defined at /usr/include/pcap.h:256:
| extern pcap_dumper_t * pcap_dump_fopen(pcap_t *, FILE * fp);
|
| API and ABI addition: identifier pcap_dump_ftell is new
| is now defined at /usr/include/pcap.h:258:
| extern long int pcap_dump_ftell(pcap_dumper_t *);
|
| API and ABI addition: identifier pcap_fopen_offline is new
| is now defined at /usr/include/pcap.h:217:
| extern pcap_t * pcap_fopen_offline(FILE *, char *);
|
| API and ABI addition: identifier pcap_inject is new
| is now defined at /usr/include/pcap.h:231:
| extern int pcap_inject(pcap_t *, void const *, size_t);
|
| API and ABI addition: identifier pcap_nametollc is new
| is now defined at /usr/include/pcap-namedb.h:71:
| extern int pcap_nametollc(char const *);
|
| API and ABI addition: identifier pcap_nametoportrange is new
| is now defined at /usr/include/pcap-namedb.h:68:
| extern int pcap_nametoportrange(char const *, int *, int *, int *);
|
| API and ABI addition: identifier pcap_sendpacket is new
| is now defined at /usr/include/pcap.h:232:
| extern int pcap_sendpacket(pcap_t *, u_char const *, int);
|
| API and ABI addition: identifier pcap_setdirection is new
| is now defined at /usr/include/pcap.h:227:
| extern int pcap_setdirection(pcap_t *, direction_t);
|
| ABI is not backward-compatible
| API is not backward-compatible
--
,''`.
: :' :Romain Francoise <[EMAIL PROTECTED]>
`. `' http://people.debian.org/~rfrancoise/
`-
-
This is the tcpdump-workers list.
Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] detecting libpcap 0.9
Guy Harris <[EMAIL PROTECTED]> writes: > Unfortunately, that happened after the 0.9/3.9 release, so, for better > or worse, we're stuck with the old names; I've backed out the > aforementioned change. It's not too late to release 0.9.2 with these API changes and encourage people not to use 0.9.1... -- ,''`. : :' :Romain Francoise <[EMAIL PROTECTED]> `. `' http://people.debian.org/~rfrancoise/ `- - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] 3.9.1
The CHANGES file in libpcap-0.9.1.tar.gz is... strange: | @(#) $Header: /tcpdump/master/libpcap/CHANGES,v 1.59.2.1 2005/07/05 21:04:27 mcr Exp $ (LBL) | | Tue. July 5, 2005. [EMAIL PROTECTED] Summary for 3.9.x tcpdump | | Fixes for compiling on nearly every platform, | including improved 64bit support | MSDOS Support | Add support for sending packets | OpenBSD pf format support | IrDA capture (Linux only) | | Tue. May 27, 2005. [EMAIL PROTECTED] Summary for 0.9.1 release | | Numerous fixes for Looks like the entry got mangled. -- ,''`. : :' :Romain Francoise <[EMAIL PROTECTED]> `. `' http://people.debian.org/~rfrancoise/ `- - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] release 0.9.2/3.9.2
"Michael Richardson" <[EMAIL PROTECTED]> writes: > libpcap/tcpdump are tagged and are tar.gz. > I will sign them when I get home, and update the web site. The VERSION files still say 0.9.1 and 3.9.1. The CHANGES file in libpcap 0.9.2 still says "Summary for 3.9.x tcpdump" where it should say "Summary for 0.9.x release", or something. Looks great otherwise! -- ,''`. : :' :Romain Francoise <[EMAIL PROTECTED]> `. `' http://people.debian.org/~rfrancoise/ `- - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] 3.9.x
Michael Richardson <[EMAIL PROTECTED]> writes: > I will do a new 3.9.3, and sign it. The VERSION files are still at x.9.2... -- ,''`. : :' :Romain Francoise <[EMAIL PROTECTED]> `. `' http://people.debian.org/~rfrancoise/ `- - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] 3.9.x
Michael Richardson <[EMAIL PROTECTED]> writes: > Sigh. Sorry. > I'm not going to fix this. Let's wait for a bug report. No worries. I'll patch them in the Debian diff. -- ,''`. : :' :Romain Francoise <[EMAIL PROTECTED]> `. `' http://people.debian.org/~rfrancoise/ `- - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
[tcpdump-workers] Spelling fixes
Can we merge these spelling fixes (courtesy of Michael Shields
<[EMAIL PROTECTED]>) for 3.9.4?
diff -urNad ./icmp6.h /tmp/dpep-work.xvutUn/tcpdump-3.9.3/icmp6.h
--- ./icmp6.h 2005-01-14 11:41:50.0 +0100
+++ ./icmp6.h 2005-07-17 12:30:15.0 +0200
@@ -104,9 +104,9 @@
#define MLD6_LISTENER_DONE 132 /* multicast listener done */
#define ND_ROUTER_SOLICIT 133 /* router solicitation */
-#define ND_ROUTER_ADVERT 134 /* router advertisment */
+#define ND_ROUTER_ADVERT 134 /* router advertisement */
#define ND_NEIGHBOR_SOLICIT135 /* neighbor solicitation */
-#define ND_NEIGHBOR_ADVERT 136 /* neighbor advertisment */
+#define ND_NEIGHBOR_ADVERT 136 /* neighbor advertisement */
#define ND_REDIRECT137 /* redirect */
#define ICMP6_ROUTER_RENUMBERING 138 /* router renumbering */
diff -urNad ./print-icmp6.c /tmp/dpep-work.xvutUn/tcpdump-3.9.3/print-icmp6.c
--- ./print-icmp6.c 2005-07-11 22:24:32.0 +0200
+++ ./print-icmp6.c 2005-07-17 12:30:15.0 +0200
@@ -75,7 +75,7 @@
{ ND_ROUTER_SOLICIT, "router solicitation"},
{ ND_ROUTER_ADVERT, "router advertisement"},
{ ND_NEIGHBOR_SOLICIT, "neighbor solicitation"},
-{ ND_NEIGHBOR_ADVERT, "neighbor advertisment"},
+{ ND_NEIGHBOR_ADVERT, "neighbor advertisement"},
{ ND_REDIRECT, "redirect"},
{ ICMP6_ROUTER_RENUMBERING, "router renumbering"},
{ IND_SOLICIT, "inverse neighbor solicitation"},
@@ -131,7 +131,7 @@
{ ND_OPT_PREFIX_INFORMATION, "prefix info"},
{ ND_OPT_REDIRECTED_HEADER, "redirected header"},
{ ND_OPT_MTU, "mtu"},
- { ND_OPT_ADVINTERVAL, "advertisment interval"},
+ { ND_OPT_ADVINTERVAL, "advertisement interval"},
{ ND_OPT_HOMEAGENT_INFO, "homeagent information"},
{ ND_OPT_ROUTE_INFO, "route info"},
{ 0,NULL }
--
,''`.
: :' :Romain Francoise <[EMAIL PROTECTED]>
`. `' http://people.debian.org/~rfrancoise/
`-
-
This is the tcpdump-workers list.
Visit https://lists.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] Spelling fixes
Guy Harris <[EMAIL PROTECTED]> writes: > Checked into the main and x.9 branches. Thanks. -- ,''`. : :' :Romain Francoise <[EMAIL PROTECTED]> `. `' http://people.debian.org/~rfrancoise/ `- - This is the tcpdump-workers list. Visit https://lists.sandelman.ca/ to unsubscribe.
[tcpdump-workers] Fwd: [PATCH] fix printing of tcp seqno for data segments
I received the following patch from Ilpo Järvinen through the Debian
BTS (http://bugs.debian.org/517661):
---
[PATCH] fix printing of tcp seqno for data segments
The new formatting carelessly removed this check and put
it inside the block only, meaning that seqno won't be
printed at all unless at least -v -v are given.
Signed-off-by: Ilpo Järvinen
---
print-tcp.c |2 +-
1 files changed, 1 insertions(+), 1 deletions(-)
diff --git a/print-tcp.c b/print-tcp.c
index 17c1775..c8c2b90 100644
--- a/print-tcp.c
+++ b/print-tcp.c
@@ -452,7 +452,7 @@ tcp_print(register const u_char *bp, register u_int length,
#endif
length -= hlen;
-if (vflag > 1 || flags & (TH_SYN | TH_FIN | TH_RST)) {
+if (vflag > 1 || length > 0 || flags & (TH_SYN | TH_FIN | TH_RST)) {
(void)printf(", seq %u", seq);
if (length > 0) {
--
Romain Francoise
http://people.debian.org/~rfrancoise/
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.
[tcpdump-workers] libpcap's usbmon interfaces vs. usb ethernet devices
[I sent the following yesterday but it didn't reach the list so I'm
resending with a different from address.]
Hi,
There's an unfortunate namespace conflict between the usbnet driver
in Linux and libpcap's usbmon pseudo-interfaces: both use usbX
names, which leads to surprising results when trying to capture
(Ethernet) packets on a USB Ethernet device: since the interface
name contains 'usb', pcap_create() assumes that it should do USB
capture. This is usually not what the user wants.
Changing libpcap's names to 'usbmonX' (which is what the following
patch does) would avoid this problem. (For context, see Debian bug
report #520259: http://bugs.debian.org/520259)
Subject: [PATCH] Change USB device prefix to 'usbmon'
Ethernet USB devices (supported by the usbnet driver in Linux) are
by default named 'usbX', which is also what libpcap uses for its
usbmon pseudo-interfaces. To avoid this namespace conflict, change
libpcap's USB interface prefix to 'usbmon'.
---
inet.c |2 +-
pcap-linux.c |2 +-
pcap-usb-linux.c |2 +-
3 files changed, 3 insertions(+), 3 deletions(-)
diff --git a/inet.c b/inet.c
index 9cd7df7..11efbf4 100644
--- a/inet.c
+++ b/inet.c
@@ -669,7 +669,7 @@ pcap_lookupnet(device, netp, maskp, errbuf)
|| strstr(device, "bluetooth") != NULL
#endif
#ifdef PCAP_SUPPORT_USB
- || strstr(device, "usb") != NULL
+ || strstr(device, "usbmon") != NULL
#endif
) {
*netp = *maskp = 0;
diff --git a/pcap-linux.c b/pcap-linux.c
index 43dfe92..9314eec 100644
--- a/pcap-linux.c
+++ b/pcap-linux.c
@@ -324,7 +324,7 @@ pcap_create(const char *device, char *ebuf)
#endif
#ifdef PCAP_SUPPORT_USB
- if (strstr(device, "usb")) {
+ if (strstr(device, "usbmon")) {
return usb_create(device, ebuf);
}
#endif
diff --git a/pcap-usb-linux.c b/pcap-usb-linux.c
index 93c3f6d..358865c 100644
--- a/pcap-usb-linux.c
+++ b/pcap-usb-linux.c
@@ -64,7 +64,7 @@ static const char rcsid[] _U_ =
#include
#endif
-#define USB_IFACE "usb"
+#define USB_IFACE "usbmon"
#define USB_TEXT_DIR "/sys/kernel/debug/usbmon"
#define SYS_USB_BUS_DIR "/sys/bus/usb/devices"
#define PROC_USB_BUS_DIR "/proc/bus/usb"
--
Romain Francoise
http://people.debian.org/~rfrancoise/
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] Release schedule?
Michael Richardson writes: > http://www.ca.tcpdump.org/beta/ contains 4.1/1.1 tar.gz, signed > with my regular key. > If there are no complaints about these tar balls, I will resign it > with the tcpdump release key on Saturday. Both seem fine to me. -- Romain Francoise http://people.debian.org/~rfrancoise/ - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
[tcpdump-workers] [PATCH] When saving with -U, flush the dump file after opening it
Reading from a capture file that has not yet received any packets fails
with "truncated dump file"; to avoid this, flush the file (forcing the
pcap header out) immediately after opening it.
Suggested by Ferenc Wagner in Debian bug #533625.
---
tcpdump.c |4
1 files changed, 4 insertions(+), 0 deletions(-)
diff --git a/tcpdump.c b/tcpdump.c
index 06683af..76dc67b 100644
--- a/tcpdump.c
+++ b/tcpdump.c
@@ -1205,6 +1205,10 @@ main(int argc, char **argv)
callback = dump_packet;
pcap_userdata = (u_char *)p;
}
+#ifdef HAVE_PCAP_DUMP_FLUSH
+ if (Uflag)
+ pcap_dump_flush(p);
+#endif
} else {
type = pcap_datalink(pd);
printinfo.ndo_type = 1;
--
1.7.1.rc0.13.g7ec1e
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.
[tcpdump-workers] [PATCH] Small fixes to the tcpdump man page
Merge back changes from the Debian package: - fix TCP flags output description, by Christophe Rhodes Original patch submitted in http://bugs.debian.org/575724 - two remaining typo fixes, by A Costa Original patch submitted in http://bugs.debian.org/342310 --- tcpdump.1.in | 11 +-- 1 files changed, 5 insertions(+), 6 deletions(-) diff --git a/tcpdump.1.in b/tcpdump.1.in index 5e1a00f..e77e7f2 100644 --- a/tcpdump.1.in +++ b/tcpdump.1.in @@ -256,7 +256,7 @@ Print the link-level header on each dump line. .B \-E Use \fi...@ipaddr algo:secret\fP for decrypting IPsec ESP packets that are addressed to \fIaddr\fP and contain Security Parameter Index value -\fIspi\fP. This combination may be repeated with comma or newline seperation. +\fIspi\fP. This combination may be repeated with comma or newline separation. .IP Note that setting the secret for IPv4 ESP packets is supported at this time. .IP @@ -272,7 +272,7 @@ The ability to decrypt packets is only present if \fItcpdump\fP was compiled with cryptography enabled. .IP \fIsecret\fP is the ASCII text for ESP secret key. -If preceeded by 0x, then a hex value will be read. +If preceded by 0x, then a hex value will be read. .IP The option assumes RFC2406 ESP, not RFC1827 ESP. The option is only for debugging purposes, and @@ -871,8 +871,8 @@ The general format of a tcp protocol line is: \fISrc\fP and \fIdst\fP are the source and destination IP addresses and ports. \fIFlags\fP are some combination of S (SYN), -F (FIN), P (PUSH), R (RST), W (ECN CWR) or E (ECN-Echo), or a single -`.' (no flags). +F (FIN), P (PUSH), R (RST), U (URG), W (ECN CWR), E (ECN-Echo) or +`.' (ACK), or `none' if no flags are set. \fIData-seqno\fP describes the portion of sequence space covered by the data in this packet (see example below). \fIAck\fP is sequence number of the next data expected the other @@ -919,8 +919,7 @@ bytes and there was a max-segment-size option requesting an mss of Csam replies with a similar packet except it includes a piggy-backed ack for rtsg's SYN. Rtsg then acks csam's SYN. -The `.' means no -flags were set. +The `.' means the ACK flag was set. The packet contained no data so there is no data sequence number. Note that the ack sequence number is a small integer (1). -- 1.7.1.rc0.13.g7ec1e - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] [PATCH] When saving with -U, flush the dump file after opening it
Guy Harris writes: > Checked into the main and 4.1 branches and pushed. Thanks, -- Romain Francoise http://people.debian.org/~rfrancoise/ - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
[tcpdump-workers] tcpdump 4.2.0rc1 build fix
Hi, The 4.2.0rc1 beta tarball of tcpdump is missing the ppi.h file, so print-ppi.c doesn't build. The following will fix it for the next release: diff --git a/Makefile.in b/Makefile.in index 265b47e..04a58dc 100644 --- a/Makefile.in +++ b/Makefile.in @@ -168,6 +168,7 @@ HDR = \ oui.h \ pcap-missing.h \ pmap_prot.h \ + ppi.h \ ppp.h \ route6d.h \ rpc_auth.h \ Thanks, -- Romain Francoise http://people.debian.org/~rfrancoise/ - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] Capturing in 32 bit guests
Guy Harris writes: > so the mmap interface should work between a 64-bit kernel and 32-bit > userland *if* the kernel supports TPACKET_V2, as libpcap should choose > TPACKET_V2 rather than TPACKET_V1 if TPACKET_V2 is supported. I'd need > to know what version of the kernel is running on the system to determine > whether TPACKET_V2 is supported or not (I don't know which kernel > version first introduced it). You need 2.6.27 to make it work (TPACKET_v2 + PACKET_RESERVE). -- Romain Francoise http://people.debian.org/~rfrancoise/ - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
[tcpdump-workers] [PATCH] Avoid losing CPPFLAGS in configure.in
Hi,
Simon Ruderich found that tcpdump's configure script
loses the value of CPPFLAGS because the save/restore code has a typo.
He provided the following patch to fix the problem:
diff --git a/configure.in b/configure.in
index 4ac664e..2bf219c 100644
--- a/configure.in
+++ b/configure.in
@@ -732,7 +732,7 @@ if test $ac_cv_func_pcap_findalldevs = "yes" ; then
dnl Check for Mac OS X, which may ship pcap.h from 0.6 but libpcap may
dnl be 0.8; this means that lib has pcap_findalldevs but header doesn't
dnl have pcap_if_t.
-savedppflags="$CPPLAGS"
+savedcppflags="$CPPFLAGS"
CPPFLAGS="$CPPFLAGS $V_INCLS"
AC_CHECK_TYPES(pcap_if_t, , , [#include ])
CPPFLAGS="$savedcppflags"
--
Romain Francoise
http://people.debian.org/~rfrancoise/
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] [PATCH] Avoid losing CPPFLAGS in configure.in
Guy Harris writes:
> Checked into the trunk and 4.2 branches.
Thanks, but I should have made it more explicit that the patch fixes *two*
typos: 'savedppflags' vs. 'savedcppflags' and 'CPPLAGS' vs. 'CPPFLAGS'.
You fixed only the latter, so the following is still necessary after your
commit:
diff --git a/configure.in b/configure.in
index f1300d7..8864238 100644
--- a/configure.in
+++ b/configure.in
@@ -732,7 +732,7 @@ if test $ac_cv_func_pcap_findalldevs = "yes" ; then
dnl Check for Mac OS X, which may ship pcap.h from 0.6 but libpcap may
dnl be 0.8; this means that lib has pcap_findalldevs but header doesn't
dnl have pcap_if_t.
-savedppflags="$CPPFLAGS"
+savedcppflags="$CPPFLAGS"
CPPFLAGS="$CPPFLAGS $V_INCLS"
AC_CHECK_TYPES(pcap_if_t, , , [#include ])
CPPFLAGS="$savedcppflags"
@@ -1067,7 +1067,7 @@ if test "$want_libcrypto" != "no"; then
fi
AC_CHECK_LIB(crypto, DES_cbc_encrypt)
- savedppflags="$CPPFLAGS"
+ savedcppflags="$CPPFLAGS"
CPPFLAGS="$CPPFLAGS $V_INCLS"
AC_CHECK_HEADERS(openssl/evp.h)
CPPFLAGS="$savedcppflags"
--
Romain Francoise
http://people.debian.org/~rfrancoise/
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.
[tcpdump-workers] 4.3/1.3 releases?
Hi, What's the status of the 4.3/1.3 releases? I see that CHANGES has been updated, there are apparently corresponding branches in Git (although they are not present on GitHub and the bpf server appears to be down) but the tarballs are not on the website. Thanks, -- Romain Francoise http://people.debian.org/~rfrancoise/ - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] Building tcpdump with static libraries
Guy Harris writes: > Presumably the version number didn't change because the binary interface > to the library hasn't changed in a backwards-incompatible fashion for > ages (new routines and other new capabilities have been added, so the > binary of an app built with a *later* shared version of the library > won't work with an *earlier* shared version of the library if they use > those new routines or capabilities, but, modulo library bugs, the binary > of an app built with an *earlier* shared version of the library should > work with a *later* shared version of the library). Yes, that's right. -- Romain Francoise http://people.debian.org/~rfrancoise/ - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] 4.3/1.3 releases?
Michael Richardson writes: > Hi, I issued the 4.3 release candidates back at the end of March. > I was hoping for a few "yes, it worked on obscure system FOO" > reportes before I called it done, but 8 weeks later, I think it's time > to release it. Hmm, then the announcement did not make it to the list... > Do you have any debian packaging diffs that we could/should include? You could pick up these trivial spelling fixes: http://anonscm.debian.org/gitweb/?p=users/rfrancoise/tcpdump.git;a=blob_plain;f=debian/patches/20_spelling.diff;hb=HEAD The rest is not really upstreamable. Thanks! -- Romain Francoise http://people.debian.org/~rfrancoise/ - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] 4.3/1.3 releases?
Michael Richardson writes: > Why? > I really want to be able to do: > git clone ... > dpkg-buildpackage -us -uc -rfakeroot > and get identical code as from apt-get. Why would I want to make your > life harder? Unfortunately the packaging evolves continually with its environment: helper scripts, dependencies, toolchain, etc. The lifecyle is just too different from upstream's generally to make it worthwhile for Debian developers to maintain their packaging with the upstream code. You can still do that though--just clone from git.debian.org ;-) -- Romain Francoise http://people.debian.org/~rfrancoise/ - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] Michael Richardson: 4.3 rc1
Michael Richardson writes: > (Is there a debian, ubuntu, fedora, *BSD code freeze that would care?) Debian wheezy freezes in about two weeks; it would be cutting it a little short but it's probably doable. -- Romain Francoise http://people.debian.org/~rfrancoise/ - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] Michael Richardson: 4.3 rc1
Michael Richardson writes: > I'll push it out late Monday (2012-06-11). Thanks, both releases are now in Debian. Did you mean to sign them with your personal key rather than the tcpdump.org signing key? Thanks, -- Romain Francoise http://people.debian.org/~rfrancoise/ - This is the tcpdump-workers list. Visit https://cod.sandelman.ca/ to unsubscribe.
[tcpdump-workers] [PATCH] LLDP: print packet protocol at all verbosity levels
The LLDP printer doesn't show the packet protocol unless -v is used,
which results in pretty useless output lines where only the timestamp is
present. Make sure we include the default protocol+length output even in
default mode.
---
print-lldp.c |4 +---
1 file changed, 1 insertion(+), 3 deletions(-)
diff --git a/print-lldp.c b/print-lldp.c
index 8735e58..377f2cd 100644
--- a/print-lldp.c
+++ b/print-lldp.c
@@ -1184,9 +1184,7 @@ lldp_print(register const u_char *pptr, register u_int
len) {
tptr = pptr;
tlen = len;
-if (vflag) {
-printf("LLDP, length %u", len);
-}
+printf("LLDP, length %u", len);
while (tlen >= sizeof(tlv)) {
--
1.7.10
-
This is the tcpdump-workers list.
Visit https://cod.sandelman.ca/ to unsubscribe.
Re: [tcpdump-workers] tcpdump 4.4 release candidate 1
Michael Richardson writes: > fa33da4f1c54e40a792cafedba3323238b826a5a libpcap-1.4.0-rc1.tar.gz > e45c91cad15e7516610a8906c20745cbb00ff451 tcpdump-4.4.0-rc1.tar.gz Thanks. EXTRA_DIST needs to be updated in tcpdump, `make check' from the tarball fails because some test files are missing (this isn't the first time this happens, so maybe the dist target could be made smarter and automatically include files from tests/TESTLIST). > DISTRO MANAGERS: I think that the libusb should be disabled in libpcap, > otherwise ELF shared library systems will break, as the application > won't know to link libusb in. Hmm. It seems to me that pcap-config already does the right thing: % pcap-config --libs -L/usr/lib/x86_64-linux-gnu -lpcap % pcap-config --libs --static -L/usr/lib/x86_64-linux-gnu -lpcap -lusb-1.0 -lpthread % Now you could argue that not all applications use pcap-config, but that's outside our control... > What I'd like to see is a libpcap0.8 compatible libpcap1.4 release that > has libusb removed. I'd like to also have a libpcap1.4 package that has > libusb included. Would this make sense? As far as I can tell enabling libusb support doesn't actually change the ABI, so you could have libusb support in libpcap0.8. But adding binary dependencies to a core library has a cost that I'm not willing to pay unless there are some compelling reasons... Guy and I had the same discussion about libnl support a few months ago. On the other hand, introducing a completely separate set of packages just for some extra features would be wasteful. So I don't know. Maybe I could add an extra 'libpcap0.8-sumo' binary package with all third-party libraries enabled, or something. -- Romain Francoise http://people.debian.org/~rfrancoise/ ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
[tcpdump-workers] Failing tcpdump 4.5.1 testsuite
Hi, FYI, the tcpdump 4.5.1 testsuite has new two testcases which we may want to disable by default: - the pppoes_id testcase requires a pcap version which supports PPPoE session ID filtering (>= 1.5) - the nflog-e testcase requires a little-endian host, the NFLOG TLV length is in host byte order and the capture file was generated on a little-endian machine, so it can't be read successfully on a big-endian build host. Thanks. ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] Failing tcpdump 4.5.1 testsuite
Michael Richardson writes: > True... I'm not sure that we have, up until now, considered this a > problem. I don't think we've ever had this problem; at least I always update tcpdump first in Debian (just in case) and this is the first time this happens. ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] Tcpdump 4.6 delayed
Michael Richardson writes: > I was way too at this ietf89 to build changelog and push release button. > I propose to release at Easter. (April 21) So it looks like this never happened? ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] Tcpdump 4.6 delayed
Michael Richardson writes: > Yeah, my bad; was sick that weekend, and stuff... happened. No problem. > How about July 1? So -rc1 on July 1, then release a week later? Or -rc1 in the meantime, and release on July 1? (Works for me either way.) ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] building libpcap without usb support
On Sun, Jul 06, 2014 at 03:19:19AM -0700, Guy Harris wrote: > is a kernel header; does USB sniffing require > libusb-dev at all? Nope. libusb is only required for canusb support. ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
[tcpdump-workers] Official patches for CVE-2014-8767/CVE-2014-8768/CVE-2014-8769?
Hi, I'm looking for the official patches for CVE-2014-8767, CVE-2014-8768 and CVE-2014-8769 but they don't seem to be in the Github repository. The advisories also mention a 4.7.0 version with the fixes, but it's not there either. More info: http://seclists.org/bugtraq/2014/Nov/88 http://seclists.org/bugtraq/2014/Nov/89 http://seclists.org/bugtraq/2014/Nov/90 Thanks, -- Romain Francoise http://people.debian.org/~rfrancoise/ ___ 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?
On Fri, Nov 21, 2014 at 03:47:06PM -0500, Michael Richardson wrote: > It's supposed to happen, but I'm checking. > Should be there now. Is cron failing to do it's thing? Ok, the fixes still aren't on master, but now there's a tcpdump-4.7 branch with the commits I need. So I apparently need all of these? 3f5693a 10 days ago Guy Harris Report a too-long unreachable destination list. 54d2912 10 days ago Guy Harris Not using offsetof() any more, so no need for . e302ff0 10 days ago Guy Harris Further cleanups. 3e8a443 10 days ago Guy Harris Clean up error message printing. ab4e52b 10 days ago Guy Harris Add initial bounds check, get rid of union aodv. 4038f83 10 days ago Guy Harris Do more bounds checking and length checking. 9255c9b 10 days ago Guy Harris Do bounds checking and length checking. print-aodv.c | 481 ++--- print-geonet.c | 270 ++-- print-olsr.c | 56 +-- 3 files changed, 417 insertions(+), 390 deletions(-) That's a lot bigger than typical security patches. :( > It's in the tcpdump.org/beta/ directory, but I didn't want to release > until the distros had a chance to patch. But did you notify the distros? Because I didn't get advance notice, and the others haven't released security updates yet either. Thanks, -- Romain Francoise http://people.debian.org/~rfrancoise/ ___ 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?
On Fri, Nov 21, 2014 at 11:01:15PM +0100, Romain Francoise wrote: > But did you notify the distros? Because I didn't get advance notice, and > the others haven't released security updates yet either. Oh, actually I'm wrong: Fedora has updated packages. -- Romain Francoise http://people.debian.org/~rfrancoise/ ___ 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?
On Sun, Nov 23, 2014 at 11:35:21PM -0800, Guy Harris wrote: > So did I. :-) > (See branches tcpdump_4.1 through tcpdump_4.6.) Ah, great, I need patches for Debian stable, which ships tcpdump 4.3.0. I was about to use Michal's patches for 4.4.0 from the fc19 srpm, but if you have "official" backports, even better. The branch also has fixes for print-udp.c and print-ppp.c. Are these security-sensitive? Should I pick them up as well? If so, do they have CVE identifiers? Thanks, -- Romain Francoise http://people.debian.org/~rfrancoise/ ___ 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?
On Mon, Nov 24, 2014 at 08:16:56AM +0100, Michal Sekletar wrote: > Also it would be nice if we agree on single place where development > happens and stick to that. > > Because bpf.tcpdump.org has a bad track-record (IIRC multiple power, > network failures in the past) I am for sticking with GitHub. Yes, please. -- Romain Francoise http://people.debian.org/~rfrancoise/ ___ 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?
On Mon, Nov 24, 2014 at 11:26:06AM -0800, Michal Zalewski wrote: > I didn't request one, but probably. RH or Debian folks can likely just > assign one from their pools. I can ask the Debian security team to assign one, or we can ask cve-assign@mitre directly. Or perhaps the other Michal can get one via internal Red Hat channels? -- Romain Francoise http://people.debian.org/~rfrancoise/ ___ 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?
On Tue, Nov 25, 2014 at 06:43:03PM +0100, Michal Sekletar wrote: > I got a response from a member of Red Hat's SRT stating that since the > issue was already reported publicly they can not assign CVE number. If > we want to request CVE number we should either write to oss-security > list or ask MITRE directly. Ok, thanks. So unless someone has a better idea, I will ask MITRE. -- Romain Francoise http://people.debian.org/~rfrancoise/ ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] bad soname for libpcap.so.1.6.2 ?
Hello, On Fri, May 06, 2016 at 05:22:24PM +0200, ikuzar RABE wrote: > is normal that soname of libpcap.so.1.6.2 is libpcap.so.0.8 ? This is specific to Debian and its derivatives, for more details see: https://people.debian.org/~rfrancoise/libpcap-faq.html -- Romain Francoise http://people.debian.org/~rfrancoise/ ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
