from:"Neil Piercy"

[Wireshark-dev] Building under Ubuntu on WSL

2020-05-01 Thread Neil Piercy

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 faked-tcp'

The second issue was  https://github.com/Microsoft/WSL/issues/3023, but the 
workaround worked: "strip --remove-section=.note.ABI-tag 
/usr/lib/x86_64-linux-gnu/libQt5Core.so.5.12.8 ."

That gets all the way to the packaging which is failing in a very strange way:
dpkg-gencontrol: error: install new files list file: No such file or directory

Turning on the verbose build flags gives some invocations of dpkg-gencontrol 
work and some fail, and re-running, it looks like _different_ package 
invocations succeed and fail on every build run. Using --no-parallel didn't 
change behaviour, but it also didn't seem to propagate to the dh_gencontrol 
except to remove the --parallel option (it didn't add --no-parallel, and the 
dh_gencontrol still seems to be by default --parallel)), but even using an 
override rule with -no-parallel didn't seem to actually make it non parallel. 
Sample logs (grep'ed with "gencontrol" and the long lines truncated) below.

Anyone tried building on WSL or seen anything similar? I'm beginning to suspect 
a WSL FS issue, but that is just a guess right now.

Regards,
Neil

*** Default rules + Debug/verbose:
   dh_gencontrol -O--buildsystem=cmake -O--parallel
dpkg-gencontrol -pwireshark-doc -ldebian/changelog 
-Tdebian/wireshark-doc.substvars -Pdebian/wiresh
dpkg-gencontrol -plibwireshark-data -ldebian/changelog 
-Tdebian/libwireshark-data.substvars -Pdebia
dpkg-gencontrol -pwireshark-common -ldebian/changelog 
-Tdebian/wireshark-common.substvars -Pdebian/
dpkg-gencontrol -pwireshark-qt -ldebian/changelog 
-Tdebian/wireshark-qt.substvars -Pdebian/.debhelp
dpkg-gencontrol -ptshark -ldebian/changelog -Tdebian/tshark.substvars 
-Pdebian/.debhelper/tshark/db
dpkg-gencontrol -plibwsutil11 -ldebian/changelog 
-Tdebian/libwsutil11.substvars -Pdebian/.debhelper
dpkg-gencontrol -plibwiretap10 -ldebian/changelog 
-Tdebian/libwiretap10.substvars -Pdebian/.debhelp
dpkg-gencontrol -plibwireshark-dev -ldebian/changelog 
-Tdebian/libwireshark-dev.substvars -Pdebian/
dpkg-gencontrol: error: install new files list file: No such file or directory
dpkg-gencontrol: error: install new files list file: No such file or directory
dh_gencontrol: error: dpkg-gencontrol -pwireshark-common -ldebian/changelog 
-Tdebian/wireshark-commo
dh_gencontrol: error: dpkg-gencontrol -ptshark -ldebian/changelog 
-Tdebian/tshark.substvars -Pdebian
dpkg-gencontrol -pwireshark-qt -ldebian/changelog 
-Tdebian/wireshark-qt.substvars -Pdebian/wireshar
dpkg-gencontrol -plibwsutil11 -ldebian/changelog 
-Tdebian/libwsutil11.substvars -Pdebian/libwsutil1
dpkg-gencontrol -plibwireshark13 -ldebian/changelog 
-Tdebian/libwireshark13.substvars -Pdebian/.deb
dpkg-gencontrol -plibwiretap10 -ldebian/changelog 
-Tdebian/libwiretap10.substvars -Pdebian/libwiret
dpkg-gencontrol -pwireshark-gtk -ldebian/changelog 
-Tdebian/wireshark-gtk.substvars -Pdebian/wiresh
dpkg-gencontrol: error: install new files list file: No such file or directory
dpkg-gencontrol -plibwireshark13 -ldebian/changelog 
-Tdebian/libwireshark13.substvars -Pdebian/libw
dh_gencontrol: error: dpkg-gencontrol -plibwireshark-dev -ldebian/changelog 
-Tdebian/libwireshark-de
dpkg-gencontrol -plibwsutil-dev -ldebian/changelog 
-Tdebian/libwsutil-dev.substvars -Pdebian/libwsu
dpkg-gencontrol -plibwiretap-dev -ldebian/changelog 
-Tdebian/libwiretap-dev.substvars -Pdebian/libw
dh_gencontrol: error: Aborting due to earlier error


*** Default rules + Debug/verbose- -O--parallel:
   dh_gencontrol -O--buildsystem=cmake
dpkg-gencontrol -pwireshark-doc -ldebian/changelog 
-Tdebian/wireshark-doc.substvars -Pdebian/wiresh
dpkg-gencontrol -plibwireshark-data -ldebian/changelog 
-Tdebian/libwireshark-data.substvars -Pdebia
dpkg-gencontrol -pwireshark-common -ldebian/changelog 
-Tdebian/wireshark-common.substvars -Pdebian/
dpkg-gencontrol -pwireshark-qt -ldebian/changelog 
-Tdebian/wireshark-qt.substvars -Pdebian/.debhelp
dpkg-gencontrol -ptshark -ldebian/changelog -Tdebian/tshark.substvars 
-Pdebian/.debhelper/tshark/db
dpkg-gencontrol -plibwsutil11 -ldebian/changelog 
-Tdebian/libwsutil11.substvars -Pdebian/.debhelper
dpkg-gencontrol -plibwiretap10 -ldebian/changelog 
-Tdebian/libwiretap10.substvars -Pdebian/.debhelp
dpkg-gencontrol -plibwireshark-dev -ldebian/changelog 
-Tdebian/libwireshark-dev.substvars -Pdebian/
dpkg-gencontrol: error: install new files list file: No such file or directory
dh_gencontrol: error: dpkg-gencontrol -ptshark -ldebian/changelog 
-Tdebian/tshark.substvars -Pdebian
dpkg-gencontrol:

Re: [Wireshark-dev] [!!Mass Mail]Re: "Wireshark-dev: Re: using pinfo structure to save data after first iteration"

2015-06-30 Thread Neil Piercy

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;   /* at 
present only NULL vs non-NULL matter */
guint  mki_len; 
 /* number of octets used for the MKI in the RTP payload */
guint  auth_tag_len;   /* 
number of octets used for the Auth Tag in the RTP payload */
#if 0   /* these are only needed once the dissector include the crypto 
functions to decrypt and/or authenticate */
struct srtp_key_info **master_keys; /* an array of pointers to master keys 
and their info, the array and each key struct being wmem_file_scope'ed  */
void   *enc_alg_info,  /* 
algorithm-dependent info struct - may be void for default alg with default 
params */
void   *auth_alg_info /* 
algorithm-dependent info struct - void for default alg with default params */
#endif
};

/* Add an SRTP conversation with the given details */
WS_DLL_PUBLIC
void srtp_add_address(packet_info *pinfo,
 address *addr, int port,
 int other_port,
 const gchar *setup_method,
 guint32 setup_frame_number,

gboolean is_video,
 rtp_dyn_payload_t *rtp_dyn_payload,
 struct srtp_info *srtp_info);

There are small differences in packet-rtp handling when SRTP is used, but those 
differences are easy to handle inline.

Regards,
Neil

From: wireshark-dev-boun...@wireshark.org 
[mailto:wireshark-dev-boun...@wireshark.org] On Behalf Of Anders Broman
Sent: 30 June 2015 11:41
To: Developer support list for Wireshark
Subject: [!!Mass Mail]Re: [Wireshark-dev] "Wireshark-dev: Re: using pinfo 
structure to save data after first iteration"

Hi,
Isn’t a SRTP packet in essence an RTP packet with encrypted payload? So I don’t 
see why it should be a problem to process the packet in packet-rtp.c
On the first pass.

Tip p_get_proto_data() can be used for per packet data. Are you using the 
development version as there seems to be some basic stuff for SRTP already in 
the dissector.
Regards
Anders

From: 
wireshark-dev-boun...@wireshark.org 
[mailto:wireshark-dev-boun...@wireshark.org] On Behalf Of koundinya poluri
Sent: den 30 juni 2015 11:28
To: wireshark-dev
Subject: [Wireshark-dev] "Wireshark-dev: Re: using pinfo structure to save data 
after first iteration"

Hi, Anders,

I had a similar idea on how it should be done.I wanted to save some srtp 
related data once you processs the packets first time like creating a context 
which carries the ssrc and keys so that it can relate the packets to keys using 
the ssrc.But unfortunately wireshark cant differentiate between a rtp packet 
and srtp packet so it just processes the srtp packet as an rtp packet and 
changes the visited flag to one.

So cant use that flag which is generally used to differentiate the first 
iteration from the next ones.So i tried to put my own flag in the pinfo 
structure and modify it,but that did not work, as it looks like pinfo structure 
is a READ ONLY structure from a dissector's point of view.So how do I 
differentiate between iterations??

Is my understanding correct ?If so what is the solution to my problem?Thanks!

Also I am using UAT for entering keys!

-koundinya
___
Sent via:Wireshark-dev mailing list 
Archives:https://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] [!!Mass Mail]Re: What Wireshark base version to use for customization

2014-12-12 Thread Neil Piercy



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
source code may stay private as well?


[NPP>] IANAL, but I believe that if you ship a modified binary to a third 
party, you must ship it and the source code (or a promise to make the source 
code available) under the same GPL license terms as the original. You cannot 
oblige the third party in any other way from using that code except for the 
GPL. That means you cannot control whether the third party chooses to keep both 
the source and binary private, or whether they choose to make both public – 
that becomes their decision, not yours. Further of course the third party can 
only pass the software on under the same GPL terms, including the source.

