hap
hap copied to clipboard
Server does not appear to do any service annoucement via DNS-SD
I'm running the example in the README usage section; the server starts and is listening but does not appear to be doing any service announcement and therefore never can be paired in the Home app.
If I run dns-sd -B _hap._tcp it does not appear.
I tried the hklamp example from the previous library hc and it worked fine and did show up when running dns-sd -B _hap._tcp so I feel that I can rule out my setup/system/network.
I seem to have the same fate with running hkcam: v0.0.9 (hc version) works fine, but if I try the newer version v0.1.0 that has migrated to hap it fails to show up.
I am using macOS Monterey and it is a M1 Max machine.... but I'm hoping that this is not the issue.
If I force a downgrade of dnssd to v1.1.1 it works again. Seems to have broken in dnssd v1.2.0+
I'm unable to reproduce your problem. I've tried it on macOS 12.3.1 (Monterey) and the dns-sd entry for the HomeKit accessory appears as expected.
Do you see the dns-sd entry in Discovery.app?
Same issue here. After i force replaced [email protected] with [email protected] via the go.mod file, hap appears in HomeKit and your recommended Discovery app.
@rogchap Have you tried v0.0.17 of hap yet, where dnssd v1.2.3 is used?
@brutella Same fate unfortunately: does not work 😞
I notice that when I call cancel on the context that is passed to hap.Server.ListenAndServe(ctx) to shut everything down, the http server will stop successfully but the dnssd responder will not stop and hang the process.
Using hap v0.0.17 with forcing dnssd v1.1.1 still works though.
@brutella Same fate unfortunately: does not work 😞
I notice that when I call
cancelon the context that is passed tohap.Server.ListenAndServe(ctx)to shut everything down, the http server will stop successfully but thednssd responderwill not stop and hang the process.Using hap
v0.0.17with forcing dnssdv1.1.1still works though.
I have this issue too
@brutella I've since updated to Ventura and still see the same issue even with the latest versions of hap and dnssd.
I'm guessing that it's an arm vs amd issue?
I have however seemed to track the problem down to this change: https://github.com/brutella/dnssd/compare/300f11afe64a6514a2aeab95e9d27d67d55d19c5...2e23d4dbff63cfa7a7195138ffb7c1743af141d9#diff-d423371206870c274f93e6da9c6976865b7238016127fdbbf4cbeae0a60090fcR121
If I revert all the changes to responder.go then all is working again, so the bug is in here somewhere; possibly the r.announceAtInterface() function.
I'm still digging, but though I'd share my findings so far, just in case you have an "ah ha" moment.
go r.announceAtInterface(service, iface) these goroutines seem to be the cause of the dnssd responder hanging when the context gets canceled to shutdown the server.
Example code:
ctx, cancel := context.WithCancel(context.Background())
go func() {
sig := waitForShutdown()
logger.Debug("Notify", zap.String("signal", sig.String()))
logger.Info("Shutting down controller")
cancel()
}()
fs := hap.NewFsStore("./db")
b := accessory.NewSwitch(accessory.Info{
Name: "MySwitch",
Manufacturer: "Me",
})
s, _ := hap.NewServer(fs, b)
s.ListenAndServe(ctx)
Ctrl-C will cause the server to shutdown, but not the dnssd responder
I'm also think we have a closure issue as gorotines are not executed straight away; ie:
for _, service := range services {
for _, iface := range service.Interfaces() {
+++ service, iface := service, iface
go r.announceAtInterface(service, iface)
}
}
Could you please enable debug logging for dnssd?
import(
"github.com/brutella/dnssd/log"
)
log.Debug.Enable()
Do you see the statements Sending 1st announcement and Sending 2nd announcement for every network interface in the log?
I see this statement pre changes in responder.go; but in 1.2.+ I do not; far less debug logs in general.
I've just pushed dnssd v1.2.6 with some small changes.