Re: [Wireshark-dev] Multiple input files
Dario Lombardo writes:
> for file in *.pcap
> do
> tshark -r $file -Y "FILTER" -w - | mergecap -a - -w output.pcap
> done
>
> what about that?
Two problems:
1) How do you guarantee the files will be processed in correct time order
for appending?
2) mergecap today doesn't support reading from stdin.
I think Jasper's solution is the way to go for now (less the -a option due
to #1 above).
Even my earlier proposed script isn't as useful as it could be. What might
make it more useful (potentially) is if in addition to supporting reading
from stdin, mergecap also supported reading from and writing to the same
file, as that would completely avoid the tmp file(s) altogether, i.e.:
#!/bin/sh
if (( ${#} < 3 ))
then
echo "Usage: $0 "
exit 0
fi
filter=$2
outfile=$3
rm -f $outfile
touch $outfile
for file in `ls -1 $1`
do
wireshark-gtk2/tshark.exe -r $1/$file -Y "$filter" -F libpcap -w - |
wireshark-gtk2/mergecap.exe -w $outfile - $outfile
done
echo "Done merging files in $1/ to $outfile"
___
Sent via:Wireshark-dev mailing list
Archives:http://www.wireshark.org/lists/wireshark-dev
Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev
mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Clang build with ASAN
On 8/13/2013 9:43 AM, Evan Huus wrote: On Mon, Aug 12, 2013 at 11:17 AM, Alexis La Goutte mailto:alexis.lagou...@gmail.com>> wrote: Hi, it is now possible to build wireshark with clang (CC=clang ./configure && make) (i fix last issue last week end). I will try the ASAN feature ( http://clang.llvm.org/docs/AddressSanitizer.html ) I wonder if it is possible to also run include-what-you-use now? https://code.google.com/p/include-what-you-use/ I've done a little trial of include-what-you-use (iwyu). IMO, the output is a bit useful but most of theoutput is not . It appears, for example, that iwyu seems wants to, in effect, "expand" .h file includes (e.g., packet.h) and then just include the actual .h files needed. This (obviously) can be valid (and might reduce compile time) but I certainly don't think going through and substituting individual #includes for packet.h as suggested by iwyu is something that should be done. One possible action might be to look at the "remove these lines" suggestions; individual inspection would probably be required to determine if an #include can be removed w/o having to add a "sub-include". Bottom line (IMO): 1. Blindly applying all the suggestions is a non-starter. 2. Manually applying certain suggested items seems like a lot of work for not much result. So, I thoink there's other stuff with much higher priority. Bill == [[ iwyu output for packet-netsync.c and packet-tcp.c ]] packet-netsync.c should add these lines: #include // for NULL #include "./column-utils.h" // for col_set_str #include "./ftypes/ftypes.h"// for ftenum::FT_BYTES, etc #include "./proto.h"// for proto_tree_add_item, HFILL, etc #include "./tvbuff.h" // for tvbuff_t, tvb_get_guint8, etc #include "./value_string.h" // for val_to_str, value_string #include "epan/column_info.h" // for ::COL_PROTOCOL #include "epan/packet_info.h" // for packet_info #include "glib/gmacros.h" // for TRUE, FALSE #include "glib/gtypes.h"// for gint, guint, gboolean #include "glibconfig.h" // for guint8, guint32 packet-netsync.c should remove these lines: - #include // lines 34-34 [[[ OK: included in prefs.h ]]] - #include // lines 36-36 [[[ OK: Not needed ]]] - #include // lines 31-31 The full include-list for packet-netsync.c: #include // for array_length, etc #include #include // for NULL #include "./column-utils.h" // for col_set_str #include "./ftypes/ftypes.h"// for ftenum::FT_BYTES, etc #include "./proto.h"// for proto_tree_add_item, HFILL, etc #include "./tvbuff.h" // for tvbuff_t, tvb_get_guint8, etc #include "./value_string.h" // for val_to_str, value_string #include "config.h" // for _U_ #include "epan/column_info.h" // for ::COL_PROTOCOL #include "epan/packet_info.h" // for packet_info #include "glib/gmacros.h" // for TRUE, FALSE #include "glib/gtypes.h"// for gint, guint, gboolean #include "glibconfig.h" // for guint8, guint32 #include "packet-tcp.h" // for tcp_dissect_pdus --- CC libdissectors_la-packet-tcp.lo packet-tcp.h should add these lines: #include "./address.h" // for address #include "./proto.h"// for proto_tree #include "./tvbuff.h" // for tvbuff_t #include "epan/conversation.h" // for __CONVERSATION_H__, etc #include "epan/packet.h"// for dissector_t #include "epan/packet_info.h" // for packet_info #include "epan/wmem/wmem_tree.h"// for wmem_tree_t #include "glib/gtypes.h"// for gboolean, gchar, guint #include "glibconfig.h" // for guint32, guint16, gint32, etc #include "wsutil/nstime.h" // for nstime_t packet-tcp.h should remove these lines: - #include // lines 37-37 The full include-list for packet-tcp.h: #include "./address.h" // for address #include "./proto.h"// for proto_tree #include "./tvbuff.h" // for tvbuff_t #include "epan/conversation.h" // for __CONVERSATION_H__, etc #include "epan/packet.h"// for dissector_t #include "epan/packet_info.h" // for packet_info #include "epan/wmem/wmem_tree.h"// for wmem_tree_t #include "glib/gtypes.h"// for gboolean, gchar, guint #include "glibconfig.h" // for guint32, guint16, gint32, etc #include "ws_symbol_export.h" // for WS_DLL_PUBLIC #include "wsutil/nstime.h" // for nstime_t --- packet-tcp.c should add these lines: #include "./column-utils.h" // for col_prepend_fence_fstr, e
Re: [Wireshark-dev] Usefulness of checklicenses.py
On 9/6/13 7:25 AM, Joerg Mayer wrote: > Hello, > > buildbot is failing in checklicenses - and it looks like the list of > failed licenses is long. If nobody fixes this, then what's the idea > behind that check? > > http://buildbot.wireshark.org/trunk/builders/Ubuntu-12.04-x64/builds/6101/steps/check > licenses/logs/stdio The script came from Chromium: http://src.chromium.org/viewvc/chrome/trunk/src/tools/checklicenses/ I was hoping we could use it to check our code base for incompatible licenses. However, it needs some work to better match our repository instead of Chromium. If that's too much trouble I don't mind disabling the build step or removing the script completely. If we do keep it we might want to use Chromium's version of licensecheck.pl since it seems to do a better job of detecting licenses, particularly for code generated by bison: http://src.chromium.org/viewvc/chrome/trunk/src/third_party/devscripts/ ___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
[Wireshark-dev] Usefulness of checklicenses.py
Hello, buildbot is failing in checklicenses - and it looks like the list of failed licenses is long. If nobody fixes this, then what's the idea behind that check? http://buildbot.wireshark.org/trunk/builders/Ubuntu-12.04-x64/builds/6101/steps/check licenses/logs/stdio Ciao Jörg -- Joerg Mayer We are stuck with technology when what we really want is just stuff that works. Some say that should read Microsoft instead of technology. ___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Wireshark crashes
Anders Broman writes: > I’m wondering if anyone sees these crashes (Ubuntu 13.04 ) , to reproduce: > Preferences > Update list of packets in real time: off > Automatic scrolling in live captures: off > > Start a capture – wait for a few packets to arrive ( packet counter) > Stop capture. > > Start a new capture – continue without saving > Stop capture > *Crash* I don't see that on Windows 7 64; however, I still experience https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=6217, which is similar in nature, but would appear to be a different crash since you didn't indicate that you also had a display filter applied. ___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
[Wireshark-dev] Wireshark crashes
Hi, I'm wondering if anyone sees these crashes (Ubuntu 13.04 ) , to reproduce: Preferences Update list of packets in real time: off Automatic scrolling in live captures: off Start a capture - wait for a few packets to arrive ( packet counter) Stop capture. Start a new capture - continue without saving Stop capture *Crash* ___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Multiple input files
Another option could be to support stdin as input file in mergecap with an "append" switch. If mergecap whould support something like this cat input1.pcap | mergecap -a - -w output.pcap cat input2.pcap | mergecap -a - -w output.pcap this would allow a user to do something like for file in *.pcap do tshark -r $file -Y "FILTER" -w - | mergecap -a - -w output.pcap done what about that? On Thu, Sep 5, 2013 at 3:35 PM, Christopher Maynard < christopher.mayn...@gtech.com> wrote: > Evan Huus writes: > > > You can even (I think) pipe from mergecap to tshark as follows: > > > > > > mergecap -w - in1.pcap in2.pcap in3.pcap | tshark -Y > "dns.qry.name contains google" -o google.pcap > > Just a slight correction on the tshark command-line options needed (note > the > "-i -"): > > mergecap -w - in1.pcap in2.pcap in3.pcap | tshark -i - -Y "dns.qry.name > contains google" -o google.pcap > > > ___ > Sent via:Wireshark-dev mailing list > Archives:http://www.wireshark.org/lists/wireshark-dev > Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev > mailto:wireshark-dev-requ...@wireshark.org > ?subject=unsubscribe ___ Sent via:Wireshark-dev mailing list Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