Neil
___
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] WS_DLL_PUBLIC only works for files with registered protocols

2013-05-03 Thread Neil Piercy

> > 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 plugins) do not get those
> functions exported (but they are in the .lib).
> 
> Do the header files declaring only pure helper functions include
> "ws_symbol_export.h"?
[NPP>] Yes - but even with that the symbols did not show in the DLL (but were 
global in the .lib). Adding a (dummy) register function to the file and moving 
it to the registered dissector files part of the makefile made the symbols show 
up (both steps were needed). Very strange: I certainly don't understand why.

Neil





This message contains confidential information and may be privileged. If you 
are not the intended recipient, please notify the sender and delete the message 
immediately.

ip.access Ltd, registration number 3400157, Building 2020, 
Cambourne Business Park, Cambourne, Cambridge CB23 6DW, United Kingdom
___
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] WS_DLL_PUBLIC only works for files with registered protocols

2013-05-02 Thread Neil Piercy

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). Is the 
correct answer that these files should be somewhere else in the directory 
structure?

This is using MSVC2010EE in Win7, and these files are (for now at least) 
private.

Neil





This message contains confidential information and may be privileged. If you 
are not the intended recipient, please notify the sender and delete the message 
immediately.

ip.access Ltd, registration number 3400157, Building 2020, 
Cambourne Business Park, Cambourne, Cambridge CB23 6DW, United Kingdom


___
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] Global conversation

2011-10-10 Thread Neil Piercy

> 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 conversation which was created with a different key, then
> >> add the new key to the existing conversation, otherwise create a new
> >> conversation with the new key.
> >> * Allow conversations to be associated with conversations in other
> >> protocols.  The set of associated conversations becomes the global
> >> conversation, but is flexible in terms of the sequence of build-up of
> >> supporting protocols.
> >> * A dissector can use a protocol/key pair to find a potentially
> >> associated conversion already existing in another protocol.
> >> * A dissector can access the set of keys for any protocol in an
> >> associated conversation

> How about something like
> 
>   * proto_conv_new(proto ,key(s))
>   Check if global/top/main conversation exist by matching the key with
> other protocols using that key.
>   ( string key looking in a (hash)table of strings finding list of 
> proto_conv ?)
>  if not create it and create the proto_conv.
> Return proto_conv and possible top_conv
> 
>   * proto_conv_add_key(proto, key(s));
> if a new key has turned up in the conversation look if there are matching
> proto_convs with a
> different top_conv if true join them.
> 
> I'm sure there are many pitfall here and with phone call as an example what
> if two consecutive calls are made how to differentiate between them.

Not sure that this as big a problem as it first seems: at some layer at least 
the protocol itself has this ambiguity, so it can provide an "end of 
conversation" explicitly - in fact I have previously thought this would be a 
good thing to add to the current conversations to distinguish re-use of 
identifiers in a new conversation.

> Another mater is performance and memory consumption.

One awkward relationship to consider is that conversations in different 
protocols at different layers have different multiplicity relationships with 
the conversations above and below them, e.g. a MAC layer conversation may have 
multiple RLC conversations carried over it (or specifically in 3G, an RRC 
connection can be associated with multiple RABs), and in some cases a high 
level "call" may be carried over several different bearers (e.g. in 3G SRBs and 
RABs associated with voice call). It would be really useful to be able to 
filter on this relationship at any level, so a filter on a conversation at a 
layer which includes a multiplexor may get multiple higher layer conversations 
included, and filtering on any one of these higher conversations excludes the 
other higher layer conversations, but still includes the lower layer multiplex 
conversation which carries it.

Perhaps you could consider "conversations" to be any such general relationship 
between endpoints, no matter how dynamic, e.g. in 3G TCP/IP/Ethernet terms, an 
Ethernet "conversation" can carry multiple IP conversations (and other protocol 
conversations), each of which can carry the TCP conversations, each of which 
may carry signalling for (typically more dynamic) higher layer conversations.

Or has this abstracted too far? If the above could be made to work in a general 
way, the current bloat of the packet info structure might be reduced, as it 
tends to get custom data to handle some of the specific relationships.

Neil





This message contains confidential information and may be privileged. If you 
are not the intended recipient, please notify the sender and delete the message 
immediately.

ip.access Ltd, registration number 3400157, Building 2020, 
Cambourne Business Park, Cambourne, Cambridge CB23 6DW, United Kingdom
___
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] ASN.1 bit string alignment

2010-03-29 Thread Neil Piercy

Looking at the changes in packet-per.c, it looks like the changes were
deliberate to remove leading pads and return a tvb which had trailing
bits padded - which sounds reasonable to me: I suspect the tvb
bit-offset code assumes no leading bit pads: correct?

If so, it becomes just a display problem.

Given that the bit string is of arbitrary length, and not necessarily
interpreted as an integer, how would we _want_ the example below to be
displayed?

I think the basic problem is the attempt to display a bit string in hex
- would it be better to display it in binary (if say <=32 bits) and have
its (unpadded) integer value (hex or dec?) included too if small enough
- e.g.

dl-HFN: 00100 (0x4) [bit length 25]

Neil

> -Original Message-
> From: wireshark-dev-boun...@wireshark.org [mailto:wireshark-dev-
> boun...@wireshark.org] On Behalf Of Anders Broman
> Sent: 26 March 2010 20:53
> To: Developer support list for Wireshark
> Subject: Re: [Wireshark-dev] ASN.1 bit string alignment
> 
> Looks like a bug, please make a bug report and attach a sample trace.
> Regards
> Anders
> 
> -Original Message-
> 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 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.
> 
> Is this a deliberate change?
> 
> I know bit strings are of arbitrary length, therefore a "natural"
> representation is challenging, but I find the above counter-intuitive.
> 
> Neil
> 
> 
> 
> 
> 
> This message contains confidential information and may be privileged.
> If you are not the intended recipient, please notify the sender and
> delete the message immediately.
> 
> ip.access Ltd, registration number 3400157, Building 2020, Cambourne
> Business Park, Cambourne, Cambridge CB23 6DW, United Kingdom
>
___
> 
> 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






This message contains confidential information and may be privileged. If you 
are not the intended recipient, please notify the sender and delete the message 
immediately.

ip.access Ltd, registration number 3400157, Building 2020, 
Cambourne Business Park, Cambourne, Cambridge CB23 6DW, United Kingdom
___
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] ASN.1 bit string alignment

2010-03-22 Thread Neil Piercy

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.

Is this a deliberate change?

I know bit strings are of arbitrary length, therefore a "natural"
representation is challenging, but I find the above counter-intuitive.

Neil





This message contains confidential information and may be privileged. If you 
are not the intended recipient, please notify the sender and delete the message 
immediately.

ip.access Ltd, registration number 3400157, Building 2020, 
Cambourne Business Park, Cambourne, Cambridge CB23 6DW, United Kingdom
___
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] Need help in Decoding RTP Multiplex streamsinWireshark

2009-09-04 Thread Neil Piercy

Hi Munish,

It was added to the SVN trunk under bug 3958.

Regards,
Neil

=
ip.access ltd   Tel: 01954 713715 
Building 2020,  Fax: 01954 713799 
Cambourne Business Park, 
Cambourne, 
Cambridge, CB23 6DW, UK 
Company Registered Number3400157 
Visit the website at http://www.ipaccess.com 
= 
 

> -Original Message-
> From: wireshark-dev-boun...@wireshark.org 
> [mailto:wireshark-dev-boun...@wireshark.org] On Behalf Of Munish Dayal
> Sent: 03 September 2009 13:38
> To: wireshark-dev@wireshark.org
> Subject: Re: [Wireshark-dev] Need help in Decoding RTP 
> Multiplex streamsinWireshark
> 
> 
> Hi,
> 
> Is this dissector code for "RTP multiplexed streams" 
> submitted to Wireshark ?
> What is the bug 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: "Developer support list for Wireshark"
> 
> Message-ID:
> 
> 
> Content-Type: text/plain; charset="us-ascii"
> 
> 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 the protocol nb_rtpmux, as the 29.414 spec 
> is originally for the Nb interface.
> 
> Regards,
> Neil
> 
> 
> =
> ip.access ltd   Tel: 01954 713715
> Building 2020,  Fax: 01954 713799
> Cambourne Business Park,
> Cambourne,
> Cambridge, CB23 6DW, UK
> Company Registered Number3400157
> Visit the website at http://www.ipaccess.com 
> <http://www.ipaccess.com/> 
> =
> 
> 
> 
> 
> 
> 
> 
> From: wireshark-dev-boun...@wireshark.org
> [mailto:wireshark-dev-boun...@wireshark.org] On Behalf Of shruti singh
> Sent: 27 August 2009 12:36
> To: Developer support list for Wireshark
> Subject: Re: [Wireshark-dev] Need help in Decoding 
> RTP Multiplex streams inWireshark
> 
> 
> Hi,
> 
> Yes RTP multiplexing is in compliance to 3GPP TS 
> 29.414 Release
> 7 specification
> 
> thanks
> Shruti
> 
> 
> On Wed, Aug 26, 2009 at 7:58 PM, Jaap Keuter 
>  wrote:
> 
> 
> Hi,
> 
> Is there an RFC on that? Are there sample 
> captures to work with? This always helpsin development.
> 
> Thanx,
> Jaap
> 
> Now competing at http://www.ec2009.info
> 
> On 26 aug 2009, at 07:36, shruti singh 
>  wrote:
> 
> 
> 
> Hi
> 
> I need to decode RTP Multiplex 
> streams using wireshark. Presently we can decode only Non 
> -Multiplexed RTP streams in wireshark.
> 
> 
> A multiplexed voice packet is 
> composed by concatenating RTP encapsulated voice packets and 
> IP and UDP headers.
> 
>  Below is the Multiplex Packet format
> 
> 
> 
> IP
> 
> UDP
> 
> Multiplex Header
> 
> Compressed RTP Header
> 
> RTP Payload
> 
> Multiplex Header
> 
> Compressed RTP Header
> 
> RTP Payload
> 
> 
> 
> This Multiplex header is repeated in 
> beginning of each RTP packet. So I was thinking of way to 
> extract this multiplex header & use it to decode each RTP 
> packet following this Multiplex header.
> 
> I supose we need to make a dissector 
> packet-rtpmultiplex.c regestring to a UDP port as a starting point.
> 
> 
> 
> Dissect the multiplex header, 
> decompress the rtp header and have the RTP dissector dissecting
> the resulting "RTP packet" - decompressed
> header+data.
> 
> Could you help me in dissecting the 
> multiplex header and make this work.
> 
> 
> 
> 
> Also I need to know the steps to 
> write our own filters in wireshark
> 
> 
> 
> 
> It would be great help. Kindly reply 
> as soon as possible
&g

