I'm trying to re-building the standard Ubuntu wireshark package 3.2.3-1 from
focal installed under WSL from the MS store.
First issue was the lack of SYSV_IPC, so default fakeroot builds don't work,
but switching to faked tcp as a build option works: "debuild -b -uc -us
-r'fakeroot --faked fake
That was the intent: packet-rtp.[ch] already had the following added ready for
this approach a long time back:
struct srtp_info
{
guint encryption_algorithm; /* at present only NULL vs
non-NULL matter */
guint auth_algorithm;
Does the license only apply to those to whom the binary has been distributed
to? If the plugin is never publicly released, does the license imply that
only the receivers of the plugin are required to be sent the source code?
If the plugin is never seen by the public eye, does that imply that the
> > The WS_DLL_EXPORT mechanism
>
> Presumably you mean WS_DLL_PUBLIC?
[NPP>] Sorry, yes.
> > seems to only actually export the symbols in libwireshark.dll from files (in
> epan/dissectors) that contain registered protocols: files which contain pure
> helper functions (to share amongst several pl
The WS_DLL_EXPORT mechanism seems to only actually export the symbols in
libwireshark.dll from files (in epan/dissectors) that contain registered
protocols: files which contain pure helper functions (to share amongst several
plugins) do not get those functions exported (but they are in the .lib)
> Anders Broman skrev 2011-10-07 18:10:
> > Mike Morrin skrev 2011-10-07 17:48:
> >>
> >> I think that it should be a bit more flexible:
> >> * Have conversations per protocol, with 1 or more identifier keys.
> >> * When a new identifier is observed, if it can be associated with an
> >> existing co
From: wireshark-dev-boun...@wireshark.org [mailto:wireshark-dev-
> boun...@wireshark.org] On Behalf Of Neil Piercy
> Sent: den 22 mars 2010 19:31
> To: Developer support list for Wireshark
> Subject: [Wireshark-dev] ASN.1 bit string alignment
>
> In 1.0.x PER ASN.1 bit strings used t
In 1.0.x PER ASN.1 bit strings used to be padded in the MSBs, (e.g.
extract from an RRC message):
dl-HFN: 0004 [bit length 25]
Since 1.2.x they appear to be padded in the LSBs (e.g. the same
extract):
dl-HFN: 0200 [bit length 25]
The value carried in both cases above is meant to be 4.
ug number ?
>
> Thanks,
> Munish
>
> -Original Message-
>
> Message: 5
> Date: Fri, 28 Aug 2009 18:20:28 +0100
> From: "Neil Piercy"
> Subject: Re: [Wireshark-dev] Need help in Decoding RTP Multiplex
> streams inWireshark
> To: "
Hi,
ip.access have developed a basic dissector for this protocol which we
will happily add to the project - I'll raise a bug report and attach the
file.
At present it only handles the uncompressed RTP header case, but should
provide a starting point for further development.
BTW we have called
> -Original Message-
> From: [EMAIL PROTECTED]
> > --- Comment #4 from Neil Piercy <[EMAIL PROTECTED]>
> 2008-09-11
> > 01:52:04 PDT --- It is 2.59 - I'll get it upgraded and retest.
>
> Does this mean that we now require autoconf 2.60 or newe
Folks,
I'm trying to understand the best way of handling endpoint contexts between
protocol layers in Wireshark - e.g. for conversation tracking where the
conversation is not just the TCP/UDP address/port pairs. The prompt for this
is a bug report I've filed on GPRS SNDCP reassembly. Basically one
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Guy Harris
>
> On Aug 5, 2008, at 7:23 AM, Vinod M wrote:
>
> > "Optionally, the BYE packet MAY include an 8-bit octet
> count followed
> > by that many octets of text indicating the reason for
>
It should be - see wireshark-1.0.0\asn1\rrc\rrc.cnf
Neil
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of praveen.jha
Sent: 16 May 2008 09:52
To: Wireshark-dev@wireshark.org
Subject: [Wireshark-dev] dissection of NA
I know this might be a strange thing to do, but...
I'm trying to get one plugin to use external symbols from another
plugin, and it _almost_ works:
- windows build easy - manual Makefile.nmake hacks easy
- linux build slightly harder due to my lack of understanding of
automake, but now works
- rpm
That was enough of a hint - thanks. Bug 2192 and patch for review
submitted.
Regards, Neil
PS Did you know MSVC6 cannot set breakpoints beyond line 64k of a file -
and packet-rrc.c is a _lot_ bigger (but MSVC6 actually points you back
to rrc.cnf correctly anyway, but...)
__
I'm looking at the same issue for my company and came to similar
conclusion. At present we've gone down the route of (c) for a quick try,
but I think it will soon be coming unstuck - it certainly isn't general
enough to feed back yet. We haven't yet got any MAC/RLC dissection, but
would be happy t
> -Original Message-
> [mailto:[EMAIL PROTECTED] On Behalf Of
> ronnie sahlberg
> Not tested!
> grab the hfinfo structure and modify the fields at runtime :
>
> header_field_info *hfinfo;
>
> hfinfo = proto_registrar_get_nth(hf_index);
> hfinfo->bitmask = new bitmask
> hfinfo->bitshi
> -Original Message-
> >>I know there is per-packet info, but is there a way of
> >>adding/retrieving per PDU info which copes with multiple PDUs in a
> >>packet ? How does a dissector even know if it is handfling
> the first,
> >>second etc PDU in a packet ?
> >
> > This has been requ
And another "Is there question"...
I know there is per-packet info, but is there a way of adding/retrieving
per PDU info which copes with multiple PDUs in a packet ? How does a
dissector even know if it is handfling the first, second etc PDU in a
packet ?
Neil
If the protocol has bitfields they can be defined in the hf structs, but
what is the best way to cope if these fields can be at different bit
offsets within the byte ? E.g. a 4 bit field which can occur as the
lower 4 bits or the upper 4 bits of a byte.
The more I think about it, the general way w
Hi,
I have written a dissector for our company's version of A-bis, which is
heavily standards based but includes a fair number of extensions too.
This is currently a private dissector, but I could probably do a very
quick cut-out of the ip.access specific aspects and release the rest if
that woul
IMHO the gsm_a is really about four protocol dissectors which are too
inter-mixed in the one huge file, and should really all be in separate
files and with "proper" wireshark linkage between them. The clue is in
the name: it contais the set of protocols carried over the A interface,
not one protoco
> -Original Message-
> What about having an option to "flatten the tree" to search
> all the protocols, sorted alphabetically, like today?
>
> Or even a "filter" box to search the list?
Or a group "All" which has all protocol preferences, some/all of which
can be accessed via groups t
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of Luis Ontanon
> What about heuristics?
> is there some sort of magic we can use to determine if it is SRTP?
> is there a checksum or similar info we can check?
The trouble with SRTP is basically a w
Attached is a patch which adds display of DLR, SLR and Cause values to
Column info for SCCP messages which our engineers have found useful. I think
it might be worth adding to the code base unless anyone objects.
There are also a couple of trivial robustness changes to better handle the
case when
Attached are patches which provide a basic dissection of Secure RTP/RTCP
profile:
- display of the fields used in the SRTP & SRTCP payloads
- deliberate prevention of the normal dissection of the encrypted payloads
- addition of a callable interface to add SRTP (rather than RTP) streams
from sig
Or is http://anonsvn.wireshark.org/wireshark/trunk-0.99.5/ the replacement ?
Regards,
Neil
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev
I've had a build failure under Windows since the move to glib 2.12.6, which I
traced to a setup problem: the unzip of the packages in tools/win32-setup.sh
uses "unzip -nq" - the -n prevents it updating existing files at all, ending up
with a mix of original package and new package for those pack
I had the same issue and forgot to submit it: the win32-setup.sh (and
IIRC one of the other scripts in the top level - make-manuf perhaps?)
had been converted to DOS line endings and bash doesnt like it (even
under Windoes)
Neil
Robert Trybis wrote:
> I am trying to work my way through the Dev
Hi,
Ulf Lamping wrote:
> Yes, the current cygwin python binding has some problems, I've installed
> it and compile without your changes! I just don't really understand why???
No, I am totally confused as to what triggers the issue: I had a working
build environment on one PC with Windows Python
Any chance of getting this patch applied ? I've updated the patch in
bugzilla (#1157, not the typo'ed number below) to the latest SVN.
Neil
Neil Piercy wrote:
> I finally got round to raising bug #1175 and adding the proposed patch.
>
> Thanks,
> Neil
>
> Joerg Ma
I finally got round to raising bug #1175 and adding the proposed patch.
Thanks,
Neil
Joerg Mayer wrote:
> On Fri, Sep 08, 2006 at 10:24:24AM +0100, Neil Piercy wrote:
>> I submitted this a few days ago, but it hasn't made it to the SVN as far
>> as I can see - is there a pr
I submitted this a few days ago, but it hasn't made it to the SVN as far
as I can see - is there a problem with it (I can believe that ;-), or
did it just overflow the stack ?
Neil
Index: asn1/rrlp/Makefile.nmake
===
--- asn1/rrlp/
This issue bubbled around in mid July, but I forgot to submit a patch -
here is a patch which changes the native Windows PYTHON lines from using
"/" to "\" as directory separators - I _think_ I've got all the makefiles...
Neil
Index: asn1/rrlp/Makefile.nmake
Quoting Ulf Lamping <[EMAIL PROTECTED]>:
> Of course this bug should be fixed and I guess you got the right place
> for the bugzilla entry (Tor Lillquist may respond in a few days).
>
> BTW: Did you noticed my comment at "our" bugzilla entry?
I have now ;-)
Actually, although the patch I suggest
---Ursprungligt meddelande-
> Från: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] För Neil Piercy
> Skickat: den 10 augusti 2006 20:01
> Till: Joerg Mayer
> Kopia: Developer support list for Wireshark
> Ämne: Re: [Wireshark-dev] Ideas regarding bug 1025?
>
> Joerg Mayer wrot
Joerg Mayer wrote:
> OK, I've created a small testprogram (under Suse 10.1) which you should
> compile as similar as possible to the way you compile Wireshark. Let's
> see whether it crashes and if so, where. I hope the program doesn't much
> tweaking to compile on W32.
Worse than you feared: it c
I've just had a bug in one of our private dissectors which meant that
the handle passed to call_dissector was null. This seemed to give
varying behavior - on some Windows installations it hit wireshark's
in-built exception handling, and displayed that the dissector had an
error (correct), but o
like it
went into the guts of the core gnulib/vasnprintf, where it hit an abort
call. Without the debug lib it is difficult to see where or why.
Bottom line: looks to me like a glib bug or a build incompatibility
between guint64 handling in the glib binary and ethereal perhaps?
Neil
Neil
Hi,
The head of the stack just before the exception is given below.
The actual error is in proto_tree_set_representation at the call:
g_vsnprintf(fi->rep->representation, ITEM_LABEL_LENGTH, format, ap);
The format has a single %I64x value needed.
The entry to the routine throws an MSVC
Hi,
I follow what has been done to the SVN fine, but I'm still confused
about what is intended in the future for the separate trunks:
Will a new trunk be produced for every release ?
If so, do they represent a snapshot which is then left frozen ? If not
frozen, what is the intended maintenance
Cook, Timothy wrote:
> Using OS: Win XP SP2 Dev Env: MS VC 6 & CYGWIN
Out of interest, are you using Windows Python 2.4 ? I reported the same
when I moved to 2.4 (but the "official" Windows native (i.e. non-cygwin)
Python for wireshark is still 2.3) ?
> I have been able to continue building b
Just to add dissector name registration to the main IETF AMR dissector.
Neil
Index: packet-amr.c
===
--- packet-amr.c(revision 18574)
+++ packet-amr.c(working copy)
@@ -457,6 +457,7 @@
"Type of AMR encoding of
Attached is a packet which used to crash wireshark due to passing a null
pointer string to a format in proto_tree_add_uint_format due to an
undissected Message Id.
The patch avoids the crash for unknown messages, adds the Common Id
message dissection which caused it, and also add dissector nam
45 matches
Mail list logo
