Thanks for taking the time to trace the network logs Keith! In case it helps or anyone wonders, below are the firewall logs from my router showing a typical/working connection to my Wyze Cam v2 from a public WiFi hotspot:
Aug 13 12:39:54 ACCEPT IN=br0 OUT=eth0 <1>SRC=192.168.1.143 DST=35.163.180.168 <1>LEN=60 TOS=0x00 PREC=0x00 TTL=63 ID=43723 DF PROTO=TCP <1>SPT=57456 DPT=8443 SEQ=4130897516 ACK=0 WINDOW=14600 RES=0x00 SYN URGP=0 OPT (020405B40402080A00F8D4A70000000001030304)
Aug 13 12:40:30 ACCEPT IN=br0 OUT=eth0 <1>SRC=192.168.1.143 DST=50.19.254.134 <1>LEN=60 TOS=0x00 PREC=0x00 TTL=63 ID=16764 DF PROTO=TCP <1>SPT=58405 DPT=443 SEQ=4030047175 ACK=0 WINDOW=14600 RES=0x00 SYN URGP=0 OPT (020405B40402080A00F8E2BB0000000001030304)
Aug 13 12:40:30 ACCEPT IN=br0 OUT=eth0 <1>SRC=192.168.1.143 DST=my.pub.lic.ip <1>LEN=68 TOS=0x00 PREC=0x00 TTL=63 ID=0 DF PROTO=UDP <1>SPT=59568 DPT=36602 LEN=48
Aug 13 12:40:30 ACCEPT IN=br0 OUT=eth0 <1>SRC=192.168.1.143 DST=my.wi.fi.ip <1>LEN=68 TOS=0x00 PREC=0x00 TTL=63 ID=0 DF PROTO=UDP <1>SPT=59568 DPT=46194 LEN=48
Aug 13 12:40:30 ACCEPT IN=br0 OUT=eth0 <1>SRC=192.168.1.143 DST=my.wi.fi.ip <1>LEN=68 TOS=0x00 PREC=0x00 TTL=63 ID=0 DF PROTO=UDP <1>SPT=59568 DPT=46194 LEN=48
Aug 13 12:40:30 ACCEPT IN=br0 OUT=eth0 <1>SRC=192.168.1.143 DST=my.wi.fi.ip <1>LEN=72 TOS=0x00 PREC=0x00 TTL=63 ID=0 DF PROTO=UDP <1>SPT=59568 DPT=46194 LEN=52
Aug 13 12:40:31 ACCEPT IN=br0 OUT=eth0 <1>SRC=192.168.1.143 DST=my.wi.fi.ip <1>LEN=68 TOS=0x00 PREC=0x00 TTL=63 ID=0 DF PROTO=UDP <1>SPT=59568 DPT=46194 LEN=48
Aug 13 12:40:31 ACCEPT IN=br0 OUT=eth0 <1>SRC=192.168.1.143 DST=my.wi.fi.ip <1>LEN=68 TOS=0x00 PREC=0x00 TTL=63 ID=0 DF PROTO=UDP <1>SPT=59568 DPT=46194 LEN=48
Aug 13 12:40:31 ACCEPT IN=br0 OUT=eth0 <1>SRC=192.168.1.143 DST=my.wi.fi.ip <1>LEN=72 TOS=0x00 PREC=0x00 TTL=63 ID=0 DF PROTO=UDP <1>SPT=59568 DPT=46194 LEN=52
Note, “192.168.1.143” is the private IP of my Wyze Cam v2, and I replaced the public IP of the WiFi hotspot with “my.pub.lic.ip” and my WiFi IP address with “my.wi.fi.ip” because reasons.
What I was actually doing in the Wyze app to generate this traffic:
- Open the Wyze app on my phone (while connected to a public WiFi hotspot).
- Tap on my camera.
- Wait through the 3 steps of authentication/connection, now I can see the live stream from my Wyze Cam.
You can see from the logs that the first connection is from my camera to an Amazon server on port 8443 (according to Wyze, TCP 8443 = Cloud API).
Next, it contacts a different Amazon server on port 443 (TCP 443 = Cloud data transfer).
Third, it establishes a UDP stream directed to the WiFi hostpot’s public IP on port 33602 (UDP = Heartbeat and streaming).
Fourth, it attempts to start a UDP stream 6 times to my private IP on the WiFi hotspot (which as Keith noted will never work because that’s a NAT’d non-routable IP).
So the first 3 steps seem to line up with my actions within the app:
- Open Wyze app = perform auth/lookup via Amazon Cloud API
- Tap camera = download thumbnail/settings(?) via Amazon Cloud data transfer
- View live stream = UDP stream to public IP (routable)
But it does seem odd that it also tries to stream directly to my private IP as if I were on the same LAN as the camera. I wonder if matching private subnets on different LANs might confuse the camera into thinking it's on the same LAN as the phone. For example, most consumer routers use the 192.168.1.0/24 or 192.168.1.0/24 subnets, so if my camera is at 192.168.1.143 on my home network and I'm on my buddy's WiFi with an IP of 192.1.68.1.160, the camera might think I'm on the same subnet even though I'm on a completely different LAN.
If I can get a tcpdump of the actual packets I will, then I can see approximately how much data is actually being streamed from the camera vs from the AWS servers.