Re: [Wireshark-dev] Need help in Decoding RTP Multiplex streams inWireshark

2009-08-28 Thread Neil Piercy

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 the protocol nb_rtpmux, as the 29.414 spec is
originally for the Nb interface.
 
Regards,
Neil
 

=
ip.access ltd   Tel: 01954 713715
Building 2020,  Fax: 01954 713799
Cambourne Business Park,
Cambourne,
Cambridge, CB23 6DW, UK
Company Registered Number3400157
Visit the website at http://www.ipaccess.com  
=


 




From: wireshark-dev-boun...@wireshark.org
[mailto:wireshark-dev-boun...@wireshark.org] On Behalf Of shruti singh
Sent: 27 August 2009 12:36
To: Developer support list for Wireshark
Subject: Re: [Wireshark-dev] Need help in Decoding RTP Multiplex
streams inWireshark


Hi, 

Yes RTP multiplexing is in compliance to 3GPP TS 29.414 Release
7 specification

thanks
Shruti


On Wed, Aug 26, 2009 at 7:58 PM, Jaap Keuter
 wrote:


Hi, 

Is there an RFC on that? Are there sample captures to
work with? This always helpsin development. 

Thanx,
Jaap

Now competing at http://www.ec2009.info

On 26 aug 2009, at 07:36, shruti singh
 wrote:



Hi 

I need to decode RTP Multiplex streams using
wireshark. Presently we can decode only Non -Multiplexed RTP streams in
wireshark. 


A multiplexed voice packet is composed by
concatenating RTP encapsulated voice packets and IP and UDP headers.

 Below is the Multiplex Packet format

 

IP

UDP

Multiplex Header

Compressed RTP Header

RTP Payload

Multiplex Header

Compressed RTP Header

RTP Payload

  

This Multiplex header is repeated in beginning
of each RTP packet. So I was thinking of way to extract this multiplex
header & use it to decode each RTP packet following this Multiplex
header.

I supose we need to make a dissector
packet-rtpmultiplex.c regestring to a UDP port as a starting point.



Dissect the multiplex header, decompress the rtp
header and have the RTP dissector dissecting
the resulting "RTP packet" - decompressed
header+data.

Could you help me in dissecting the multiplex
header and make this work.




Also I need to know the steps to write our own
filters in wireshark




It would be great help. Kindly reply as soon as
possible




Regards

Shruti





___
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








This message contains confidential information and may be privileged. If you 
are not the intended recipient, please notify the sender and delete the message 
immediately.

ip.access Ltd, registration number 3400157, Building 2020, 
Cambourne Business Park, Cambourne, Cambridge CB23 6DW, United Kingdom


___
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-bugs] [Bug 2863] RPM build fails dueto partially changed man path

2008-09-11 Thread Neil Piercy

> -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 newer? If 
> so, I'll update autogen.sh to reflect this.

That would have saved me (and others who responded to the bug report)
some time, and most likely will save others in the future, so I would
say so!

Ciao,
Neil




This message contains confidential information and may be privileged. If you 
are not the intended recipient, please notify the sender and delete the message 
immediately.

ip.access Ltd, registration number 3400157, Building 2020, 
Cambourne Business Park, Cambourne, Cambridge CB23 6DW, United Kingdom
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
https://wireshark.org/mailman/listinfo/wireshark-dev

[Wireshark-dev] Conversation tracking and endpoint contexts between layers

2008-09-09 Thread Neil Piercy

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 of the
problems spotted is that the reassembly needs to keep track of fragments
within a conversation between endpoints, but that for SNDCP the set of
parameters which identify a single conversation are:

IP addresses of NSIP layer endpoints
UDP ports of NSIP layer endpoints
MS TLLI in the BSSGP layer
SAPI in the LLC layer

(even this is strictly not true in a multi-NS-link environment, but it
normally is)

This is not the first time I've come across this problem, and so far I've
managed to work around it, but I'm realising that this is a general issue,
which maybe should have a general solution or design template at least. I've
not spotted any obvious manner in which such conversations can be tracked in
Wireshark - the current conversation code really only deals with TCP/UDP
port and IP address. Even how to pass such endpoint information around
between layers is not obvious to me - some options:

A) it looks like pinfo is sometimes used for this, but I'm not convinced
extending pinfo with endpoint info for any layer of any protocol stack is
not scalable.

B) adding protocol-specific packet info can be used to hold endpoint info,
and retrieved by other layers, but then you need a mechanism to distribute
the proto handles round between layers

The latter could be done by a function which looks up the proto handle by
proto name quite easily I suspect, so this is the best way I know of right
now.

Maybe I need to look at a more general conversation mechanism using custom
key structs too.

Have I missed something?

Any views on the best way to deal with multi-layer endpoint conversation
tracking in general ?

Regards,
Neil

___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
https://wireshark.org/mailman/listinfo/wireshark-dev

Re: [Wireshark-dev] Terminating NULL chraracter in RTCP Byereason string

2008-08-05 Thread Neil Piercy


> -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 
> leaving, e.g., 
> > "camera malfunction" or "RTP loop detected".
> >  The string has the same encoding as that described for SDES.
> >  If the string fills the packet to the next 32-bit boundary, the 
> > string is not null terminated.

The real problem in the spec is here - the leap from "octets of text" to
"string".

> It sounds as if whoever wrote RFC 3550 needs to learn the 
> difference between the words "padded" and "terminated" - they 
> probably meant to say that the string is null-*padded* to a 
> 4-byte boundary.

Maybe they did know the diference, and maybe they didn't, but what they
actually said was:

> >  If the string fills the packet to the next 32-bit boundary, the 
> > string is not null terminated.

i.e. they have defined a case in which a "string" is not null terminated
(i.e. is a sequence of non-null characters only), so Wireshark should
not object to the string not being null terminated in this case.

Neil
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
https://wireshark.org/mailman/listinfo/wireshark-dev

Re: [Wireshark-dev] dissection of NAS messages in RRC

2008-05-16 Thread Neil Piercy

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 NAS messages in RRC



Hi,

 

Is the dissection of NAS PDUs contained in RRC messages
supported in release 1.0 of wireshark?

Can any body throw some light on it?

And also it would be of great help if somebody can provide the
RRC packet containing NAS PDU.

 

Thanks and Regards

Praveen 




"DISCLAIMER: This message is proprietary to Aricent and is
intended solely for the use of the individual to whom it is addressed.
It may contain privileged or confidential information and should not be
circulated or used for any purpose other than for what it is intended.
If you have received this message in error,please notify the originator
immediately. If you are not the intended recipient, you are notified
that you are strictly prohibited from using, copying, altering, or
disclosing the contents of this message. Aricent accepts no
responsibility forloss or damage arising from the use of the information
transmitted by this email including damage from virus."


___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev

[Wireshark-dev] plugins linked to other plugins ?

2008-02-15 Thread Neil Piercy

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 packaging fails!

The problem I've got with the rpm packaging is that when constructing
the install tree under /tmp, libtool notices that the child plugin is
linked against the parent and tries to relink it - unfortunately using
-l but thus tries to find lib.so, not
.so.

Is there any way to prevent this relink - as I understand it, provided
they are loaded in the right order, the relink should not be needed (but
I might be wrong there...).

Of course most answers will probably be "don't do it" ;-)

Neil
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev

[Wireshark-dev] RRC NAS MEssage dissection (was: RE: 3GPP RLC and MAC protocols support)

2008-01-14 Thread Neil Piercy

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...)



From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Anders Broman


Hi,

In rrc.cnf do something similar to whats done in RANAP

--- Snip from ranap.cnf ---

#.FN_BODY NAS-PDU  VAL_PTR = &nas_pdu_tvb

  tvbuff_t *nas_pdu_tvb=NULL;

 

%(DEFAULT_BODY)s

 

  if (nas_pdu_tvb)


dissector_try_port(nas_pdu_dissector_table, 0x1, nas_pdu_tvb,
%(ACTX)s->pinfo, proto_tree_get_root(tree));

#.END

--- End Snip from ranap.cnf ---

I guess that would be:

#.FN_BODY NAS-Message PDU  VAL_PTR = &nas_message_tvb

