We cannot define a static IP address for the device in Wiim apps to avoid a re-discovery?

[simbun]

I sure don't need UPnP nor want it It's the Android WiiM Home app that wants it, at least starting from a few releases back. My network and the WiiM app were working well with just mDNS reflector enabled, until it started not working anymore.

It's still working for me and @Nikita too by the looks of it with only a mDNS repeater.

The problem with UPnP is that, if you enable it on your router, it can also be used by devices to "punch thru" your firewall. I know I can set rules to enable just specific UPnP packets from specific devices to traverse a vlan (but also requires changing TTL) and not enable it at the firewall level. But the message I got from WiiM was "just enable UPnP", which if taken literally is a bad idea.

The UPnP setting on your router is likely to be referring to the Internet Gateway Device Protocol, which I agree you do want to keep disabled, but that doesn't stop UPnP working on your network. If you install the mconnect app does it discover the WiiM hardware (on the same vlan)? If it does then UPnP is working.

But we keep missing the point. None of this would be needed if the WiiM app used a static address. The app itself lets you set the WiiM with a static address, yet doesn't use it to connect to it. There's no reason for me to hack my home network to work around a WiiM-specific problem that has no reason to even exist: my WiiM will always be at the same address.

We're not missing the point, it's working for us and we're trying to help.

The mDNS and UPnP protocols were designed to work on the same broadcast domain, this is not a WiiM specific problem.

Supplying an IP address will only help if you use the WiiM Home app exclusively, and only then for online services, so it's really a niche of a niche.

 

[robca]

We're not missing the point, it's working for us and we're trying to help.

The mDNS and UPnP protocols were designed to work on the same broadcast domain, this is not a WiiM specific problem.

Supplying an IP address will only help if you use the WiiM Home app exclusively, and only then for online services, so it's really a niche of a niche.

The old "works for me" reply, I see It used to work for me, too. Now it's hit and miss (Android). IT works from another Android device. Still, it would all work much better caching the last address (and running discovery in the background for other devices)

How's "using an IP address" in the WiiM Home app going to impact the other working services in the WiiM Pro device? Only the WiiM app is broken, every other service on the WiiM that use mDNS is working. The WiiM Watcher extension uses an IP address just fine.

I'm not suggesting to disable mDNS on the device, that would make no sense. I'm suggesting that the WiiM Home app should cache the last working IP address and look there first, before running discovery and issuing the useless error below. The app can find the WiiM, but somehow refuses to use it. All the while that same WiiM is working from any other app and service on the same phone. Or even the WiiM Home app as long as I do discovery from the vlan, then switch to main lan.

It's purely a discovery issue in the app. Everything works as long as the app gets the IP

 

[simbun]

How's "using an IP address" in the WiiM Home app going to impact the other working services in the WiiM Pro device? Only the WiiM app is broken, every other service on the WiiM that use mDNS is working.

My point was that in and of itself what does it do? Specifying an IP address resolves one very specific problem you're having on your network with one of your phones. Is that the business justification?

The app can find the WiiM, but somehow refuses to use it.

I think those messages just mean that the device was once connected, but it's now not discoverable. Try turning the WiiM off and you'll see the same thing.

 

[robca]

My point was that in and of itself what does it do? Specifying an IP address resolves one very specific problem you're having on your network with one of your phones. Is that the business justification?

Well, the business justification is that caching the IP makes it faster for everyone, and for people like me and the user posting this thread, solves an actual problem where the Wiim app is unusable. You have at least 2 people reporting this problem. So, advantages for everyone, no downside, helping the few users for which the discovery process is problematic.

I think those messages just mean that the device was once connected, but it's now not discoverable. Try turning the WiiM off and you'll see the same thing.

You are right, I had missed it (same if you "forget it" from that screen). Thanks for pointing this out. But, even more so, all it would take is for the WiiM home app to use the cached address of that device, since it's at the same address as before.

