Re: [Wireshark-dev] About window scale option
On Wednesday, October 29, 2014, 6:42:00 PM, Jeff Morriss wrote: On 10/28/14 11:12, ?? wrote: Hi , If the server does not support 'Window Scale' option, even the client send one packet with WS=256, I thought the real window size should be consider small than 64K.But I can see the 'Calculated window size' is larger that 64K on Wireshark1.12.1, is there something wrong ? the trace file is attached. Well remember that on a given TCP connection there are 2 window sizes: that of the client and that of the server. Technically 6, 3 in each direction. The effective window is the minimum of the 3 which apply in a particular direction. There is the receiver's advertised window, which itself is determined by (according to implementation) the minimum of the receiver's buffer and its own congestion implementation. (There are receivers that will open their window wide open to the full buffer from the outset, others, including current Linux under default but changeable configuration, which will only open their window to a little more than they expect the sender's congestion control to be able to exploit. I guess you could interpret that as 8 (4 in each direction) separate windows if the receiver is doing that.) The sender is not allowed to exceed the advertised window, however that is determined by the receiver. Then there is the sender's physical window, which doesn't appear on the wire but is determined by the maximum buffer space the sender is prepared to allocate. Since it must be prepared to retransmit any data within the window it must hold all in-flight data in memory until ACKed. Then there is the sender's congestion window, to which TCP slow start applies. Old-style, 3*MSS initially, new-style generally larger, 10*MSS as the current Linux default, other systems may have other initial defaults (and some local configurations raise it *much* higher to optimise early thoughput), rising each round-trip by the amount of ACKed data (so under ideal conditions, doubling each RTT until it hits one of the other limits or detects packet loss.) In this trace the client supports scaling but the server does not. Wireshark (at least the development version I just tried) correctly applied scaling to the client's window but not to the server's window: If the server doesn't send a Window Scale option, not even with a scale factor of 1 (indicating it understands, but is not using it on its own advertised receive windows), then it doesn't understand the option and the client should assume it doesn't apply. Not that it *really* matters since the server will simply not be using all of the client's allowed receive window and the client never had any expectation that it ought to be receiving a certain amount of data at any point anyway. (The one place it might matter is a boundary error condition: if the server doesn't SYN/ACK the Window Scale option, but nevertheless puts more data on the wire than the client's window scaled by 1, but less than the client's window scaled by its own advertised Window Scale option, the server is technically in error and the client is entitled (probably even mandated) to drop that data regardless of local buffer availability.) Note that an old installation I have here on that attached pcap file, running Win32 WS 1.2.1 (29141), correctly decodes the client's Window Scale option but then not seeing a corresponding server option, uses the raw window for the client from then on. I haven't checked a more recent (less ancient!) build on that capture specifically (since pretty much everything does scaling these days it's not something I've noticed), but if it's now assuming unidirectional scaling it is almost certainly wrong. (Note the client initially advertises scale=8 (256), raw window=8192, which would be 2MB if accepted. Subsequently it advertises nearly the full 64k raw. Under scale=8 (256), that's 16MB, which is somewhat unlikely so the client presumably is acting in accordance with a scale of 1 from then on. Also, at the end, the client's raw window value has decreased by almost exactly the amount of data the server transmitted, also indicating no scaling.) ./tshark -Y ip.src==192.168.1.200 -Vr /tmp/window_scale_neg.pcapng |grep -i window size Window size value: 8192 [Calculated window size: 8192] Window size value: 64952 [Calculated window size: 16627712] Scaling applied [Window size scaling factor: 256] Window size value: 64952 [Calculated window size: 16627712] [Window size scaling factor: 256] Window size value: 64222 [Calculated window size: 16440832] [Window size scaling factor: 256] Window size value: 64222 [Calculated window size: 16440832] [Window size scaling factor: 256] ./tshark -Y ip.dst==192.168.1.200 -Vr /tmp/window_scale_neg.pcapng |grep -i window size Window size value: 14600 [Calculated window size: 14600] Window size value: 11256 [Calculated window
Re: [Wireshark-dev] TCP: Retrieving connection initiator as well as looping through connections
On Wed, Oct 29, 2014 at 12:23 PM, Matt matta...@gmail.com wrote: For posterity, here is how I've done it: conv = (conversation_t*)g_hash_table_find( get_conversation_hashtable_exact(), check_mptcp_token, (gpointer)token); I am now looking for a way to debug. printf seems the way(and not g_log/Q_INFO ?) to go but I need to display the con sole to see the messages and I 've been unable to find a way to do so with the Qt version. I've set gui.console.open to ALWAYS in .wireshark/preferences (since prefs dialog didn't save my changes) but I still have no console. Whaat do I do wrong please ? There is some bug with console window and Qt... You can use proto_tree_add_debug_text to display in output and also add info on tree. Regards, 2014-10-28 14:23 GMT+01:00 Matt matta...@gmail.com: From what I understand, I need either to redissect with a tcp filter (ie dfilter(tcp) ) but it looks slow. I would rather search through created TCP conversations. My problem is that conversations look saved into different hashtables such as GHashTable* conversation_hashtable_exact. To compare my token with a key against all TCP connections, I believe I should compare it over the conversations in the 4 hashtables. Is that correct ? 2014-10-28 9:58 GMT+01:00 Matt matta...@gmail.com: Is that option present in all TCP packets or just in the initial 3-way handshake? If the former, then you have the problem I described above, with the indicated workaround. This is one of the problems (and advantages) of these multipath protocols, it's easier to evade data capture. Especially for MPTCP, you have to get all SYN/ACKs to be able to map a subflow to an MPTCP connection, otherwise you can't tell anything (MPTCP exchanges keys/nonces to authenticate a subflow during the3WHS). I wished to propose expert info in case of packet retransmission (such as detecting wrong keys) but it's not mandatory. In fact, an MPTCP communication starts with a TCP 3WHS that exchanges some cryptographic keys with the TCP option MPTCP_CAPABLE.Then data is sent on this TCP connection. At anytime a new TCP connection can be made to join the precedent MPTCP connection. It is achieved with the establishment of a new TCP connection with the TCP option MP_JOIN. THis tcp option carries tokens derived from the keys exchanged during the MPTCP connection. So I need to check the token against all previous keys to see if it maches a previously registered MPTCP connection. That's why I need to loop through TCP connections find_conversation() returns one conversation based on IP addresses/ports but I want to run a check against token/keys and I dunno how to do it. Thanks for your help 2014-10-27 14:47 GMT+01:00 Matt matta...@gmail.com: Hi, I am trying to improve the MPTCP support in the TCP dissector. To provide expert infos, I need to identify which host initiated the connection (ie sent the SYN). I wonder how to do that, I could use tcp_analysis::server_port if ports were guaranted to be different on both sides. Secondly, I am trying to setup an MPTCP *stream* identifier , similar to tcp stream. Indeed a single MPTCP connection can be composed of several TCP connections. Thing is to know to which MPTCP stream a TCP stream is bound to, I have to check a token (in a TCP option) against all MPTCP connections until I find a match. So I need to loop through TCP connections. How can I do that. Regards Matt ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Translation tools
On Tue, Oct 28, 2014 at 10:08 AM, Michal Labedzki michal.labed...@tieto.com wrote: Hello, FYI, I am working on improvements on translation feature in Qt Ui. If you see some untranslated texts that you already translated, it will be fixed next/this week. Hi Michal, What change you have planned ? (there is a issue the translation ?) Regards, On 28 October 2014 10:02, Jasper Bongertz jas...@packet-foo.com wrote: Hi all, FYI, for the fun of it I started working on the German translation for the QT UI. Just in case someone else gets the same idea. Cheers, Jasper ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe -- Pozdrawiam / Best regards - Michał Łabędzki, Software Engineer Tieto Corporation Product Development Services http://www.tieto.com / http://www.tieto.pl --- ASCII: Michal Labedzki location: Swobodna 1 Street, 50-088 Wrocław, Poland room: 5.01 (desk next to 5.08) --- Please note: The information contained in this message may be legally privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, you are hereby notified that any unauthorised use, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. Thank You. --- Please consider the environment before printing this e-mail. --- Tieto Poland spółka z ograniczoną odpowiedzialnością z siedzibą w Szczecinie, ul. Malczewskiego 26. Zarejestrowana w Sądzie Rejonowym Szczecin-Centrum w Szczecinie, XIII Wydział Gospodarczy Krajowego Rejestru Sądowego pod numerem 124858. NIP: 8542085557. REGON: 812023656. Kapitał zakładowy: 4 271500 PLN ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Translation tools
General change. I will upload it this weekend. Simple changelog: - simplify adding new translations (remove switches/enums etc.) - dynamic change of UI language (no restart needed) - add suppotrt for system/user translation directories - fix some texts that are translated in *.ts/*.qm but not used in UI I will put my change into gerrit im RFC mode. Also I have big update for Polish translation. On 30 October 2014 10:15, Alexis La Goutte alexis.lagou...@gmail.com wrote: On Tue, Oct 28, 2014 at 10:08 AM, Michal Labedzki michal.labed...@tieto.com wrote: Hello, FYI, I am working on improvements on translation feature in Qt Ui. If you see some untranslated texts that you already translated, it will be fixed next/this week. Hi Michal, What change you have planned ? (there is a issue the translation ?) Regards, On 28 October 2014 10:02, Jasper Bongertz jas...@packet-foo.com wrote: Hi all, FYI, for the fun of it I started working on the German translation for the QT UI. Just in case someone else gets the same idea. Cheers, Jasper ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe -- Pozdrawiam / Best regards - Michał Łabędzki, Software Engineer Tieto Corporation Product Development Services http://www.tieto.com / http://www.tieto.pl --- ASCII: Michal Labedzki location: Swobodna 1 Street, 50-088 Wrocław, Poland room: 5.01 (desk next to 5.08) --- Please note: The information contained in this message may be legally privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, you are hereby notified that any unauthorised use, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. Thank You. --- Please consider the environment before printing this e-mail. --- Tieto Poland spółka z ograniczoną odpowiedzialnością z siedzibą w Szczecinie, ul. Malczewskiego 26. Zarejestrowana w Sądzie Rejonowym Szczecin-Centrum w Szczecinie, XIII Wydział Gospodarczy Krajowego Rejestru Sądowego pod numerem 124858. NIP: 8542085557. REGON: 812023656. Kapitał zakładowy: 4 271500 PLN ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe -- Pozdrawiam / Best regards - Michał Łabędzki, Software Engineer Tieto Corporation Product Development Services http://www.tieto.com / http://www.tieto.pl --- ASCII: Michal Labedzki location: Swobodna 1 Street, 50-088 Wrocław, Poland room: 5.01 (desk next to 5.08) --- Please note: The information contained in this message may be legally privileged and confidential and protected from disclosure. If the reader of this message is not the intended recipient, you are hereby notified that any unauthorised use, distribution or copying of this communication is strictly prohibited. If you have received this communication in error, please notify us immediately by replying to the message and deleting it from your computer. Thank You. --- Please consider the environment before printing this e-mail. --- Tieto Poland spółka z ograniczoną odpowiedzialnością z siedzibą w Szczecinie, ul. Malczewskiego 26. Zarejestrowana w Sądzie Rejonowym Szczecin-Centrum w Szczecinie, XIII Wydział Gospodarczy Krajowego Rejestru Sądowego pod numerem 124858. NIP: 8542085557. REGON: 812023656. Kapitał zakładowy: 4 271500 PLN ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
[Wireshark-dev] Updating debian symbols?
Hi, How to update the symbols file? dpkg-gensymbols: warning: some new symbols appeared in the symbols file: see diff output below dpkg-gensymbols: warning: debian/libwireshark0/DEBIAN/symbols doesn't match completely debian/libwireshark0.symbols --- debian/libwireshark0.symbols (libwireshark0_1.99.1_amd64) +++ dpkg-gensymbols3gHR2l 2014-10-30 16:27:03.188650385 + @@ -83,6 +83,7 @@ call_dissector_only@Base 1.9.1 call_dissector_with_data@Base 1.9.1 call_heur_dissector_direct@Base 1.12.0~rc1 + call_per_oid_callback@Base 1.99.1 camelSRTtype_naming@Base 1.9.1 camel_opr_code_strings@Base 1.9.1 capture_ap1394@Base 1.9.1 @@ -319,6 +320,7 @@ dissect_ndr_uuid_t@Base 1.9.1 dissect_nt_64bit_time@Base 1.9.1 dissect_nt_64bit_time_ex@Base 1.99.0 + dissect_nt_64bit_time_opt@Base 1.99.1 dissect_nt_sid@Base 1.9.1 dissect_per_BMPString@Base 1.9.1 dissect_per_GeneralString@Base 1.9.1 @@ -762,6 +764,7 @@ new_register_ber_oid_dissector@Base 1.99.1 new_register_ber_syntax_dissector@Base 1.99.1 new_register_dissector@Base 1.9.1 + new_register_per_oid_dissector@Base 1.99.1 next_tvb_add_handle@Base 1.9.1 next_tvb_add_string@Base 1.9.1 next_tvb_add_uint@Base 1.9.1 @@ -1207,6 +1210,7 @@ tfs_accepted_not_accepted@Base 1.9.1 tfs_ack_nack@Base 1.9.1 tfs_active_inactive@Base 1.9.1 + tfs_allocated_by_receiver_sender@Base 1.99.1 tfs_allow_block@Base 1.9.1 tfs_allowed_not_allowed@Base 1.9.1 tfs_available_not_available@Base 1.9.1 dpkg-gensymbols: warning: some new symbols appeared in the symbols file: see diff output below dpkg-gensymbols: warning: some symbols or patterns disappeared in the symbols file: see diff output below dpkg-gensymbols: warning: debian/libwsutil0/DEBIAN/symbols doesn't match completely debian/libwsutil0.symbols --- debian/libwsutil0.symbols (libwsutil0_1.99.1_amd64) +++ dpkg-gensymbolstRiJGi 2014-10-30 16:27:04.580730076 + @@ -139,8 +139,8 @@ sober128_read@Base 1.99.0 sober128_start@Base 1.99.0 started_with_special_privs@Base 1.10.0 - strnatcasecmp@Base 1.12.0~rc1 - strnatcmp@Base 1.12.0~rc1 +#MISSING: 1.99.1# strnatcasecmp@Base 1.12.0~rc1 +#MISSING: 1.99.1# strnatcmp@Base 1.12.0~rc1 test_for_directory@Base 1.12.0~rc1 test_for_fifo@Base 1.12.0~rc1 type_util_gdouble_to_guint64@Base 1.10.0 @@ -156,6 +156,8 @@ update_crc10_by_bytes@Base 1.10.0 update_crc6_by_bytes@Base 1.10.0 ws_add_crash_info@Base 1.10.0 + ws_ascii_strnatcasecmp@Base 1.99.1 + ws_ascii_strnatcmp@Base 1.99.1 ws_base64_decode_inplace@Base 1.12.0~rc1 ws_buffer_append@Base 1.99.0 ws_buffer_assure_space@Base 1.99.0 dh_makeshlibs: dpkg-gensymbols -plibwsutil0 -Idebian/libwsutil0.symbols -Pdebian/libwsutil0 -edebian/libwsutil0/usr/lib/x86_64-linux-gnu/libwsutil.so.0.0.0 returned exit code 1 make: *** [binary] Error 1 dpkg-buildpackage: error: fakeroot debian/rules binary gave error exit status 2 program finished with exit code 2 elapsedTime=531.424488 ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] Updating debian symbols?
Hi Anders, 2014-10-30 17:49 GMT+01:00 Anders Broman anders.bro...@ericsson.com: Hi, How to update the symbols file? The output of the dpkg-gensymbols command includes the patch which should be applied, Whenever a new symbol is exported/removed the symbols file must be updated. This reminds us to keep the API stable :-) Cheers, Balint dpkg-gensymbols: warning: some new symbols appeared in the symbols file: see diff output below dpkg-gensymbols: warning: debian/libwireshark0/DEBIAN/symbols doesn't match completely debian/libwireshark0.symbols --- debian/libwireshark0.symbols (libwireshark0_1.99.1_amd64) +++ dpkg-gensymbols3gHR2l 2014-10-30 16:27:03.188650385 + @@ -83,6 +83,7 @@ call_dissector_only@Base 1.9.1 call_dissector_with_data@Base 1.9.1 call_heur_dissector_direct@Base 1.12.0~rc1 + call_per_oid_callback@Base 1.99.1 camelSRTtype_naming@Base 1.9.1 camel_opr_code_strings@Base 1.9.1 capture_ap1394@Base 1.9.1 @@ -319,6 +320,7 @@ dissect_ndr_uuid_t@Base 1.9.1 dissect_nt_64bit_time@Base 1.9.1 dissect_nt_64bit_time_ex@Base 1.99.0 + dissect_nt_64bit_time_opt@Base 1.99.1 dissect_nt_sid@Base 1.9.1 dissect_per_BMPString@Base 1.9.1 dissect_per_GeneralString@Base 1.9.1 @@ -762,6 +764,7 @@ new_register_ber_oid_dissector@Base 1.99.1 new_register_ber_syntax_dissector@Base 1.99.1 new_register_dissector@Base 1.9.1 + new_register_per_oid_dissector@Base 1.99.1 next_tvb_add_handle@Base 1.9.1 next_tvb_add_string@Base 1.9.1 next_tvb_add_uint@Base 1.9.1 @@ -1207,6 +1210,7 @@ tfs_accepted_not_accepted@Base 1.9.1 tfs_ack_nack@Base 1.9.1 tfs_active_inactive@Base 1.9.1 + tfs_allocated_by_receiver_sender@Base 1.99.1 tfs_allow_block@Base 1.9.1 tfs_allowed_not_allowed@Base 1.9.1 tfs_available_not_available@Base 1.9.1 dpkg-gensymbols: warning: some new symbols appeared in the symbols file: see diff output below dpkg-gensymbols: warning: some symbols or patterns disappeared in the symbols file: see diff output below dpkg-gensymbols: warning: debian/libwsutil0/DEBIAN/symbols doesn't match completely debian/libwsutil0.symbols --- debian/libwsutil0.symbols (libwsutil0_1.99.1_amd64) +++ dpkg-gensymbolstRiJGi 2014-10-30 16:27:04.580730076 + @@ -139,8 +139,8 @@ sober128_read@Base 1.99.0 sober128_start@Base 1.99.0 started_with_special_privs@Base 1.10.0 - strnatcasecmp@Base 1.12.0~rc1 - strnatcmp@Base 1.12.0~rc1 +#MISSING: 1.99.1# strnatcasecmp@Base 1.12.0~rc1 +#MISSING: 1.99.1# strnatcmp@Base 1.12.0~rc1 test_for_directory@Base 1.12.0~rc1 test_for_fifo@Base 1.12.0~rc1 type_util_gdouble_to_guint64@Base 1.10.0 @@ -156,6 +156,8 @@ update_crc10_by_bytes@Base 1.10.0 update_crc6_by_bytes@Base 1.10.0 ws_add_crash_info@Base 1.10.0 + ws_ascii_strnatcasecmp@Base 1.99.1 + ws_ascii_strnatcmp@Base 1.99.1 ws_base64_decode_inplace@Base 1.12.0~rc1 ws_buffer_append@Base 1.99.0 ws_buffer_assure_space@Base 1.99.0 dh_makeshlibs: dpkg-gensymbols -plibwsutil0 -Idebian/libwsutil0.symbols -Pdebian/libwsutil0 -edebian/libwsutil0/usr/lib/x86_64-linux-gnu/libwsutil.so.0.0.0 returned exit code 1 make: *** [binary] Error 1 dpkg-buildpackage: error: fakeroot debian/rules binary gave error exit status 2 program finished with exit code 2 elapsedTime=531.424488 ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] About window scale option
On 10/30/14 02:07, John Sullivan wrote: On Wednesday, October 29, 2014, 6:42:00 PM, Jeff Morriss wrote: On 10/28/14 11:12, ?? wrote: Hi , If the server does not support 'Window Scale' option, even the client send one packet with WS=256, I thought the real window size should be consider small than 64K.But I can see the 'Calculated window size' is larger that 64K on Wireshark1.12.1, is there something wrong ? the trace file is attached. Well remember that on a given TCP connection there are 2 window sizes: that of the client and that of the server. Technically 6, 3 in each direction. The effective window is the minimum of the 3 which apply in a particular direction. Well, true, but in this context there are only 2 which we're talking about. :-) In this trace the client supports scaling but the server does not. Wireshark (at least the development version I just tried) correctly applied scaling to the client's window but not to the server's window: If the server doesn't send a Window Scale option, not even with a scale factor of 1 (indicating it understands, but is not using it on its own advertised receive windows), then it doesn't understand the option and the client should assume it doesn't apply. Not that it *really* matters since the server will simply not be using all of the client's allowed receive window and the client never had any expectation that it ought to be receiving a certain amount of data at any point anyway. Hmm, I don't do much with TCP (from a protocol perspective) but that certainly makes sense. And, in fact, it appears that the TCP dissector *wants* to act that way, based on the comments in the code: /* This is called for SYN and SYN+ACK packets and the purpose is to verify * that we have seen window scaling in both directions. * If we can't find window scaling being set in both directions * that means it was present in the SYN but not in the SYN+ACK * (or the SYN was missing) and then we disable the window scaling * for this tcp session. */ It would be good if someone can open a bug report (attaching this already-public capture file) so this isn't forgotten. ___ Sent via:Wireshark-dev mailing list wireshark-dev@wireshark.org Archives:http://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
