problem became evident with an update from autoconf 2.52 to 2.53).
Worked around a bug in libtool that caused -dlopen to be ignored (and
things being linked into the code instead).
Many many thanks to Dirk M�ller for providing me with the workaround!
svn path=/trunk/; revision=7991
change the decode of sequence and extensions to assume the lower bound for the number of extensions is 1 and thus 1 have to be added to the encoded value.
dont know if this is right or not, the satndard x691 does not mention anything
about the lb being 1 and the value being semiconstrained but a note at 18.8
does mention that the number of extensions can not be 0.
i think there is a difference between saying a value can not be zero and
between saying the lower bound is 1. but hey it is a telco standard.
the change might be right or it might be wrong.
i think it is wrong or else the standard is wrong.
it at least dissects the very few captures i have properly.
telco guys, either give feedback or live with the dissector being potentially
wrong.
its that easy.
svn path=/trunk/; revision=7990
for the individualk bits in the bitmap field for whether each extension
is present or not, add "(<extension name> [is|is NOT] present)" to the
tree item.
this makes the dissection of the extension bitmap more meaningful
svn path=/trunk/; revision=7988
for the individual bits, if we know the name of the optional field
then put "<field name> [is|is NOT] present" into the tree pane
so we can see what each bit in this field refers to.
svn path=/trunk/; revision=7987
"coding_std_vals[]".
Add a bunch of cause codes from Q.850.
Use "q2931_rejection_reason_vals[]", not "q2931_cause_condition_vals[]",
for rejection reason values.
svn path=/trunk/; revision=7984
unused; presumably it'll either
1) get written, in which case if an argument isn't used it
shouldn't be supplied
or
2) be removed, in which case there aren't any arguments.
svn path=/trunk/; revision=7983
the network type being 1 and the byte after it being 2; we assume, for
now, that the network type is 1 byte, and that if the byte after it is
0, the network type is an NDIS type - 1, and if it's 2, it's an NDIS type.
svn path=/trunk/; revision=7973
have plugin support. (Don't do so if we *do* have it, because if
"proto_init()" ever changes so that it doesn't use the argument even if
we have plugin support, we want a warning so we know that we should get
rid of that argument.)
svn path=/trunk/; revision=7972
RFC2833 is a bit "unclear" but I guess this type is encoded
as first a length-determinant followed by the actual ascii data.
I belive the length-determinant is byte aligned in aligned-per so the entire
field is so.
at best, this is pure guesswork but it does decode the single capture i do have containing GeneralString types properly.
Anyone interested are welcome to purchase and provide
proper h323 standard docs from itu-t and snail-mail them to me.
A random asn file from www.packetyzer.com together with the X.691 pdf file is
"difficult".
svn path=/trunk/; revision=7969
Replace dissect_h245_TransportAddress() which was the generic decoder for the TransportAddress sequence with several semi-identical routines that matches the name of the field (instead of the type).
This makes the presentation easier to read.
e.g. Present this ip address as mediaChannel which is the field name instead of as TransportAddress
svn path=/trunk/; revision=7967
connection to check for addresses and ports at the same time, rather
then checking the source addresses, destination addresses, and ports
separately, as the latter doesn't handle A:X->B:Y and B:X->A:Y both
being active connections.
svn path=/trunk/; revision=7966
itself, so we leaked memory when freeing the interface list; in
"free_interface_list()", use "g_list_foreach()", calling a list free
routine, to free the data items in the list, and then use
"g_list_free()" to free the list.
Use "free_interface_list()" in "get_interface_list()" to free the list
if we have an error, as it now does what the code that use to be there
did.
svn path=/trunk/; revision=7965
Short Message reassembly;
Preference to allow automatic decoding of Short Message data as
CL-WSP if a Port Number UDH is present.
Use "%u" rather than "%d" for unsigned quantities.
Use "tvb_get_ntohs()" to fetch big-endian 16-bit quantities rather than
calling "tvb_get_guint8()" twice and reassembling yourself.
svn path=/trunk/; revision=7960
"tvb_get_string()" rather than "tvb_format_text()". (This fixes a
problem wherein we freed the return value of "tvb_format_text()", which
we should not do as "tvb_format_text()" doesn't dynamically allocate the
buffer it returns, but means that we don't handle non-printable
characters - but that's a problem with "cb_wstr_postprocess()" as well,
as "tvb_fake_unicode()" also doesn't handle non-printable characters
specially; we should fix the problem in *both* routines.)
svn path=/trunk/; revision=7955
UDH dissection in SMPP message
WTP and WSP dissection over SMPP (no reassembly)
WSP status code rendering in Info column
svn path=/trunk/; revision=7954
source files, so that they're not defined in every file that includes
the header file, regardless of whether the file uses the table (in which
case it should be defined in one file, and externally referenced in
other files) or not (in which case it should't be defined in that file
at all).
Get rid of a boilerplate comment paragraph that doesn't apply.
svn path=/trunk/; revision=7952
don't assume that a dissector handle has a protocol associated
with it (there's none for the "OSI network layer" dissector, for
example, as that dissector hands off to one of several protocols
based on the NLPID);
rename a few functions to have names that better explain what
they do;
have separate functions to show all the layer types (dissector
tables) and to show all the protocols supported for a layer
type, and have both of them take, as an argument, the standard
I/O stream to which they should write;
improve the parser for the "-d" option to give more information
on errors;
fix up some comments.
svn path=/trunk/; revision=7949
rathe than the record length minus the record header length, as the
number of available (captured) bytes in the packet. Check to make sure
that value isn't bigger than the record length minus the header length.
Only subtract the 4-byte FCS length from the purported length of the
packet on the wire if that would leave the on-the-wire length >= the
number of captured bytes, so that we can better handle capture files
from programs that produce LANalyzer-format captures where the
on-the-wire length *doesn't* include the FCS.
svn path=/trunk/; revision=7948
Guy Harris