I think it's much more easy to read the leading text and the value if
the details of the bitfields does not start the line. Ofcourse my
personal opinion, but mostly I do not care about the bits.
After committing this I wondered if it was worth it, i.e. it makes the
display less clean
On 16-Aug-2007 18:47:37 ZE5B, [EMAIL PROTECTED]
[EMAIL PROTECTED] wrote:
Hi,
If I have frame like for eg:-
45 60 76 87 23 97 00
Now in this frame starting 2 bit is header of one dissector now I want to
pass that frame to other dissector after removing the haeder.
If i change the tvb
On 8/13/07, Stig Bjørlykke [EMAIL PROTECTED] wrote:
Hi.
The etsie2e4.xml is missing from Makefile.am.
Should bugzilla be used for such small patches?
I don't know what the general answer to this is, but your patch is
committed with change 22495.
Thanks,
Martin
On 8/9/07, Luis EG Ontanon [EMAIL PROTECTED] wrote:
shouldn't we just be registering by name all dissectors for once and for
all?
I'd vote for that. I'm sick of (and a little self-conscious about)
making individual dissectors findable by name - usually so that the
DCT2000 dissector can find
That's pretty funny. I can't believe someone would take the time to
write the DTD for it!
On 8/8/07, Luis EG Ontanon [EMAIL PROTECTED] wrote:
http://tools.ietf.org/html/rfc3252 ?
:-)
On 8/8/07, [EMAIL PROTECTED] [EMAIL PROTECTED] wrote:
On 8/8/07, Lampe, Sebastian [EMAIL PROTECTED] wrote:
Hi,
we're working on XCAP and want to use Wireshark for testing and
analyzing network traffic. Will there be any possibility to Wireshark
for showing XCAP-Packets respectively planed for future releases?
Currently we have to filter for
Hi,
Please do send the code, preferably with one or more test captures (I
have examples for some of R6, but not all)!
Thanks,
Martin
On 7/19/07, Nitin Naveen [EMAIL PROTECTED] wrote:
Hi,
I generated dummy packets for WiMAX protocol. Saved the capture to a dummy
file wimax_ether.cap.
Then
- Some of the commands are not matching their entries from the XML
files (e.g. 275 which is in dictionary.xml)
I found the cause of this problem.
When running in RFC mode, it looks up only those commands in no_vnd.
What it should be looking up is *all* vendors. The hack below got
command
This looks pretty good, Luis.
I noticed some things that you may well already be aware of:
- when you find an unknown AVP, you no longer log it as an expert item
- I saw instances where the name shown in diameter.avp.code didn't
match the value field of the AVP, e.g. AVPs 17 and 18 (frame 115) in
No, I Wasn't aware... But that's the rationale in the commit early
commit often, the sooner a bug is committed (preferably along with
some other code :-) the shorter it takes for it to get noticed the
shorter it takes for it to be fixed.
It also reminds me of a pirate film I once saw. The
The old diameter dissector doesn't lie ruined at the botttom of the
sea, but hopefully people will help test/finish the new one.
On 7/16/07, Luis EG Ontanon [EMAIL PROTECTED] wrote:
On 7/16/07, Martin Mathieson [EMAIL PROTECTED] wrote:
It also reminds me of a pirate film I once saw. The gung
Are there really any cases where AVPs have the same code and the same
vendor ID but different meanings under different application IDs?
There are plenty of places in the 3GPP specs where an AVP defined in
one interface/application id is used in another one. Would you only
use the app id to
On 7/10/07, Luis EG Ontanon [EMAIL PROTECTED] wrote:
A year or more ago I abandoned a way towards (3) (similar to what I
did for radius dictionary) a while ago, due to a personal lack of
diameter use after switching jobs and a stall about how to handle
recursion in attribute_groups.
I will
useful.
On 7/11/07, Luis EG Ontanon [EMAIL PROTECTED] wrote:
On 7/11/07, Martin Mathieson [EMAIL PROTECTED] wrote:
On 7/10/07, Luis EG Ontanon [EMAIL PROTECTED] wrote:
I wondered if MATE or the LUA support could make this kind of
filtering possible, but dynamically creating filters
That expression will match any frame that has at least one avp with
code value 829 and at least one avp whose data is uint32 whose value
is 1.
I suspect that what you want is to match the *same* AVP with both
parts of the expression, which I don't think is possible with a simple
display filter.
There are several ways this could be tackled:
(1) A script. Export capture to PDML, parse output and match/check
them yourself
(2) We could add a new filterable field, diameter.avp, whose type was
hex data. You could right-click to create a filter for that AVP, then
edit the last word to check
OK, I just implemented (2) with change 22284.
You should be able to right-click on a whole AVP that matches the code
you're interested in, choose 'Prepare as Filter | Selected', edit the
last 4 bytes and apply it.
Martin
On 7/10/07, Martin Mathieson [EMAIL PROTECTED] wrote:
There are several
I'm seeing this error when starting wireshark (despite tshark below in
the error output).
Ronnie - will you be adding samr.hnd back again as a field, or should
this filter expression (in packet-smb-sidsnooping.c) be changed now?
tshark: Couldn't register
Assuming you're using xmllib, the quick fix for you would be to remove
the IMS-Information entry from diameter/chargecontrol.xml and rely
upon the better-looking entry in dictionary.xml.
I'm not sure why these AVPs are defined in both places
Martin
On 7/5/07, cco [EMAIL PROTECTED] wrote:
[EMAIL PROTECTED] wrote:
On Thu, Jul 05, 2007 at 01:40:55PM +0100, Martin Mathieson wrote:
Assuming you're using xmllib, the quick fix for you would be to remove
the IMS-Information entry from diameter/chargecontrol.xml and rely
upon the better-looking entry in dictionary.xml.
I'm not sure why
there's nothing to
highlight in the data (because it's not there).
--kan--
-Original Message-
From: [EMAIL PROTECTED]
[mailto:[EMAIL PROTECTED] On Behalf Of Martin Mathieson
Sent: Friday, June 29, 2007 12:39 PM
To: Developer support list for Wireshark
Subject: Re: [Wireshark-dev] Proper
Hi,
Does anyone know of a free version of od for use with Windows? (I'm trying
to create some test captures using text2pcap).
I found xd but it doesn't support the -w flag to set the line width
Thanks,
Martin
___
Wireshark-dev mailing list
or
2) just use Intel's dissector by getting a recent buildbot build.
___
Intel has supplied dissectors for wireless interface protocols. I
understand that WiMAX involves other interfaces/protocols (it looks like the
air interface may be R1
Hi,
I think this regression is related to Gerald's change 21898, whose log
message was:
Don't set the focus on the display filter entry when we're passed a
contorl- or alt-modified character. Fixes bug 1610.
I notice that pressing down control or alt doesn't affect the value of
event-keyval
On 5/3/07, Kriang Lerdsuwanakij [EMAIL PROTECTED] wrote:
Hello
This patch adds the handling of Spare Extension bytes
to UMTS Frame Protocol. It also handles the case when
the presence of CRC in dedicated channels is not known
(i.e. when FP from a K12/K15 log is dissected).
The new
]
[mailto:[EMAIL PROTECTED] On Behalf Of Martin Mathieson
Sent: den 26 april 2007 13:20
To: Developer support list for Wireshark
Subject: Re: [Wireshark-dev] [Wireshark-commits] rev
21556:/trunk/epan//trunk/epan/: proto.c proto.h - all buildbots rednow :-(
Anders,
I've tried the functions (with new
I've had a play with this function, I like it - it can improve and
simplify parts of packet-umts_fp.c which are bit-oriented, like E-DCH
data. Having the function spit out the return value is helpful here,
as this will avoid the dissector doing the equivalent shiting and
masking work for a second
Hi Toralf,
My workaround at the moment is to update with this command:
svn update svn update -r 21451 epan/dissectors/packet-ieee80211.c
Martin
On 4/20/07, Jeff Morriss [EMAIL PROTECTED] wrote:
Toralf Förster wrote:
After some of the last SVN updates I get now:
...
Hi,
My build is failing to link from this revision onwards. The error
output is the following:
gcc -DINET6 -D_U_=__attribute__((unused)) -Wall -Wpointer-arith -W
-g -O2 -Wdeclaration-after-statement -I/usr/local/include -DXTHREADS
-D_REENTRANT -DXUSE_MTSAFE_API -I/opt/gnome/include/gtk-2.0
I just noticed (when trying to build with packet-ieee80211.c removed
from epan/dissectors/Makefile.common) that my config.h has the
following:
/* Enable AirPDcap (WPA/WPA2 decryption) */
#define HAVE_AIRPDCAP 1
Is this correct?
Martin
On 4/17/07, Martin Mathieson [EMAIL PROTECTED] wrote:
I've
Hi Andrej,
There wasn't any follow-up to my query. I'm afraid I've come to
prefer the 'Expert Info Composite' view.
I just tried to reproduce the problem with my up-to-date build (it
doesn't have the patch from the previous email), and everything looks
OK. I disabled colour highlighting and
Currently, you don't tend to even notice new warnings that you introduce
on your own platform, as they get lost in the general compilation noise.
Part of the problem (when working from the command-line at least) is
how much output is generated, and how far you'd need to scroll back to
see the
This patch only touches K12's part. There are a few parameters
for FP that the patch still does not provide together with my idea for
future
work:
- The UMTS release number - This will go into a preference setting. FP
dissector
should use a default release from preference when it is not given
Richard,
I remember struggling with this when writing the Microsoft Media
Server protocol (packet-ms-mms.c), but it did seem to work.
It was ideal for me for 2 reasons:
(1) tcp_dissect_pdus() doesn't work for new-style dissectors that can
reject data
(2) in that protocol large PDUs can be
This is the end of the Windows buildbot log, very similar to my linux
build failure (I build with libpcap support enabled).
I don't have time to dig into it this morning...
Martin
Linking wireshark.exe
link @C:\DOCUME~1\buildbot\LOCALS~1\Temp\nma02516.
ringbuffer.obj : error LNK2001:
On 1/27/07, Kriang Lerdsuwanakij [EMAIL PROTECTED] wrote:
With above 3 changes together, dissecting Iub traces are correct for
control and signaling planes. I am still investigating user plane
frames because writing UMTS RLC/MAC protocol dissector is required.
.
Hi Kriang,
This is very
Could you please test with latest svn rev (20479 or later) or send a
capture file?
Regards,
Martin
On 1/18/07, rmkml [EMAIL PROTECTED] wrote:
Hi,
Im found this event :
14 14:31:11.880727 00:09:11:e4:17:bb - 01:00:0c:cc:cc:cc UDLD
[Dissector bug, protocol UDLD: proto.c:1096: failed
Is this useful?
Martin
GNU gdb 6.2.1
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type show copying to see the conditions.
There is
On 1/4/07, Martin Mathieson [EMAIL PROTECTED] wrote:
On 1/3/07, Guy Harris [EMAIL PROTECTED] wrote:
Martin Mathieson wrote:
For the more general problem, I see 2 possible solutions:
(1) have both signed and values in the union, and use the appropriate
signed or unsigned parts
Hi,
I notice that the whole Tools menu is not available unless HAVE_LUA_5_1
is defined (it isn't for me, I don't have Lua installed yet).
How should this be fixed?
Martin
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
)?
Regards,
Martin
LEGO wrote:
As I added that menu for Lua's use I thought that having an empty menu
would not be nice so I excluded it when Lua isn't there.
On 10/2/06, Martin Mathieson [EMAIL PROTECTED] wrote:
Hi,
I notice that the whole Tools menu is not available unless HAVE_LUA_5_1
OK, done.
LEGO wrote:
You are right, that's how it should have been.
That's to be applied!
On 10/2/06, Martin Mathieson [EMAIL PROTECTED] wrote:
The top-level 'Tools' menu *does* appear for me, but is empty.
I (wrongly) thought that I was missing existing menu items (i.e. not
relating
Its trying to print the value of an FT_NONE field, which ends up looking
at uninitialised bytes.
The attached patch doesn't write the show attribute for FT_NONE
fields, but does this result in well-formed PDML?
Best regards,
Martin
[EMAIL PROTECTED] wrote:
Andreina,
If the RTP session is properly exchanging RTCP sender receiver
reports, wireshark can calculate the network roundtrip delay in both
directions (i.e. the time in milliseconds it takes the RTCP reports to
travel from the point of capture to either RTP endpoints and back
again). To
VoIP calls
Guys,
Thanks for your efforts, as I am not a developer, I await 0.99.3 with
interest.
Keith French.
- Original Message -
From: Martin Mathieson [EMAIL PROTECTED]
To: Developer support list for Wireshark wireshark-dev@wireshark.org
Sent: Tuesday, July 25
: [Wireshark-dev] Small [Patch] to H.323 VoIP calls
Guys,
Thanks for your efforts, as I am not a developer, I await 0.99.3 with
interest.
Keith French.
- Original Message -
From: Martin Mathieson [EMAIL PROTECTED]
To: Developer support list for Wireshark wireshark-dev
Martin Mathieson wrote:
name [A-Za-z][-a-z0-9_]*[-a-zA-Z0-9_]*
Wouldn't
[A-Za-z][-a-zA-Z0-9_]*
suffice? ([...]* matches zero or more occurrences, and [-a-zA-Z0-9_] is
a superset of [a-z0-9_].)
That would have been the obvious fix to make in the first place, I was
lazily
I missed out a patch to add the new header file to
epan/dissector/Makefile.common
Thanks,
Martin
Martin Mathieson wrote:
Hi,
These patches:
- allow SDP to parse the IP address + port for the MSRP session from
the path attribute
- setup an MSRP conversation using this address, whose data
Guy Harris wrote:
On Jun 27, 2006, at 5:51 AM, Martin Mathieson wrote:
Looking at frame 170 in the trace, it looks like
tvb_get_ephemeral_text() struggles with the null character in the
middle of the 4th parameter (in the WWW-Authenticate header) and
returns NULL.
That shouldn't
Martin Mathieson wrote:
Joerg Mayer wrote:
On Wed, Jul 19, 2006 at 06:51:26PM +, [EMAIL PROTECTED] wrote:
http://anonsvn.wireshark.org/viewvc/viewvc.cgi?view=revrevision=18766
User: etxrab
Date: 2006/07/19 06:51 PM
Log:
From Martin Mathieson:
This patch:
- adds headers found
Hi,
Here is a DTD for xcap-caps and changes needed to install it (nsi change
is untested).
Regards,
Martin
? wireshark:protocol
proto_name=xcap-caps
description=XML Configuration Access Protocol Server Capabilities
hierarchy=yes ?
!--
$Id: reginfo.dtd 18248 2006-05-29 20:44:06Z
Hi,
Mike Oliveras has indicated that for MGCP voip calls, 2 seconds may be a
better timeout for still matching DLCX requests to a hung-up endpoint,
as in this patch.
Regards,
Martin
___
Wireshark-dev mailing list
Wireshark-dev@wireshark.org
PROTECTED] on behalf of Martin Mathieson
Sent: Tue 7/4/2006 11:49 AM
To: Developer support list for Wireshark
Subject: [Wireshark-dev] [Patch] to voip_calls.c (bug 892 again)
This time with patch attached
Hi,
Mike Oliveras has indicated that for MGCP voip calls, 2 seconds may be a
better timeout
301 - 353 of 353 matches
Mail list logo
