Extract MDNS Metadata

[lucaderi]

MDNS is often used to advertise host services as in the enclosed packets.

This ticket is to request to extend struct ndpi_flow_struct { . } adding a new entry for MDNS (similar to SSDP an other protocols) that in case of advertised services (as in the enclosed pcap) they are reported in the flow metadata.

mdns.pcapng.zip

[Gianla]

Should the MDNS entry be structured similarly to the DNS one, or should it only contain advertised host service names?

Regarding metadata parsing, would it be better to extend /src/lib/protocols/dns.c, or should I implement a new protocol dissector for MDNS?

[lucaderi]

Use the dns dissector, no need to create fresh code as it is already doing what's necessary.

[Gianla]

I've tried to add the MDNS entry outside the union because i don't want it to interfere with the dns entry, but at this point at compile time i get "Size of the flow struct increased to more than 1232 bytes, please check if this change is necessary.".
Before changing the hardcoded limit of 1232 bytes, i want to ask if that is the correct way or if it should be done in another way.

[IvanNardi]

Is it possible to add a new specific mdns entry in the union, at the same level of dns or tls_quic?

…

On Tue, Jul 15, 2025, 14:09 Gianla ***@***.***> wrote: *Gianla* left a comment (ntop/nDPI#2906) <#2906 (comment)> I've tried to add the MDNS entry outside the union because i don't want it to interfere with the dns entry, but at this point at compile time i get "Size of the flow struct increased to more than 1232 bytes, please check if this change is necessary.". Before changing the hardcoded limit of 1232 bytes, i want to ask if that is the correct way or if it should be done in another way. — Reply to this email directly, view it on GitHub <#2906 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ADBD4JZF6DERCRI7Z2NQUCL3ITVQDAVCNFSM6AAAAACAD3OHACVHI2DSMVQWIX3LMV43OSLTON2WKQ3PNVWWK3TUHMZTANZTGM2TEOBUGU> . You are receiving this because you are subscribed to this thread.Message ID: ***@***.***>

[Gianla]

For the mdns.pcap.ng file linked here, is it intended behaviour that process_aswers() is never called? You can check it from this simple fork which is only debugging process_aswers and process_queries: https://github.com/Gianla/nDPI-fork
I can't copy answers and save them in a metadata field anyways if this code is never reached. Changing dns.c too much (for example search_dns() function) doesn't seem like the best option to me.

[IvanNardi]

@Gianla
Two points.
First. Right now process_answers() is called only for reply messages and you don't have replay messages in that pcap... Let's try something trivial like:

--- a/src/lib/protocols/dns.c
+++ b/src/lib/protocols/dns.c
@@ -821,6 +821,8 @@ static void search_dns(struct ndpi_detection_module_struct *ndpi_struct, struct
     if(rc == -1)
       printf("[DNS] Error queries (query msg)\n");
 #endif
+    off = rc;
+    rc = process_answers(ndpi_struct, flow, &dns_header, off, &proto);
   } else {

Just a POC; no proper error checking!
Please note that this change shoudn't have any impact on DNS packets because you don't usually have replies in DNS requests...

Second. Which are the exact metadata that you want to extract? For example, what info you want from the first pkt of that pcap?

[Gianla]

@IvanNardi Thank you for your reply. I knew there was no reply message in the pcap, but I thought that process_answers() would have been called anyways the moment that the dissector realize that the packet contains answers (even if it is a query).

Please note that this change shoudn't have any impact on DNS packets because you don't usually have replies in DNS requests...

I realized. That's why i didn't want to change any more important function (e.g. search_dns()) than process_answers(). But if it's necessary, we obviously want to do that.

Second. Which are the exact metadata that you want to extract? For example, what info you want from the first pkt of that pcap?

I'm trying to extract the advertised services, contained in the answer field of the packet. For example, the info I'm trying to extract from the first one is the Name field from the first and only answer (first field if you open it in Wireshark), which appears to be _companion-link._tcp.local.

[IvanNardi]

I'm trying to extract the advertised services, contained in the answer field of the packet. For example, the info I'm trying to extract from the first one is the Name field from the first and only answer (first field if you open it in Wireshark), which appears to be _companion-link._tcp.local.

If this is the ONLY info you need:

• the PTR domain are already saved in flow->protos.dns.ptr_domain_name (if correctly processed), i.e. no need to change anything in the protocols union....
• you need to update ndpi_grab_dns_name() to correctly extract the compress name (after having applied something like the 2-lines patch above)

[Gianla]

Please check my last two commits: https://github.com/Gianla/nDPI-fork.
Even by calling process_answers() with error checking, flow->protos.dns.ptr_domain_name is still empty aswell as hostname inside ndpi_grab_dns_name(). The answer is nowhere to be seen anyways. I'm asking again if this is intended behaviour.

[IvanNardi]

• you need to update ndpi_grab_dns_name() to correctly extract the compress name (after having applied something like the 2-lines patch above)

This

[Gianla]

Good afternoon, I pushed a working implementation to my personal fork here.

Functionally, it behaves as expected and implements the feature: advertised services are stored in the union as pointers, I decided for a maximum of MAX_NUM_DNS_RSP_ADDRESSES (4) services — though this may need to be adjusted.

Extra allocated memory is needed to remember the advertised services, so I used dynamic allocation too. Unfortunately, I’ve noticed that it currently causes memory leaks when run with ndpiReader (you can easily spot them using Valgrind). Please note that this is not a final solution — the push still contains some debug printf() statements to help illustrate the behavior with the linked .pcapng file.

I left them to show the behavior with the linked pcapng file: for the last flow, it seems like calling search_dns_again resets the counter by executing flow->protos.mdns_metadata.num_services = 0 again, which results in overwriting already allocated pointers and causes the leak.

At this point I'm asking if I should move this initialization somewhere else or if I should find a solution. Thanks in advance.

[Gianla]

Good afternoon,

I created a clean fork to clearly show all the differences; you can see the changes on this branch here.

I no longer experience memory issues. As I suspected, keeping mdns_metadata inside the union conflicted with the dns entry. Moving it outside the union, along with some smaller adjustments, resolved the problem.

Please note that all tests pass by running make check.