Do you agree that having Alexa Cast being able to find and use the WiiM while the WiiM app cannot find it is broken? Can you think of any reason why, outside of a bug in the WiiM app (or a timeout or something similar), the same WiiM device is discoverable using Chromecast, Airplay, Tidal, Amazon and the Bonjour browser, but not the WiiM app? And why, everything else being the same on my network, the app can randomly find and use the WiiM, but not reliably?

 

[simbun]

Well, the business justification is that caching the IP makes it faster for everyone, and for people like me and the user posting this thread, solves an actual problem where the Wiim app is unusable. You have at least 2 people reporting this problem.

I don't know enough about mDNS to be able to answer that, but if the response to an mDNS discovery included the capabilities of the player then caching the IP could actually be slower, especially if you have multiple devices.
With cached addresses the app would need to connect to each device to check that it's online and of its capabilities, and probably still issue an mDNS discovery for any other devices.

Can you think of any reason why, outside of a bug in the WiiM app (or a timeout or something similar), the same WiiM device is discoverable using Chromecast, Airplay, Tidal, Amazon and the Bonjour browser, but not the WiiM app? And why, everything else being the same on my network, the app can randomly find and use the WiiM, but not reliably?

I don't have an answer for any of that, but given that it's only a problem with one of your phones that's where I'd start looking.

I'm.not arguing against such a change so please don't think I am, it's just not an elegant solution.

 

[d6jg]

I'm sorry, but this is completely wrong. Yes, mDNS by itself won't traverse vlans, but with any type of redirector or smcroutes, it does. My network works for any other device and app, excluding only the WiiM Home app. Everything else, including the WiiM when acting as a Chromecast, Alexa Cast, Tidal, Airplay end point works. Just the WiiM app has problems

If WiiM put such a sticker, they would shoot themselves in the foot with all the people who learned a long time ago that you can safely run IoT devices in a vlan, and understand enough networking concepts to make it work. What WiiM should do, is either fix the discovery problems (why can Bonjour browser see the WiiM but not the WiiM app?) or allow the use of static addresses.

WiiM, instead, tells you that your device is online but in another network. So discovery kinda works, but not really

I don't wish to start an argument but your use case is clearly not in the majority. Probably 99%+ people don't know what a VLAN is let alone how to set one up. The WiiM products are clearly aimed at consumers at a price point where the evidence from this forum is that many are not very, if at all, experienced in digital streaming let alone the underlying technology including the networking issues.
I'd still suggest to you that VLANs can make things unnecessarily complicated - not because they are complicated to set up - but because they require accurate and consistent categorisation of what you mean to achieve before you even start. I run some VLANs but I don't put my streamers into the same one as things like my central heating controller or Ring doorbells.
In hindsight the sticker should read "We do not support this product if used in a VLAN environment" i.e. a do so at your own risk statement.

PS. I do agree that the discovery mechanism could be better and as an LMS user I'd like the option to set a specific server IP address rather than rely on UDP.

 

[robca]

I don't have an answer for any of that, but given that it's only a problem with one of your phones that's where I'd start looking.

I'm.not arguing against such a change so please don't think I am, it's just not an elegant solution.

Well, it turns out that all Android devices on my network have the same issue, the other device worked that one time I tried, but it's not working reliably anymore, exhibiting the same problem.

As for elegance, the OP and I (and probably others) have poorly working WiiM devices. Something is broken when it should work, and that's not very elegant either . The WiiM app does something strange compared to everything else out there. Not the WiiM device, which works.

Judging from the amount of posts online for people asking about mDNS redirectors for Chromecast, Airplay and other streaming devices, my scenario is not uncommon at all. Might not be mainstream, but more and more people are putting all IoT devices, including streamers. in vlans. It's not just a few weirdos doing it, but becoming more of a common scenario. Properly supporting mDNS discovery across vlans is something that all streaming devices do properly. After all, if you are worried about security, a 5 years old random Chinese Chromecast device with no security updates is a security issue. WiiM keeps improving their devices, but security is hard. Streamers are as much a security concern as any other IoT device, there's nothing inherently less risky about them.

