Re: [tcpdump-workers] tcpdump 4.4 release candidate 1
On Mar 25, 2013, at 12:24 PM, Guy Harris wrote: > Should we make new libpcap_1.4 and tcpdump_4.4 branches from the trunk, so > that they reflect what's in the rc3 tarballs? OK, I've done that. Building release tarballs from those branches produces release tarballs that are the same as the rc3 tarballs, except that 1) the libpcap CHANGES file from the libpcap_1.4 branch has an entry I just added for the Bluetooth fixes; 2) the tcpdump CHANGES file from the tcpdump_4.4 branch has some entries for the new print-msnlb.c, print-vxlan.c, and print-otv.c printers and for changes to the BGP printer; 3) the tcpdump tests directory from the tcpdump_4.4 branch is missing failure-outputs.txt and lmp.new. The first is a change that should go into the final 1.4.0 tarball. The second is a change that should go into the final 4.4.0 tarball. The second might reflect files left over from running a test in the 4.4.0 tree from which the rc3 tarball was made, so I assume those files are *not* supposed to be in the final 4.4.0 tarball. ___ 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
On Mar 26, 2013, at 1:26 AM, Guy Harris wrote: > > On Mar 25, 2013, at 12:24 PM, Guy Harris wrote: > >> Should we make new libpcap_1.4 and tcpdump_4.4 branches from the trunk, so >> that they reflect what's in the rc3 tarballs? > > OK, I've done that. Building release tarballs from those branches produces > release tarballs that are the same as the rc3 tarballs, except that > > 1) the libpcap CHANGES file from the libpcap_1.4 branch has an entry I > just added for the Bluetooth fixes; > > 2) the tcpdump CHANGES file from the tcpdump_4.4 branch has some > entries for the new print-msnlb.c, print-vxlan.c, and print-otv.c printers > and for changes to the BGP printer; > > 3) the tcpdump tests directory from the tcpdump_4.4 branch is missing > failure-outputs.txt and lmp.new. ...and 4) some bugs in the recent changes to tcpdump, revealed by some test compiles done on The Written Word's machines, have been fixed. Those fixes, which are in the trunk and tcpdump_4.4 branch, should also be put into the final release tarball. ___ 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
> "Guy" == Guy Harris writes: Guy> On Mar 25, 2013, at 7:55 AM, Michael Richardson Guy> wrote: Guy> 4.4.0rc2 appears to have stuff that's in the trunk but not the Guy> tcpdump_4_4rel0 branch, such as print-msnlb.c, print-vxlan.c, Guy> and print-otv.c, a change to print-bgp.c, and a change to the Guy> Makefile not to have an explicit list of tests but to run a Guy> find command to find the tests. Is that intentional? >> huh? It should all be there. Guy> In the tarball, or in the branch? Guy> That stuff *is* in the tarball. The issue is that it's not in Guy> the tcpdump_4_4rel0 branch, or, at least, not in my repository Guy> cloned from your repository and then set to the tcpdump_4_4rel0 Guy> branch. My mistake, I pushed the tcpdump branch to a local repo (my non-brnach directory) rather than to bpf. -- ] Never tell me the odds! | ipv6 mesh networks [ ] Michael Richardson, Sandelman Software Works| network architect [ ] m...@sandelman.ca http://www.sandelman.ca/| ruby on rails[ ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
[tcpdump-workers] [Patch] print-dhcp6.c
This file doesn't compile using MSVC v16 (from VC-Express 2010)
because it has variable definitions after statements ('<< problem X' below).
tcpdump should be in pure C, not C++ or gcc features. Right?
Patch:
--- Git-Latest\print-dhcp6.cThu Feb 28 16:10:44 2013
+++ print-dhcp6.c Mon Mar 04 13:25:40 2013
@@ -335,6 +335,8 @@
size_t optlen;
u_int8_t auth_proto;
u_int authinfolen, authrealmlen;
+ int remain_len; /* Length of remaining options */
+ int label_len; /* Label length */
if (cp == ep)
return;
@@ -723,10 +725,9 @@
break;
}
tp = (u_char *)(dh6o + 1);
- int remain_len = optlen; << !! problem 1
+ remain_len = optlen;
printf(" ");
/* Encoding is described in section 3.1 of RFC 1035 */
- int label_len; /* Label length */ << !! problem 2
while (remain_len && *tp) {
label_len = *tp++;
if (label_len < remain_len - 1) {
---
--gv
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] [tcpdump] coredump when launched in a ESX4 VM without interface parameter (#59)
> "JoKoT3" == JoKoT3 writes: JoKoT3> tcpdump version 4.3.0 libpcap version 1.3.0 Systems : both JoKoT3> systems are arch x64 up-to-date, one is an ESX 4 VM, the JoKoT3> other is a dell laptop JoKoT3> Error : tcpdump core dumps when lauched without -i parameter JoKoT3> in a VM running on ESX 4. The same command does not produce JoKoT3> a core dump when launched on my laptop Both are ok when JoKoT3> specifying an interface. JoKoT3> strace when core dump : http://pastebin.com/Md6btdcn gdb JoKoT3> backtrace of the coredump : http://pastebin.com/zB2JFgsC Thanks. The fault seems to be inside of libusb: Using host libthread_db library "/usr/lib/libthread_db.so.1". Core was generated by `/usr/sbin/tcpdump icmp'. Program terminated with signal 11, Segmentation fault. #0 0x7feae033fb50 in __opendirat () from /usr/lib/libc.so.6 (gdb) bt #0 0x7feae033fb50 in __opendirat () from /usr/lib/libc.so.6 #1 0x7feadfc68e9e in ?? () from /usr/lib/libusb-1.0.so.0 #2 0x7feadfc6153c in libusb_get_device_list () from /usr/lib/libusb-1.0.so.0 #3 0x7feae0647a9f in canusb_platform_finddevs () from /usr/lib/libpcap.so.1 It appears that it faults if there are no USB devices, which wouldn't be surprising for a VM. openat(AT_FDCWD, "/dev/bus/usb", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = -1 ENOENT (No such file or directory) openat(AT_FDCWD, "/proc/bus/usb", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = -1 ENOENT (No such file or directory) openat(AT_FDCWD, "/dev", O_RDONLY|O_NONBLOCK|O_DIRECTORY|O_CLOEXEC) = 3 I did not see a related bug report at http://www.libusb.org/report/1 or at: http://www.libusb.org/report/9 What distro are you running? Can you tell what minor version of libusb-1.0 you have (there appears to be up to 1.0.9) I'm waiting for my regisration so that I can file a bug. ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] [Patch] print-dhcp6.c
On Mar 26, 2013, at 6:08 AM, Gisle Vanem wrote:
> This file doesn't compile using MSVC v16 (from VC-Express 2010)
> because it has variable definitions after statements ('<< problem X' below).
> tcpdump should be in pure C, not C++ or gcc features. Right?
Right. (GCC features are OK if
1) they're protected with an #ifdef/#if
and
2) if the #ifdef/#if test fails, the resulting code works the same as
if it succeeds.
See, for example, extract.h, which uses __attribute__() if the compiler
supports it, but still works if the compiler doesn't support it.)
I've checked your fix into the trunk and the 4.4 branch.
___
tcpdump-workers mailing list
tcpdump-workers@lists.tcpdump.org
https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
Re: [tcpdump-workers] [tcpdump] coredump when launched in a ESX4 VM without interface parameter (#59)
On Mar 26, 2013, at 9:07 AM, Michael Richardson wrote: > The fault seems to be inside of libusb: > > Using host libthread_db library "/usr/lib/libthread_db.so.1". > Core was generated by `/usr/sbin/tcpdump icmp'. > Program terminated with signal 11, Segmentation fault. > #0 0x7feae033fb50 in __opendirat () from /usr/lib/libc.so.6 > (gdb) bt > #0 0x7feae033fb50 in __opendirat () from /usr/lib/libc.so.6 > #1 0x7feadfc68e9e in ?? () from /usr/lib/libusb-1.0.so.0 > #2 0x7feadfc6153c in libusb_get_device_list () from > /usr/lib/libusb-1.0.so.0 > #3 0x7feae0647a9f in canusb_platform_finddevs () from > /usr/lib/libpcap.so.1 > > It appears that it faults if there are no USB devices, which wouldn't be > surprising for a VM. It faults because it's being handed a NULL first argument, and it's being handed a NULL argument because libpcap isn't checking whether libusb_init() succeeded or not. So, while it's crashing inside libusb, that's because libpcap wasn't using libusb correctly. If you've filed a libusb bug, you might want to close it. This bug was fixed last year in commit 9f8827ee41bbf24c7dc98d5f6ff3790756e378f4 Author: Guy Harris Date: Mon Aug 6 15:25:30 2012 -0700 Check whether libusb_init() succeeds, and give up if it doesn't. libusb_init() isn't guaranteed to succeed; it returns a (presumably) non-zero error on failure. If it doesn't return 0, just give up - we presumably don't have a valid libusb_context pointer, which is probably what's causing crashes when we call libusb_get_device_list() on a system with no usbfs mounted. This fixes bug 3554749 in the tracker, and a bunch of upstream bugs. ___ tcpdump-workers mailing list tcpdump-workers@lists.tcpdump.org https://lists.sandelman.ca/mailman/listinfo/tcpdump-workers