%(DEFAULT_BODY)s

 

  if (nas_pdu_tvb)

then the actual hook into packet-gsm_a.c

 

If you do something along those lines please submit the result
back to us.

Regards

Anders



___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev

Re: [Wireshark-dev] 3GPP RLC and MAC protocols support

2008-01-08 Thread Neil Piercy

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 to work with somebody to do so - even if we only leave
the glue to transports as proprietary for now.
 
BTW is anyone planning on hooking RRC NAS message IEs into gsm_a_dtap ?
Since RRC is from the ASN.1, I've not tried it yet, but any pointers
appreciated.
 
Neil





From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Martin
Mathieson
Sent: 08 January 2008 11:26
To: Developer support list for Wireshark
Subject: Re: [Wireshark-dev] 3GPP RLC and MAC protocols support


Hi,
I don't know of anyone working on MAC or RLC dissectors.

FP is currently only available for Catapult DCT2000 and
Tektronix K12 file formats, since those formats include the information
needed to interpret the message payloads.  This amounts to using
Wireshark as a different log viewer, rather than as a passive network
analyser. 

In order to decode the MAC and RLC layers, you'd need to either:
(a) use a file format that gives you this information directly
(as above), OR
(b) infer the FP/MAC/RLC layer configuration/state using
information gleaned from RRC configuration messages, OR MAYBE 
(c) guess from the message size/timing/contents that common
transport formats have been used, e.g. there are standard settings using
with AMR co-ordinated channels? OR EVEN LESS LIKELY
(d) get all of this information from preference settings.  I
think this is probably a non-starter since so much of the information is
per-channel or even per-frame. 

I'd love to see someone do this, but know that it isn't trivial
- my company (Catapult) built such an analyser (using (b) - before I
joined).

I could have extended the approach of (a) for the DCT2000
format, i.e. dissect our own proprietary primitive headers then use this
and other information in the file format to hand off to pure MAC or RLC
dissectors (that would use attached information, as the FP dissector
does), but this would still just be using Wireshark as a different log
viewer, I don't know of any other file formats that would then be able
to take advantage of these dissectors in the same way (possibly K12
again...).  I believe the headers for MAC and RLC are quite short, and
that it would take more effort to dissect the proprietary headers than
it would for the actual protocol headers. 

Regards,
Martin


On Jan 8, 2008 10:41 AM, Anders Broman
<[EMAIL PROTECTED]> wrote:


Hi,
An RRC dissector (packet-rrc.c) exists but only partly
used. Some time
ago some one
asked about MAC and probably did something with it but
nothing was
commited back to WS.
These are somewhere in the middle of the tread 

http://www.wireshark.org/lists/wireshark-dev/200708/msg00121.html

http://www.wireshark.org/lists/wireshark-dev/200708/msg00275.html
Regards
Anders


-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf
Of
[EMAIL PROTECTED] 
Sent: den 8 januari 2008 15:35
To: Developer support list for Wireshark
Subject: [Wireshark-dev] 3GPP RLC and MAC protocols
support





Hi,

Is anybody working on dissectors for 3GPP-UMTS- RLC and
MAC protocols ? 
Or are these dissectors already available somewhere ?

Thanks & Regards,
Munish





***  Aricent-Unclassified
***

"DISCLAIMER: This message is proprietary to Aricent  and
is intended 
solely for the use of the individual to whom it is
addressed. It may
contain privileged or confidential information and
should not be
circulated or used for any purpose other than for what
it is intended.
If you have received this message in error, please
notify the originator 
immediately. If you are not the intended recipient, you
are notified
that you are strictly prohibited from using, copying,
altering, or
disclosing the contents of this message. Aricent accepts
no

Re: [Wireshark-dev] Is there a good way of handling bitfields withdifferent bitmask offsets ?

2007-11-14 Thread Neil Piercy

 

> -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->bitshift = new bit shift

> very ugly.   it could work.

I agree - but I'll try!

> please do not contribute any code to wireshark that does 
> anything like this  :-)

That's a shame, because this is needed in order to extend the current
gsm_a dissector to cope with half octet IE which can be in the upper or
lower half of the octet.  I did ask for an _good_ way ;-).

I still reckon the general way is to add bit_offset to all the proto
calls - but I guess that won't happen anytime soon ;-).  Even more ugly
hack: use the _top_ 3 bits of the current offset in those calls as a bit
offset..  maybe not!

Neil
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev

Re: [Wireshark-dev] Is there a good way of handling "per pdu" info ?

2007-11-13 Thread Neil Piercy

> -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 requested before, but has not been 
> implemented to date 
> > in Wireshark.  A workaround you can use is to use a linked 
> list from 
> > GLib (which has a nice easy interface to them) and store 
> that in the 
> > per packet info.  Each item in your list would correspond to a 
> > different PDU.
> 
> But, as Neil asked, how would you know which PDU you were 
> handling in the dissector?

That is the issue I'm facing!

> > One of us should get around to implementing per-pdu packet info in 
> > Wireshark itself.  It wouldn't be too difficult.  All we 
> need is spare 
> > time :)
> 
> Hrm; it gets quite a lot harder when your PDUs can themselves 
> span multiple packets (ie, there is no correspondence between 
> PDUs and packets). See H.223 for details...

I think what is actually needed is the concept of a PDU handle on an
arbirtary point in the parsing - e.g. the concatenation of the frame
number and the byte offset in that frame would be a suitable handle for
a PDU which started at a "real" point in a frame, but this still would
not work for constructed TVBs (e.g. a TVB carrying the decrypt from
SSL). For that you would need have the PDU handle be based on the
hierarchy of TVBs in some way. This is all sounding challenging to me,
but could it be made to work for the normal case of a TVB being at an
offset into a frame, and e.g. tvb_get_handle(tvb,offset) to return a PDU
handle ?

If you could do that then the per-packet info is good enough as you say
with the list of entries.

Neil
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev

[Wireshark-dev] Is there a good way of handling "per pdu" info ?

2007-11-12 Thread Neil Piercy

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
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev

[Wireshark-dev] Is there a good way of handling bitfields with different bitmask offsets ?

2007-11-12 Thread Neil Piercy

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 would be to add a bit offset
to _every_ existing proto_tree_add_*() to go with the existing byte
offset, but is there a simpler way which
A) maintains the bitmask display in the main packet field view which the
hf bitmasks provide.
B) isnt just a text decode - is based on hf entries.

Neil
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev

Re: [Wireshark-dev] Is there anybody dissect Abis protocol

2007-09-10 Thread Neil Piercy

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 would help. It is not by any means complete, and has not been
brought up to date with some of the latest wireshark "best practices",
but it should get you going.
 
One question: what transport are you thinking of - we have an IP-based
version of the signalling rather than E1-based.
 
Let me know if this would be useful to you.
 
Regards,
Neil




From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of alpha
Sent: 08 September 2007 13:47
To: wireshark-dev@wireshark.org
Subject: [Wireshark-dev] Is there anybody dissect Abis protocol


Is there anybody  dissecting the GSM-Abis protocol  in
wireshark? Now, I'm trying decode it with the wireshark project

-- 
alpha 

___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev

Re: [Wireshark-dev] Dissectors for SMS over GPRS-LLC

2007-08-16 Thread Neil Piercy

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 protocol.
 
I'd support (and might be able to help with) such a separation.
 
Neil




From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Anders Broman
(AL/EAB)
Sent: 16 August 2007 16:03
To: Developer support list for Wireshark
Subject: Re: [Wireshark-dev] Dissectors for SMS over GPRS-LLC


Hi,
>some SMS Control Protocol (SMS CP) fields are included in GSM A
DTAP dissector, but not the whole protocol.
Should all SMS-CP dissection be done by the new dissector or
perhaps the code moved into packet-gsm_a.c ?
Regards
Anders



From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Cyrille Colin
Sent: den 16 augusti 2007 16:10
To: wireshark-dev@wireshark.org
Subject: [Wireshark-dev] Dissectors for SMS over GPRS-LLC



Hi 

SMS msg can be carried over packet switched GPRS, and I am
trying to have Wireshark decode SMS carried on GPRS LLC protocol (SAPI
7). 

The stack is the following: 

  --- 
 | sms msg |
  --- 
 | sms T-PDU  | --> dissector exists (gsm_sms) in
packet-gsm_sms.c 
  --- 
 | sms RP   |   --> dissector exists (gsm_a_rp)
in packet-gsm_a.c 
  --- 
 | sms CP   |   
  --- 
 | GPRS LLC   | --> dissector exists  (gprs-llc) in
packet-gprs-llc.c 
  --- 

some SMS Control Protocol (SMS CP) fields are included in GSM A
DTAP dissector, but not the whole protocol. 

So I basically wrote a small plugin for SMS CP -following the
dev guidelines-, and linked to GPRS-LLC and SMS-RP and it works fine. 


The questions are: 
- is there any interest in having this submitted back to the
Wireshark source ? 
- if it is the case, what is the best practice (plugin, native)
and recommendations for the dissector calls - restrain the calls to be
within the new protocol code, or rather use call_dissector() etc in
other dissectors, which implies a small diff on other dissectors too.


Thks, and btw I found the developper doc extremely useful -many
thks to the author(s). 

Cyrille 
  

___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev

Re: [Wireshark-dev] preference tree for SS7

2007-03-27 Thread Neil Piercy

 

> -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 too (or is such multiple reference too big a
change) ?

Neil
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev

Re: [Wireshark-dev] Addition of basic SRTP/SRTCP support

