there are only 5 gmemchunks left but they have different litetime for their allocations than the 100+ ones that have been removed.
The remaining 5 should be converted some other way.
svn path=/trunk/; revision=15328
- add support for Multi-Link Frame-Relay (FRF.15) captures
taken on Juniper ML-, LS-, AS- PICs.
- rework of the common juniper header dissector:
test the extension flag (0x80) which indicates that there are
meta-information like interface-index, interface-name etc.
present
- minor bugfix (LSQ L3-proto masks, direction masks were broken)
svn path=/trunk/; revision=15316
These GMemChunks are used here because :
1, GMemChunks are cheap to allocate and cheap to free
2, We always unconditionally free the entire chunk When and only when we load a new capture.
==>
se_alloc() does exactly the same thing but with significantly less code
==>
se_alloc() is a much better fit to out allocation requirements and useage than GMemChunks
svn path=/trunk/; revision=15303
doesn't give you the address value, it gives a pointer to the address
value.
Don't assume that pointer is aligned on a 32-bit boundary.
svn path=/trunk/; revision=15300
The generated file has a lot of indentation changes due probably to a change in asn2eth.
The underlying reason for which I added this code (dissect_ber_integer() would not add as a "filterable" field if it is larger than 4 bytes, should be handled in dissect_ber_integer() ) remains there.
Should we change dissect_ber_integer() itself to make sure that a 5 byte unsigned integer which fits in 4 bytes gets added to the tree as "filterable"?
svn path=/trunk/; revision=15294
If we encounter a frame we have already seen (i.e. visited==1) but we can not fing the ISCSI command inside the _matched table, this just means there were no response pdu nor any data pdu with the S bit set.
So, then just pick the cdata structure up from the _unmatched table instead.
The SCSI CDB dissector really really want a real CDATA structure passed to it.
svn path=/trunk/; revision=15291
as heuristics they are not 100% perfect, else they would not be heuristics.
IF the preference option "Dissect unknown RPC program numbers" are enabled,
add a sanity check to see that program_version is <=10
(no one uses versions >10 ?)
to avoid trying to add 2 bilion different versions to the program->version linked list
in case we mistook the packet for ONC-RPC and the "version" field contains a huge random number.
This bug would only trigger a hang/crash IFF the option above is enabled.
svn path=/trunk/; revision=15290
This might at some places interfere with the changes for gcc4, we might have to negotiate in that case :-)
Please note that a lot of these warnings were GTK1.x related only!
svn path=/trunk/; revision=15286