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 rc
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 b
> "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-b
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
> "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
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
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
