Re: [Wireshark-dev] Unit testing dissector code
Hi Martin, This is promising. I think dissecting a TVB and walking the proto_tree to assert the result is probably the way to go about implementing a dissector test suite (instead of reading a pcap with tshark and grepping the output). But regarding your PoC having to give extern linkage to the internal dissector code is a big drawback IMO, even if it isn't visible in a DLL (because we use default hidden visibility when the compiler supports it). Maybe that could be solved by including the dissector source file in the test source file? /* test_packet-bt-dht.c */ #include void test_foo(void) {...} int main(void) {...} /* end test_packet-bt-dht.c */ Just something to consider. Build time will be slowish with a large test suite, but running the test suite should be several orders of magnitude faster. And there are no binaries committed to the repo tree for dissectors (assuming the TVB data is included as a C array). BR, João On 01/03/21 19:40, Martin Nyhus wrote: Hi, since the happy-shark discussion died out I've been looking at other ways of adding test coverage for some bug fixes I've been preparing to push, and right now the idea is to add a new unit test suite based on wmem_test for dissector code. I think this should solve the concern that was mentioned about build/CI runtime, but I'm not sure how people feel about the effect on the source tarballs and the repository. My attempt at implementing this is merge request 2250 [0], and I've got some more tests I'd like to add on a branch in my own fork [1]. I'd like to hear what people think about this approach to testing dissector code. - Martin [0] https://gitlab.com/wireshark/wireshark/-/merge_requests/2250 [1] https://gitlab.com/zidel_/wireshark/-/commit/e6f4a741599ac162d168497e45452c1379bac23e ___ Sent via:Wireshark-dev mailing list Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe ___ Sent via:Wireshark-dev mailing list Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
Re: [Wireshark-dev] please close issue 12800
Hi Eugene, 4 juin 2021 18:41:53 Eugène Adell : > Hello, > > anyone with sufficient rights please close : > > https://gitlab.com/wireshark/wireshark/-/issues/12800 Done. Best regards, Pascal. ___ Sent via:Wireshark-dev mailing list Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
[Wireshark-dev] please close issue 12800
Hello, anyone with sufficient rights please close : https://gitlab.com/wireshark/wireshark/-/issues/12800 ___ Sent via:Wireshark-dev mailing list Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe
[Wireshark-dev] Fixing decoding of RDP traffic
Hi, I'm trying to fix the decoding of RDP traffic. My scenario is a typical RDP connection TLS encrypted (well with ciphers lowered so that no PFS is negotiated). So here's the list of my botherings: * I'm setting the TLS key associated with port 3389 and the host, but with RDP, there's 2 negotiation packets at the beginning of the connection before switching to TLS, so these 2 packets gets aggressively decoded as TLS (and it fails of course). That's much a detail but well, still bothering, what's the strategy to adjust this ? * I have configured the next protocol in the SSL records as TPKT, so that works for most of the first packets, but unfortunately quickly RDP goes to fastpath, that is not implemented yet. How can I implement that, I mean do I have to code a new protocol that does TPKT or fastpath, depending on what it can find in the packet, and configure that new TPKTorFastPath protocol in the SSL keys configuration ? * I wrote a decoder in LUA that decodes the RDPUDP protocol on port 3389 on UDP, but my problem is that if I configure SSL decoding on that host and port, everything gets decoded as RDPUDP even the traffic on the TCP port. Is there a way to express "TCP port 3389 decode as TPKT, and UDP port 3389 decode as RDPUDP" ? My question is very general: do I need to write a new RDP dissector that will have a global view, will call the appropriate dissectors on sub part of the packets ? Thoughts welcome :) -- David FORT website: https://www.hardening-consulting.com/ ___ Sent via:Wireshark-dev mailing list Archives:https://www.wireshark.org/lists/wireshark-dev Unsubscribe: https://www.wireshark.org/mailman/options/wireshark-dev mailto:wireshark-dev-requ...@wireshark.org?subject=unsubscribe