mqtt was identified as TLS

[echoechoin]

-----------------------------------------------------------
* NOTE: This is demo app to show *some* nDPI features.
* In this demo we have implemented only some basic features
* just to show you what you can do with the library. Feel 
* free to extend it and send us the patches for inclusion
------------------------------------------------------------

Using nDPI (4.8.0-4333-467c27ce) [1 thread(s)]
Using libgcrypt version 1.8.6internal
Reading packets from pcap file /home/echo/work/108_sample_result/mqtt.pcap...
Running thread 0...

nDPI Memory statistics:
        nDPI Memory (once):      37.20 KB     
        Flow Memory (per flow):  944 B        
        Actual Memory:           7.83 MB      
        Peak Memory:             7.83 MB      
        Setup Time:              38 msec
        Packet Processing Time:  0 msec

Traffic statistics:
        Ethernet bytes:        695           (includes ethernet CRC/IFC/trailer)
        Discarded bytes:       0            
        IP packets:            1             of 1 packets total
        IP bytes:              671           (avg pkt size 671 bytes)
        Unique flows:          1            
        TCP Packets:           1            
        UDP Packets:           0            
        VLAN Packets:          0            
        MPLS Packets:          0            
        PPPoE Packets:         0            
        Fragmented Packets:    0            
        Max Packet size:       637          
        Packet Len < 64:       0            
        Packet Len 64-128:     0            
        Packet Len 128-256:    0            
        Packet Len 256-1024:   1            
        Packet Len 1024-1500:  0            
        Packet Len > 1500:     0            
        nDPI throughput:       1.96 K pps / 10.42 Mb/sec
        Analysis begin:        11/Apr/2024 14:24:59
        Analysis end:          11/Apr/2024 14:24:59
        Traffic throughput:    0.00 pps / 0 b/sec
        Traffic duration:      0.000 sec
        Guessed flow protos:   1            
        DPI Packets (TCP):     1             (1.00 pkts/flow)
        Confidence: DPI        1             (flows)

Detected protocols:
        TLS                  packets: 1             bytes: 671           flows: 1            

Protocol statistics:
        Safe                           671 bytes

Risk stats [found 1 (100.0 %) flows with risks]:
        Known Proto on Non Std Port                  1 [50.0 %]
        Unidirectional Traffic                       1 [50.0 %]

        NOTE: as one flow can have multiple risks set, the sum of the
              last column can exceed the number of flows with risks.

pcap.tar.gz

[echoechoin]

and this SNMP pcap is identified as TLS: snmp.tar.gz

[utoni]

Without using Wireshark, I would say that such things may happen for malformed packets. nDPI does packet dissection different then Wireshark and thus the results (especially for malformed packets) may vary. Is that packet a forged / fuzzed one?

[echoechoin]

how about the smnp pcap files? They look like right packets.

[utoni]

Please try running ndpiReader again with -d -v2 as additional arguments and paste the output here.

[IvanNardi]

In the first trace, there is (only) a valid Client Hello to m.etax.chinatax.gov.cn, so the classification returned from nDPI seems correct.

In the second trace, the first pkt is a valid Client Hello, but the response from the server is a SMTP banner, in cleartext. This is completely non standard; if this is real traffic I would like to see the next reply from the client: I bet it is some kind of TCP RST or TLS error. You can see this trace as an TLS attempt connection with the server replying with random data, i.e. the TLS handshake fails. No sure what nDPI should/could do differently here...

[echoechoin]

Thanks! Our device is filled with lots of error messages. That is a big problem.