2007-03-22 Thread Neil Piercy

 

> -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 worse case than the trouble with
all RTP profiles: they assume out-of-band signalling to have occurred to
allow the receiver to decode them.

In the case of SRTP there is a default SRTP profile which has a standard
encryption and authentication algorithm, standard authentication tag
size and standard (zero) MKI size, but there is no way to know whether
any application has overridden the defaults by heuristics short of brute
force trying of different tag sizes and algorithms. There are 
already 2 defined encryption algorithms, and the non-default one is in
common usage too.

Really it needs almost "per stream" preferences - maybe as well as the
right-click "Decode As..." we should have a "Configure this protocol
with...", and a dialogue to allow e.g. the user to enter a decryption
key, tag sizes etc which are saved in the conversatin data for the
protocol and used to redissect it. Is this perhaps a general problem for
other protocols too (e.g. SSL keys) ? I suspect some of the other
preferences should really be per stream but we get away with them
because captures commonly show many streams with the same prerences
(e.g. SCCP is ITU or ANSI - rarely seen together!).

Regards,
Neil
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev

[Wireshark-dev] Display column additions for SCCP

2007-03-22 Thread Neil Piercy

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 the user has selected the wrong SCCP variant (ITU vs ANSI etc.).

Regards, 
Neil


packet-sccp.c.diff
Description: Binary data
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev

[Wireshark-dev] Addition of basic SRTP/SRTCP support

2007-03-22 Thread Neil Piercy

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 signalling protocols.

There are no signalling protocols using this yet - I have a currently
private protocol which uses it, but I think SRTP/SRTCP support is of wider
relevance.

It has passed testing with our usage of these functions, but we certainly
don't exercise all paths, so all comment and testing welcome.

Ideally I (or somebody else) will go on to add decryption - some hooks are
already in the header files for this - and subsequent dissection of the
payload.

I'd also welcome any views on how to handle RTP profiles in general in
Wireshark, especially for non-signalled RTP captures: having lots of user
preferences sounds to me like it will get out of hand, but without that I'm
not sure how to deal with RTP payloads - de we need another layer of "Decode
As..." for RTP payloads ?

Regards,
Neil



packet-rtp.h.diff
Description: Binary data


packet-rtp.c.diff
Description: Binary data


packet-rtcp.h.diff
Description: Binary data


packet-rtcp.c.diff
Description: Binary data
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev

[Wireshark-dev] Any chance of http://anonsvn.wireshark.org/wireshark/releases/wireshark-0.99.5/ ?

2007-03-16 Thread Neil Piercy

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

[Wireshark-dev] win32 setup/build problem

2007-01-11 Thread Neil Piercy

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 packages which reuse a 
non-versioned directory for the unpacked files.


Proposed fix:
a) change the makefile so all unversioned package directories are deleted during 
setup (looks like somebody else noticed similar as this is already done for gtk2 
for 2.12, but it should be wider) - it is slower but safer to maybe always 
delete the destination dir and create it afresh ?


b) change win32-setup.sh to use -uo in place of -n - at least then you get all 
the new package, possibly with remnants of the old package if it wasnt deleted 
first and the files are no longer in the new package.


Patches attached.

Neil
Index: win32-setup.sh
===
--- win32-setup.sh  (revision 20392)
+++ win32-setup.sh  (working copy)
@@ -78,7 +78,7 @@
err_exit "Can't download $DOWNLOAD_PREFIX/$PACKAGE_PATH"
cd "$DEST_SUBDIR" || err_exit "Can't find $DEST_SUBDIR"
echo "Extracting $DEST_PATH/$PACKAGE into $DEST_PATH/$DEST_SUBDIR"
-   unzip -nq "$DEST_PATH/$PACKAGE" ||
+   unzip -uoq "$DEST_PATH/$PACKAGE" ||
err_exit "Couldn't unpack $DEST_PATH/$PACKAGE"
echo "Verifying that the DLLs in $DEST_PATH/$DEST_SUBDIR are 
executable."
for i in `/usr/bin/find $DEST_PATH/$DEST_SUBDIR -name \*\.dll` ; do
Index: Makefile.nmake
===
--- Makefile.nmake  (revision 20392)
+++ Makefile.nmake  (working copy)
@@ -534,9 +534,13 @@
 # If you used this setup target before, consider doing a clean_setup.
 setup: verify_tools
 if not exist $(WIRESHARK_LIBS) md $(WIRESHARK_LIBS)
+# build problems due to stuff left in these dirs, remove them 
+   rm -rf $(WIRESHARK_LIBS)/gtk2
+   rm -rf $(WIRESHARK_LIBS)/gtk+
+   rm -rf $(WIRESHARK_LIBS)/gtk-wimp
+   rm -rf $(WIRESHARK_LIBS)/glib
+   rm -rf $(WIRESHARK_LIBS)/WpdPack
 !IF "$(GTK2_INST_VERSION)" == "2.10"
-# ran into problems probably due to stuff left in gtk dir, remove it 
-   rm -rf $(WIRESHARK_LIBS)/gtk2
@$(SH) tools\win32-setup.sh --download "$(WIRESHARK_LIBS)" \
glib gtk2.10/glib-2.12.6.zip
@$(SH) tools\win32-setup.sh --download "$(WIRESHARK_LIBS)" \
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev

Re: [Wireshark-dev] Verify installed tools failing

2006-11-06 Thread Neil Piercy

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 Developer Installation on a
> Windows XP machine, but tools verification seems to fail;
> 
> I have got Microsoft Visual Studio 6.0 installed.
> The installation of Cygwin and its additional packages seemed to go
> okay, I can open a bash window.
> I downloaded the wireshark-0.99.4 sources using SVN
> Running nmake to verify the tools fails though, the output is given
> below.
> 
> Any ideas what is going wrong and how to correct it?
> 
> Regards
> RT
> 
> 
> C:\Program Files\Wireshark>nmake -f Makefile.nmake verify_tools 
> 
> Microsoft (R) Program Maintenance Utility   Version 6.00.9782.0
> Copyright (C) Microsoft Corp 1988-1998. All rights reserved.
> 
>   bash tools\win32-setup.sh --appverify  cl  link  nmake  bash
> bison  flexenv grep/usr/bin/find   perlenv python
> sedunzip   wget
> tools/win32-setup.sh: line 2: 
> : command not found
> tools/win32-setup.sh: line 8: 
> : command not found
> tools/win32-setup.sh: line 9: syntax error near unexpected token `{
> '
> tools/win32-setup.sh: line 9: `err_exit () {
> '
> NMAKE : fatal error U1077: 'bash' : return code '0x2'
> Stop.
> ___
> Wireshark-dev mailing list
> Wireshark-dev@wireshark.org
> http://www.wireshark.org/mailman/listinfo/wireshark-dev

-- 
=
ip.access ltd   Tel: 01954 713715
Building 2020,  Fax: 01954 713799
Cambourne Business Park,
Cambourne,
Cambridge, CB23 6DW, UK
Visit the website at http://www.ipaccess.com
=
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev

Re: [Wireshark-dev] Follow up to making register.c - python problem - patch

2006-10-27 Thread Neil Piercy

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 2.3, and when I setup 
another PC from clean with Python 2.4 it had this issue. When I upgraded 
the first to Python 2.4 it also failed so I thought it was that change 
(but I did start a clean build tree at the same time), and others have 
reported the issue on Python 2.3 too, so I suspect the Python version is 
irrelevant really.

It looks like something changes in the environment which causes either 
the command line arguements to be parsed for options - "/" being a 
common Windows option separator - so the path gets broken up and not 
treated as the file, or has the path not properly converted to the 
Windows "\" separator in actual use - but that is mainly speculation 
(and I'm far from a Python expert ;-). I was wondering whether it was 
something in our Python scripts which was just not general enough to 
cope in how the arguements were parsed and passed under Windows, but 
again, my lack of Python expertise prevented much progress.

> I've started to put the string name in brackets "../../xy.py" in one of 
> the nmake files some days ago, instead of replacing the slashes by 
> backslashes as you did - which seems to both be working with native python.

Yes - somebody else reported the quotations working and indeed they do 
for me too.

> Do you know of any drawbacks of either solutions?

Actually I suspect the right way to go is to quote paths - and possibly 
for all paths if we wanted to be very strict (what if somebody used a 
path with a space in it ? Understandably hated under Unix, but rather 
common on Windows in some circles).

> I still don't have a good idea what the right solution to this problem 
> really is - and don't want to change a lot of places just to notice that 
> this raises other problems :-)

I don't know of any problems with either solution - btw I produced the 
patch by running a script over the tree, so I guess it would be easy to 
do the same for a patch to add quotes if you want.

Regards,
Neil
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev

Re: [Wireshark-dev] Follow up to making register.c - python problem - patch

2006-10-26 Thread Neil Piercy

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 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 problem with it (I can believe that 
>>> ;-), or did it just overflow the stack ?
>>
>> The preferred way to send patches is to send the to the list - just as
>> you did. In case you don't receive any feedback for (let's say) 10 days,
>> then the best thing is to open a bug and attach the patch there. That
>> way we will not loose it.
>>
>>  Ciao
>>  Joerg
> 
> 

-- 
=
ip.access ltd   Tel: 01954 713715
Building 2020,  Fax: 01954 713799
Cambourne Business Park,
Cambourne,
Cambridge, CB23 6DW, UK
Visit the website at http://www.ipaccess.com
=
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev

Re: [Wireshark-dev] Follow up to making register.c - python problem - patch

