packet-h245.c:13932: warning: invalid storage class for function `dissect_h245_RedundancyEncodingElement'
by moving the function declarations outside other functions
svn path=/trunk/; revision=9631
and NO_PORT_B - the corresponding flags have the same values, but they
don't have the same semantics (a "find_conversation()" call with a
missing address or port B will do a wildcard match on *both* addresses
or ports, not just the second one).
svn path=/trunk/; revision=9604
compatible with and dissect the packets from Martin R and Paul H.
I still think ethereal was correct before this patch and that
this patch is not compatible with teh standard.
Anyway, that doesnt matter much. With this patch ethereal will dissect the packets properly.
Time to study x691 again.
svn path=/trunk/; revision=9066
1) string tables for t35CountryCode, t35Extension and
h221ManufacturerCode were moved into the new file t35.c
because they are common for more dissectors
2) the dissect_h245_NonStandardParameter_with_extension_marker()
was moved from h245 to h225 and renamed to
dissect_h225_NonStandardParameter() because the
NonStandardData type is different for H.225.0 and H.245
3) type of the "h245.nsp.object" dissector table was changed from
FT_UINT32 to FT_STRING, so it can select a dissector based on
an OID rather than the Adler-32 hash of an OID
4) the "h225.nsp.object" and "h225.nsp.h221" dissector tables
were created
svn path=/trunk/; revision=8550
it is currently done in a way too crude way,
when a h245 endpoint is found, it calls dissector_add("tcp.port",...) and
thus registers it globally for this port for ALL ip addresses.
if someone knows how to change it to only register it for
<ipaddress><tcpport> instead, that would be much better.
svn path=/trunk/; revision=8120
constrained integers with an extension marker.
Update all calls to the constrained integer dissector
Add dissection to the rfc_number type which is a constrasined integer with an extension marker
Add H245 so that it builds by default in ethereal.
It has been tested extensively by a semi-large number of people with a lot of real and synthetic captures and seems to work very well.
New protocol added to ethereal
svn path=/trunk/; revision=8032
and put them in their own file.
I had to put them im packet-per.c instead of asn1-per.c since othervise
i couldnt get it to invoke the register routine from register.c
the per dissector is compiled into ethereal by default, but there are no callers in ethereal until the h245 dissector is added.
someone that knows the registry stuff better might consider renaming it to asn1-per.c instead of packet-per.c
svn path=/trunk/; revision=8017
IA5String when tehre are no restriction on the alphabet is actually just an octet string
start populating the COL_INFO with request/response commandname
COL_INFO will be tricky to get nice.
we might needs some hack to pass different values around through the dissect_per layer so can format values from different parts/subdissector functions nicely.
svn path=/trunk/; revision=8013
It looks like the constrained version of IA5String might be encoded as
a constrained integer followed by (byte aligned) a list of ASCII bytes makeing up shte string.
svn path=/trunk/; revision=8009
use proto_tree_add_item() instead of proto_tree_add_string() since there is nothing that says the string will be null terminated.
svn path=/trunk/; revision=8006
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
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
Guy Harris