Anders Broman wrote:
Hi,
Yes sounds like a good idea. Have been contemplating testing it too.
I just installed the "Build Tools for Visual Studio 2022"
https://visualstudio.microsoft.com/downloads/#build-tools-for-visual-studio-2022
But was disappointed it does not include a newer compiler
João Valverde wrote:
you can (and probably should) include "config.h", just like other Wireshark
bundled plugins do.
Why does this project not use '-FI./config.h'?
--
--gv
___
Sent via:Wireshark-dev mailing list
Arc
Maynard, Chris wrote:
Which specific release of VS2019 are you running? This is a bit of a stretch,
but *possibly* your version could use an update?
I have the latest AFAIK I ran vs_installer last week.
From 'cl /?': Version 19.24.28319 for x86
From 'vswhere': VisualStudio.16.Release/16.4
I'm surprised no one has come across this compile
error yet:
epan/dissectors/packet-f5ethtrailer.c(482): error C2143: syntax error:
missing ';' before '.'
epan/dissectors/packet-f5ethtrailer.c(485): error C2224: left of '.S_addr'
must have struct/union type
epan/dissectors/packet-f5ethtrai
Hi list.
I remember wireshark-qt in the old days had a button
to change the 2.4GHz WiFi channel to capture on. But
since some time, I fail to find on 'Preference' setting
to get it enabled. Was it dropped?
It seems the functions 'ws80211_set_freq()' and
'airpcap_if_set_device_channel()' should b
I wrote:
In my recently built Tshark/Wireshark etc., I've discovered
this longer works:
tshark.exe -i \Device\NPF_{3A46ACA0-CBED-44BC-A239-6AEA3D0C451D}
It says:
Capturing on '\Device\NPF_{3A46ACA0-CBED-44BC-A239-6AEA3D0C451D}'
tshark: The capture session could not be initiated on inte
In my recently built Tshark/Wireshark etc., I've discovered
this longer works:
tshark.exe -i \Device\NPF_{3A46ACA0-CBED-44BC-A239-6AEA3D0C451D}
It says:
Capturing on '\Device\NPF_{3A46ACA0-CBED-44BC-A239-6AEA3D0C451D}'
tshark: The capture session could not be initiated on interface
'\Devic
João Valverde wrote:
if (!g_file_get_contents(list, &contents, NULL, NULL))
return;
- for (arg = strtok(contents, " \n"); arg != NULL; arg = strtok(NULL, "
\n")) {
+ for (arg = strtok(contents, " \r\n"); arg != NULL; arg = strtok(NULL, "
\r\n")) {
scan_file(arg,
Anders Broman wrote:
Problems building register.c with older glib g_async_queue_timeout_pop().
I don't know about this problem.
But another problem is the "\r\n" newlines in a response-file
given to make-dissectors.exe. Should IMHO be:
--- a/epan/dissectors/make-dissectors.c 2017-11-23 12:01
Dario Lombardo wrote:
> The current master can't build if we disable PCAP in cmake.
I can't be build if HAVE_EXTCAP is not defined either
--
--gv
___
Sent via:Wireshark-dev mailing list
Archives:https://www.wiresha
I wrote:
The is for sure a problem in how lines of text are generated in dumpcap.exe
and how tshark is interpreting them. I'm not even sure the lines have
"\r\n" terminations since from dumpcap.c:
#ifdef _WIN32
/* set output pipe to binary mode, to avoid ugly text conversions */
I wrote:
> The is for sure a problem in how lines of text are generated in dumpcap.exe
> and how tshark is interpreting them. I'm not even sure the lines have
> "\r\n" terminations since from dumpcap.c:
> #ifdef _WIN32
> /* set output pipe to binary mode, to avoid ugly text conversion
Graham Bloice wrote:
Which branch though, master or master-2.2?
'master' it seems. But I tried to resolve the issue myself.
First by trying w/o HAVE_EXTCAP (to exclude any problems with that). But
that is impossible. E.g.:
capture_sync.c(521): error C2039: 'extcap_fifo': is not a member of
Graham Bloice wrote:
Unsure whether this is related, but MSVC2015 support is regarded as
"experimental". The official builds are still using
VS2013.
Really. MSVC-2015 is much better regarding C99 conformance etc.
The above "read 21 indicator: S empty value" for me indicates a problem
I'm on Win-10 and have now troubles sniffing on anything except
BlueTooth! This is the list of interfaces I expect to get:
dumpcap.exe -D
1. \Device\NPF_{C25DD2C2-2E05-4337-A847-84EF6CAB86BF}
(Bluetooth-nettverkstilkobling)
2. \Device\NPF_{F92984E3-5D40-4AD9-B054-41288EAE699F} (Wi-Fi 2)
3
Guy Harris wrote:
> They (MaxMind) might want to consider having a cleanup routine anyway, given
> that 1) their code works
> on Windows and 2) unless the GeoIP library and the code that calls it are
> built with the same version
> of MSVC, or the "universal CRT" or whatever it's called is bein
Hi list.
I got a crash in epan/geoip_db.c and MSVCRT:free().
Due to the use of g_free() at line 379:
case GEOIP_ASNUM_EDITION:
raw_val = GeoIP_name_by_ipnum(gi, addr);
if (raw_val) {
ret = db_val_to_utf_8(raw_val, gi);
Yang Luo wrote:
> AFAIK, Npcap/WinPcap works on the data link level and it sees the Ethernet
> frames. In my understanding, VPN SSL (https)
> or raw HTTP is just data of high-levels (IP packets) for Npcap/WinPcap. I
> don't know if it's appropriate or viable for
> Npcap/WinPcap to see this data.
"Guy Harris" wrote:
Presumably autotools can be convinced to generate ws_config.h rather than
config.h.
I'm not a user of auto* tools, but I guess it's done with:
- AC_CONFIG_HEADERS(config.h)
+AC_CONFIG_HEADERS(ws_config.h)
--gv
_
"Shanks, Graham (UK)" wrote:
A better solution would be to move the local config.h into a subdirectory and
then use the following:
#include “subdir/config.h”
Since several dependent packages could have a config.h in it's ./include dir,
(shadowing for Wireshark's "config.h"), why not rename
The 'Editor modelines' at end of make-version.pl should not be printed.
E.g. 'perl make-version.pl -h' prints this garbage at the end:
...
Options can be used in any combination. If none are specified --set-svn
is assumed.
# # Editor modelines - http://www.wireshark.org/tools/modelines.html #
Why is main.cpp included in ui/qt/about_dialog.cpp like this:
...
#include "wireshark_application.h"
#include "main.cpp"
#include
And then main.cpp is also present in qtshark.pro. This gives multiple
defined symbols while linking. What's the idea behind this?
--gv
"Graham Bloice" wrote:
and maybe due to my CMake ineptness it turned out to be one file per line.
How fast will CMake generate such a temp-file? There are approx 1100 packet-*.c
files. I figured this macro does it:
MACRO(REGISTER_DISSECTOR_FILES _outputfile _registertype )
if(${_regis
I saw the recent change to 'tools/make-dissector-reg.py' to allow
reading list of files from a file; the argument "dissectorsinfile". I find this
a bit awkward. Isn't it better to use the more familiar response-file syntax?
So the command to generate register.c would be something like:
@$(PYTH
"Bálint Réczey" wrote:
how about making gtk3 the default over gtk2 when building Wireshark? Just
to be clear: I only want to reverse the build defaults between gtk2 and 3.
Hopefully it will get much more testing that way, so it is up to prime time
for the next release?
I fully support the idea
"Brandon Carpenter" wrote:
I have to say that I dislike getopt() and getopt_long() for option
parsing because of the disconnect between the options and the help. It
creates multiple places that require updating when options change and
quite often, one of those places is forgotten.
Agreed.
I'm having a problem compiling the *non* generated easy_codec_plugin.c.
The message from MSVC is:
"error C2491: 'version' : definition of dllimport data not allowed"
for the line:
WS_DLL_PUBLIC_NOEXTERN const gchar version[] = "0.0.1";
The preprocessed output becomes:
__declspec(dllimport)
"Max Baker" wrote:
I've created a new dissector for USB PTP
(http://en.wikipedia.org/wiki/Picture_Transfer_Protocol) . This is the
protocol most digital cameras speak over USB. I've gotten far enough
to do the basic dissection, and I'm pretty stoked on the results!
Just a side-question. An
"Bálint Réczey" wrote:
I have created the attached patch to control symbol visibility using
C defines instead of .def and .sym files. It is expected to work on every
platform and every build system we support, but I did not want to
commit it without discussing the direction.
Nice, but why not
"Christopher Maynard" wrote:
My new email address is "njgm890@...". Please update "AUTHORS".
Thanks, -Nathan
Done in r47235.
Can you change mine to while you're at it?
From "" to
"".
--gv
___
Sent via:Wireshark
"Guy Harris" wrote:
Checked in (with the checks and #defines moved up a little earlier).
Thanks. Works fine now. But I'm curious about why this:
#if 0 /* XXX: including config.h causes compilation errors; TBD: why */
#include "config.h"
is needed. "config.h" should be able to live up ther
"Gisle Vanem" wrote:
The code in capture_win_ifnames.c assume there's always
a GUID in the ifname. Not so here. From my 'tcpdump -D':
I saw the changes of capture_win_ifnames.c in SVN regarding the
missing GUID. But the g_log() error-text is still messing th
The code in capture_win_ifnames.c assume there's always
a GUID in the ifname. Not so here. From my 'tcpdump -D':
1: \\.\airpcap00
2: \Device\NPF_GenericDialupAdapter
3: \Device\NPF_{7F56352E-EF2F-49F4-844C-BA1FA0105667}
4: \Device\NPF_{8D3A23A7-9C6C-408B-A23B-6736F9E56510}
5: \Device\NPF_{37F
I'm running into problems with the huge command-line passed to my shell in
generating register.c (I'm using a home-made build-system for the MSVC version
of Wireshark ... based on Mingw-make/Msys sh). So can you please accept this
patch to use a response-file in tools/make-dissector-reg.py?
--
"Jakub Zawadzki" wrote:
On Tue, Oct 02, 2012 at 03:02:11PM +0200, Gisle Vanem wrote:
utf_8to16() and utf_16to8() uses indices from 0 to 3.
Nope, from 0 to 2.
Bummer! Long time since I used the 'mod&#
utf_8to16() and utf_16to8() uses indices from 0 to 3. So there should be 4
buffers
for length and data. No?
--- SVN-Latest\wsutil\unicode-utils.c 2012-07-05 19:01:54.078125000 +0200
+++ wsutil\unicode-utils.c 2012-10-02 15:00:36.65625 +0200
@@ -52,8 +52,8 @@
wchar_t *
utf_8to16(const
"Guy Harris" wrote:
found a bunch of stuff about problems with Perl scripts processing text files, and some stuff about
problems with *bash* handling shell scripts with CR-LF line endings, but nothing specifically about Perl.
Thank for the CygWin info Guy.
Yap is a Perl script. So "problems
"Jeff Morriss" wrote:
Gisle Vanem wrote:
The files in tools/tpg seems to have DOS/Win line-endings (CR-LF). This
doesn't work well with the Cygwin compiled perl I have here. Could you
pass them through dos2unix before adding to svn?
Those files all have svn:eol-style set to
The files in tools/tpg seems to have DOS/Win line-endings (CR-LF).
This doesn't work well with the Cygwin compiled perl I have here.
Could you pass them through dos2unix before adding to svn?
--gv
___
Sent via:Wireshar
"Jakub Zawadzki" wrote:
Hi,
On Thu, May 31, 2012 at 09:13:50PM +0200, Gisle Vanem wrote:
The implementation of 'stats_tree_get_cfg_by_abbr()' takes a
'const char *', so why shouldn't the prototype do the same?
Really? Looking at code it's without
The implementation of 'stats_tree_get_cfg_by_abbr()' takes a
'const char *', so why shouldn't the prototype do the same?
--- SVN-Latest\epan\stats_tree_priv.h Thu Feb 23 01:51:50 2012
+++ epan\stats_tree_priv.h Thu May 31 13:08:15 2012
@@ -179,7 +179,7 @@
extern gchar *stats_tree_get_abbr(
asn1/nbap/packet-nbap-template.c now introduces an enum value
'PCH' that clashes with 'PCH' in .
According to:
http://anonsvn.wireshark.org/viewvc/trunk/asn1/nbap/packet-nbap-template.c?r1=42779&r2=42783
The change happened at May 22 15:39:12. Could that be renamed to '_PCH'?
--gv
___
When I did this:
1. Open menu 'Capture | Interfaces' and select 'Options | Manage Interfaces'.
2. Click 'Local Interfaces' with the intention to hide the interface
'MS Tunnel interface driver', I got a crash at
airpcap_channel_offset_changed_cb().
I'm not sure how the right way (TM) of hiding
"Jeff Morriss" wrote:
Hmmm, reassemble_test doesn't use that symbol directly, it's used within
libwireshark, so technically I don't think it should need to be exported.
Ops, you're right. Somehow my $(REASSEMBLE_TEST_OBJ) included reassemble.obj
etc. Hence the link failure.
--gv
Isn't reassemble_test.exe among the targets on Windows?
(or any OS; I dont understand the 'EXTRA_DIST' stuff in
epan/Makefile.am).
Can't seems to make it link because of a missing export of
'proto_registrar_get_name' in epan/libwireshark.def. Hence, I think
patch should fix it:
--- SVN-Latest\ep
"Rajesh P S" wrote:
It says that it is not able to find ps.c file. Suggest some fix for it?
Maybe you don't have Python installed? It is required to build
ps.c.
--gv
___
Sent via:Wireshark-dev mailing list
Archives:
"Graham Bloice" wrote:
I built on the same platform just a few minutes ago (from trunk r41048) and
register.c was fine. I'm using python 2.7.1 though. How are you
determining your environment size?
I'm sure the is a function for this, but I approximated by a
"set > foo", counting the lin
I hit a problem with the Python generation of epan/dissectors/register.c.
The message from my python (v. 2.7.2) at this stage was:
.. "execvp: python: Bad file number"
after reading the docs on '_execvp' [1] at MSDN, I suspect this error
is related to the very long command-line given to pytho
Generated files in ui/qt should perhaps not be put in
the SVN repo. This one is there now:
ui\qt\qrc_toolbar.cpp
--gv
___
Sent via:Wireshark-dev mailing list
Archives:http://www.wireshark.org/lists/wireshark-dev
Uns
"Gerald Combs" wrote:
Checked in in r40378. At the present time you must compile the main
sources using CMake, then compile the Qt code using Qt Creator. More
information can be found in doc/README.qt.
I've built Qt-GUI using MSVC2010. Looks rather simple now, but good
job! Only offline captu
Or bug reports, plural - I suspect the two problems he cites are unrelated to
each other.
Guy + Jaap. I will get cook up some reproducible test-case
and add a bug-report.
--gv
___
Sent via:Wireshark-dev mailing list
A
There are some places in the ./gtk sources that causes a
crash while sniffing on a AirPcap adapter. I don't know why;
maybe most code assumes the captured frames contain network
layer packets. Since my Airpcap (\\.\airpcap00 on Win-XP) only gives
me IEEE 802.11 radio frames, I can only speculate.
"homeryan" wrote:
I am a student from China, one of my homework is developing a simple network analyzer act just like wireshark. I decided to
develop GUI interface and module of packets capture. But the part of dissector is too complex for me to complish, so, how can I
invoke or use the dis
"Chris Maynard" wrote:
Should be fixed in r39865. Hopefully the names I've chosen are sensible enough.
Ok, good. Similar problem with packet-spice.c;
epan/dissectors/packet-spice.c(588) : error C2371: 'POINT' : redefinition;
different basic types
g:\VC_2010\SDK\include\windef.h(343)
Just a FYI:
epan/dissectors/packet-rlc.c(113) : error C2365: 'PCCH' : redefinition;
previous definition was 'typedef'
g:\VC_2010\SDK\include\winnt.h(419) : see declaration of 'PCCH'
epan/dissectors/packet-rlc.c(113) : error C2086: 'channel_type PCCH' :
redefinition
epan/dissectors
"Guy Harris" wrote:
Is there an MSVC tool to look find out what DLLs an executable uses?
(I.e., the equivalent of, say, ldd on many systems using ELF, or otool on Mac OS X.)
cygcheck from the CygWin package. Running it on AthTek's version of wireshark
reveals this.
G:\internet\sniffer\AthTe
When right after statup and before I choose any interface, I get a crash
when I enter the "Statistics | Packet Lengths.." menu. From WinDbg:
wireshark!gtk_stats_tree_cb(struct _GtkAction * action = 0x63a57e95, void *
user_data = 0x03fb63f0)+0x44
WARNING: Stack unwind information not available. F
The header-guard '_STAT_H_' in epan/stat_cmd_args.h clashes with the
header-guard in MingW's . Hence the protype for
'register_stat_cmd_arg()' isn't seen when is included first.
Would you please rename the guard like this:
--- epan\stat_cmd_args.hTue Jun 24 06:44:59 2008
+++ SVN-Latest\e
Building w/o HAVE_PCAP_REMOTE or HAVE_PCAP_SETSAMPLING, I
got this error from MSVC:
file_dlg_win32.c
G:\MingW32\src\inet\Wireshark\gtk\capture_dlg.h(58) : error C2016: C
requires that a struct or union has at least one member
Can be solved by adding a dummy value:
--- SVN-Latest\gtk\captur
"Guy Harris" wrote:
and pressing the "Follow stream" button,
It let you press "Follow stream"? I did a capture on the loopback interface, and got
a window with no conversations, and the "Follow stream" button was grayed out.
Not greyed out here. No idea why. It should.
--gv
___
While clicking inside the "Statistics | Conversations" window (blank window btw)
and pressing the "Follow stream" button, I got a crash. From WinDbg (my JIT
debugger):
wireshark!follow_stream_cb(struct _GtkWidget * follow_stream_bt = 0x63a57e95,
void * data = 0x046533f0)+0x1c
WARNING: Stack unw
Here is another patch for a missing WINAPI:
--- SVN-Latest\wsutil\file_util.c Mon Jul 18 21:40:32 2011
+++ wsutil\file_util.c Wed Aug 17 21:36:27 2011
@@ -487,10 +487,11 @@
gboolean dll_dir_set = FALSE;
wchar_t *program_path_w;
- typedef BOOL (*SetDllDirectoryHandler)(LPC
init_process_policies() has this:
typedef BOOL (*SetProcessDEPPolicyHandler)(DWORD);
Surely the function must be WINAPI? According to:
http://msdn.microsoft.com/en-us/library/bb736299(v=vs.85).aspx
anyway. So, here is a patch. Besides I've rewritten the assignment and if-test:
--- SVN-Latest\
On Tue, Aug 16, 2011 at 08:05:29PM +0200, Gisle Vanem wrote:
> So it seems Mailman doesn't care so much about the address, but rather my
> name.
> Anyone can subscribe and claim to be me. Doesn't sound correct.
And anyone can change his name to 'Gisle Vanem', welc
"Stig Bjørlykke" wrote:
On Tue, Aug 16, 2011 at 12:17 AM, Gisle Vanem wrote:
This:
#ifdef _MSC_VER
#define localtime_r(a, b) memcpy((b), localtime((a)), sizeof(struct tm));
#endif
doesn't look so safe. We should maybe use the localtime_r() in
wsutil/strptime.c?
Or
This:
#ifdef _MSC_VER
#define localtime_r(a, b) memcpy((b), localtime((a)), sizeof(struct tm));
#endif
doesn't look so safe. We should maybe use the localtime_r() in
wsutil/strptime.c?
--gv
___
Sent via:Wireshark-dev
"Helge Kruse" wrote:
Why do you try to compile at all when you only need the import library?
It's generated with a one-liner:
link /dll /out:libwireshark.dll /def:libwireshark.def /implib:libwireshark.lib
>nul
Does it? Where are the .obj files in this command?
--gv
I cannot see that 'gtk/text_import_scanner_lex.h' is of any
use anymore. Hence we should remote it from gtk/Makefile.common:
--- SVN-Latest/gtk/Makefile.common Tue Mar 22 13:41:14 2011
+++ gtk/Makefile.common Wed Apr 06 13:34:58 2011
@@ -24,8 +24,7 @@
# Foundation, Inc., 59 Temple Place - Su
I have a request for a UI-feature. I many Windows programs the combination
of pressing 'left Ctrl'-key while using the mouse scroll-wheel, the text in the
main window is zoomed out (scroll-wheel backward) or zoomed in (scroll-wheel
forward). Since Wireshark already has a zoom feature, could this f
I'm not very happy about all the #ifdef-ing in capture_if_details_dlg_win32.c.
Isn't it possible to do away with those by using unique names for possibly
missing constants and typedefs (structs and enums)? Like:
typedef unsigned short ws_eth_sa_family_t;
...
struct ws_sockaddr_storage {
ws_e
"Bill Meier" wrote:
> Without knowing the code, but given that print_update_dynamic() appears
> to be only used in file_dlg_win32.c I'd be inclined to remove the
> declaration from the .h file
>
> Any reason not to ?
That would be the best, sure.
--gv
print_update_dynamic() isn't defined 'static' in file_dlg_win32.h.
Hence:
--- gtk\file_dlg_win32.cSun Nov 21 04:04:45 2010
+++ gtk\file_dlg_win32.c Mon Nov 22 13:54:53 2010
@@ -886,7 +886,7 @@
print_update_dynamic(dlg_hwnd, args);
}
-static void
+void
print_update_dynamic(HWND
> Can anybody verify the attached live capure I did just now?
> All the frames in the capture seems to have wrong Frame Check Sequence
> numbers.
False alarm or not, but all captures seems to be okay now.
--gv
___
Sent via:
"Gianluca Varenni" wrote:
> They definitely look like junk... did the capture contain *only* such
> errored frames?
> Which AirPcap adapter are you using (Classic, Tx, Ex, Nx)?
I only captured for 3-4 minutes using AirPcap 4.0 Classic.
(the one you kindly gave me).
--gv
___
Can anybody verify the attached live capure I did just now?
All the frames in the capture seems to have wrong Frame Check Sequence
numbers. The capture was done with latest AirPcap on a Win-XP SP3 box running
the latest svn version of WireShark. Also verified with tshark.
--gv
ethera04084
I have problems with plugins\easy_codec\codec*.c.
E.g. codec-g722.c fails to compile with gcc 3.4.5 (MingW)
because of:
struct g722_context {
CODER_HANDLE handle;
short speach_buffer[L_G722_FRAME];
};
void *codec_g722_init(void) {
g722_context *ctx = 0;
---
The struct shoul
"Kukosa, Tomas" <[EMAIL PROTECTED]> wrote:
> Based on gcc usage it seems you use any non-Windows platform as gcc is
> not supported for Wireshark build on Windows.
> But from __attribute__((dllexport)) it seems you use Windows platform.
I use MingW/gcc which has worked fine for a long time. I'm
b
This plugin requires a C++ compiler because the ImTelephone folks
built the libs using a C++ compiler. How stupid is that? But then
"gcc -x c++" bails out with an error:
plugins/easy_codec/easy_codec_plugin.c:38: error: external linkage required for
symbol 'version' be cause of 'dllexport' attri
"Guy Harris" <[EMAIL PROTECTED]> wrote:
> Does "svn status" report any conflicts (lines beginning with "C")?
No.
--gv
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev
"Jeff Morriss" <[EMAIL PROTECTED]> wrote:
> Also eth_stdio_fopen() needs to be exported from the dll because some
> plugins use it now.
Let me see if I understand you; you mean eth_stdio_fopen() should
be exported from _libwireshark.dll_? eth_stdio_fopen() is already exported
from wiretap*.dll.
"Guy Harris" <[EMAIL PROTECTED]> wrote:
> If the first somebody was you, then "svn update" (or its GUI equivalent)
> should have reported the conflict. The "<<< .mine" lines aren't in
> the current version in SVN, so I suspect it's reporting a conflict
> between changes you made and change
What does the lines like "<<< .mine" do in this file?
Besides eth_stdio_fopen() shall not be exported from libwireshark.dll.
A patch:
--- SVN-Latest\epan\libwireshark.defWed Oct 31 17:03:44 2007
+++ epan\libwireshark.def Wed Oct 31 17:31:01 2007
@@ -221,17 +221,10 @@
dissect_per_sequenc
must be included because of eth_fopen():
--- SVN-Latest\epan\dissectors\packet-isakmp.c Tue Oct 23 14:29:00 2007
+++ epan\dissectors\packet-isakmp.c Thu Oct 25 14:21:56 2007
@@ -66,6 +66,7 @@
#include
#include
#include
+#include
#define isakmp_min(a, b) ((ahttp://www.wireshark.org/
Some signals needs to be ifdef'ed (missing on VC/MingW):
--- SVN-Latest/trigcap.cSat Jul 28 15:44:35 2007
+++ trigcap.c Wed Aug 22 14:42:30 2007
@@ -249,9 +249,15 @@
dprintf(2,"opened dumper file '%s'\n",outfile);
signal(SIGINT, sig_int);
+#ifdef SIGQUIT
signal(S
This file fails to compile with the latest libpcap since
pcap_compile() now takes a 'const char *' as the filter-string.
AFAICS an easy fix is to use WPCAP_CONSTIFIED. Patch attached.
--gv
--- SVN-Latest/capture-wpcap.c Mon Jan 22 23:20:35 2007
+++ capture-wpcap.c Sat Jul 28 16:34:35 2007
@
In file included from epan/dissectors/packet-ieee80211.c:84:
./airpcap_loader.h:84: error: syntax error before "AirpcapChannelInfo"
./airpcap_loader.h:85: error: syntax error before "PAirpcapChannelInfo"
./airpcap_loader.h:86: error: syntax error before "AirpcapChannelInfo"
./airpcap_loader.h:110:
In file included from epan/dissectors/packet-ieee80211.c:84:
./airpcap_loader.h:84: error: syntax error before "AirpcapChannelInfo"
./airpcap_loader.h:85: error: syntax error before "PAirpcapChannelInfo"
./airpcap_loader.h:86: error: syntax error before "AirpcapChannelInfo"
./airpcap_loader.h:110:
A small typo in a filename; replace 'umts_rrc_PDU_definitions.asn'
with 'umts_rrc_PDU-definitions.asn'. Attached.
--gv
--- SVN-Latest\asn1\umts_rrc_pdu_def\Makefile Sun Oct 01 18:18:19 2006
+++ asn1\umts_rrc_pdu_def\Makefile Tue Apr 17 20:45:02 2007
@@ -6,8 +6,8 @@
generate_dissector: $(
I tried adding this file to the build of libwireshark.dll, but got an
assert in epan/packet.c at line 674 (sub_dissectors == NULL).
I know this dissector isn't in any makefile, but I'd like to try it anyway.
Should this file be removed from svn until fixed? Or fixed
before the next release? I'm n
I know this dissector isn't in any makefile, but I'd like to try it anyway.
I added the file to the build of libwireshark.dll, but got an assert in
epan/packet.c at line 674 (sub_dissectors == NULL).
Should this file be removed from svn until fixed? Or fixed
before the next release? I'm not in th
"Ulf Lamping" <[EMAIL PROTECTED]> wrote:
> If you still have such problems, please note.
There's still some in generated files. It seems someone added the pragmas after
they where autogenerated. IMHO the #pragma should go elsewhere. But
where, should be left to the experts.
A patch for now:
di
The #ifdef's in capture_wpcap_packet.c and gtk/capture_if_details_dlg.c
assumes that only MSVC is used to build on Win32. MingW works just
fine.
MingW defines WINVER == 0x400, but it does have sockaddr_storage.
Why can't the structure be moved to a common .h-file? (to keep the
.c-files more clea
"Graham Bloice" <[EMAIL PROTECTED]> wrote:
> Gisle Vanem wrote:
>> The "#pragma warning()" statements are MSVC specific. So
>> embed them inside "#ifdef _MSC_VER".
>>
>
> I always thought unrecognised #pragma directives were ign
The "#pragma warning()" statements are MSVC specific. So
embed them inside "#ifdef _MSC_VER".
Patch attached.
--gv
diff -u3 -Hb -r SVN-Latest\asn1\rrlp\packet-rrlp-template.c
.\asn1\rrlp\packet-rrlp-template.c
--- SVN-Latest\asn1\rrlp\packet-rrlp-template.c Tue Mar 27 17:18:46 2007
+++ .\asn1\
The #ifdef's in capture_wpcap_packet.c and gtk/capture_if_details_dlg.c
assumes that only MSVC is used to build on Win32. MingW works just
fine.
MingW defines WINVER == 0x400, but it does have sockaddr_storage.
Why can't the structure be moved to a common .h-file? (to keep the
.c-files more clea
The file epan/dissectors/packet-k12.c uses the function
strcasestr() which is not available on e.g. Windows. So I cooked
up a patch to epan/strutil.c to add epan_strcasestr() (is there a more
suited place for such a function?)
Attached in diffs-3.txt
--gv
--- SVN-Latest\epan\strutil.c Mon F
The file epan/dissectors/packet-k12.c uses the function
strcasestr() which is not available on e.g. Windows. So I cooked
up a patch to epan/strutil.c to add epan_strcasestr() (is there a more
suited place for such a function?)
Attached in diffs-3.txt
--gv
--- SVN-Latest\epan\strutil.c Mon F
A case of conflict in definition and implementation:
--- SVN-Latest\airpcap_loader.h Mon Jan 22 22:20:27 2007
+++ airpcap_loader.hMon Jan 22 22:37:08 2007
@@ -309,7 +309,7 @@
* Will return null if no device is found.
*/
GList*
-get_airpcap_interface_list(int *err, char *err_str);
+get_airpc
"Stephen Fisher" <[EMAIL PROTECTED]> wrote:
>> Some missing exports (needed by airpdcap*.c):
>
> Are these missing exports causing compilation to fail?
Yes, it causes linking of programs that used libwireshark.lib
(via ENABLE_LIBWIRESHARK) to fail due to said symbols
used by airpdcap*.c.
--gv
_
"Sake Blok" <[EMAIL PROTECTED]> wrote:
> Looks like your mailserver is messing things up. In the attached rawmessage
> there is a line:
> X-MIME-Autoconverted: from base64 to 8bit by bryggen.bgnett.no id
> =l0GCELid030303
> When I look at the same message in my mailbox, it is still base64encoded
1 - 100 of 107 matches
Mail list logo