2006-10-11 Thread Neil Piercy

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 problem with it (I can believe that ;-), or 
>> did it just overflow the stack ?
> 
> The preferred way to send patches is to send the to the list - just as
> you did. In case you don't receive any feedback for (let's say) 10 days,
> then the best thing is to open a bug and attach the patch there. That
> way we will not loose it.
> 
>  Ciao
>  Joerg

___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev

Re: [Wireshark-dev] Follow up to making register.c - python problem - patch

2006-09-08 Thread Neil Piercy

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/Makefile.nmake(revision 19103)
+++ asn1/rrlp/Makefile.nmake(working copy)
@@ -15,7 +15,7 @@
 
 $(DISSECTOR_FILES): ../../tools/asn2wrs.py rrlp.asn packet-rrlp-template.c 
packet-rrlp-template.h rrlp.cnf
 !IFDEF PYTHON
-   $(PYTHON) ../../tools/asn2wrs.py -u -e -p $(PROTOCOL_NAME) -c rrlp.cnf 
-s packet-rrlp-template rrlp.asn
+   $(PYTHON) ..\..\tools\asn2wrs.py -u -e -p $(PROTOCOL_NAME) -c rrlp.cnf 
-s packet-rrlp-template rrlp.asn
 !ELSE
@echo Error: You need Python to use asn2wrs.py
@exit 1
Index: asn1/nbap/Makefile.nmake
===
--- asn1/nbap/Makefile.nmake(revision 19103)
+++ asn1/nbap/Makefile.nmake(working copy)
@@ -15,7 +15,7 @@
 
 $(DISSECTOR_FILES): ../../tools/asn2wrs.py nbap.asn packet-nbap-template.c 
packet-nbap-template.h nbap.cnf
 !IFDEF PYTHON
-   $(PYTHON) ../../tools/asn2wrs.py -e -F -p $(PROTOCOL_NAME) -c nbap.cnf 
-s packet-nbap-template nbap.asn
+   $(PYTHON) ..\..\tools\asn2wrs.py -e -F -p $(PROTOCOL_NAME) -c nbap.cnf 
-s packet-nbap-template nbap.asn
 !ELSE
@echo Error: You need Python to use asn2wrs.py
@exit 1
Index: asn1/h245/Makefile.nmake
===
--- asn1/h245/Makefile.nmake(revision 19103)
+++ asn1/h245/Makefile.nmake(working copy)
@@ -15,7 +15,7 @@
 
 $(DISSECTOR_FILES): ../../tools/asn2wrs.py  MULTIMEDIA-SYSTEM-CONTROL.asn 
$(PROTOCOL_NAME).cnf packet-$(PROTOCOL_NAME)-template.c 
packet-$(PROTOCOL_NAME)-template.h
 !IFDEF PYTHON
-   $(PYTHON) ../../tools/asn2wrs.py -e -p $(PROTOCOL_NAME) -c 
$(PROTOCOL_NAME).cnf -s packet-$(PROTOCOL_NAME)-template  
MULTIMEDIA-SYSTEM-CONTROL.asn
+   $(PYTHON) ..\..\tools\asn2wrs.py -e -p $(PROTOCOL_NAME) -c 
$(PROTOCOL_NAME).cnf -s packet-$(PROTOCOL_NAME)-template  
MULTIMEDIA-SYSTEM-CONTROL.asn
 !ELSE
@echo Error: You need Python to use asn2wrs.py
@exit 1
Index: asn1/pkixcrmf/Makefile.nmake
===
--- asn1/pkixcrmf/Makefile.nmake(revision 19103)
+++ asn1/pkixcrmf/Makefile.nmake(working copy)
@@ -15,7 +15,7 @@
 
 $(DISSECTOR_FILES): ../../tools/asn2wrs.py CRMF.asn packet-crmf-template.c 
packet-crmf-template.h crmf.cnf 
 !IFDEF PYTHON
-   $(PYTHON) ../../tools/asn2wrs.py -b -e -p $(PROTOCOL_NAME) -c crmf.cnf 
-s packet-crmf-template CRMF.asn
+   $(PYTHON) ..\..\tools\asn2wrs.py -b -e -p $(PROTOCOL_NAME) -c crmf.cnf 
-s packet-crmf-template CRMF.asn
 !ELSE
@echo Error: You need Python to use asn2wrs.py
@exit 1
Index: asn1/h248/Makefile.nmake
===
--- asn1/h248/Makefile.nmake(revision 19103)
+++ asn1/h248/Makefile.nmake(working copy)
@@ -15,7 +15,7 @@
 
 $(DISSECTOR_FILES): ../../tools/asn2wrs.py MEGACO.asn 
packet-$(PROTOCOL_NAME)-template.c packet-$(PROTOCOL_NAME)-template.h 
$(PROTOCOL_NAME).cnf 
 !IFDEF PYTHON
-   $(PYTHON) ../../tools/asn2wrs.py -b -e -p $(PROTOCOL_NAME) -c 
$(PROTOCOL_NAME).cnf -s packet-$(PROTOCOL_NAME)-template MEGACO.asn
+   $(PYTHON) ..\..\tools\asn2wrs.py -b -e -p $(PROTOCOL_NAME) -c 
$(PROTOCOL_NAME).cnf -s packet-$(PROTOCOL_NAME)-template MEGACO.asn
 !ELSE
@echo Error: You need Python to use asn2wrs.py
@exit 1
Index: asn1/ftam/Makefile.nmake
===
--- asn1/ftam/Makefile.nmake(revision 19103)
+++ asn1/ftam/Makefile.nmake(working copy)
@@ -15,7 +15,7 @@
 
 $(DISSECTOR_FILES): ../../tools/asn2wrs.py ISO8571-FTAM.asn 
packet-$(PROTOCOL_NAME)-template.c packet-$(PROTOCOL_NAME)-template.h 
$(PROTOCOL_NAME).cnf
 !IFDEF PYTHON
-   $(PYTHON) ../../tools/asn2wrs.py -b -e -p $(PROTOCOL_NAME) -c 
$(PROTOCOL_NAME).cnf -s packet-$(PROTOCOL_NAME)-template ISO8571-FTAM.asn
+   $(PYTHON) ..\..\tools\asn2wrs.py -b -e -p $(PROTOCOL_NAME) -c 
$(PROTOCOL_NAME).cnf -s packet-$(PROTOCOL_NAME)-template ISO8571-FTAM.asn
 !ELSE
@echo Error: You need Python to use asn2wrs.py
@exit 1
Index: asn1/pkix1implicit/Makefile.nmake
===
--- asn1/pkix1implicit/Makefile.nmake   (revision 19103)
+++ asn1/pkix1implicit/Makefile.nmake   (working copy)
@@ -15,7 +15,7 @@
 
 $(DISSECTOR_FILES): ../../tools/asn2wrs.py PKIX1IMPLICIT93.asn 
packet-pkix1implicit-template.c packet-pkix1implicit-template.h 
pkix1implicit.cnf
 !IFDEF PYTHON
-   $(PYTHON) ../../tools/asn2wrs.py -e -b -p $(PROTOCOL_NAME) -c 
pkix1implicit.cnf -s packet-pkix1implicit-template PKIX1IMPLICIT93.asn 
+   $(PYTHON) ..\..\tools\asn2

[Wireshark-dev] Follow up to making register.c - python problem - patch

2006-09-01 Thread Neil Piercy

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
===
--- asn1/rrlp/Makefile.nmake(revision 19103)
+++ asn1/rrlp/Makefile.nmake(working copy)
@@ -15,7 +15,7 @@
 
 $(DISSECTOR_FILES): ../../tools/asn2wrs.py rrlp.asn packet-rrlp-template.c 
packet-rrlp-template.h rrlp.cnf
 !IFDEF PYTHON
-   $(PYTHON) ../../tools/asn2wrs.py -u -e -p $(PROTOCOL_NAME) -c rrlp.cnf 
-s packet-rrlp-template rrlp.asn
+   $(PYTHON) ..\..\tools\asn2wrs.py -u -e -p $(PROTOCOL_NAME) -c rrlp.cnf 
-s packet-rrlp-template rrlp.asn
 !ELSE
@echo Error: You need Python to use asn2wrs.py
@exit 1
Index: asn1/nbap/Makefile.nmake
===
--- asn1/nbap/Makefile.nmake(revision 19103)
+++ asn1/nbap/Makefile.nmake(working copy)
@@ -15,7 +15,7 @@
 
 $(DISSECTOR_FILES): ../../tools/asn2wrs.py nbap.asn packet-nbap-template.c 
packet-nbap-template.h nbap.cnf
 !IFDEF PYTHON
-   $(PYTHON) ../../tools/asn2wrs.py -e -F -p $(PROTOCOL_NAME) -c nbap.cnf 
-s packet-nbap-template nbap.asn
+   $(PYTHON) ..\..\tools\asn2wrs.py -e -F -p $(PROTOCOL_NAME) -c nbap.cnf 
-s packet-nbap-template nbap.asn
 !ELSE
@echo Error: You need Python to use asn2wrs.py
@exit 1
Index: asn1/h245/Makefile.nmake
===
--- asn1/h245/Makefile.nmake(revision 19103)
+++ asn1/h245/Makefile.nmake(working copy)
@@ -15,7 +15,7 @@
 
 $(DISSECTOR_FILES): ../../tools/asn2wrs.py  MULTIMEDIA-SYSTEM-CONTROL.asn 
$(PROTOCOL_NAME).cnf packet-$(PROTOCOL_NAME)-template.c 
packet-$(PROTOCOL_NAME)-template.h
 !IFDEF PYTHON
