Original Message:
Sent: May 19, 2025 05:11 AM
From: Herman Robers
Subject: Ring doorbell live view not working
What I would do in this case is create a copy of that net-destination rule, and enable log on the policy to see what exact traffic hits the rule. From there determine why that traffic (which is expected to be not matching) is matching. Working with your HPE Aruba Networking partner, or with TAC, and have a 'live' look may be more effective. It's hard to see the exact issue and solution in a forum, despite you shared a lot of information already.
------------------------------
Herman Robers
------------------------
If you have urgent issues, always contact your HPE Aruba Networking partner, distributor, or Aruba TAC Support. Check https://www.arubanetworks.com/support-services/contact-support/ for how to contact HPE Aruba Networking TAC. Any opinions expressed here are solely my own and not necessarily that of Hewlett Packard Enterprise or HPE Aruba Networking.
In case your problem is solved, please invest the time to post a follow-up with the information on how you solved it. Others can benefit from that.
Original Message:
Sent: May 16, 2025 05:31 AM
From: cauliflower
Subject: Ring doorbell live view not working
Hello Herman,
We did some testing yesterday where I went through and removed each ACL rule one by one until the Live View started working. The offending rule seems to be one that includes pretty much all the University's IP ranges (but obviously doesn't specifically include 34.251.201.66
), once I removed it Live View began working. It's the 'user -> alias cam_netdst deny' rule, number 5 in the "uws-iot-open-acl" ACL. I can DM you the ranges included in that if you like. It seems odd that that would have any impact on traffic not destined for any of those address ranges so I wonder what is going on here.
What does it mean when it says 'local' for the traffic type? And what is the significance of Openflow?
Thank you,
Guy
Original Message:
Sent: May 14, 2025 10:46 AM
From: Herman Robers
Subject: Ring doorbell live view not working
10.247.12.16 is your Ring doorbell?
What triggers me is the 'O' OpenFlow and local vs tunnel fr the denied traffic. What's the role that the ring has in the network? What is the policy for that role (show rights name-of-the-role)?
------------------------------
Herman Robers
------------------------
If you have urgent issues, always contact your HPE Aruba Networking partner, distributor, or Aruba TAC Support. Check https://www.arubanetworks.com/support-services/contact-support/ for how to contact HPE Aruba Networking TAC. Any opinions expressed here are solely my own and not necessarily that of Hewlett Packard Enterprise or HPE Aruba Networking.
In case your problem is solved, please invest the time to post a follow-up with the information on how you solved it. Others can benefit from that.
Original Message:
Sent: May 14, 2025 10:06 AM
From: cauliflower
Subject: Ring doorbell live view not working
Hello,
Arubaos 8.10.0.16
ClearPass 6.12.4
We have an IoT SSID, devices are registered in ClearPass and authenticate via mPSK. Airgroup is enabled on the devices though I don't think that should be relevant here.
We have a report of one particular Ring doorbell that is working as it should right up to the point where Live View is needed (ie when someone presses the doorbell and the video feed is supposed to show up on the reception screen). Apparently they cannot view the feed even if they go directy to the Ring website on another device.
I'm struggling to see where the issue lies. The first frame of the video does make it through but that's it, no stream.
I did a show datapath session on the doorbell IP while a colleague pressed it, at which point I believe it should start streaming. This was one of the outputs of that command at that time, though I have several like this:
Datapath Session Table Entries
------------------------------
Flags: F - fast age, S - src NAT, N - dest NAT
D - deny, R - redirect, Y - no syn
H - high prio, P - set prio, T - set ToS
C - client, M - mirror, V - VOIP
Q - Real-Time Quality analysis
u - Upstream Real-Time Quality analysis
I - Deep inspect, U - Locally destined
E - Media Deep Inspect, G - media signal
r - Route Nexthop, h - High Value
A - Application Firewall Inspect
i - Session classified on first packet
J - SDWAN Default Probe stats used as fallback
B - Permanent, O - Openflow
L - Log, o - Openflow config revision mismatched
Source IP or MAC Destination IP Prot SPort DPort Cntr Prio ToS Age Destination TAge Packets Bytes Flags CPU ID
----------------- --------------- ---- ----- ----- -------- ---- --- --- ----------- ---- ---------- ---------- --------------- -------
10.247.12.16 8.8.8.8 17 2410 53 0/0 0 24 1 tunnel 4945 12 2 138 FTCI 15
131.111.8.42 10.247.12.16 17 53 2410 0/0 0 24 1 tunnel 4945 12 1 532 FI 10
10.247.12.16 34.251.201.66 6 36024 8557 0/0 0 24 0 tunnel 4945 1 16 3026 TC 15
34.251.201.66 10.247.12.16 17 41284 37639 0/0 5 40 0 local 1 4 456 FDHPTCVBO 14
10.247.12.16 3.220.149.173 6 33398 9999 0/0 0 24 0 tunnel 4945 1199 561 96689 TC 15
10.247.12.16 34.249.138.48 1 291 2048 0/0 0 24 1 tunnel 4945 b 1 32 FTCI 15
34.249.138.48 10.247.12.16 1 291 0 0/0 0 24 1 tunnel 4945 b 1 32 FI 11
1.1.1.1 10.247.12.16 17 53 2410 0/0 0 24 1 tunnel 4945 13 1 363 FI 11
10.247.12.16 131.111.8.42 17 2410 53 0/0 0 24 1 tunnel 4945 13 2 138 FTCI 15
34.251.201.66 10.247.12.16 6 8557 36024 0/0 0 24 0 tunnel 4945 2 19 13206 15
131.111.12.20 10.247.12.16 17 53 2410 0/0 0 24 1 tunnel 4945 13 1 532 FI 10
8.8.8.8 10.247.12.16 17 53 2410 0/0 0 24 1 tunnel 4945 13 1 363 FI 11
10.247.12.16 34.251.201.66 17 37639 41284 0/0 5 40 0 local 2 321 329263 FDHPTCVBO 15
10.247.12.16 3.209.230.181 6 46738 443 0/0 0 24 1 tunnel 4945 13 68 68597 FTC 15
3.220.149.173 10.247.12.16 6 9999 33398 0/0 0 24 0 tunnel 4945 1199 548 53807 16
10.247.12.16 1.1.1.1 17 2410 53 0/0 0 24 1 tunnel 4945 13 2 138 FTCI 15
10.247.12.16 131.111.12.20 17 2410 53 0/0 0 24 1 tunnel 4945 14 2 138 FTCI 15
3.209.230.181 10.247.12.16 6 443 46738 0/0 0 24 1 tunnel 4945 14 42 12674 F 14
As you can see there are a couple of 'D's in there - cuold this be traffic being dropped? Is there any way to see why that might be happening?
As far as I am aware from the report everything else works as it should - the device is registered on the app and shows as online, when the doorbell is rung the chimes chime(!) but the video doesn't appear. I have never used a Ring device so I'm a little in the dark. From what I have garnered so far it seems that essentially all it needs to do is talk to ring.com.
Guy