Netgate 2100 blocking? Spotify issue

[MikeHalsey]

Hi, I have a Netgate 2100 appliance as my gateway to my Starlink internet connection. That then feeds into a TP-Link router and managed mesh system.

Everything works just brilliantly, all of the time. I never have any problems with downloads, browsing, IoT devices, everything's fine all of the time.

Except for Spotify, and I get the same problem almost every single day. When I go to play Spotify around my house or garden on one of my smart speakers, suddenly the Spotify app (on both smartphones and PCs) can't see any of the speakers.

I have discovered that if I reboot the Netgate then all of a sudden all the smart speakers can be seen again and Spotify will play to them happily for the rest of the day.

Then the following day I have exactly the same problem recur. As I say this only ever affects Spotify, and I know that there's a known "undocumented feature" with Spotify commonly not seeing some devices unless you put it into offline mode, and back to normal mode. While this used to fix the problem for me, it's stopped doing so no.

Is anybody here using pfSense with Spotify and seeing the same or a similar problem? If so, have you found a way around it?

Thanks all

[stephenw10]

Are the phones and speaker using the same access points? Same subnet?

What sort of speakers? Can other applications play to them?

[MikeHalsey]

@stephenw10 They're mostly Amazon speakers or Alexa-powered Bose speakers connected to a guest Wi-Fi network. A couple of them are Alexa-powered Bose soundbars connected via ethernet on a subnet to my main network. Those can be "seen" but still Spotify can't play to them.

The phone I use is on the main Wi-Fi network, and my PCs are connected via the main Wi-Fi network and my desktop is connected by ethernet.

Like I say, the moment I restart the Netgate everything returns to normal and everything can see and play to everything else, until the following day when it breaks again. It's weird!

All other Alexa features work perfectly, all of the time.

[stephenw10]

Hmm, not much pfSense would be doing with that traffic. It could be resolving host names if they are accessing them that way. You might try just restarting Unbound in the 2100 instead of rebooting it.

[MikeHalsey]

@stephenw10 What's Unbound and how do I restart it manually? If that turns out to work, is there a cron command I can set to restart it each day?

Many thanks

[stephenw10]

Unbound is the default DNS resolver service in pfSense. You can restart it from Status > Services.

If clients are trying to resolve the speakers as hosts that could be a problem. Though I doubt it's that to be honest.

[MikeHalsey]

@stephenw10 I'll give that a try, thanks. If it works do you know a cron command I can use to automate the process please?

[stephenw10]

There are many ways you could do that but you shouldn't need to. If restarting Unbound does correct it we should dig into why that happens.

[MikeHalsey]

@stephenw10 Hi, I just restarted the service and all the devices reappeared looks like I might need to automate this

[MikeHalsey]

@stephenw10 Just in case you're going to ask for them, here are screenshots of the DNS Resolver settings. Many thanks for all your help with this.

login-to-view

login-to-view

login-to-view

[stephenw10]

Ok, good result. Then it appears to be some DNS issue. Check the DNS logs when it's failing. Try to resolve the hosts (speakers) from one of the clients when it's failing.

[stephenw10]

Ah, looks like you have pfBlocker in the mix too. You might try running an update on it when Spotify is failing and see if that also allows it to start.

[MikeHalsey]

@stephenw10 As an interim anyway, do you know how I can configure a cron job to restart Unbound each day please?

[stephenw10]

You can use: /usr/local/sbin/pfSsh.php playback svc restart unbound

You have to use the full path like that in a cronjob.

[Gertjan]

@MikeHalsey said in Netgate 2100 blocking? Spotify issue:

do you know how I can configure a cron job to restart Unbound each day please?

Depending on how you've set up pfBlockerng, it already restarts regularly.

Restarting unbound, is a subject that is very known.
But the question is always the other way around : nobody wants that unbound restarts as you'll be loosing the cache - thus the overall DNS speed, and during the DNS restart, a you are using pfBlockerng with the 'unbound' mode instead of the python mode, is also slow(er) to restart. And during the restart : DNS errors, as it is not answering, all over the place.

You've shown your unbound (resolver) settings and you took some settings from 'default', may I draw your attention to the fact that de default settings are chosen by Netgate for a reason : they are the best.

Really, what you want, is something like this. Although the image shows the resolve's memory or cache usage, it also shows the restarts.
A perfect scenario, unbound shouldn't restart at all. It runs all the time. It's meant to run all the time.

And what if, for example, pfBlocker does it's thing like updating dnsbl and afterwards it restart unbound and at the same moment, your cron also restart unbound...
You've got yourself a nice race condition ... and a complete unknown issue, purely self inflected.

Also :

Do this :

login-to-view

and click on execute.
What did you saw ?

( you really want to restart the resolver even more then that ?? )

[MikeHalsey]

@stephenw10 I've set that up to restart at 5am each day and will report back if I still get the issue. Many thanks again

[MikeHalsey]

@Gertjan login-to-view

[stephenw10]

Mmm, so it restarts multiple times already. You need to see what actually fixes the blocking issue when you run that. Or rather what's failing before you run it. Check the Unbound logs at that point. You may need to turn up the logging.

[MikeHalsey]

@stephenw10 So, you're saying wait until I can't see the devices and run this command again, then restart Unbound and run the command a second time to compare?

[jrey]

@MikeHalsey

that's a lot of unbound starts/restarts your are showing there -- why?

just a thought..

are you buy chance running service_watchdog to restart unbound if it stops -- don't (i've never had a need for service watchdog, not even installed)

pfblockerNG? - are you updating something in DNSBL that is updating hourly ? Several of those look like hourly, followed by chaos -- check the pfblockerng.log it will tell you in there when it has restarted unbound.

if the list of DNSBL is processing hourly, and something changes it will restart unbound.
service_watchdog will in that brief time see it is down and try to restart it.
that pid likely won't last long because it is already running, but it is detected as down again. etc etc in that condition it doesn't take very long for things to go south and stop.

unbound can and should run for days without issue. Mine hasn't had to restart since Sept 1. even though the DNSBL checks for updates regularly, none of those lists have changed, so nothing (unbound) needs restarting.

on the pfblocker dashboard if you are running it. you will see (whatever list / lists) you are running and when they were updated last example
login-to-view

and that is the last time unbound "started" here

login-to-view

and it won't restart again - until the next time DNSBL (list or list(s)) update.

pfblockerng.log will have entries like this

Saving DNSBL statistics... completed
Reloading Unbound Resolver (DNSBL python)
Stopping Unbound Resolver.
Unbound stopped in 2 sec.
Additional mounts (DNSBL python):
  No changes required.
Starting Unbound Resolver... completed [with a timestamp when it restarted]

It really goes down and up in "2 seconds" on my 2100 - and you should really never know it happened.