-   $(PYTHON) ../../tools/asn2wrs.py -e -p $(PROTOCOL_NAME) -c 
$(PROTOCOL_NAME).cnf -s packet-$(PROTOCOL_NAME)-template  
MULTIMEDIA-SYSTEM-CONTROL.asn
+   $(PYTHON) ..\..\tools\asn2wrs.py -e -p $(PROTOCOL_NAME) -c 
$(PROTOCOL_NAME).cnf -s packet-$(PROTOCOL_NAME)-template  
MULTIMEDIA-SYSTEM-CONTROL.asn
 !ELSE
@echo Error: You need Python to use asn2wrs.py
@exit 1
Index: asn1/pkixcrmf/Makefile.nmake
===
--- asn1/pkixcrmf/Makefile.nmake(revision 19103)
+++ asn1/pkixcrmf/Makefile.nmake(working copy)
@@ -15,7 +15,7 @@
 
 $(DISSECTOR_FILES): ../../tools/asn2wrs.py CRMF.asn packet-crmf-template.c 
packet-crmf-template.h crmf.cnf 
 !IFDEF PYTHON
-   $(PYTHON) ../../tools/asn2wrs.py -b -e -p $(PROTOCOL_NAME) -c crmf.cnf 
-s packet-crmf-template CRMF.asn
+   $(PYTHON) ..\..\tools\asn2wrs.py -b -e -p $(PROTOCOL_NAME) -c crmf.cnf 
-s packet-crmf-template CRMF.asn
 !ELSE
@echo Error: You need Python to use asn2wrs.py
@exit 1
Index: asn1/h248/Makefile.nmake
===
--- asn1/h248/Makefile.nmake(revision 19103)
+++ asn1/h248/Makefile.nmake(working copy)
@@ -15,7 +15,7 @@
 
 $(DISSECTOR_FILES): ../../tools/asn2wrs.py MEGACO.asn 
packet-$(PROTOCOL_NAME)-template.c packet-$(PROTOCOL_NAME)-template.h 
$(PROTOCOL_NAME).cnf 
 !IFDEF PYTHON
-   $(PYTHON) ../../tools/asn2wrs.py -b -e -p $(PROTOCOL_NAME) -c 
$(PROTOCOL_NAME).cnf -s packet-$(PROTOCOL_NAME)-template MEGACO.asn
+   $(PYTHON) ..\..\tools\asn2wrs.py -b -e -p $(PROTOCOL_NAME) -c 
$(PROTOCOL_NAME).cnf -s packet-$(PROTOCOL_NAME)-template MEGACO.asn
 !ELSE
@echo Error: You need Python to use asn2wrs.py
@exit 1
Index: asn1/ftam/Makefile.nmake
===
--- asn1/ftam/Makefile.nmake(revision 19103)
+++ asn1/ftam/Makefile.nmake(working copy)
@@ -15,7 +15,7 @@
 
 $(DISSECTOR_FILES): ../../tools/asn2wrs.py ISO8571-FTAM.asn 
packet-$(PROTOCOL_NAME)-template.c packet-$(PROTOCOL_NAME)-template.h 
$(PROTOCOL_NAME).cnf
 !IFDEF PYTHON
-   $(PYTHON) ../../tools/asn2wrs.py -b -e -p $(PROTOCOL_NAME) -c 
$(PROTOCOL_NAME).cnf -s packet-$(PROTOCOL_NAME)-template ISO8571-FTAM.asn
+   $(PYTHON) ..\..\tools\asn2wrs.py -b -e -p $(PROTOCOL_NAME) -c 
$(PROTOCOL_NAME).cnf -s packet-$(PROTOCOL_NAME)-template ISO8571-FTAM.asn
 !ELSE
@echo Error: You need Python to use asn2wrs.py
@exit 1
Index: asn1/pkix1implicit/Makefile.nmake
===
--- asn1/pkix1implicit/Makefile.nmake   (revision 19103)
+++ asn1/pkix1implicit/Makefile.nmake   (working copy)
@@ -15,7 +15,7 @@
 
 $(DISSECTOR_FILES): ../../tools/asn2wrs.py PKIX1IMPLICIT93.asn 
packet-pkix1implicit-template.c packet-pkix1implicit-template.h 
pkix1implicit.cnf
 !IFDEF PYTHON
-   $(PYTHON) ../../tools/asn2wrs.py -e -b -p $(PROTOCOL_NAME) -c 
pkix1implicit.cnf -s packet-pkix1implicit-template PKIX1IMPL

Re: [Wireshark-dev] Ideas regarding bug 1025?

2006-08-12 Thread Neil Piercy

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 suggested fixed the immediate problem, I'm not at
all convinced that the I?64 formats are handled properly by vasnprintf - the
HAVE_INT64_AND_I64 define appears not to be in anywhere near enough places,
whereas the HAVE_LONG_LONG usage looks original and OK. Interestingly I've now
noticed the makefile for the gnulib files includes a -DHAVE_LONG_LONG_FORMAT,
which looks like a failed attempt to cope on Windows. That, and the fact that
your suggestion isolates the fix to wireshark code makes it very attractive.

Neil
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev

Re: [Wireshark-dev] Ideas regarding bug 1025?

2006-08-12 Thread Neil Piercy

I think I've found it: a bug in glib Windows port of gnulib vasnprintf.c (patch
attached) - I've checked the latest glib 2.10.3, and the same issue exists.

The patch allows the test program to work OK, but unfortunately I've still got a
build problem with trying to use the whole libglib-2.0.dll with wireshark, so I
cant yet verify that this allows 1025 to be fixed.

I've submitted a bug report to bugzilla.gnome.org (bug 351034) - I _think_ they
maintain the Windows port of gnulib, but I might be wrong on that too, but I
hope not!

Neil

Quoting Anders Broman <[EMAIL PROTECTED]>:
> 
> Hi,
> The GTK and Glib packages where obtained from:
> http://www.gimp.org/~tml/gimp/win32/downloads.html
> it might be worth trying a newer version to see if the problem has been
> resolved (or check the release notes).
> Brg
> Anders
> 
> -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 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 crashes on test2 (in exactly the same manner 
> as the whole wireshark app does with the test capture, so the test looks
> 
> valid) - i.e. as soon as the upper 32 bits are non-zero. I'm trying to 
> build a debug version of the glib-2.6.6 from original source, but its a
> 
> bit painful - does anyone know the exact source (including config) that
> 
> the distributed glib dll was built from ?
> 
> Neil
> ___
> Wireshark-dev mailing list
> Wireshark-dev@wireshark.org
> http://www.wireshark.org/mailman/listinfo/wireshark-dev
> 
> 
> ___
> Wireshark-dev mailing list
> Wireshark-dev@wireshark.org
> http://www.wireshark.org/mailman/listinfo/wireshark-dev
> 
> 



===
ip.access ltd  Tel: 01954 713715 Direct
2020 Cambourne Business Park   Fax: 01954 713799
Cambourne, Cambridge
Cambs, UK, CB3 6DW
Visit the website at http://www.ipaccess.com
===

vasnprintf.c.diff
Description: Binary data
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev

Re: [Wireshark-dev] Ideas regarding bug 1025?

2006-08-10 Thread Neil Piercy

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 crashes on test2 (in exactly the same manner 
as the whole wireshark app does with the test capture, so the test looks 
valid) - i.e. as soon as the upper 32 bits are non-zero. I'm trying to 
build a debug version of the glib-2.6.6 from original source, but its a 
bit painful - does anyone know the exact source (including config) that 
the distributed glib dll was built from ?

Neil
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev

[Wireshark-dev] Defending against NULL dissector handles

2006-08-09 Thread Neil Piercy

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 on some installations it just crashed wireshark 
(not helpful). I _think_ the difference was whether MSVC was installed 
or not, but on a sample of only 3 machines.


Should call_dissector include explicit null handle checks, and if so, 
should it:-


a) g_assert - the simple patch attached
b) fallback to doing a data decode (as disabled protocols do)
c) try to invoke the wireshark exception handling for the packet

Or is the correct answer none of the above - the exception handler 
should already cope ?


