Switching from "On Net" DVR to Remote DVR (and back)

Channels DVR Server
#4

The WiFi is in the same subnet and the range extender is the in the regular network as well.

I noted the range extender as there are updates from FreeNAS about changes to ARP addresses served by the Range Extender

freenas.kneifel.local kernel log messages:

arp: 192.168.202.66 moved from 02:XX:XX:XX:d2:7d to 8e:XX:XX:XX:d2:7d on em0

– End of security output –

The two addresses are both associated with the Range Extender

However, I tried the test again after I had disabled the Range Extender and had the same issue - connect via LTE from outside with no issue, connect back to the house WiFi and have to restart Bonjour.

Charley

#5

Try downloading the “Bonjour Browser” app and see if it reliably shows the DVR under _channels_dvr

Also try updating to the latest DVR pre-release which improves Bonjour support on FreeBSD to automatically detect IP changes. You can update by holding down the SHIFT key on the keyboard and clicking the “Check for Updates” button.

#6

I have updated to the latest DVR pre-release - 2018-05-17.0342 update

I ran Bonjour Browser and it did not show channels dvr in any of the fields.

After I disable, waited for a few seconds, then re-enabled Bonjour on the DVR, I now see an entry for:

_channels_dvr._tcp. channels

#7

That should be:

_channels_dvr._tcp.     channels

which when I click it shows:

arch     x86_64
os        freebsd
version  2018.05.17.0342
#8

Strange. Those bonjour entries should show up automatically without having to turn it off and back on.

Do you have other macs or Apple TVs on the network? Do they reliably show up on the browser?

Is the FreeNAS box on Wi-Fi or wired in?

#9

The FreeNAS box is wired (it’s running in a VM)

There are 3 Apple TVs running on the network (2 wired - 4K, 1 wireless - Original)

There is a Mac Mini, 2 iPhones, and 3 iPADs on the network.

There is also an older Netgear ReadyNAS which provides AFP

And also an early AirPort for Airplay to the downstairs audio system.

#10

It’s disappeared from Bonjour Browser (v1.13) and also from my iPhone app again.

Showed up again after I stopped and started Bonjour on the DVR.

Charley

#11

What hypervisor? Is the network bridged?

#12

It’s all running under VMWare - vSphere 5.5 and I am not sure what you mean by bridged - the FreeNAS VM is part of the regular network (it’s IP is 192.168.202.83) and the DVR is running inside and is part of the same network (192.168.202.220 is the DVR address with the same default gateway and broadcast domain as the rest of the subnet - 192.168.202.1/192.168.202.255)

Charley

#13

Here is the network information from the FreeNAS screen -

#14

I took a look at the VM configuration and updated to VMWare Hardware version v10 after I shutdown the FreeNAS VM. After booting up the server

_channels_dvr._tcp.    channels

is appearing in Bonjour Browser without having to restart Bonjour on the DVR.

It’s running the e1000 drivers and not the VMXNet3 VMWare network drivers.

Charley

#15

Unfortunately it looks like the Bonjour discovery servoce stopped running and I had to restart it via the browser control.

Is there something I can look for on the FreeNAS box?

the mdnsresponder.log file has the following:

May 20 16:08:02 freenas mDNSResponder: mDNSResponder (Engineering Build) (Mar 14 2018 03:28:04) starting
May 20 16:08:02 freenas mDNSResponder: mDNS_AddDNSServer: Lock not held! mDNS_busy (0) mDNS_reentrancy (0)
May 20 16:08:02 freenas mDNSResponder: mDNS_AddDNSServer: Lock not held! mDNS_busy (0) mDNS_reentrancy (0)
May 20 16:08:02 freenas mDNSResponder: mDNS_AddDNSServer: Lock not held! mDNS_busy (0) mDNS_reentrancy (0)
May 20 16:08:02 freenas mDNSResponder: CheckNATMappings: Failed to allocate port 5350 UDP multicast socket for PCP & NAT-PMP announcements
May 20 16:08:02 freenas mDNSResponder: mDNS_Execute: mDNSPlatformRawTime went backwards by 442 ticks; setting correction factor to 1044764297
May 20 16:10:15 freenas mDNSResponder: Client application PID[-1]() has received results for DNSServiceResolve(Family\032Room._mediaremotetv._tcp.local.) yet remains active over two minutes.
May 20 16:10:26 freenas mDNSResponder: Client application PID[-1]() has received results for DNSServiceResolve(Family\032Room._mediaremotetv._tcp.local.) yet remains active over two minutes.
May 20 16:10:26 freenas mDNSResponder: Client application PID[-1]() has received results for DNSServiceResolve(Family\032Room._mediaremotetv._tcp.local.) yet remains active over two minutes.

