Guy Harris
changed
bug 8250
What |
Removed |
Added |
Hardware |
x86-64
|
All
|
OS |
Linux (other)
|
All
|
Comment # 1
on bug 8250
from Guy Harris
packet-goose.c is a machine-generated dissector, so it should not be modified;
the files that generate it (or the generator) should be modified.
The ASN.1 file for GOOSE (asn1/goose/goose.asn) says:
IECGoosePdu ::= SEQUENCE {
gocbRef [0] IMPLICIT VisibleString,
timeAllowedtoLive [1] IMPLICIT INTEGER,
datSet [2] IMPLICIT VisibleString,
goID [3] IMPLICIT VisibleString OPTIONAL,
t [4] IMPLICIT UtcTime,
stNum [5] IMPLICIT INTEGER,
sqNum [6] IMPLICIT INTEGER,
test [7] IMPLICIT BOOLEAN DEFAULT FALSE,
confRev [8] IMPLICIT INTEGER,
ndsCom [9] IMPLICIT BOOLEAN DEFAULT FALSE,
numDatSetEntries [10] IMPLICIT INTEGER,
allData [11] IMPLICIT SEQUENCE OF Data --,
-- security [12] ANY OPTIONAL
-- reserved for digital signature
}
so stNum and sqNum are specified as INTEGER, which the ASN.1-to-dissector
generator turns, I think, into FT_INT32.
In theory, especially with BER, INTEGER should turn into an FT_INT that handles
arbitrary-size bignums; unfortunately, we don't implement such a type.
If you add
#.FIELD_ATTR
IECGoosePdu/stNum TYPE = FT_UINT32 DISPLAY = BASE_DEC
IECGoosePdu/sqNum TYPE = FT_UINT32 DISPLAY = BASE_DEC
to asn1/goose/goose.cnf, that causes the generated dissector to make
goose.stNum and goose.sqNum FT_UINT32 fields.
I'm not sure whether the BER decoding code handles integer values > 2^31-1,
however. If you just change FT_INT32 to FT_UINT32 in
epan/dissectors/packet-goose.c (which is what the above change to
asn1/goose/goose.cnf will do if you regenerate the dissector), does the
resulting dissector properly handle stNum and sqNum values > 2^31-1?
You are receiving this mail because:
- You are watching all bug changes.