loving FreeRTOS+TCP so far but i have an issue when using mDNS. Trying to ping
mydevice.local from my ubuntu machine i can see the mDNS request being generated and
my device answering. However the response from my device contains not only the Answer RR but also the Question. Also the AA flag is not set. Since according to the mDNS RFC RFC6762 this behaviour is not allowed and so the response seems to get ignored. Wireshark also flags it as unsolicited. Am i doing something wrong?
The only configuration i did was setting #define ipconfigUSE_TCP 1 #define ipconfigUSE_IPv4 1 #define ipConfigUSE_IPv6 0 #define ipconfigUSE_LLMNR 0 #define ipconfigUSE_DNS 1
//#define ipconfigUSE_DNS_CACHE 0 #define ipconfigUSE_MDNS 1 #define ipconfigUSE_NBNS 1
Which version of FreeRTOS+TCP are you using? Last time I checked mDNS queries from my Windows PC to the device, it seems to have been working fine (both pings and mDNS queries).
I will check the wireshark logs to see why its getting ignored.
Can i attach a wireshark capture here?
Yes, you should be able to upload files. I will ask to update the permission.
Hi @dinocroc123,
Thanks for reporting this for us!
Could you help apply below change and let us know if that work for you?
At the meanwhile, I’ll prepare a PR for this.
In response messages for Multicast domains, the Authoritative Answer
bit MUST be set to one (not setting this bit would imply there’s some
other place where “better” information may be found) and MUST be ignored on reception.
Thanks, but still the packet doesnt get recognized and still marked by wireshark as unsolicited. I think you need to remove the question inside the response packet aswell to comply with the RFC:
Multicast DNS responses MUST NOT contain any questions in the Question Section. Any questions in the Question Section of a
received Multicast DNS response MUST be silently ignored. Multicast
DNS queriers receiving Multicast DNS responses do not care what
question elicited the response; they care only that the information
in the response is true and accurate.
I’ve attached the new capture mdns2.tar.gz (671 Bytes)
Hi @dinocroc123,
As RFC described, even it has the question section, the receiver can ignore it silently.
Does your environment have stricter rule on this? Is it possible to bypass it?
Yeah i was wondering that too, but i’m just using plain Ubuntu Linux, no special modification.
Only thing i can think of is that if the question in the response gets faithfully ignored entirely as if it wasnt there, then the compressed name format of the response wont work since it points to the name in the question. It would be awesome if you could tell me how to disable this question packet in the FreeRTOS code so i can check if that fixes things.
Also i’ve tried it using a windows vm and it does work, but it feels like its accepting the response with the question in it as a fallback, and only after retrying 10 seconds after the initial request.
To achieve that, you can construct MDNS response separately in FreeRTOS_DNS_Parser. Like the pseudo code below:
if( xSet.usPortNumber == ipMDNS_PORT )
{
/* Set all DNS response header. */
vSetField16( xSet.pxDNSMessageHeader, DNSMessage_t, usFlags, dnsMDNS_FLAGS_IS_RESPONSE );
vSetField16( xSet.pxDNSMessageHeader, DNSMessage_t, usQuestions, 0 );
/* Set usAnswers, usAuthorityRRs and usAdditionalRRs */
/* Set the DNS response payload starting with domain name. */
pucMdnsAnswer = ( char* )( xSet.pxDNSMessageHeader + 1 );
/* Copy length and name here. Note that a NULL terminator is mandatory after the name. */
/* Then set the type, class, and TTL, IP address length and IP address itself. */
}
Note that current structure LLMNRAnswer_t is not proper for this case because length of domain name is not fixed. I’d suggest to create a different structure to address this.
Allright, i changed the code to leave out the question and now it works. (Wireshark capture attached). Shall i create a PR Request? Dont know if my code is good enough though. It also seems to not be quite right yet, since wireshark still marks this packet as unsolicited.