Comment # 4
on bug 10842
from Anders Broman
(In reply to Mato from comment #3)
> (In reply to Anders Broman from comment #1)
> > From what I can see the record type is:
> >
> > ...1 0101 = Tag: 21
> >
> > GPRSRecord ::= CHOICE
> > --
> > -- Record values 20, 22..27 are specific
> > -- Record values 76, 77, 86 are MBMS specific
> > -- Record values 78,79 and 92, 95, 96 are EPC specific
> > --
> > {
> > sgsnPDPRecord [20] SGSNPDPRecord,
> > sgsnMMRecord [22] SGSNMMRecord,
> >
> > Which isn't specified in the ASN1 description, should it have been record
> > type 20? or what type of record is it supposed to be?
>
> I just successfully(In reply to Anders Broman from comment #1)
> > From what I can see the record type is:
> >
> > ...1 0101 = Tag: 21
> >
> > GPRSRecord ::= CHOICE
> > --
> > -- Record values 20, 22..27 are specific
> > -- Record values 76, 77, 86 are MBMS specific
> > -- Record values 78,79 and 92, 95, 96 are EPC specific
> > --
> > {
> > sgsnPDPRecord [20] SGSNPDPRecord,
> > sgsnMMRecord [22] SGSNMMRecord,
> >
> > Which isn't specified in the ASN1 description, should it have been record
> > type 20? or what type of record is it supposed to be?
>
> I just successfully decoded contents in Wireshark 1.8.10 as:
> GPRSCallEventRecord: ggsnPDPRecord (21)
> recordType: ggsnPDPRecord (19)
Ok, the current code in packet-gtp.c is
if(format==1) {
if(rel_id == 6){
dissect_gprscdr_GPRSCallEventRecord_PDU(next_tvb, pinfo,
cdr_dr_tree, NULL);
}else if(rel_id >6){
dissect_gprscdr_GPRSRecord_PDU(next_tvb, pinfo,
cdr_dr_tree, NULL);
}
If I remember correctly the spec at some point changed the naming from
GPRSCallEventRecord to GPRSRecord and apparently the defentions changed. So
either your rel_id does not fit the CDR format or Wiresharks code is wrong :-)
(I'm not sure when I'll have the time to check which one it is).
You are receiving this mail because:
- You are watching all bug changes.