- Fix: Changed Preferences to inherit privately from Ui::Preferences
- Added "About Qt" to Help Menu
- Added the PortList/StreamList actions to File Menu
- Fix: "New Stream" action is enabled only when a port is selected in the port list
- Fix: Ostinato now looks for Drone in the correct path
- Win32: If bindconfig.exe is not present, WinPcapPort::hasExclusiveControl() returns false instead of true (we assume we don't have exclusive control)
- Win32: WinPcapPort now looks for bindconfig.exe in the app's dirPath() instead of the current directory
- Top level 'make clean' and 'make distclean' now do not stop in case of errors
- 'make distclean' now removes the object_script.* generated files
- Added the Logo to the About dialog and also the application icon
- The default 'all' target no longer has 'qmake' as prerequisite; 'make qmake' shd be done manually on a pristine codebase
- eol's changed from dos-style to unix-style
- Trivial changes in sample.h/sample.cpp
- Implemented ARP protocol
- Top level Makefile now has a 'release' target
- pcap_set_direction() is no longer invoked in case of Win32 as older versions of WinPcap do not support this API
- MyService::modifyPort() declaration modified to fix the error reported by newer gcc compiler
- Queued RPC calls would cause crashes due to invalid pointers to request/response and/or controller; this has been fixed
- PbRpcController now takes ownership of request and response messages and
will delete them when it itself is being deleted
- This design mandates that request and response messages for each RPC call
have to be allocated on the heap.
- The convention for the Closure 'done' call now is to allocate and pass a
pointer to the controller object to it which will delete it after use;
this requires that controller itself be also allocated on the heap
(NOTE: this is just a convention - not mandatory)
- All existing RPC calls (in portgroup.cpp) have been changed to follow the
above convention
- Reordering of queued RPC calls has been fixed
- PortManager is now destroyed at exit; because of this fix the per port temporary capture files are auto-removed at exit
- WinPcapPort destructor no longer deletes the monitor threads because the parent class PcapPort already does it
- Capture does not automatically (and incorrectly) stop after one packet if started immediately after a View Capture operation
- User is prompted to stop transmit on a port first if he tries to apply configuration changes on a port in 'transmit' state
- OstProto service has a new method "modifyPort()"
- At port init port.isExclusive is now set using a bindconfig query (Win32 only)
- AbstractPort interface has 2 new pure virtual methods - hasExclusiveControl() and setExclusiveControl()
- PcapPort does not support this functionality (yet) so these methods return false
- WinPcapPort suppots this new functionality using bindconfig
- Port's notes (specifying Rx/Tx limitations) are now set and updated based on hasExclusiveControl()
- Presence of 'notes' on a port is indicated using a '*' after the port name in the port stats window
- The tabwidget has been removed from Port Window | Stream View Pane
- Ostinato Client has a new action in the port window's context menu for the same
- Port Icon in the Port Window is decorated based on exclusive control
- Server now updates the "packet list" after every "apply" rather than before a "start transmit" (if dirty) - this better reflects user's expectation from these operations
- Client disables the entire application and changes to a "Busy" cursor when "applying" stream configuration
Fixes
- UDP checksum no longer is zero but a valid value
- Order of streams no longer gets messed up across a "apply"
- (Abs/Pcap/WinPcap)Port: Inter SendQueue Timing implemented using a dummy packet length of zero (this is not supported by the winpcap pcap_sendqueue_transmit() but since we don't use that API we are not affected)
- (Abs/Pcap/WinPcap)Port: Loop Mode Timing across loop iterations implemented
- Added the year 2010 to Copyright notice in the About dialog
Fixes
- (Win)PcapPort: Fixed the wrong rates when packets sent in 'burst' mode
