["Ronnie Sahlberg" <ronnie_sahlberg@xxxxxxxxxxxxxx>]

I am pretty sure your fix is wrong and the real problem is that your
implementation that generated the packet is broken.
Your fix does cause ethereal dissect that particular packet in the way you
wish it to do but it does not dissect it according to the ASN.1
definition of h.245.

As Guy wrote below, the definition for this type is :
signalType
                 IA5String(SIZE (1) ^ FROM ("0123456789#*ABCD!")),

but the alphabet string passed to
"dissect_per_restricted_character_string()" is "!#*0123456789ABCD".

Note that ethereal specifies the alphabet using a different order of the
possible characters.
The reason for this is that  a restricted alphabet in ASN.1 does not require
the individual characters in the alphabet to be specified in any
given order.   You can rearrange them any way you want and it will still
describe the same restricted alphabet and the encoding will still be the
same.
Thus  IA5String(SIZE (1) ^ FROM ("0123456789#*ABCD!")),
is equivalent and is encoded in exactly the same way as IA5String(SIZE (1) ^
FROM ("DCBA9876543210#*!")),
When restricted alphabets are used, the individual characters in the
restricted subset will automatically be reordered in the order they
appear in some table in the standard (the ASCII value order?)

Anyway, Ethereal does NOT do this reordering of the individual characters
byt REQUIRES the alphabet to be specified in the order the
characters will be assigned values. That is why the alphabet characters are
specified in a different order.


OK. Now look at how the characters in a restricted character string is
encoded:
For a restricted string, each character in the string will be encoded as a
bitfield of as many bits that are required to represent the
entire restricted alphabet.  I.e.  We need n number of bits to describe 2^n
or less restricted characters.
For ALIGNED PER (which this uses) there is an additional restriction  : the
number of bits used to represent each restricted character must also
be a power of two.
I.e.  in ALIGNED PER the number of bits used to encode each character MUST
be either 1,2,4 or 8.

This alphabet consists of 17 characters.  We need 5 bits to be able to
represent 17 different values. However since we use ALIGNED PER,
5 bits per character is not legal so we go to the next larger valid number:
8

Each character in the string is thus encoded as 8 bits.   (would only be 5
bits for UNALIGNED PER)


The values used in the encoding starts at 0 and is incremented with 1 for
each character in the restricted alphabet :
Thus hte characters would then be encoded as 8 bit values with the following
values:
!     0x00
#    0x01
*    0x02
0    0x03
1    0x04
2    0x05
3    0x06
4    0x07
5    0x08
6    0x09
7    0x0a
8    0x0b
9    0x0c
A    0x0d
B    0x0e
C    0x0f
D    0x10

These are all the possible values in the restricted aplhabet.
Each character is encoded as 1 BYTE   the ONLY legal values in this encoding
are 0x00 to and including 0x10.


When the PER dissectors in ethereal dissects a restricted character string
that contains an illegal value, ethereal will replace that character with
'?'
This is why ethereal dissects it and shows it as '?' even though '?' is not
part of the alphabet.



SIZE (1) ^ FROM ("0123456789#*ABCD!")),
means that the stuff is to be encoded according to the intersection of both
restrictions
=>  the value should be encoded as exactly 1 character from the restricted
alphabet.


The ONLY way that the change you did would change ehtereal to dissect it as
'!' would be if your implementation
was broken and generated the encoding as if the standard said
IA5String(SIZE (1))
This would ALSO encode the field as a character of 8 bits.
However for this field, all values 0x00 toi 0xff would be allowed and the
character that would be encoded would be the one
represented by the (ASCII?) table for ASN.1 that describes the order of
characters.

I would check the implementation that it handles INTERSECTIONS properly.
The only way I can see your fix helping would be if your encoder can not
parse INTERSECTIONS properly.



I.e.   as far as I can see, ethereal is right and the thing that created
this packet is broken.
I could be wrong.





----- Original Message ----- 
From: "Paul Higgs (CA/EUS)"
Sent: Thursday, November 20, 2003 12:38 PM
Subject: RE: [Ethereal-users] Problem with h245 dissector


