Bug#1067057: tcpdump: Environment undocumented in the man page, yet the TZ variable has effect on the timezone

> I'll look at getting the man pages fixed. I've filed https://bugzilla.kernel.org/show_bug.cgi?id=218711 against the strftime man page. For localtime(), it may be sufficient that the man page indicates that localtime() behaves as if tzset() were called, and that the tzset man page indicates

Bug#1067057: tcpdump: Environment undocumented in the man page, yet the TZ variable has effect on the timezone

> Very little, if anything, of strftime() needs to handle TZ, because it's > handed a const struct tm *, generated either by a call to localtime() or > gmtime() If generated by a call to localtime(), localtime() has already done > all the work of converting a time_t to local time, meaning that

Bug#1067057: tcpdump: Environment undocumented in the man page, yet the TZ variable has effect on the timezone

> tcpdump has no special handling of TZ, it just calls strftime() which handles > TZ as described in strftime(3). Very little, if anything, of strftime() needs to handle TZ, because it's handed a const struct tm *, generated either by a call to localtime() or gmtime() If generated by a call

Bug#954181: Please stop disabling Bluetooth monitor support in libpcap

Package: libpcap0.8 Version: 1.8.1-6 That version of the package has a patch, patches/bluez-build.diff, that "[Includes] bluetooth/mgmt.h in bt-monitor compile test to make it fail with BlueZ 5.x." This has already caused at least one complaint with Wireshark running on a Debian derivative,

Bug#705224: manpage: tcp section problems

On Thu, 11 Apr 2013 09:53:21 +0200 Jorgen Grahn wrote: > > 2. The annotated example printouts include things like: > > > rtsg.1023 > csam.login: P 2:21(19) ack 1 win 4096 > > The notation is 'first:last(nbytes)' which means 'sequence numbers > > first up to but not

Bug#705224: manpage: tcp section problems

On Thu, 11 Apr 2013 09:53:21 +0200 Jorgen Grahn wrote: > 1. The section starts with this disclaimer: > > > (N.B.:The following description assumes familiarity with the TCP > > protocol described in RFC-793. If you are not familiar with the > > protocol, neither this

Bug#841161: /usr/sbin/tcpdump: tcpdump -d impossible as normal user

On Tue, 18 Oct 2016 09:43:37 +0200 =?utf-8?q?Uwe_Kleine-K=C3=B6nig?= wrote: > I wonder why I need to be root (well, probably "only" need a net related > capability) when generating a bpf filter: Because 1) in order to generate a BPF filter, you need a link-layer

Bug#734455: Are you sure that's the right fix?

The patch you cite is a fix for https://github.com/the-tcpdump-group/libpcap/issues/333 which causes infinite loops. There's another bug wherein packets aren't seen by apps that set the read timeout to 0 and packets don't come in at a sufficiently high rate, the packets are dropped

Bug#577723: Can't reproduce with Wireshark 1.10.5 and OpenBSD 4.8 on an Ethernet interface

I ran tcpdump -s 1500 -w file.pcap on a (virtual) machine running OpenBSD 4.8, scp'ed the file to my Mac, and opened it with Wireshark 1.10.5; it had no problem with it. There's probably something different about your setup; what type of interface are you capturing on? Perhaps it has

Bug#281731: manpage: proto ip6 - Multiple discrepancies in ipv6 docs

On Nov 13, 2012, at 12:34 AM, Guy Harris g...@alum.mit.edu wrote: proto {XXX} is short for ip proto {XXX} or ip6 proto {XXX} (or just ip proto {XXX} in versions of libpcap that don't support IPv6), which means the argument to proto must be a protocol running atop IP, e.g. proto tcp

Bug#281731: manpage: proto ip6 - Multiple discrepancies in ipv6 docs

What you want is ip6 and dst port 179 ip6 is a primitive token in the filter language, and, for better or worse, if you want to use a primate as a string argument to something such as proto, you have to quote it, e.g.: tcpdump -d proto \\ip6 and dst port 179 (the double

Bug#648768: tcpdump: does not include words mac address hardware in the -e option paragraph in the manpage

I've checked a change into the trunk and 4.3 branches of the tcpdump.org tcpdump Git repository to say −e Print the link‐level header on each dump line. This can be used, for example, to print MAC layer addresses for protocols such as Ethernet and

Bug#686276: tcpdump: minor format error in print-ntp.c

I've checked this fix into the trunk and 4.3 branches of the tcpdump.org Git repository. -- To UNSUBSCRIBE, email to debian-bugs-dist-requ...@lists.debian.org with a subject of unsubscribe. Trouble? Contact listmas...@lists.debian.org

Bug#524488: libpcap0.8-dev: pcap_setfilter gives valgrind error on 32bit systems

Somebody needs to teach valgrind that, when a pointer to a structure of the form struct sock_fprog { /* Required for SO_ATTACH_FILTER. */ unsigned short len;/* Number of filter blocks */ struct sock_filter __user *filter; }; is

Bug#651783: libpcap0.8: libpcap should be linked with libnl

On Jan 29, 2012, at 12:50 PM, Romain Francoise wrote: Guy Harris g...@alum.mit.edu writes: Another possibility might be to add support to libpcap to use libmnl for this, so libpcap can just use that. [...] If that makes sense, let me know, and I can look at updating libpcap so that it can

Bug#651783: libpcap0.8: libpcap should be linked with libnl

(I'm doing Reply all, as I think sending to 651...@bugs.debian.org will get this reply into the bug log. If the right thing to do is to reply *only* to that address, so you don't get your own copy, let me know.) On Dec 12, 2011, at 2:34 PM, Romain Francoise wrote: Hi Guy, Guy Harris g

Bug#651783: libpcap0.8: libpcap should be linked with libnl

Package: libpcap0.8 Version: 1.1.1-2 Severity: normal libpcap's configure script, when run on Linux, checks to see whether libnl is present and usable and, if so, uses it to create monN interfaces when monitor mode is requested for 802.11 adapters. This is used by tcpdump, and by TShark and

Bug#281731: manpage: proto ip6 - Multiple discrepancies in ipv6 docs

If you want to capture IPv6 packets to and from TCP or UDP port 179, but *not* IPv4 packets to or from those ports, the correct expression is ip6 and port 179 proto XXX as a filter expression means look up XXX with getprotobyname() and, if that fails, try to interpret it as a number; if