I have some dump AP setup my main router is still on V19 atm
I have a basic dump AP with ether Ksmbd or Samba4 network shearing for a usb drive
with minidlna for media shearing
these AP's are setup with DHCP to get Statically allocated Leases form my main router
the routers host name is the same as in the static lease
V19 works fine but V21 & Master branch has this problem
dnsmasq & odhcpd are disabled
wsdd2 is not showing in the logs at all
wsdd2 seems to stop or not start
I can manually start or restart the service & it works
it will stop at some point I'm thinking a new lease maybe stopping it
anyone else having this problem or know of a change between V19 & V21
Hi, same issue.
WRT1900ACS v2 with openwrt 21.02.2, same on old 21.02.1
Seems that after some time stop to work. After start or restart it works for some time and then disappear...
I'm starting to think it's due to being attached to br-lan
it makes sense it's showed up with the change to DAS
it's like the interface up / down signals of the bridge
are different from a physical port or are wrong
I would imagine a successful dhcp transaction should restart the service but it's not
seem the interface change is detected & the service is restarted
both dhcp and wsddd2 start at the same time
but if the new ip has not been sorted it fails to have an ip to bind wsdd2 to
Thanks for posting these extremely helpful workarounds. I just realized restarting wsdd2 makes the computer reappear in the network overview on my installation and came here that way.
I am just wondering how to debug this a little bit.
If netinterface/dhcp changes (ipv6? Since ipv4 is static on most user's br-lan!) are triggering this:
Previously, on an OpenWRT snapshot from last year, I had samba+wsdd2 ran from a docker container: ServerContainers/samba. Its wsdd2 is from the same source as OpenWRT's one.
This one - including wsdd2 - was running flawlessly for months worth of uptime.
Since this container was started in host networking mode, how was it immune to what the native OpenWRT's one is not?
In my case the situation is appeared after new interface up, doesn' t matter which one, even ppp.
It is connected with that wsdd2 binary restarts itself after appearing new interface on the system for checking any changes and reloading settings/bindings.
I a patch that allow to behavior in this manner only if up interface which wsdd2 is currently binded to, for example, if it' s binded to lan and the interface is restarted via ifdown lan && ifup lan, then wsdd2 is restarted and reloads interface configuration and rebinded to lan again; if it is binded to lan, but wan is restarted, there is nothing.
But if interface is specified via -i switch.
If there is no an interface, the same way wsdd2 as was.
I can confirm that this change network_get_device ifname br-lan work in my case too.
After a reboot the NAS is present. I have an USB3 SSD connected to the R7800 USB3 port.
With the latest master build kernel 5.15 I don't see wrong wsdd2 behaviour even though I didn't modify network_get_device ifname lan
to network_get_device ifname br-lan.
turn's out changing this line just changes wsdd2 to work on all interfaces
witch works out fine for access points
but will send it to wan as well for a router
it's good news if they have fixed something in 5.15 tho
Seems like it's not fixed.
Currently I use it on my new router with kernel 6.1 with default settings.
After a few days the shares disappear from network shares on Windows PCs.
WSDD2 has to be restarted manually in order for the shares to appear again in Network.
