Reolink updates Learn More
Meet Reolink at IFA 2024! Learn More
Reolink Q&A Learn More
Your browser does not seem to support JavaScript. As a result, your viewing experience will be diminished, and you have been placed in read-only mode.
Please download a browser that supports JavaScript, or enable it if it's disabled (i.e. NoScript).
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
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.jpeglogging-E1s-console-and-papertrail.jpeg
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.139Pinging 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.139Tracing 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.
Also, here is the tracert:
C:Usersfrank>tracert 192.168.10.80Tracing 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.
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
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.
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.
Welcome Back!
Hi there! Join the Commnunity to get all the latest news, tips and more!