https://bugs.wireshark.org/bugzilla/show_bug.cgi?id=7932
--- Comment #6 from Vineeth <vineethvijaysv@xxxxxxxxx> 2012-10-30 02:27:07 PDT ---
(In reply to comment #5)
> (In reply to comment #4)
> > Agreed on having a generic APN to string function. Will try it.
> >
> > With regards to label being upto 63 characters long, I am a bit confused. As
> > per 3GPP maximum length of APN is 100 octets. (#define MAX_APN_LENGTH
> > 100 in packet-gsm_a_gm.c) .APN network identifier does follow RFC 1035 as
> > you mentioned. May be issue was unreported till now since nobody uses APN's of
> > above 20 character length :). Will try to simulate it.
>
> An APN name is composed of several labels separated by dots. So there is no
> contradiction here: 100 is the global maximum size while 63 is the maximum size
> for one label.
I was referring to your statement regarding APN length check of 31 (0x20)
instead of 63. It actually seems like a bug. A test APN of length greater than
32 characters is getting decoded wrongly due to messing up of offsets.
(Problematic Test Case attached)
Same is getting decoded correctly when changing the label check to 63.
static void
decode_apn(tvbuff_t * tvb, int offset, guint16 length, proto_tree * tree)
{
guint8 *apn = NULL;
int name_len, tmp;
if (length > 0) {
name_len = tvb_get_guint8(tvb, offset);
if (name_len < 0x3F) {
apn = tvb_get_ephemeral_string(tvb, offset + 1, length - 1);
for (;;) {
if (name_len >= length - 1)
break;
tmp = name_len;
name_len = name_len + apn[tmp] + 1;
apn[tmp] = '.';
}
} else
apn = tvb_get_ephemeral_string(tvb, offset, length);
proto_tree_add_string(tree, hf_gtp_apn, tvb, offset, length, apn);
}
}
Should I open a raise bug for this???
--
Configure bugmail: https://bugs.wireshark.org/bugzilla/userprefs.cgi?tab=email
------- You are receiving this mail because: -------
You are watching all bug changes.
