Allow multiple TXT records to be published on the same service

[scotia70]

Hi,
I've built openmdnsd on FreeBSD (to replace avahi) and have found that I can't publish a service with two TXT records. In order to publish Apple's TimeMachine share on my NAS running netatalk I would normally use the avahi record:

<!DOCTYPE service-group SYSTEM "avahi-service.dtd">
<service-group>
  <name replace-wildcards="yes">%h</name>
  <service>
    <type>_adisk._tcp</type>
    <port>9</port>
    <txt-record>sys=waMA=3c:d9:2b:04:2b:6f,adVF=0x100</txt-record>
    <txt-record>dk0=adVF=0xa1,adVN=tm,adVU=12D28B6D-AFD0-1D56-7161-723FBFE36EDC</txt-record>
  </service>
</service-group>

But doing the following with mdnsctl:

mdnsctl publish nas-01 adisk tcp 9 "sys=waMA=3c:d9:2b:04:2b:6f,adVF=0x100" "dk0=adVF=0xa1,adVN=tm,adVU=12D28B6D-AFD0-1D56-7161-723FBFE36EDC"

throws a superfluous argument error.
Running two mdnsctl commands with a TXT record in each throws a collision error.
Can you permit multiple TXT records on the command line?
Thanks.

[haesbaert]

Indeed currently there is no support for publishing two TXT records, I was not aware of any service that needed that. It's possible that this became common in more recent years, I'll have to check the RFC, but this will require some modifications to the daemon as well.

[scotia70]

I was hoping just a change to mdsctl. I've attached another example of a service requiring multiple text records, my printer.

Note that when I run mdsctl browse -r it shows only the first TXT field:

+++ Brother HL-1210W                                 pdl-datastream       tcp
 Name: Brother HL-1210W
 Port: 9100
 Target: BRNC03896916881.local
 Address: 10.1.1.207
 Txt: txtvers=1

[haesbaert]

Sadly it is not that simple. Check mdns_service structure, it expects just one txt. This is something defined by the dns-sd protocok, not mdns itself. I was quite sure it was only one text record in 2011, but I might have misunderstood the RFC. In any case we need to convert that single txt you multiple txts, so the daemon will probably have a list, and we need to pass that list down/up to mdnsctl. I intend to write support for it, as this is a basic functionality (seems at least). I can't promise a date since I'm involved in other projects now.

…

On Tue, 14 Mar 2017 at 11:16, scotia70 ***@***.***> wrote: I was hoping just a change to mdsctl. I've attached another example of a service requiring multiple text records, my printer. [image: screen shot 2017-03-14 at 21 12 33] <https://cloud.githubusercontent.com/assets/17132292/23895848/64c878cc-08fb-11e7-922e-7323de9d78f7.png> — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#19 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAMdEGlUB982kDFGwWFVE6J5F8tdkvDsks5rlmjwgaJpZM4McJxZ> .

[scotia70]

This might be my reason to get into serious C programming :)

FYI: this is what MacOS reports when browsing for the printer:

$ dns-sd -L "Brother HL-1210W" _pdl-datastream
Lookup Brother HL-1210W._pdl-datastream._tcp.local
DATE: ---Tue 14 Mar 2017---
21:25:57.843  ...STARTING...
21:25:58.040  Brother\032HL-1210W._pdl-datastream._tcp.local. can be reached at BRNC03896916881.local.:9100 (interface 4)
 txtvers=1 qtotal=1 pdl= note= ty=Brother\ HL-1210W\ series product=\(Brother\ HL-1210W\ series\) adminurl=http://BRNC03896916881.local./ priority=25 usb_MFG=Brother usb_MDL=HL-1210W\ series usb_CMD=PJL,HBP Color=F Copies=T Duplex=F Fax=F Scan=F PaperCustom=T Binary=T Transparent=F TBCP=T UUID=e3248000-80ce-11db-8000-c03896916881

It breaks up each TXT with a space and escapes any spaces within a TXT.

[haesbaert]

Indeed I checked the RFC and it changed. At docs/ you can find the dns-sd draft (not a RFC at the time), there is no section 6.8 "Multiple TXT records". But if you check the RFC 6763 (the draft formalization) they have this multiple records under section 6.8. I'd love a patch, am happy to help with any difficulties :-).

…