Neil
Index: packet.c
===
--- packet.c(revision 18852)
+++ packet.c(working copy)
@@ -1702,6 +1702,7 @@
 {
int ret;
 
+   g_assert(handle != NULL);
ret = call_dissector_work(handle, tvb, pinfo, tree);
if (ret == 0) {
/*
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev

Re: [Wireshark-dev] Ideas regarding bug 1025?

2006-08-04 Thread Neil Piercy

I did a little more investigation on this:

The crash only happens trying to display the response packets in the bug 
trace - handling the request packets is fine, and both go through the 
same execution path in this area. The big difference between the request 
and the response is that the _values_ of the 64 bit monotonic replay 
detection counter: the requests use very small values, the responses use 
huge values (i.e. all bytes of the 64 bit values are non-zero).

The crash definitely happens deep in the glib handling of the 
g_vsnprintf - I dont have a debug build of glib, but it looked 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 Piercy wrote:
> 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 Runtime Library error dialogue.
> 
> Not an area I know much about, but I can reproduce it - if this isnt 
> ringing any bells, drop me a line with where to look next, and I'll give 
> it a whirl.
> 
> Neil
> 
> proto_tree_set_representation(_proto_node * 0x02d6e418, const char * 
> 0x01489ad8, char * 0x0012e378) line 2938
> proto_tree_add_text(_proto_node * 0x02d6e4d8, tvbuff * 0x02cfba9c, int 
> 323, int 8, const char * 0x01489ad8) line 677 + 17 bytes
> bootp_option(tvbuff * 0x02cfba9c, _proto_node * 0x02cfb020, int 318, int 
> 376, int 0, int * 0x0012e478, const char * * 0x0012e488, const unsigned 
> char * * 0x0012e454) line 1211 + 42 bytes
> dissect_bootp(tvbuff * 0x02cfba9c, _packet_info * 0x02c1cef8, 
> _proto_node * 0x02cfb5c0) line 3162 + 35 bytes
> call_dissector_through_handle(dissector_handle * 0x02abd640, tvbuff * 
> 0x02cfba9c, _packet_info * 0x02c1cef8, _proto_node * 0x02cfb5c0) line 
> 387 + 18 bytes
> 
> Joerg Mayer wrote:
> 
>>Hello,
>>
>>On Linux, I can't reproduce the crash mentioned in
>>http://bugs.wireshark.org/bugzilla/show_bug.cgi?id=1025
>>Can someone please try to test this on Windows and maybe provide a stack
>>trace?
>>
>>Thanks
>> Joerg
> 
> 

-- 
=
ip.access ltd   Tel: 01954 713715
Building 2020,  Fax: 01954 713799
Cambourne Business Park,
Cambourne,
Cambridge, CB3 6DW, UK
Visit the website at http://www.ipaccess.com
=
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev

Re: [Wireshark-dev] Ideas regarding bug 1025?

2006-08-02 Thread Neil Piercy

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 Runtime Library error dialogue.

Not an area I know much about, but I can reproduce it - if this isnt 
ringing any bells, drop me a line with where to look next, and I'll give 
it a whirl.

Neil

proto_tree_set_representation(_proto_node * 0x02d6e418, const char * 
0x01489ad8, char * 0x0012e378) line 2938
proto_tree_add_text(_proto_node * 0x02d6e4d8, tvbuff * 0x02cfba9c, int 
323, int 8, const char * 0x01489ad8) line 677 + 17 bytes
bootp_option(tvbuff * 0x02cfba9c, _proto_node * 0x02cfb020, int 318, int 
376, int 0, int * 0x0012e478, const char * * 0x0012e488, const unsigned 
char * * 0x0012e454) line 1211 + 42 bytes
dissect_bootp(tvbuff * 0x02cfba9c, _packet_info * 0x02c1cef8, 
_proto_node * 0x02cfb5c0) line 3162 + 35 bytes
call_dissector_through_handle(dissector_handle * 0x02abd640, tvbuff * 
0x02cfba9c, _packet_info * 0x02c1cef8, _proto_node * 0x02cfb5c0) line 
387 + 18 bytes

Joerg Mayer wrote:
> Hello,
> 
> On Linux, I can't reproduce the crash mentioned in
> http://bugs.wireshark.org/bugzilla/show_bug.cgi?id=1025
> Can someone please try to test this on Windows and maybe provide a stack
> trace?
> 
> Thanks
>  Joerg

-- 
=
ip.access ltd   Tel: 01954 713715
Building 2020,  Fax: 01954 713799
Cambourne Business Park,
Cambourne,
Cambridge, CB3 6DW, UK
Visit the website at http://www.ipaccess.com
=
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev

Re: [Wireshark-dev] Repository updates

2006-07-13 Thread Neil Piercy

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: just major bugs fixes ?

If not, should the trunks be "trunk-1.0-stable" etc ? If so, what is the 
intended maintenance:  Cosmetic fixes ? New dissectors ? New capture 
methods ?

Should patches (for whatever maintenance regime is used) by the non-core 
team be produced as patches against the main trunk only, or all trunks - 
i.e. is the maintenance also community-driven or by the core developers 
taking decisions about which patches to apply to the non-main trunk(s) ?

This issue has bubbled around a bit, so I'm slightly hesitant even to 
raise it again, but I'm not convinced any answers were clearly 
communicated when the now-defunct trunk-1.0 was created, but its demise 
certainly reopens it IMHO.

Regards,
Neil

Gerald Combs wrote:
> As discussed last week, I've made the following changes to the SVN
> repository:
> 
>   Copied revision 18388 of "/trunk-1.0" to
>   "/prerelease/wireshark-0.99.1pre1".
> 
>   Moved "/trunk-1.0", "/branches", and "/tags" to "/historic".
> 
>   Copied "/trunk" to "/trunk-0.99.2".
> 
> I'm working on the 0.99.2pre1 release right now.
> 
> If you need any help visualizing the new repository layout, please
> visit
> 
> http://anonsvn.wireshark.org/wireshark/
> ___
> Wireshark-dev mailing list
> Wireshark-dev@wireshark.org
> http://www.wireshark.org/mailman/listinfo/wireshark-dev
> 

-- 
=
ip.access ltd   Tel: 01954 713715
Building 2020,  Fax: 01954 713799
Cambourne Business Park,
Cambourne,
Cambridge, CB3 6DW, UK
Visit the website at http://www.ipaccess.com
=
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev

Re: [Wireshark-dev] making register.c - python problem

2006-07-12 Thread Neil Piercy

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 by replacing line:
> 
>  @$(PYTHON) ../../tools/make-dissector-reg.py . dissectors
> $(DISSECTOR_SRC)
> 
> with
> 
>  @$(PYTHON) "../../tools/make-dissector-reg.py" . dissectors
> $(DISSECTOR_SRC)

My version of a fix was to replace all "/" with "\" for the native 
Windows (i.e. non-cygwin) tool usage in nmake-files.

Neil
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
http://www.wireshark.org/mailman/listinfo/wireshark-dev

[Wireshark-dev] ...and a minor AMR patch

2006-06-26 Thread Neil Piercy


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 the payload",
   &amr_encoding_type, encoding_types, FALSE);
 
+   register_dissector("amr", dissect_amr, proto_amr);
register_dissector("amr_if1", dissect_amr_if1, proto_amr);
register_dissector("amr_if2", dissect_amr_if2, proto_amr);
 }
___
Wireshark-dev mailing list
[EMAIL PROTECTED]
http://www.wireshark.org/mailman/listinfo/wireshark-dev

[Wireshark-dev] GSM A interface bug fix

2006-06-26 Thread Neil Piercy

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 name 
registration for the 2 other protocols which this file can provide - 
(which strikes me as indicative that it should really be split into the 
3 internal layers BSSMAP, DTAP and SMS RP).


Neil
Index: packet-gsm_a.c
===
--- packet-gsm_a.c  (revision 18574)
+++ packet-gsm_a.c  (working copy)
@@ -139,6 +139,7 @@
 { 0x2c,"LSA Information" },
 { 0x2d,"Perform Location Response" },
 { 0x2e,"Perform Location Abort" },
+{ 0x2f,"Common Id" },
 { 0x30,"Reset" },
 { 0x31,"Reset Acknowledge" },
 { 0x32,"Overload" },
@@ -14524,6 +14525,26 @@
 EXTRANEOUS_DATA_CHECK(curr_len, 0);
 }
 
+/*
+ *  [2] 3.2.1.68
+ */
+static void
+bssmap_common_id(tvbuff_t *tvb, proto_tree *tree, guint32 offset, guint len)
+{
+guint32curr_offset;
+guint32consumed;
+guint  curr_len;
+
+curr_offset = offset;
+curr_len = len;
+
+is_uplink = IS_UPLINK_FALSE;
+
+ELEM_MAND_TLV(gsm_bssmap_elem_strings[BE_IMSI].value, 
BSSAP_PDU_TYPE_BSSMAP, BE_IMSI, "");
+
+EXTRANEOUS_DATA_CHECK(curr_len, 0);
+}
+
 #defineNUM_GSM_BSSMAP_MSG 
(sizeof(gsm_a_bssmap_msg_strings)/sizeof(value_string))
 static gint ett_gsm_bssmap_msg[NUM_GSM_BSSMAP_MSG];
 static void (*bssmap_msg_fcn[])(tvbuff_t *tvb, proto_tree *tree, guint32 
offset, guint len) = {
@@ -14556,6 +14577,7 @@
 bssmap_lsa_info,   /* LSA Information */
 NULL,  /* Perform Location Response */
 NULL,  /* Perform Location Abort */
+bssmap_common_id,  /* Common Id */
 bssmap_reset,  /* Reset */
 NULL /* no associated data */, /* Reset Acknowledge */
 bssmap_overload,   /* Overload */
@@ -18141,13 +18163,13 @@
{
col_append_fstr(pinfo->cinfo, COL_INFO, "%s ", str);
}
-}
 
 /*
  * add BSSMAP message name
  */
 proto_tree_add_uint_format(bssmap_tree, hf_gsm_a_bssmap_msg_type,
tvb, saved_offset, 1, oct, "Message Type %s",str);
+}
 
 tap_p->pdu_type = BSSAP_PDU_TYPE_BSSMAP;
 tap_p->message_type = oct;
@@ -19260,6 +19282,8 @@
 gsm_a_tap = register_tap("gsm_a");

register_dissector("gsm_a_dtap", dissect_dtap, proto_a_dtap);
+   register_dissector("gsm_a_rp", dissect_rp, proto_a_rp);
+   register_dissector("gsm_a_bssmap", dissect_bssmap, proto_a_bssmap);
 }
 
 


common_id_crash.pcap
Description: Binary data
___
Wireshark-dev mailing list
[EMAIL PROTECTED]
http://www.wireshark.org/mailman/listinfo/wireshark-dev

45 matches

Mail list logo