@robca is struggling with mDNS discovery across VLANs so would like to be able to specify an IP address in the WiiM Home App instead.
We cannot define a static IP address for the device in Wiim apps to avoid a re-discovery?
- Thread starter kenilElk
- Start date
We're all using mDNS reflectors/repeaters, which work well, but for some reason @robca is having discovery issues with the WiiM Home App even though other apps are able to discover the hardware.
I sure don't need UPnP nor want it
It's the Android WiiM Home app that wants it, at least according to WiiM support and 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. As I said, that's purely the WiiM app, not the WiiM. All other services on the WiiM use mDNS and work just fine. If you use a Bonjuor browser, you see the WiiM and all its services. Alexa Cast can send music to the WiiM, while the WiiM Home app on the same phone is not workingThe 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.
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.
Last edited:
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
Last edited:
Yes, of course: you can define a static DHCP lease for the WiiM. But how the WiiM gets a static address is irrelevant, that's not the issue. The WiiM app doesn't allow you to enter a static address to find the device at. It lets you set the device as a static address (so clearly they support the scenario where a device has a fixed address), but doesn't use it to look for the device. However you do it, my WiiM has a fixed address: the app, though, starts discovery every time instead of using the static address. Sometimes that doesn't work.
To be clear: they have good reasons, I'm not saying that they are clueless or bad: if there are multiple WiiM devices on the same network, with discovery you would be able to find all of them and manage them. Trying to have an UI that allows the manually enter multiple static addresses can get ugly when there are more than one or two devices. But if the app cached all the previously found devices and tried contacting them at the previous address, then it would work in all cases: for a single device, it's always at the same address, ready to work.
It's still working for me and @Nikita too by the looks of it with only a mDNS repeater.I sure don't need UPnP nor want it
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.
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
Attachments
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?
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.
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.
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?
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.
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.
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.
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
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.
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.
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.
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
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
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?
Similar threads
- Suggestion
- Suggestion