Change "cd.." to "cd .." - I don't know whether they're equivalent, but,
if they're not, the former probably won't work.
svn path=/trunk/; revision=17997
============================ Samba log start ============
svn: When specifying working copy paths, only one target may be given
============================ Samba log end ==============
svn path=/trunk/; revision=17994
scsi_mmc_val DATA
scsi_sbc2_val DATA
scsi_ssc2_val DATA
BTW: these values should be renamed to ..._vals as in every other dissector I know!
svn path=/trunk/; revision=17989
mention informational URLs at the beginning and not at each element
replace some // by /**/
start to decode the informational elements in the BSSID list
add a privacy tab to the BSSID list (None, WEP, WPA, WPA2)
various minor label changes
svn path=/trunk/; revision=17988
With the new feature we can:
1. Measure how big the bursts are for a video streams (it uses sliding window algorithm) 2. Measure how big the output buffer should be that no packet drop will occur (it uses Leaky bucket algorithm)
3. Detect if we have loses inside the MPEG2 video stream (if there are already MPEG2 packets missing) - this part of code is not added yet, see Limitations
The addition is called Multicast streams and works as follows:
- it uses the TAP system
- the main "stream" logic is taken from rtp_strems.* files
- the TAP system checks for UDP packets where the destination MAC address starts with "01:00:5E" (ethernet multicast address)
- it creates an entry for every new multicast stream
- based on sliding window and leaky bucket algorithm it calculates for every stream average BW, max BW, burst size, max buffer needed, some alarms if the limits are exceeded,...
- the same calculation is done for all streams together
- inside the window dialog you can specify the burst interval, the alarm limits and output speeds
To do & limitations:
- Currently the analysis can be done only for multicast streams, it means that VoD (Video on demand) or PayTV streams, which are normally unicast can not be analysed.
- since the MPEG2 is patended I don't know if decoding of MPEG2 packets is allowed? Can we look inside this packets and calculate packets drops based on some counter information inside the payload? Can someone please answer this question? If we can do this, I will post this part of code too.
- some more flexibility will be added
svn path=/trunk/; revision=17980
This patch should hopefully remove any possible buffer overflows in
parse_line() as reported by the current Coverity scan. I'm not sure
that the error it currently reports is valid (I think its confused by
supposing that a condition that is being tested can be true, whereas it
can't...), but this patch fixes a number of potential problems remaining
in the function.
svn path=/trunk/; revision=17979
update the comment in packet-scsi.c to reflect that it is the transport now that is responsible to track itl and itlq data
make scsi tapable
svn path=/trunk/; revision=17974
Clean up the checks for STP vs. RSTP vs. MSTP.
Show the version 3 length field as a separate field, rather than as the
top-level item for the MSTP stuff.
"Trust" the version 3 length field, so that if it doesn't agree with the
packet length, we report a malformed frame (as we should).
svn path=/trunk/; revision=17973
and, in particular, means we don't, for example, use tvb_get_ntohs() to
fetch a 4-byte quantity - that fixes bug 883.
The MST config name is either null-terminated or null-padded; mark it as
such.
svn path=/trunk/; revision=17972
library. If that's not done, it leaves to ethereal or other binaries
using it the job of linking adns within them. This behaviour is
unreliable and breaks when using the --as-needed flag for GNU ld
(version 2.16 or better 2.17).
svn path=/trunk/; revision=17969
structures for scsi.
we no longer need the scsi_task_id structure passed by pinfo->private_data so get rid of it.
we no longer need the (broken by design) scsi_task_data hash table since this has been replaced byt hte itl and itlq structures and tracking
svn path=/trunk/; revision=17952
remove the two fields opcode and devtype from the scsi_task_data structure since these are also part of the itlq and itl structures
svn path=/trunk/; revision=17949
I tried out the 0.99.0pre1 release and I noticed that all my SCCP management messages (on SSN==1) were getting decoded as TCAP. Turns out that the INAP dissector (due to a bug) registers to SSN==1 by default (instead of 106 and 241). Rather than just fix that bug, the attached patch modifies the INAP dissector to use a range preference (like GSM MAP, TCAP, etc.).
svn path=/trunk/; revision=17945
Using the attached patch, this file was generated via "File -> Export -> as XML
- "PDML" (packet details) file ...". As can be seen in the file, the 1st
packet now contains the value for the "media", whereas previously it did not.
svn path=/trunk/; revision=17943
and get rid of some breakage in the design
let the scsi transport keep track of itl (initiator, target, lun) matching
and let it pass a itl structure to scsi that is persistent across packets.
let scsi use this itl structure to track device type for a specific itl instead of the (must have been) broken hashtable.
update both iscsi and fc to track the itl structure for scsi and schange the scsi signature to accept itl as a parameter.
more to come.
svn path=/trunk/; revision=17942
