Re: [Wireshark-dev] TCP: Retrieving connection initiator as well as looping through connections
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
Re: [Wireshark-dev] Translation tools
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. 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
Re: [Wireshark-dev] Translation tools
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 smime.p7s Description: S/MIME Cryptographic Signature ___ 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] ctype.h calls
Just catching up on 3 weeks of traffic on the the -commits list... Is there any reason the remaining ctype.h calls in master shouldn't be removed [and the functions put on the prohibited list in checkAPIs.pl]? ___ 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] ctype.h calls
Jeff Morriss wrote: Is there any reason the remaining ctype.h calls in master shouldn't be removed [and the functions put on the prohibited list in checkAPIs.pl]? One of the calls in ctype.h is tolower() which is used in wsutil/strncasecmp.c. Could we simply remove that entire file and use g_ascii_strncasecmp() instead? Ed ___ 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] ctype.h calls
On Oct 28, 2014, at 10:56 AM, Jeff Morriss jeff.morriss...@gmail.com wrote: Just catching up on 3 weeks of traffic on the the -commits list... Is there any reason the remaining ctype.h calls in master shouldn't be removed [and the functions put on the prohibited list in checkAPIs.pl]? The remaining calls in Wireshark proper (I'm leaving the build tools out, at least for now), at least based on what files are still including ctype.h, are: in the H.245 dissector, a call to isascii() used to decide whether to display something as text or hex; in the S1AP dissector, a call to isalpha(), which is in a loop that is being used to check whether something should be displayed as a text string; in file.c, calls to toupper() and tolower() in string matching code; in wsutil/strnatcmp.c, calls to several functions in the Perform 'natural order' comparisons of strings in C routine; in wsutil/strptime.c, isspace() used when matching white space in an input string. In the first two, I *suspect* that what's really intended is is this printable ASCII?, in which case both should use g_ascii_isprint(), although if the S1AP dissector really wants to check for *alphabetic* characters, g_ascii_isalpha() could be used. In file.c, I think that code is primarily (and possibly exclusively) used for the Find function in Wireshark and, for that, if the user requested a case-insensitive search: when searching packet summary lines and lines from the detailed dissection, they might want a search that's case-insensitive, *using the rules of their locale*, *and treating both the string being searched for and the strings in which the search is being done as being encoded as UTF-8* (which is what they both should be), which is a significant change; when searching raw packet data, making the search automatically do the right thing would be extremely difficult (as the raw packet data might be in arbitrary encodings, and the only way to determine the encoding of a particular set of bytes would be to see what encoding was specified when it was dissected) - currently we support a vague sort of byte-oriented encoding that I guess is ASCII and a vague sort of 2-byte-oriented encoding that I guess you could think of as UTF-16 but it never matches anything outside the ASCII range, and maybe we should just have both matches never match anything outside the ASCII range. In wsutil/strnatcmp.c, the natural order appears, from http://sourcefrog.net/projects/natsort/ to sort strings such that numbers in the strings are sorted in numerical order: Computer string sorting algorithms generally don't order strings containing numbers in the same way that a human would do. Consider: rfc1.txt rfc2086.txt rfc822.txt It would be more friendly if the program listed the files as rfc1.txt rfc822.txt rfc2086.txt Filenames sort properly if people insert leading zeros, but they don't always do that. The routines in there are used to sort encapsulation type names for -T in the help output from editcap and mergecap; those are all ASCII, so using the g_ascii_XXX() routines would work. If we want to sort strings that might *not* be nerd tokens in a natural order, in order to show them to a user, we might want to do a dictionary sort, which would be locale-dependent. I'd vote for stuffing ascii into the names of the wsutil/strnatcmp.c routines, to make it clear that the case-insensitive natural order sort routine will always treat A-Z and a-z as equivalent (including treating I and i as equivalent, with neither being equivalent to İ or ı) and will not ever treat anything else as equivalent (including not, for example, treating Ä and ä as equivalent), and, if we ever need a natural human dictionary order sort, worrying about that problem at that point. ___ 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] About window scale option
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. window_scale_neg.pcapng Description: Binary data ___ 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] ctype.h calls
On 10/28/2014 02:25 PM, Ed Beroset wrote: Jeff Morriss wrote: Is there any reason the remaining ctype.h calls in master shouldn't be removed [and the functions put on the prohibited list in checkAPIs.pl]? One of the calls in ctype.h is tolower() which is used in wsutil/strncasecmp.c. Could we simply remove that entire file and use g_ascii_strncasecmp() instead? Good point: we prohibited strncasecmp() years ago so there's no need for it to exist any more. https://code.wireshark.org/review/4980 ___ 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
