E1 Pro unaccessible from another local subnet after firmware update

danny rodriguez

This problem is still occuring. I e-mailed Reolink support, but they are asking extremely basic questions like "are you sure the IP is correct", despite a fairly detailed ticket

This really needs to be fixed.

xcsdf

Maybe you'd get better results if you hadn't tried to hijack a thread from 2 years ago.

danny rodriguez

"Tried to hijack"? I bumped it because it has history of the same exact problem.

But thanks for the entirely vacuous response.

xcsdf

Your welcome. I hope you keep getting responses with as much thought as yours. If you want the problem fixed product reviews may have a lot more impact than forum threads

zyphermonkey

Back when I had this issue I also opened a ticket and reolink sent me a new firmware that fixed the issue.
Give me a few and I'll see if I can't track it down.

Frank

Same here. I have six E1 cameras (non-pro) and they can't traverse VLANs/subnets and hence can't be put on a restricted subnet to be accessed from my trusted devices on a different subnet.

Really looking forward to a firmware upgrade as this is unusable in my scenario and quite peculiar and unexpected for an IoT manufacturer to push out such a "feature".

All other IoT devices are easily accessible on the same subnet as the E1s, but even setting an explicit allow firewall rule on my unify dream machine for accessing the E1s fails in delivering successful connections from other subnets or even pings to the E1s. It works when on the same subnet, of course, and from the internet/cloud side on Android app. But not from another subnet.

Strange, unexpected and undesired behavior, in my case.

Which had me factory reset my router several times, as I thought it was a router or firewall issue, initially. Only to discover it is an issue with the Reolink cameras I bought.

Crimp On

Could you give examples of other IoT devices that are easily accessible from different IP subnets?
I was not aware that the Ubiquiti Dream Machine could create different subnets. That is quite a step up from the normal residential router.

Frank

Sure. Examples are Chromecast and Chromecast audio devices, which are on the same VLAN (192.168.10.0/24) as the Reolink E1 cameras. When I try to connect from the main LAN (192.168.1.0/24), there is no issue with the Chromecasts or other devices on the IoT VLAN. Multicast has not been enabled, by the way. Another examples would be Android TV boxes, which also reside in the IoT LAN. Again, the firewall rules are factory reset.

Crimp On

(Please forgive my ignorance. I got buried in the Unify user manual and made little progress.)
The Apple/Android phone being used to 'cast' to the Chromecast is on one WiFi SSID in a 192.168.1.0/24 subnet and the Chromecast is on a different WiFi SSID in a 192.168.10.0/24 subnet.

Can some OTHER device in the 192.168.1.0/24 subnet ping the Chromecast by the Chromecast IP?
i.e. a PC in 192.168.1.0/24 can ping the Chromecast on its 192.168.10.0/24 subnet IP address?

Frank

That is exactly right. I have attached a screenshot of my PC (192.168.1.18) pinging the Chromecast (192.168.10.80) with connectivity and success.
inter-vlan-ping.jpeg

Frank

Also, here is the tracert:

C:Usersfrank>tracert 192.168.10.80

Tracing route to Chromecast.iot [192.168.10.80]
over a maximum of 30 hops:

  1     1 ms     2 ms     1 ms  unifi.localdomain [192.168.1.1]
  2     2 ms     1 ms     1 ms  Chromecast.iot [192.168.10.80]

Trace complete.

tracert-LAN-to-VLAN.jpeg

Crimp On

Dang. I wish I had a way to create multiple subnets. My WiFi router creates only one /24 subnet for all devices (wired, primary WiFi, Guest WiFi). Would love to capture packets on that 192.168.10.0/24 subnet and see if the E1 responds to those pings at all, or if it responds and they do not make it back to 192.168.1.0/24.

Since the E1 does not have a web interface, the goal is to monitor the E1 using the Windows or Mac client software?

I am pretty certain that RLC cameras accept connections from anywhere, so it seems strange that the E1's would be "different".

Frank

Well, it's no Wireshark log, but the E1 cameras do not respond to ping or tracert from the main LAN (192.168.1.0/24):

C:Usersfrank>ping 192.168.10.139

Pinging 192.168.10.139 with 32 bytes of data:
Request timed out.
Request timed out.
Request timed out.
Request timed out.

Ping statistics for 192.168.10.139:
    Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),

C:Usersfrank>tracert 192.168.10.139

Tracing route to 192.168.10.139 over a maximum of 30 hops

  1     1 ms    <1 ms     2 ms  192.168.1.1
  2     *        *        *     Request timed out.
  3     *        *        *     Request timed out.
  4     *        *        *     Request timed out.

Other devices on the IoT VLAN reponds as expected.

Thickening of the plot:
Another problem I experience and may play into this as a separate or combined issue, is basic router/DHCP connectivity at times. Sometimes, the E1 cameras have persistent ARP and DNS timeouts, which I can solve be powercycling them (unplug, wait 10 seconds and replug the power cable). I have given the E1s fixed IPs, in order to reduce/eliminate DHCP issues, due to this, which seems to have alleviated some of the problem - some of the time. Unfortunately, not entirely, and this might be another candidate as contributing culprit in the cause of no connectivity across subnets, as only the E1 cameras keep getting DHCPOFFER every 6 minutes, with a a DHCPDISCOVER thrown in every now and then, too (see screen shot).

When the E1s show this behavior, I cannot externally connect to them either. At this stage, it is both across subnets and from the internet side, as well, that the connectivity is nonexistent. But joining the same subnet still gives access to the cameras (Android app), even under these circumstances. No other ARP/DNS timeouts reported for other devices on the IoT VLAN, although some TCP latency every now and then. So, I can't really see it should be a router issue from the Unifi Dream Machine Pro. Something fishy is going on, indeed, but it is across E1s, so I can't see how it should be a malfunctioning camera I have, as the batch of E1s show the same (unwanted) and identical behavior.
DHCP-Reolink-E1.jpeg

Crimp On

Will Papertrail collect ICMP packets? That would be an ideal substitute for Wireshark.
The "fixed IP's" are done (a) by setting a Static IP on the camera, or (b) by entering the camera MACaddress into a router table so that it always assigned the same IP?

Frank

I made a firewall rule to log any and all traffic (including ICMP) to the E1 cameras (see screen shot), which is then logged to Papertrail. Then I started pinging the E1s. Nothing in the logs. So even though they seems online in the router, they might be "off" the network, in some way that is beyond me. See screen shot.

The IPs for the E1s are done on the router side by MAC addresses. The E1s do not have a onption for setting a fixed IP, at least to my knowledge and experience with them.
IoT-devices-router-status.jpeg
logging-E1s-console-and-papertrail.jpeg

Crimp On

If an ICMP packet does not arrive at an E1 camera, the camera cannot respond.
How can ICMP packets get to a Chromecast when they cannot get to an E1 camera?

Frank

I am unsure of that, too. Anyway, I decided to bite the bullet and crawled into the low-height attic to connect an E1 by wire, to eliminate potential issues. I can cross VLANs when the camera has hardwired IP (by RJ45). So, it seems the connectivity issue is with E1s and wifi. When the same E1 is connected to the same IoT VLAN by cable, it acts as any other IoT device I have (although, they are all connected by wifi). That rules out the Unifi Dream Machine Pro, at least. And leaves the AC Lite and the E1s as the potential troublemakers, it seems.
attic-crawl-back-pain-legs-burning.jpg

zyphermonkey

Here's the current version I'm using provided via Reolink that allows the camera to work on a separate vlan.

https://www.
dropbox.
com/s/8oz4oha9lp1lnjr/E1_Pro_42_20062904.zip?dl=0