On Tue, 14 Mar 2017 at 11:32, scotia70 ***@***.***> wrote: This might be my reason to get into serious C programming :) FYI: this is what MacOS reports when browsing for the printer: $ dns-sd -L "Brother HL-1210W" _pdl-datastream Lookup Brother HL-1210W._pdl-datastream._tcp.local DATE: ---Tue 14 Mar 2017--- 21:25:57.843 ...STARTING... 21:25:58.040 Brother\032HL-1210W._pdl-datastream._tcp.local. can be reached at BRNC03896916881.local.:9100 (interface 4) txtvers=1 qtotal=1 pdl= note= ty=Brother\ HL-1210W\ series product=\(Brother\ HL-1210W\ series\) adminurl=http://BRNC03896916881.local./ priority=25 usb_MFG=Brother usb_MDL=HL-1210W\ series usb_CMD=PJL,HBP Color=F Copies=T Duplex=F Fax=F Scan=F PaperCustom=T Binary=T Transparent=F TBCP=T UUID=e3248000-80ce-11db-8000-c03896916881 It breaks up each TXT with a space and escapes any spaces within a TXT. — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#19 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAMdEAWNqiZ1MHywwK3U8vrI6v53bt_Vks5rlmzFgaJpZM4McJxZ> .

[scotia70]

Hi, thanks for your prompt responses.

According to:
http://www.zeroconf.org/rendezvous/txtrecords.html

Jaguar's DNSServiceDiscovery.h APIs are, like most Unix APIs, based on C strings. How then does a client encode multiple pascal strings containing name/value pairs using a single C string? The answer is that Jaguar's DNSServiceDiscovery.h APIs use ASCII 1 as the boundary marker between constituent strings within the DNS TXT record. This value can be inserted into a C string using '\001', as shown below:

DNSServiceRegistrationCreate(..., "a=1\001b=2\001c=3", ...);

So I tried:

mdnsctl publish nas-01 adisk tcp 9 sys=waMA=3c:d9:2b:04:2b:6f,adVF=0x100$'\001'dk0=adVF=0xa1,adVN=tm,adVU=12D28B6D-AFD0-1D56-7161-723FBFE36EDC

and got this from MacOS:

Lookup nas-01._adisk._tcp.local
DATE: ---Tue 14 Mar 2017---
21:44:39.420  ...STARTING...
21:44:39.421  nas-01._adisk._tcp.local. can be reached at nas-01.local.:9 (interface 4)
 sys=waMA=3c:d9:2b:04:2b:6f,adVF=0x100\\x01dk0=adVF=0xa1,adVN=tm,adVU=12D28B6D-AFD0-1D56-7161-723FBFE36EDC

If I substitute $\001\ for $\101 which is the letter 'A' then I see the 'A' in the lookup. So the shell is expanding the octal correctly.

Anyway I'm not sure if this is an Apple thing or RFC.

Thanks

[scotia70]

Ahh ok, after reading some of rfc6763 it seems I may be barking up the wrong tree. What is really needed is a single TXT record with multiple key/value pairs: As per 6.1 of the RFC:

   The format of the data within a DNS TXT record is one or more
   strings, packed together in memory without any intervening gaps or
   padding bytes for word alignment.

   The format of each constituent string within the DNS TXT record is a
   single length byte, followed by 0-255 bytes of text data.

And the example:

        -------------------------------------------------------
        | 0x09 | key=value | 0x08 | paper=A4 | 0x07 | passreq |
        -------------------------------------------------------

So the parser needs to take multiple key/value pairs and break them up using their key/value pair length as the leading byte.

I'll take a look at parser.c and see what I come up with...

[scotia70]

Which is how wireshark decodes a multi key/value pair TXT:

[haesbaert]

That makes more sense. My initial idea was to leave the interpretation of the txt tecord to the application, so mdnsctl should split them up and display. Since I never really needed it I ended up never writing it. What is happening on your truncating output on mdnsctl browse is that there is probably a null bute somewhere, as the whole TXT should be there, it's just truncating the output.

…

On Tue, 14 Mar 2017 at 12:24, scotia70 ***@***.***> wrote: Which is how wireshark decodes a multi key/value pair TXT: [image: screen shot 2017-03-14 at 22 22 31] <https://cloud.githubusercontent.com/assets/17132292/23898334/db436562-0904-11e7-9f87-aace6bdef707.png> — You are receiving this because you commented. Reply to this email directly, view it on GitHub <#19 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAMdEI8AT1BvDq3IxQFd82FL-WLH04Svks5rlnj9gaJpZM4McJxZ> .