So, yes, not the most common scenario, but something that would be easy to fix in many different ways. And something that works for the rest of similar devices. And the WiiM, as long as you don't need the WiiM app

 

[simbun]

Judging from the amount of posts online for people asking about mDNS redirectors for Chromecast, Airplay and other streaming devices, my scenario is not uncommon at all. Might not be mainstream, but more and more people are putting all IoT devices, including streamers. in vlans. It's not just a few weirdos doing it, but becoming more of a common scenario. Properly supporting mDNS discovery across vlans is something that all streaming devices do properly. After all, if you are worried about security, a 5 years old random Chinese Chromecast device with no security updates is a security issue. WiiM keeps improving their devices, but security is hard. Streamers are as much a security concern as any other IoT device, there's nothing inherently less risky about them.

I am in agreement that WiiM should resolve the mDNS discovery issues, or at least identify what's wrong in your setup, and if you've described your setup in a ticket then I hope they're able to test it.

Would you mind sharing what system you're using? I'm currently using EdgeOS which works well with the mDNS repeater (with Pixel phone and Samsung tablet) but I may be looking at alternatives soon.

 

[robca]

Sure, happy to. I'm using a Dynalink DL-WRX36 running OpenWRT 23.05.2, and the standard Ahavi redirector.

My network is relatively simple, a main network, plus IoT and Camera vlans. IoT devices can access the internet, cameras cannot (Chinese cameras are notoriously bad). standard firewall to allow lan devices to access iot and cameras, with only the necessary ports open for DHCP, DNS and mDNS. I also have adblock-fast enabled to block ads and trackers at the network level.

 

[simbun]

Sure, happy to. I'm using a Dynalink DL-WRX36 running OpenWRT 23.05.2, and the standard Ahavi redirector.

In looking at OpenWRT I found UDP Broadcast Relay that has builds for many platforms including OpenWRT, pfsense and EdgeOS, so I might give that a go at some point as it looks like it might handle UPnP too! Not sure how I've missed this before.

Sounds like we have a very similar setup.

 

[robca]

In looking at OpenWRT I found UDP Broadcast Relay that has builds for many platforms including OpenWRT, pfsense and EdgeOS, so I might give that a go at some point as it looks like it might handle UPnP too! Not sure how I've missed this before.

Sounds like we have a very similar setup.

Uh, that's interesting. I know I could do something similar with nftables, but the UDP relay has a debug output and that helps.

I installed the relay, disabled ahavi, and ran the following (br-lan.101 is the iot lan)

udp-broadcast-relay-redux --id 1 --port 5353 --dev br-lan.101 --dev br-lan.1 --multicast 224.0.0.251 -d

