Hi,
BTW the H.450 is reimplemented now with similar structure like Q.932/QSIG.
See attached picture.
Regards,
Tomas
> -Original Message-
> From: [EMAIL PROTECTED]
> [mailto:[EMAIL PROTECTED] On Behalf Of
> Anders Broman
> Sent: Monday, July 30, 2007 9:24 PM
> To: 'Developer suppor
Committed revision 22427.
When a packet is selected, it creates a cache (hash table) of all the
usable fields (FT_NONE and FT_PROTO are not, some of those had no
value and crashed so I just avoided them) marking duplicates as
unusable, if a (user defined) macro name is not found it looks for it
All,
I tried to build wireshark 0.99.6 on several platforms and I discovered
several problems I'm reporting on this email.
I haven't been following up the mailing list, so I don't know if they
are known problems or not. Anyway:
[1] When building a rpm package, the rpm build fails because of a
I was under the impression that remote desktop only supports 256 colors,
that's why I didn't specify the bit depth, but yes, that's the problem
exactly.
FYI: I did manage to change the default color scheme to something else
so that the text could be viewed. A few color schemes that seem to
work:
Maynard, Chris wrote:
> It seems that when running Wireshark 0.99.6 over a Windows XP Remote
> Desktop connection, there's a problem with the color palette, such that
> the text color is always white, rather than black. While it makes the
> text hard to read on a gray background, some areas of the
It seems that when running Wireshark 0.99.6 over a Windows XP Remote
Desktop connection, there's a problem with the color palette, such that
the text color is always white, rather than black. While it makes the
text hard to read on a gray background, some areas of the screen have a
white backgroun
Hi,
I have plans to change the TCAP dissection to use the original unchanged
ASN1 code and to split it into ITU TCAP and ANSI TCAP with heuristic
Determination of ANSI TCAP i.e ITU TCAP will be the main dissector.
Doing this also means a slight change to the TCAP dependent
Dissectors - dissection w
Michael Rogovin wrote:
> Hi,
>
> I'd like to request to register the icmp dissector in the future
> versions, by adding
> register_dissector("icmp", dissect_icmp, proto_icmp);
> in the proto_register_icmp.
>
> I rely on this dissector in my plugin. Could we add it to the next version?
Sure, wh
Great, thanks a lot!
Jeff Morriss wrote:
> Michael Rogovin wrote:
>
>> Hi,
>>
>> I'd like to request to register the icmp dissector in the future
>> versions, by adding
>> register_dissector("icmp", dissect_icmp, proto_icmp);
>> in the proto_register_icmp.
>>
>> I rely on this dissector in my
Florent Drouin wrote:
>Hi,
>
> I have found the problem, so I did add the same protection, found in
> expert.c, again "read filter" in the tcap tap. Thanks for pointing this
> bug.
> I did rename the decoding function for ANSI and ITU as suggested.
> And by the way, I did correct when a diss
Jaap Keuter wrote:
> so this has no place in production code. Shouldn't we rip it out?
+1 for that idea. :-)
> Jeff Morriss wrote:
>> Jaap Keuter wrote:
>>> Hi,
>>>
>>> Can anyone tell me why this hideous hack is in the m2m plugin?
>> My reading of it is that someone was re-using (in his/her
Hi Markus,
Two things.
First we've recently changed our patch submission policy, instead of
posting to the lis you can attach you patches to a bugzilla entry and
request review for submission. This is done to not let patches, like
yours, get overlooked.
Second you patch reverts back to the Ethere
don't bother... cf_select_packet() is the place I was looking for
On 7/30/07, Luis EG Ontanon <[EMAIL PROTECTED]> wrote:
> Where in gtk/*.c a packet gets selected?
>
>
> On 7/25/07, Luis EG Ontanon <[EMAIL PROTECTED]> wrote:
> > On 7/25/07, Ulf Lamping <[EMAIL PROTECTED]> wrote:
> > > Luis EG Onta
Where in gtk/*.c a packet gets selected?
On 7/25/07, Luis EG Ontanon <[EMAIL PROTECTED]> wrote:
> On 7/25/07, Ulf Lamping <[EMAIL PROTECTED]> wrote:
> > Luis EG Ontanon schrieb:
> > > On 7/25/07, Luis EG Ontanon <[EMAIL PROTECTED]> wrote:
> > >
> > >> If we consider this dynamic condition that a
Jaap Keuter <[EMAIL PROTECTED]> has granted Mike Duigou
<[EMAIL PROTECTED]>'s request for review_for_checkin:
Bug 1712: Add 'application/json' to list of text media types
http://bugs.wireshark.org/bugzilla/show_bug.cgi?id=1712
___
Wireshark-dev mailing li
Hi
Sorry but I can't use bugzilla. https (bug 192)
it's revision 21618 the culprit. pref reinit callbacks are only called if
prefs are changed or aren't the default so sometime http dissector doesn't
register itself.
Didier
___
Wireshark-dev mailing l
Does following scenario occur with anybody's installation, too?
I am using Visual Studio 8 to compile wireshark and my dissector.
Everything works fine, so far.
But when I put my dissector dll on another machine, where the original
Wireshark (0.99.6) is installed, Wireshark shows strange behaviou
Hello Luis,
I add a look to the SCCP association, and I must say that it is a good
idea to have a uniq code for all this kind associations. So I agree on
your proposal.
I will analyze deeper how works the SCCP association and the se_tree, to
see what changes are needed.
In my last mail, I
TCAP uses the same mechanism for mantaining sessions that SCCP uses
(also SUA, ALCAP, GTP-C and others do)
A->B SETUP (orig-key=keyA)
B->A SETUP-CONFIRM (orig-key=keyB, dest-key=keyA)
...
A->B MSG (dest-key=keyB)
B->A MSG(dest-key=keyA)
...
A->B RELEASE ([orig-key=keyA],dest-key=keyB)
B->A RELEASE
Hi,
I have found the problem, so I did add the same protection, found in
expert.c, again "read filter" in the tcap tap. Thanks for pointing this bug.
I did rename the decoding function for ANSI and ITU as suggested.
And by the way, I did correct when a dissector want's to unregister it's
ss
20 matches
Mail list logo