Hi Guy

I'm guessing (my first look at the code was yesterday) that the
"dissect_per_restricted_character_string()" is designed for something else
(of is broken for single character representation)

Basically I modified dissect_h245_signalType to be

static int
dissect_h245_signalType(tvbuff_t *tvb, int offset, packet_info *pinfo,
proto_tree *tree)
{
offset=dissect_per_IA5String(tvb, offset, pinfo, tree, hf_h245_signalType,
1, 1;

return offset;
}
and the results of the decode were exactly as I expected ( signalType: ! )
but of course without any validity check.

Having some dissect_per_restricted_IA5string() function would be the better
overall solution.

Paul

-----Original Message-----
From: Guy Harris [mailto:guy@xxxxxxxxxxxx]
Sent: Wednesday, November 19, 2003 4:24 PM
To: Paul Higgs (CA/EUS)
Cc: 'ethereal-dev@xxxxxxxxxxxx'; 'ethereal-users@xxxxxxxxxxxx' Users
Subject: Re: [Ethereal-users] Problem with h245 dissector



On Nov 19, 2003, at 10:47 AM, Paul Higgs (CA/EUS) wrote:

> I have found a problem with the dissector for H245 in regards to
> displaying the signalType of a UserInputIndication. The signalType
> prints as a ? when it is actually an !
>
> H.225.0 CS
> H323_UserInformation
> H323_UU_PDU
> h323_message_body
> h323_message_body: .... .110 : facility (6)
> FacilityUUIE
> ProtocolIdentifier: 0.0.8.2250.0.4
> FacilityReason
> transportedInformation
> CallIdentifier
> guid: 2AFA51A97C0000102143204166275475
> multipleCalls: 0... .... False
> maintainConnection: 0... .... False
> h245Tunneling: 1... .... True
> h245Control
> Item 0
> Octet String Length: 7
> H.245
> MultimediaSystemControlMessage
> PDU Type: .11. .... : Indication (3)
> IndicationMessage
> Indication Type: .... 1101 :
> UserInputIndication (13)
> UserInputIndication
> signal
>
> UserInputIndication_signal
> signalType: ?
> duration: 400
>
> 0000 00 80 37 84 fb 9c 00 10 b5 75 ac 1d 08 00 45 00
> ..7......u....E.
> 0010 00 6a bb 17 40 00 80 06 93 e7 c0 a8 15 32 c0 a8
> .j..@........2..
> 0020 15 0c 75 5a 0f a1 e5 77 18 df 95 c4 e6 f4 50 18
> ..uZ...w......P.
> 0030 43 3a b0 d2 00 00 03 00 00 42 08 02 12 76 62 1c
> C:.......B...vb.
> 0040 00 7e 00 34 05 26 80 06 00 08 91 4a 00 04 86 01
> .~.4.&.....J....
> 0050 00 1f 01 80 11 00 2a fa 51 a9 7c 00 00 10 21 43
> ......*.Q.|...!C
> 0060 20 41 66 27 54 75 01 00 01 00 10 c0 01 80 09 01
> Af'Tu..........
> 0070 07 6d 81 04 44 20 01 8f .m..D ..
>
> I looked in the codebase and it seems that this element is not
> dissceted as an IA5string but with some other method.

It's dissected as a restricted character string - but the set of
characters in that string includes "!".

What does the H.245 spec say that element is?  And, if it's a
restricted character string:

1) what's the alphabet for it?

2) what's the numerical value of the first (and only) character in it)?

According to

http://www.packetizer.com/iptel/h245/h245_asn.html

the ASN.1 for it is

signalType
                 IA5String(SIZE (1) ^ FROM ("0123456789#*ABCD!")),

but the alphabet string passed to
"dissect_per_restricted_character_string()" is "!#*0123456789ABCD".

_______________________________________________
Ethereal-users mailing list
Ethereal-users@xxxxxxxxxxxx
http://www.ethereal.com/mailman/listinfo/ethereal-users