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
