Priority given to messages tested in DPoE 1.0 ATP.
Change-Id: I6ba3f1a8ca018f2231ad60f2f347ac57f1f93a00
Reviewed-on: https://code.wireshark.org/review/1076
Reviewed-by: Evan Huus <eapache@gmail.com>
See IEEE Standard 802.3-2012 Section 5, Clause 65 and CableLabs DPoE
Security and Certificate Specification 1.0, Section 6.
Currently dissects 1G mode. 10G mode will be added when hardware is
available.
Change-Id: I6232af9bf6807644ef66a120d97e5fa5927988fe
Reviewed-on: https://code.wireshark.org/review/1284
Tested-by: Alexis La Goutte <alexis.lagoutte@gmail.com>
Reviewed-by: Evan Huus <eapache@gmail.com>
not size_t, which was giving 64/32 conversion errors on some platforms
Change-Id: Idf81dc98f8921a92840731d742d6e46a40e1387f
Reviewed-on: https://code.wireshark.org/review/1405
Reviewed-by: Evan Huus <eapache@gmail.com>
For 'x' equal to 0, HASH() macro also returns 0 which makes wmem map O(n).
When random generator will return 0 just use 1.
Change-Id: If484091352a719aea27135a705d37ff4c184a13b
Reviewed-on: https://code.wireshark.org/review/1387
Reviewed-by: Michael Mann <mmann78@netscape.net>
It was intended to change the DTLS decryption test, but changed the SSL test
file instead, which led to the SSL test mysteriously failing. The SSL capture
really is http, so that's the right protocol, and the port is the standard 443,
not 4433 (which was perhaps a typo?).
Change-Id: I84448c2326d2a4301a4bba9607f8ba90a495531d
Reviewed-on: https://code.wireshark.org/review/1401
Reviewed-by: Evan Huus <eapache@gmail.com>
packet-gvcp.c:2101:7: warning: Access to field 'req_frame' results in a dereference of a null pointer (loaded from variable 'gvcp_trans')
Change-Id: If39453f9f2ade551fd8c7e369fd60325c16df24b
Reviewed-on: https://code.wireshark.org/review/1393
Reviewed-by: Alexis La Goutte <alexis.lagoutte@gmail.com>
Tested-by: Alexis La Goutte <alexis.lagoutte@gmail.com>
Reviewed-by: Michael Mann <mmann78@netscape.net>
From Alexis La Goutte
Fix warning found by pre-commit
Partial-Bug: 10054
Change-Id: I976884a240a55bb2287a802d72668a2c845179c0
Reviewed-on: https://code.wireshark.org/review/1295
Reviewed-by: Alexis La Goutte <alexis.lagoutte@gmail.com>
Tested-by: Alexis La Goutte <alexis.lagoutte@gmail.com>
packet-http.c:2629: warning: implicit conversion shortens 64-bit value into a 32-bit value
Change-Id: I6a423639a53c24431fcfd79e0a235f2885ea86c2
Reviewed-on: https://code.wireshark.org/review/1389
Reviewed-by: Alexis La Goutte <alexis.lagoutte@gmail.com>
For pref_current, indirection of pref->varp.string will cause a read of
size 8. This will cause a global buffer overflow error for all smaller
types, for example lbmc_use_heuristic_subdissectors (size 4).
Reproduce: compile Wireshark with -fsanitize=address, open Preferences
and select OK or Apply. Result: ASAN crash.
To fix this, only indirect a pointer if the storage size is known, a
void pointer stores the address of the constant value (pref_default,
pref_stashed) or the address to the value (pref_current). Note that
pointers of different types are of equal size, I could take
valp.pref_(anything).
While at it, remove superfluous 'break' keywords where a 'return'
keyword is present.
Change-Id: I05a69e8f14a1ecb4e5d2a0c0f0b71ed3f0a41d70
Reviewed-on: https://code.wireshark.org/review/1286
Reviewed-by: Evan Huus <eapache@gmail.com>
Reviewed-by: Michael Mann <mmann78@netscape.net>
Using value_is_in_range is making quite some assumptions, namely (1) the
proxy server is always run on a registered HTTP port, and (2) the
source (client) port is always not HTTP. The former is quite a strong
assertion which fails to hold when using a custom port (8008) that got
detected through heuristics.
Fix this by recording the source address and port pair for the server
and then check this against the current packet.
This fixes detection of a SSL conversation where two conversations got
detected instead of one. Example: 8008 is proxy, 443 is target server.
Now the proxied conversation got detected as 443 --> "client port"
(server to client, ok) and 443 --> 8008 (client to server, not ok,
should be "client port" --> 443).
bug:7717
Change-Id: I05113ec2aca6c9296184759a8a62eb32cbfcbb4f
Reviewed-on: https://code.wireshark.org/review/1380
Reviewed-by: Michael Mann <mmann78@netscape.net>
Reviewed-by: Alexis La Goutte <alexis.lagoutte@gmail.com>
This moves the keyfile and psk options from the ssl code into ssl-utils
and then uses them also for dtls.
This is the last missing part for bug 9499 from my side.
Change-Id: Ie2fe5bc565eabe1e6ce62498c985b8a36e913b0f
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Reviewed-on: https://code.wireshark.org/review/1369
Reviewed-by: Peter Wu <peter@lekensteyn.nl>
Reviewed-by: Michael Mann <mmann78@netscape.net>
For long cookies, the label "[truncated] Cookie: foo=v..." is not really
helpful. Add a new subtree to display individual cookies, this makes
copying values much easier.
A new "http.cookie_pair" field was added instead of re-using
"http.cookie". This has the advantage that `tshark -Tfields -e
http.cookie` does not end up with duplicates. At the same time, one can
match against individual cookie values.
I also considered to limit the number of cookies to be split, but as
there is no limit on the number of headers, I decided not to be
restrictive for cookies either.
Change-Id: I98d9522867811278ade3e04aab02e517f997928b
Reviewed-on: https://code.wireshark.org/review/1186
Reviewed-by: Alexis La Goutte <alexis.lagoutte@gmail.com>
Reviewed-by: Evan Huus <eapache@gmail.com>
Reviewed-by: Michael Mann <mmann78@netscape.net>
From Martin Mathieson.
In a profiled run with FTP traffic, the HTTP dissector looking for the end of a line of data (which was binary) was taking around 3% of runtime.
bug:8822
Change-Id: I2617d1e49030bd5ad85b0e818c48c01dc6fae075
Reviewed-on: https://code.wireshark.org/review/1373
Reviewed-by: Michael Mann <mmann78@netscape.net>
Follow-up to g757db64e484b009c33b67b5fa38e109d7b8f5e78 which changed the filter
being tested but didn't change the target protocol, so the test was still
failing because it was still trying to use HTTP.
Change-Id: I6675cfad3bba63f7a536eb7ae82e4b25132d108e
Reviewed-on: https://code.wireshark.org/review/1375
Reviewed-by: Evan Huus <eapache@gmail.com>
The dissector only ran through the server hello extensions for the tree
and not in the ssl decryption pass. This resulted in
ssl_dissect_hnd_hello_ext() being always called with ssl == NULL. For
SSL this was also called with ssl != NULL.
Change-Id: I22f7b1089731124b3ca1a2b8515f307c4a021b7f
Signed-off-by: Hauke Mehrtens <hauke@hauke-m.de>
Reviewed-on: https://code.wireshark.org/review/1370
Reviewed-by: Evan Huus <eapache@gmail.com>
Both "any port" and "any address" are supported separatedly, but not the
combination of both. This also has the effect that the combination of
any address with the special keyword "start_tls" did not work.
Fix this by checking for a private key with the combination of any
address and port.
Change-Id: Icb49d6728f032a05007dcb7ac73ec0528778441a
Reviewed-on: https://code.wireshark.org/review/1368
Reviewed-by: Evan Huus <eapache@gmail.com>
There is no need to check for private keys if there are none. In
addition, print the number of keys for debugging purposes.
Change-Id: Idc9d650e0bf087c0f647dba4e5bd4920b4f6e228
Reviewed-on: https://code.wireshark.org/review/1367
Reviewed-by: Evan Huus <eapache@gmail.com>
The wildcard address contains all zeroes, resulting in the same hash
for 0.0.0.0 and ::. Not really problematic, but it does not sound
great either.
Change-Id: I099128973a1bd8bb5c88d0abcab3ea4ecc3a96c9
Reviewed-on: https://code.wireshark.org/review/1366
Reviewed-by: Evan Huus <eapache@gmail.com>
No caller checks its return value (which is always 0).
Change-Id: I18461ee6e5d369722c8c2b2ea1e409423aa5d631
Reviewed-on: https://code.wireshark.org/review/1365
Reviewed-by: Michael Mann <mmann78@netscape.net>
Reviewed-by: Evan Huus <eapache@gmail.com>
Change-Id: I367c99bb351993f05161d683eb54f08e5852145f
Reviewed-on: https://code.wireshark.org/review/1347
Reviewed-by: Michael Mann <mmann78@netscape.net>
... and remove last remaining proto_tree_add_text() calls!
Change-Id: I22e5446a06c22ba1f30f342b21f7676641a7f2e7
Signed-off-by: Lorand Jakab <ljakab@ac.upc.edu>
Reviewed-on: https://code.wireshark.org/review/1352
Reviewed-by: Michael Mann <mmann78@netscape.net>
Change-Id: I49f6acecdbcdf171ba28af171f8067322cc5ecf1
Reviewed-on: https://code.wireshark.org/review/1220
Reviewed-by: Michael Mann <mmann78@netscape.net>
Then have the read and seek-read routines both use that routine.
Change-Id: I3d11df82644207d0ae59486231c91e1f044090ab
Reviewed-on: https://code.wireshark.org/review/1361
Reviewed-by: Guy Harris <guy@alum.mit.edu>
"line" is used only in the main loop processing the lines.
Change-Id: I370c6516867a9c972f9673b3362141f0f42d178a
Reviewed-on: https://code.wireshark.org/review/1360
Reviewed-by: Guy Harris <guy@alum.mit.edu>
Jeff Morriss