On Wed, Oct 20, 2010 at 04:07:22AM -0700, Guy Harris wrote:
>
> On Oct 20, 2010, at 3:42 AM, cco wrote:
>
> > why is wireshark so slow when loading up >500 MB pcaps?
>
> Are you saying that the time taken to read a file, as a function of the size
> of the file, is di
hi!
why is wireshark so slow when loading up >500 MB pcaps?
is there any configuration trick to speed this up?
thanks!
bye now!
cristian
___
Sent via:Wireshark-dev mailing list
Archives:http://www.wireshark.org/lists
hi!
I am using ethereal Version 0.10.14-SVN-17749 on linux.
tbcds are not correctly shown in ascii (as isdn tel. numbers), at least in
map payloads; more specifically the tbcd nibbles:
1010 (*), 1011 (#), 1100 (a), 1101 (b) or 1110 (c)
are not correctly "translated" to a textual representation.
hi!
how exactly does wireshark distinguish the sua packets that carry an
ansi tcap payload from the ones that carry an itu one?
for example I am seeing sua packets having the same destination ssn (and
source ssn) whose payload is decoded as ansi tcap sometimes and as a itu
(gsm map) tcap sometime
On Tue, Jul 10, 2007 at 06:49:37PM +0100, Martin Mathieson wrote:
> 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.
cristian:
On Tue, Jul 10, 2007 at 08:42:15PM +0200, Luis EG Ontanon 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_gro
hi!
has anyone tested a filter like this:
(diameter.avp.code == 829) && (diameter.avp.data.uint32 == 1)
is it suppossed to work? is it actually working in your config/ver?
in my version, it does not in the sense that it will always show all the
diameter commands having an avp with the code 829 b
On Thu, Jul 05, 2007 at 06:22:19PM +0100, Martin Mathieson wrote:
> When enumerated is used it uses 4 bytes for the data...
>
> From RFC 3588:
>
> Enumerated
> Enumerated is derived from the Integer32 AVP Base Format. The
> definition contains a list of valid values and their
>
On Thu, Jul 05, 2007 at 04:58:17PM +0100, Martin Mathieson wrote:
> Change the type-name attribute to "Time".
>
> Someone (maybe me, but not for a few days at best) needs to
> rationalise these duplicated AVPs (between dictionary.xml and
> chargecontrol.xml). Anders?
>
> If you get it dissecting
hi!
the people designing ntp came up with a timestamp format which rolls over
every 136 years (weren't there already so many broken timestamp
formats?). here is the an execerpt from rfc2030 which clarifies things:
As the NTP timestamp format has been in use for the last 17 years,
it
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 these AVPs are def
hi!
the following avp:
IMS-Information(876) defined by 3gpp for the rf interface is not
correctly parsed by my wireshark (Version 0.99.4)
anyone having the same problem? any quick fix?
thanks!
bye now!
cristian
___
Wireshark-dev mailing list
Wireshark-d
On Wed, Nov 29, 2006 at 09:50:21AM +0100, cco wrote:
> On Tue, Nov 28, 2006 at 02:46:01PM +0100, Anders Broman (AL/EAB) wrote:
> >
> >
> > -Original Message-
> > From: [EMAIL PROTECTED]
> > [mailto:[EMAIL PROTECTED] On Behalf Of cco
> > Sent: den 2
On Tue, Nov 28, 2006 at 02:46:01PM +0100, Anders Broman (AL/EAB) wrote:
>
>
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of cco
> Sent: den 28 november 2006 11:56
> To: Developer support list for Wireshark
> Subject:
hi!
it seems that wireshark fails to access a previous saved state when the
specified psi is longer than 6 bytes. and yes, the state was saved at
END-MESSAGE(); at least this is what the debug message reports.
here is the scenario:
1. sigcomp pkt with bytecode is recv. sucessful decompression,
On Wed, Nov 22, 2006 at 11:08:51PM +0100, Anders Broman wrote:
> Hi,
> If the corresponding type 2 message with the bytecode isn't in the trace
> Wireshark can't decode the message.
>
> If you still think there is a problem we'd need the trace to be able to
> locate the problem.
cristian: hi ande
On Wed, Nov 22, 2006 at 11:08:51PM +0100, Anders Broman wrote:
> Hi,
> If the corresponding type 2 message with the bytecode isn't in the trace
> Wireshark can't decode the message.
cristian: the sigcomp message which creates the state is also captured
and decompressed by ethereal.
> If you still
hi!
during some tests I have seen some (possible) misbehaviour of the
sigcomp dissector: it cannot decompress a type 1 message (state access)
which is actually decompressed by one of the peers. it seems to have to do
with state management. (there are 3 nodes using sigcomp in the network
where the
18 matches
Mail list logo