<- [ 192.168.10.170:5353 -> 224.0.0.251:5353 (iface=12 len=441 ttl=255)
-> [ 192.168.10.170:5353 -> 224.0.0.251:5353 (iface=11)

<- [ 192.168.10.170:5353 -> 224.0.0.251:5353 (iface=11 len=210 ttl=65)
Echo (Ignored)

Like before, everything else works, the WiiM app doesn't. But I wonder if the "Echo (ignored)" message has some relevance. Also, all other packets have a ttl of 255, the Echo is 65

Moreover, the WiiM sends the longest packets, so I wonder if that might cause issues, too, somewhere along the line

On the other hand, there seems to be no UPnP SSDP packets

udp-broadcast-relay-redux --id 1 --port 1900 --dev br-lan.101 --dev br-lan.1 --multicast 239.255.255.250 -d

shows no traffic, outside of my smartphone

 

[simbun]

Like before, everything else works, the WiiM app doesn't. But I wonder if the "Echo (ignored)" message has some relevance. Also, all other packets have a ttl of 255, the Echo is 65

When using the WiiM Home app (on main vlan) to play music on the WiiM (on the iot vlan) from my music server (on my main vlan) I notice that there are packets being dropped originating from the WiiM toward the WiiM Home App. This manifests in big delays in the tracks starting.

I wonder if it's not the mDNS discovery that's failing for you, but something else they're doing whist establishing a connection. Have you tried allowing all traffic from iot to the main vlan (turn all the other devices on the vlan off if need be) to see if that's make a difference?

 

[robca]

When using the WiiM Home app (on main vlan) to play music on the WiiM (on the iot vlan) from my music server (on my main vlan) I notice that there are packets being dropped originating from the WiiM toward the WiiM Home App. This manifests in big delays in the tracks starting.

I wonder if it's not the mDNS discovery that's failing for you, but something else they're doing whist establishing a connection. Have you tried allowing all traffic from iot to the main vlan (turn all the other devices on the vlan off if need be) to see if that's make a difference?

Well, yes, if I enable all packets, it works. But that defeats the purpose of having an iot vlan in the first place (I know you are suggesting it only as a test). My router is fast enough that dropped packets should never happen, so if it happens, it happens on the WiiM or the WiiM Home app...

I noticed that IPv6 seems to cause problems (even if Avahi is properly configured to reflect IPv6 as well), and I'm experimenting turning off IPv6 everywhere, to see if it makes a difference. Need more tests, though

 

[simbun]

Well, yes, if I enable all packets, it works. But that defeats the purpose of having an iot vlan in the first place (I know you are suggesting it only as a test). My router is fast enough that dropped packets should never happen, so if it happens, it happens on the WiiM or the WiiM Home app...

When I said 'dropped packets' I meant that they were being dropped through firewall rules (originating from iot toward lan and not an established connection).
With the firewall rules in place can you log the packets that are being blocked, causing the "discovery" to fail?

 

[simbun]

I noticed that IPv6 seems to cause problems (even if Avahi is properly configured to reflect IPv6 as well), and I'm experimenting turning off IPv6 everywhere, to see if it makes a difference. Need more tests, though

I have IPv6 disabled on the router.

 

[robca]

When I said 'dropped packets' I meant that they were being dropped through firewall rules (originating from iot toward lan and not an established connection).
With the firewall rules in place can you log the packets that are being blocked, causing the "discovery" to fail?

Got it now, sorry.

I can only log rejected packets, not dropped, so I will have to change my settings and play with it, but need to ensure I don't break what's working for the family https://openwrt.org/docs/guide-user/firewall/fw3_configurations/fw3_traffic_logging

Right now, with IPv6 disabled everywhere, things seem to work. Too early to tell for sure, but that could explain why I'm having problems you and others don't have...

 

[simbun]

Right now, with IPv6 disabled everywhere, things seem to work. Too early to tell for sure, but that could explain why I'm having problems you and others don't have...

Fingers crossed!

 

[robca]

As an update, it looks like I solved my problem and things have been working reliably for a couple of days now. I waited until things were working long enough, because in the past I had periods of working followed by refusal to work.

After trying all the mDNS reflectors/repeaters in the OpenWRt opkg repository, it looks as if there is some sort of obscure problem with Avahi 0.8-8 and the WiiM app. Everything else works with Avahi, including all apps using the WiiM Pro, just not the WiiM app. Weirdly, WiiM support blamed UPnP for my problems, but I explicitly disallow UPnP in my network environment, yet everything works now. I wish they spent a bit more time looking at the logs instead of blowing it off.

The only thing that works is the mdns-repeater app (https://openwrt.org/packages/pkgdata/mdns-repeater), it's 4 years old and not updated anymore, but it works by simply adding the below to the mdns_repeater configuration file.

With that, everything else works like before, but now the WiiM app also works. I don't have the time/skills to check how various packets are impacted by Avahi vs the mdns-repeater, so why Avahi doesn't work in my specific case but seems to work for others is going to stay a mystery. Also, Avahi seems to work for a variable amount of time if I restart the service, but that's not a long term option (it caused a lot of false hopes, though . Every time I changed a setting, it worked for a while.

If anyone else sees this in the future with a discovery problem even with the Avahi redirector installed, try mdns-repeater instead. It's more lightweight than Avahi, as an added bonus for router with fewer resources than mine

Thanks to the various folks (esp @simbun) for all the suggestions.

config mdns_repeater 'main'
    list interface 'br-lan.1'
    list interface 'br-lan.101'
    list interface 'br-lan.102'

 

[spacegrass]

As an update, it looks like I solved my problem and things have been working reliably for a couple of days now. I waited until things were working long enough, because in the past I had periods of working followed by refusal to work.

After trying all the mDNS reflectors/repeaters in the OpenWRt opkg repository, it looks as if there is some sort of obscure problem with Avahi 0.8-8 and the WiiM app. Everything else works with Avahi, including all apps using the WiiM Pro, just not the WiiM app. Weirdly, WiiM support blamed UPnP for my problems, but I explicitly disallow UPnP in my network environment, yet everything works now. I wish they spent a bit more time looking at the logs instead of blowing it off.

The only thing that works is the mdns-repeater app (https://openwrt.org/packages/pkgdata/mdns-repeater), it's 4 years old and not updated anymore, but it works by simply adding the below to the mdns_repeater configuration file.

With that, everything else works like before, but now the WiiM app also works. I don't have the time/skills to check how various packets are impacted by Avahi vs the mdns-repeater, so why Avahi doesn't work in my specific case but seems to work for others is going to stay a mystery. Also, Avahi seems to work for a variable amount of time if I restart the service, but that's not a long term option (it caused a lot of false hopes, though . Every time I changed a setting, it worked for a while.

If anyone else sees this in the future with a discovery problem even with the Avahi redirector installed, try mdns-repeater instead. It's more lightweight than Avahi, as an added bonus for router with fewer resources than mine

Thanks to the various folks (esp @simbun) for all the suggestions.

config mdns_repeater 'main'
    list interface 'br-lan.1'
    list interface 'br-lan.101'
    list interface 'br-lan.102'

I don't have a network that is at this level of complexity, but as we all seem to have to troubleshoot wifi connection issues at some point, I am curious about a couple things regarding your issue and solution - why does enabling/disabling IPV6 make a frequent difference to connectivity with the Wiim streamers? And for @robca , what exactly did Wiim suggest to you about Upnp being the problem (even though it did not appear to apply in your case)? i.e. Why/what aspect of Upnp would likely cause a connection problem. Thanks for any thots!

 

[robca]

IPv6 or not made no difference, it was just another random dead end due to the weird interaction between Avahi and the WiiM app. Nothing else was impacted anyway.

WiiM told me to either put my phone on the IoT segment or move the WiiM Pro into the main lan. Put it another way, they did not diagnose, tried to understand or suggested anything useful. From the log they saw that the SSID name of the phone and WiiM were different, and made up some technobabble about "using UPnP", which is not the case unless you consider something like http://192.168.10.170:49152/upnp/control/rendertransport1 to be UPnP.... but that is just a control point, and requires no special consideration at the router/switch level: just the IP being reachable with a TCP packet. WiiM does not use the problematic part of UPnP, discovery and ability to punch thru firewalls (and the only parts that require specific router configuration)

The official answer is that they require the devices to be on the same wifi SSID, which is technically inaccurate not to mention a real issue for anyone with a big enough house and in need of more than one access point. I can understand trying to minimize their support costs, but frankly I was disappointed not as much by their unwillingness to help, but by the misleading answer just to blow me off and pretending to have looked at my logs.

As a side note, my network is not complex in any way. It's a simple wifi network with a vlan with a few traffic rules to improve security. It's something that can be done with almost any consumer router (and should be done by anyone who knows enough about IoT to know that those devices should never be on the main network). The only "difficult" part is to enable the mDNS reflector, which these days is more and more common, too, to the point that Avahi is enabled by default in most routers (with reflector disabled by default, but easy to enable)