Closed bwesterb closed 1 month ago
This was on Linux. When tetsting on Mac, the advertisement is Incomfort_Gateway._hap._tcp
(for some reason) and that does work. Not sure if it's OS or different network setup between the machines.
Related iOS misbehaviour radar: http://openradar.appspot.com/radar?id=4931940373233664
Mac vs Linux was a red herring. The crucial difference was that the Linux machine had two interfaces. For some reason this caused dnssd
to retry and land on the name Incomfort_Gateway 2
. This in turn hit the earlier mentioned iOS bug. Restricting to a single interfaces by setting Server.Ifaces
fixes it. Surprisingly changing dnssd
to use _2
(etc) instead of 2
doesn't work.
Surprisingly changing
dnssd
to use_2
(etc) instead of2
doesn't work.
Are you sure about that? When you make that change, does the Home app send a different Host header – I expect it to be _2
.
I didn't get to that point yet: dnssd
would keep incrementing the counter and not land on a name it thinks is free.
Ok, so I've made two changes to dnssd, which should fix your issue.
name 2
it will be name_2
.
This should prevent the issue that iOS sends a wrong http host header field as described in http://openradar.appspot.com/radar?id=4931940373233664 Those changes are now in v0.0.34
.
That fixed it. Thanks.
First off: love this package! Recently I tried to re-pair an accessory. Pairing with the Home app times out. With the hkontroller example app it pairs successfully. I made a packet dump, and I found the following difference.
hkontroller sets an empty host header, whereas the Home app send
Host: Incomfort_Gateway\0322._hap._tcp.local
. Go's http server doesn't like that, responding with a400 Bad Request: malformed Host header
.Now, I'm not sure who's at fault here. Btw,
dns-sd -Z _hap._tcp local.
returns