this is an ugly hack, as there is no code for packet re-assembly
in betwween, i.e. we only get proper dissection if the LLC message
was fitting entirely into one RLC block. Nevertheless, sufficient to
see things like RAU, ATTACH, IDENTITY procedures.
Change-Id: I1fc488aa58353e5f4264b940f9f4c18987148a7d
A change in Qt 6.0 makes QAbstractItemView::dataChanged, when called
with multiple indices, determine exactly how much of the viewport
rectangle is covered by the changed indices and only update that much
of the viewport instead of always updating the entire viewport. This
reduces CPU load when multiple indices, but not enough to span the
entire viewport, are updated at once.
( https://codereview.qt-project.org/c/qt/qtbase/+/285280https://bugreports.qt.io/browse/QTBUG-58580
)
Unfortunately, if the number of indices is very large (much larger
than the total number of indices that can possibly be displayed in
the viewport), computing the union of the intersecting rectangle takes
orders of magnitude longer than unconditionally updating the whole
viewport. ( https://bugreports.qt.io/browse/QTBUG-124173 )
When the packetListModel wants to indicate that all packets may have
changed, this makes dataChanged scale linearly with the total number of
rows/frames, whereas updating the viewport only scaled with the size of
the viewport but was unaffected by undisplayed packets. The calculation
is unnecessary because we know the entire viewport is affected. On a
sample modern workstation, measurements showed dataChanged taking 1 s
with 1.4 M packets and 9 s with 12 M packets. This signal can be issued
quite often, e.g. if IP address lookup (DNS or MaxMindIP) is enabled, it
can be issued once per second at the packet_data_timer expiration for
some period of time as idle dissection occurs when opening the file.
Instead of issuing dataChanged, we can issue layoutAboutToBeChanged()
(in practice a no-op) and layoutChanged(), which causes the QTreeView
to clear all information about its view items (d->viewItems.clear() in
QTreeView::doItemsLayout), but without clearing the current and selected
row (unlike [begin|end]ResetModel.) This takes the same 5-8 ms in the
same test procedure as above in both the 1.4 M and 12 M packet tests.
Improves #19486 considerably on Qt 6.
It's possible to get a response without having a previous request,
so the curr request response can be NULL.
Restore a bunch of NULL checks for that reason and add some in
the new code. Don't set that we have a range unless the Range
headers are successfully processed.
Restore the boolean preference settings to true from TRUE.
There are some other things still to cleanup in this new code.
Fix#19743 (and assorted others)
In addition to moving about 100 kBytes from a read-write data section to
read-only, this change also allows us to eliminate some typecasts (which
dropped "const" qualifiers) and hence stop suppressing some compiler
diagnostics (i.e. remove some DIAG_OFF_PEDANTIC/DIAG_ON_PEDANTIC pairs).
We want to get the value of the x axis range after rescaling,
in order to properly center when using ResetAxes. Also it's the
y-axis, not the x-axis, that might be logarithmic. This correctly
centers graphs after the initial retap without having to reset
again.
The profile dialog used to have a COL_PATH column which showed the path
to a profile and let you open that path in your system's file explorer.
That column was removed and we now have an auto switch filter column in
the same place. Remove the old (and formerly dead) URL code so that we
don't try to open display filters as file paths.
Add an Apply button to the preferences dialog.
Change the app signals from being queued to emitted. There was
a Qt bug on MacOS with nested event loops and processEvents (see
issues #11448, #11361) that existed in various versions starting
with 5.3.0. After a number of attempts to solve it, it was finally
resolved in 5.7.1 and 5.8.0:
https://bugreports.qt.io/browse/QTBUG-56746
We require versions of Qt later than that. We also don't exec() the
PreferencesDialog after commit f67eccedd9
so there isn't a nested event loop, removing the trigger for the bug
even if it did somehow reappear in Qt.
Remove the duplicate connections from the buttonBox accepted and
rejected signals that are created in the .ui file. It doesn't
seem to cause problems here currently, but connecting the same signal
to multiple slots can lead to some race conditions in some
circumstances. (See commit 06ba704058)
Just call accept and reject at the end of the other functions.
Fix#12566
We don't always add certain zero points to the graph, even moreso
after hasItemToShow was introduced.
For currentOffset (which is used to determine start_time_ of the
entire IOGraphDialog, not just one IOGraph), we want the necessary
conversion between relative and absolute time so that absolute time
of day works for CSV output (#13717) and for packet selection with
Time of Day (#10922) when some items aren't added to the graph.
The description for currentActiveGraph says that it applies to
the "currently selected, visible graph" but it doesn't currently
check if the graph is visible, only that the index is valid.
(It checked before IO Graphs were converted to a UAT.)
We check visibility in a few other places, but this switches us
to an displayed graph in a few cases instead of having the tracer
appear on an invisible graph or the hovering fail to find a graph
to match to a packet.
Only the hf_id field in fix_fields is ever modified; This change separates out
hf_id and makes the rest of that structure "const", moving about 26 kBytes of
data from a read-write data section to a read-only data section, moving another
6 kBytes of read-write data (formerly field hf_id) to .bss -- and reclaiming
another 6 kBytes of read-write data space which was being entirely wasted due
to field packing in the struct in 64-bit builds.
Matching was not compliant with RFC9110 when requests were sent
in a asynchronously ordered fashion. Asynchrously (yet ordered)
requests and replies were matched according to LIFO rather than
FIFO. A new matching method has been implemented to handle cases
where packets are missing from the capture.
# This is the 1st commit message:
HTTP: corrected request/response matching
Matching was not compliant with RFC9110 when requests were sent
in a asynchronously ordered fashion. Asynchrously (yet ordered)
requests and replies were matched according to LIFO rather than
FIFO. A new matching method has been implemented to handle cases
where packets are missing from the capture.
# This is the commit message #2:
HTTP: Change to Ubuntu pipeline test
The Ubuntu pipeline test is failing because it is expecting
something that my MR has changed.
This is a modification of the test file that accomodates
the new output.
# This is the commit message #3:
HTTP: Fixed indentaion error
Fixed indentation error in the script at line 545
The Ubuntu pipeline test is failing because it is expecting
something that my MR has changed.
This is a modification of the test file that accomodates
the new output.
This has been corrected using wmem_map() fucnctions.
The full method is in the comments.
HTTP: removed unused function declaration
HTTP: Ranges are used to match reqs/resps
This does NOT fix incorrect URI matching in asynchronously ordered
GETS with a status of 206.
HTTP: Request-response matching corrected
/*
* Unlike protocols such as NFS and SMB, the HTTP protocol (RFC 9110) does not
* provide an identifier with which to match requests and responses. Instead,
* matching is solely based upon the order in which responses are received.
* HTTP I/O is asynchronously ordered such that, for example, the first of four
* GET responses is matched with the first outstanding request, the next
* response with the second oldest outstanding request and so on (FIFO).
* The previous method instead matched responses with the last of several
* async requests rather than the first (LIFO), and did not handle requests
* with no responses such as the case where one or more HTTP packets were
* not captured. Whenever there were multiple outstanding requests, the SRT
* (RTT) stats were incorrect, in some cases massively so.
*
* While RFC 9110 expressly prohibits matching via byte ranges because, among
* other things, the server may return fewer bytes than requested, the first
* number of the range does not change. Unlike HTTP implementations, Wireshark
* has the problem of requests/responses missing from the capture file.
* In such cases resumption of correct matching was virtually impossible and
* all matching was incorrect from that point on.
*
* The method of matching used herein is able to recover from packet loss,
* any nummber of missing frames, and duplicate range requests. The
* method used is explaned within the comments.
HTTP: Fixed no resp_in
When a GET request has a range and the response does not,
"Response in" was not being displayed in the request.although
that frame number was available.
HTTP: Fixed error in last commit
HTTP: corrected request/response
Matching was not compliant with RFC9110 when requests were sent
asynchronously ordered fashion. A new matching method has been
added to handle cases where packets are missing from the capture.
HTTP: correct req/resp matching without comments
This is the same code with the commented out code removed.
HTTP: Fix request/reply matching
When asynchrously (yet ordered) requests and replies were matched
according to LIFO rather than FIFO. Next and previous request
and response has been eliminated because there is no use case for
them and they bloat the Packet Detail.
HTTP: Fix request/reply matching
Fixed clang errors
When asynchrously (yet ordered) requests and replies were matched
according to LIFO rather than FIFO. Next and previous request
and response has been eliminated because there is no use case for
them and they bloat the Packet Detail.
Matching was not compliant with RFC9110 when requests were sent
asynchronously ordered fashion. A new matching method has been
added to handle cases where packets are missing from the capture.
Matching of requests and responses were being done using LIFO rather than
FIFO.
The method of matching used in this change is able to recover from packet
loss, any nummber of missing frames, and duplicate range requests. The
method is explained within the comments.
/*
* Unlike protocols such as NFS and SMB, the HTTP protocol (RFC 9110) does not
* provide an identifier with which to match requests and responses. Instead,
* matching is solely based upon the order in which responses are received.
* HTTP I/O is asynchronously ordered such that, for example, the first of four
* GET responses is matched with the first outstanding request, the next
* response with the second oldest outstanding request and so on (FIFO).
* The previous method instead matched responses with the last of several
* async requests rather than the first (LIFO), and did not handle requests
* with no responses such as the case where one or more HTTP packets were
* not captured. Whenever there were multiple outstanding requests, the SRT
* (RTT) stats were incorrect, in some cases massively so.
*
* While RFC 9110 expressly prohibits matching via byte ranges because, among
* other things, the server may return fewer bytes than requested, the first
* number of the range does not change. Unlike HTTP implementations, Wireshark
* has the problem of requests/responses missing from the capture file.
* In such cases resumption of correct matching was virtually impossible and
* all matching was incorrect from that point on.
*
* The method of matching used herein is able to recover from packet loss,
* any nummber of missing frames, and duplicate range requests. The
* method used is explaned within the comments.
Initialize len if it's going to be used in the return.
In certain cases we don't enter the loop and call
dissectr_http_message at all.
Fixup 76879a480aFix#19739
Fully dissect the VMOTION-PEER message, even in a one-pass dissection or when
the VMOTION-PEER-OK message was not captured. This requires that we correlate
this Telnet conversation with the earlier one carrying the VMOTION-GOAHEAD
message, and extracting the length of the sequence number from there.
The new CE_BLOB is similar to CE_STRING, but can include zeros within its
value, is not NUL-terminated, and -- because it likely isn't printable text --
is displayed as hexadecimal.
For a VMOTION-GOAHEAD message, it is likely that we can use an earlier message
in the same conversation to determine the length of the "sequence" field,
allowing us to fully dissect that message. In a two-pass analysis, even the
length from the VMOTION-PEER-OK message allows for dissection of the preceding
VMOTION-PEER message.
For decoding the VMOTION-PEER message in one pass, it's going to require a bit
more work -- i.e. tracking the "vMotion conversation" across the two Telnet
conversations.
Changes were made to the generated packet-fix.h without making corresponding
changes to the underlying source material and scripts.
e0300eae: Changed "SYTLE" -> "STYLE", "CORRESPONDANT" -> "CORRESPONDENT"
5cd53414: Change the list terminator to "{ 0, NULL }"
Note that we have already made some modifications to the source .xml files
(in, for example, 23eac7dc and 78c05162), so I don't feel any qualms about
modifying them further here.
With these changes, the generated packet-fix.h is once again byte-for-byte
identical to the one in the repository.
Harald Welte
John Thacker