Noting in the logs inside of the iocage for the DVR.

Charley

#16

Channels has its own Bonjour server built in and does not use mdnsresponder.

I’m still not quite sure what’s going on, but if a client is sending out Bonjour discovery packets and the Channels DVR is not receiving them or not able to respond that suggests the network is dropping packets.

Can you check the Log tab at the top right of the DVR web UI and see if any errors show up?

#17

Nothing too unusual - other than the IPv6 notice - I do not have an IPv6 address configured.

2018/05/20 17:21:22 [SYS] Bonjour service stopped.
2018/05/20 17:21:31 [zeroconf] no suitable IPv6 interface: listen udp6 [ff02::]:5353: socket: protocol not supported
2018/05/20 17:21:31 [SYS] Bonjour service running for dvr-channels.local. [192.168.202.220]
2018/05/20 17:51:33 [SYS] Bonjour service stopped.
2018/05/20 17:51:39 [zeroconf] no suitable IPv6 interface: listen udp6 [ff02::]:5353: socket: protocol not supported
2018/05/20 17:51:39 [SYS] Bonjour service running for dvr-channels.local. [192.168.202.220]
2018/05/20 18:20:33 [SYS] Shutting down...
2018/05/20 18:20:33 [SYS] Bonjour service stopped.
2018/05/20 18:20:33 [DVR] Recording engine stopped.
2018/05/20 18:20:35 [SYS] Goodbye.
2018/05/20 18:22:51 [SYS] Starting Channels DVR v2018.05.17.0342 (freebsd-x86_64) in /usr/local/channels-dvr/data
2018/05/20 18:22:53 [HDR] Found 1 devices
2018/05/20 18:22:59 [SYS] Started HTTP Server
2018/05/20 18:23:08 [DVR] Recording engine started in /dvr
2018/05/20 18:23:08 [zeroconf] no suitable IPv6 interface: listen udp6 [ff02::]:5353: socket: protocol not supported
2018/05/20 18:23:08 [SYS] Bonjour service running for dvr-channels.local. [192.168.202.220]
2018/05/20 18:23:08 [DVR] Waiting 1h36m51.765017716s until next job 1526860800-25 Little Women on Masterpiece
2018/05/20 18:23:08 [SYS] Created database snapshot: backup-20180520.182308
2018/05/20 18:23:08 [SYS] Removing old backup backup-20180423.223558
2018/05/20 18:23:18 [IDX] Pruned 135 expired airings from USA-OTA27513 in 743.987512ms.
2018/05/20 18:23:53 [SYS] Bonjour service stopped.
2018/05/20 18:24:00 [zeroconf] no suitable IPv6 interface: listen udp6 [ff02::]:5353: socket: protocol not supported
2018/05/20 18:24:00 [SYS] Bonjour service running for dvr-channels.local. [192.168.202.220]
#18

Definitely a head scratcher.

You could spin up a Linux vm to run a test instance if the DVR and see if Bonjour is more reliable there.

#19

I will try that - is there any chance this could be due to how I setup the DVR inside of FreeNAS?

#20

I did as you suggested and spun up a Linux VM. After transferring everything over and running the restore process it’s now running on an Ubuntu 16.04 LTS VM.

In the last day or so I have not had issues with Bonjour - it’s still running as shown by Bonjour browser.

I was able to switch between on-net and off-net (remote DVR) without a problem.

That seems to indicate that the problem was with my DVR inside an iocage under FreeNAS (or a BSD issue since I am running it under Ubuntu with no issues).

Thank you for the help -

Charley

#21

Good to know. It could be a FreeBSD issue or an iocage issue. Would need to run more tests to narrow it down.

Glad you got your setup working reliably.

#22

The DVR has been great - no issues with reliability of the recordings or the DVR. Just the discovery services that’s been a little flaky.

It’s really a very nice product.

Charley

#23

I had to go one step further. Being an old-school IT guy, I’ve got my Ubiquiti ERLite set up for “that which is not explicitly allowed is denied.” Thus all ingress and egress must be explicitly allowed-for in my border router’s rules.

So I not only had to port-forward 8089, but include that in the list of allowed incoming TCP ports.

Later, when ambition strikes, I’ll see what happens when the primary Internet interface fails and the backup LTE interface takes over :slight_smile: