Getting a lot of "No wsa:Address in Resolve message" log entries
Closed this issue · 7 comments
So I'm seeing these requests from a couple of the Windows machines on my home network, where the first packet appears to trigger this error, causing Windows to re-try several times immediately which... also fails?
And the error message appears misleading? Or else I'm mis-reading it? Attaching as a file due to the long lines.
This is on a Debian 12 machine running natively under SystemD, same one as the ksmbd issue previously, and this may well be harmless but I wanted to verify what's going wrong here since I can't quite understand it myself?
Interesting, thank you for reporting!
Does the overall discovery still work despite these warnings? That is, does the Windows machine show the Debian host in Explorer?
Going to look at the WS-Discovery spec and whether this is legal behavior...
Ah I see what is going on. First of all the warning message is misleading - sorry about that. It is not that there is "no wsa:Address in Resolve message". The field is there, it is just that its value doesn't match the identifier of the current host. Which, considering that it came from UDP broadcast is perfectly legal. This is just a Resolve message meant to a different host.
So first of all the message should have said something like "message not to this host, ignoring". Second, this shouldn't have been a warning - just a trace level message at best.
The underlying issue is that the code simultaneously checks for existence of "wsa:Address" and its value correctness and the message doesn't differentiate between two scenarios.
I'll fix it in the next release.
Had a bit of a busy day so I couldn't squeeze off a reply sooner.
Yes, the Windows host still sees the machine okay, I was seeing an occasional hiccup where connecting was delayed and noticed that error message in the logs, but the warnings went away for a'while any time I'd restart wsddn or the debian server in troubleshooting. (Been chasing down a GPF that happens under heavy kSMBd load... as in literally playing Fallout 76 over the network share as a stress test.)
Correlation doesn't equal causation but the message being so steadily shown and marked as a warning to be logged I figured worth finding a clean example at the tracing level to submit.
And yes the "no wsa:Address" was confusing me as well since... it's there right at the end... but I didn't know the protocol enough to know that value should match another elsewhere, etc, thank you for explaining things, as there are a few active Windows shares on the network as well.
I'll wait for the next release and verify how things go after a day or so since it's not immediately logged usually.
The fix has now been released in 1.14.
Thank you!
Installed, I'll review the logs tomorrow and update/close accordingly!
Any updates on this? (no rush) 🙂
My apologies, work on-call had me so busy I hadn't circled back. I just have, and yes this resolves the issue entirely, and I haven't had the name-resolution hiccup since the update either though I'm not sure how those two things could be related but I'll take a heisenbug being squashed alongside a real bug any day of the week!
Thank you for pinging me, and again my apologies!