Foscam R2 with Lenovo Smart Tab [SOLVED]
-
Okay
Demo Proxy
Log from gateway
****************************************************************** * __ __ ___ _ _ ___ ___ _ ___ * * | \/ |/ _ \| \| |/ _ \ / __| | | __| * * | |\/| | (_) | .` | (_) | (__| |__| _| * * |_| |_|\___/|_|\_|\___/ \___|____|___| * * * ****************************************************************** ------------------------------------------------- MONOCLE RUNTIME ENVIRONMENT ------------------------------------------------- VERSION = 0.0.4-3 OS/ARCH = win32\x64 PROCESS = monocle-gateway (PID=27404) TIMESTAMP = 2020-01-22T00:30:45.429Z ------------------------------------------------- MONOCLE GATEWAY SERVICE (Version: 0.0.4-3) ------------------------------------------------- [Monocle Starting] [Monocle Connecting] [Monocle Started] [RTSP Server Starting] [RTSP Server Listening] 0.0.0.0:8555 (RTSP) [RTSP Server Listening] 0.0.0.0:443 (RTSP-TLS) [RTSP Proxy Started] (PID=7852) [RTSP Server Listening] 0.0.0.0:8554 (PROXY) [RTSP Server Started] [Monocle Connected] [RTSP Server Registered] ------------------------------------------------- MONOCLE RTSP SERVICE - INITIALIZED ------------------------------------------------- FQDN = 46224620-b4e1-424d-abce-1ddb866d01f8.mproxy.io HOST = 192.168.1.26 PORT = 443 ------------------------------------------------- ------------------------------------------------- INITIALIZE RTSP STREAM: Demo Proxy ------------------------------------------------- - NAME : Demo Proxy - MAKE : Monocle - MODEL : Demo - LABEL : PRIMARY - URL : rtsp://demo.mproxy.io:554/test - UUID : STREAM:b10829c1-f61c-4f67-a30f-dc3dd578d447 - SESS : bab0a510-777d-4b99-a1a9-a67023c700c5 - MODIF : Tue Jan 21 2020 17:15:09 GMT-0800 (Pacific Standard Time) - TAGS : @tunnel -------------------------------------------------Log from WebUI
[ { "timestamp": "2020-01-22T01:16:08.814Z", "request": "InitializeCameraStreams", "response": [ { "uri": "rtsp://demo.mproxy.io:554/test", "proxy": "rtsp://46224620-b4e1-424d-abce-1ddb866d01f8.mproxy.io:443/STREAM:b10829c1-f61c-4f67-a30f-dc3dd578d447?session=bab0a510-777d-4b99-a1a9-a67023c700c5", "resolution": { "width": "1920", "height": "1080" }, "authorizationType": "NONE", "videoCodec": "H264", "audioCodec": "NONE", "protocol": "RTSP" } ] }, {Alexa shows Camera Loading Screen and then about 10 seconds later it says “Camera Doesn’t Support That”
-
So it’s certainly acting like the tablet is not able to establish the RTSP connection to the gateway.
I know we have already checked the DNS, SSL cert, IP address, access to port 443, etc. So I think we know that a connection is not getting blocked by the typical actors.
Amazon does not provide us any details on how to further diagnose Alexa camera connection related issues on the Alexa hardware side. It’s just a black box to us.
I think some network packet sniffing might be in order to try and determine if the Alexa device is trying to connect to the gateway. This seems to be where we are stuck once again. Tracing outbound requests from the tablet device should reveal TCP attempts on port 443 to the gateway.
-Robert
-
Sure i can try to set something up with some guidance, i have used them in the past but i might need a little direction on setting it up. I mainly have windows on the network but may be able to setup something on one of the Raspberry PI3 i have.
Also the lenovo show is an android OS so im not sure if there is an android packet sniffer that can be installed directly on it. It isn’t rooted which may be necessary. I will do a little research unless you have some specific guidance.
Question: do you think its worth replacing my firewall. I have an older netgear that i have used in the past that i can try swapping out the USG with.
-
You might look into the USG and see if it supports any packet sniffing capabilities. I use a PFSense router and it does have support for traffic sniffing (with additional packages installed).
It’s hard to say if swapping out the router would make any difference … we really don’t know where the problem lies just yet.
Thanks, Robert
-
Im haven’t had a chance to analyze it yet, but essentially i installed a android packet capture on the Lenovo Smart Tab, started a packet capture and asked Alexa to show Demo Proxy
https://1drv.ms/u/s!AsWlCkfB-HIupUPka7vauYNhVbMl?e=e5Wctf
See if this link works for you. File is 1.2mb
-
Apology for the large messy file. Using tcpdump command SSH’d into the USG and putty logging
-
@skarragallagher said in Foscam R2 with Lenovo Smart Tab:
I did not see any packets either in the “Source” or “Destination” with the IP address of the gateway: “192.168.1.26”. In fact the only local addresses found are “192.168.1.1” and “192.168.1.155”.
- Robert
-
I did not see address “192.168.1.26” in the TCPDUMP file either.
-
Let me see if can get a better packet capture, helps to know what you are looking for.
-
Well i did some extensive testing last night. I plugged in an ethernet adapter and moved the gateway to my laptop so they could share the same switch. I ran wireshark and tried to reproduce the issue. I never saw any communication with the Lenovo Smart Tab to the gateway. I started checking the basics again and I did identify a type in the static record i set for the FQDN although correcting this didn’t fix the issue.
I basically reverting everything to the way it was able to resolve the address, ping the gateway with the FQDN, do a TCP Ping on port 443, and do an SSL probe using the Ping & Net app on the Lenovo Smart Tab.
In the gateway i did see a socket connection attempt like in your example. Of course not from Alexa or when trying to show the camera, but when i did the SSL probe test. So i know there are no internal networking / connectivity issues that is blocking the attempt
The packet capture that i did on the Lenovo Smart Tab using the app is kind of hard to read because it uses a VPN connection to capture using the man in the middle exploit so thats where all the 10.x.x.x. addresses are comming from there.
For some context:
192.168.1.155 is Lenovo Tab over WIFI
192.168.1.199 is Lenovo Tab over ethernet
192.168.1.105 is my laptop that i was doing testing from
192.168.1.26 is obviously the gateway and home automation serverHere is a more specific tcpdump that i ran on the USG. I recreated the error twice, once targeting the Lenovo Smart Tab over ethernet (192.168.1.199) and once targeting the the gateway. I am thinking though that this won’t capture internal communication i.e. Lenovo Smart Tab <–> Monocle Gateway but only when it traverses the internet.
https://1drv.ms/u/s!AsWlCkfB-HIupUZnPqu_QZciPVML?e=iJCqFP
This is why i tried moving both the Lenovo Tab over ethernet and the Gateway to the same switch that the laptop is wired to and running captures. This did effectively capture my ping requests from the Lenovo Tab, to the gateway (running on the laptop) but however that was the only communication between the two devices. Its as if Alexa isn’t getting the URL at all and or not even attempting to connect.
Here is the wireshark packet capture
https://1drv.ms/u/s!AsWlCkfB-HIupUdURtd2cgwRJx14?e=YwsUZU -
Just for confirmation that we are able to properly capture the packet attempts, please try to view the Demo Direct camera feed and then see if IP address “54.82.183.87” is captured as a destination from the tablet.
I agree with your testing method/approach and points on not being able to capture intra-LAN packets from the tablet to the gateway that may not cross the USG router.
Thanks, Robert
-
Yeah let me work through that, when i attempt the packet capture on the Lenovo via the app installed it won’t connect to Demo Direct over the VPN connection it creates to actually capture the packets. I will try some other apps and potentially investigate rooted this device.
In the mean time i will use the USG tcpdump method to attempt to capture this traffic and verify this connection is captured
-
@Monocle said in Foscam R2 with Lenovo Smart Tab:
54.82.183.87
I didn’t see it on the USG but it actually showed the feed.
i did see alot of this on the USG
1:10:48.232144 IP 192.168.1.155.41795 > ec2-54-145-94-27.compute-1.amazonaws.co m.62715: UDP, length 70 11:10:48.284643 IP ec2-54-145-94-27.compute-1.amazonaws.com.62715 > 192.168.1.15 5.41795: UDP, length 1276 11:10:48.328628 IP ec2-54-145-94-27.compute-1.amazonaws.com.62715 > 192.168.1.15 5.41795: UDP, length 1258 11:10:48.332397 IP ec2-54-145-94-27.compute-1.amazonaws.com.62715 > 192.168.1.15 5.41795: UDP, length 1256 11:10:48.372877 IP ec2-54-145-94-27.compute-1.amazonaws.com.62715 > 192.168.1.15 5.41795: UDP, length 1418 11:10:48.373066 IP ec2-54-145-94-27.compute-1.amazonaws.com.62715 > 192.168.1.15 5.41795: UDP, length 48 11:10:48.382885 IP ec2-54-145-94-27.compute-1.amazonaws.com.62715 > 192.168.1.15 5.41795: UDP, length 1294 11:10:48.444894 IP ec2-54-145-94-27.compute-1.amazonaws.com.62715 > 192.168.1.15 5.41795: UDP, length 1227 11:10:48.450816 IP 192.168.1.155.41795 > ec2-54-145-94-27.compute-1.amazonaws.co m.62715: UDP, length 70 11:10:48.489641 IP ec2-54-145-94-27.compute-1.amazonaws.com.62715 > 192.168.1.15 5.41795: UDP, length 1273 11:10:48.493144 IP ec2-54-145-94-27.compute-1.amazonaws.com.62715 > 192.168.1.15 5.41795: UDP, length 1320 11:10:48.533865 IP ec2-54-145-94-27.compute-1.amazonaws.com.62715 > 192.168.1.15 5.41795: UDP, length 106 11:10:48.561108 IP ec2-54-145-94-27.compute-1.amazonaws.com.62715 > 192.168.1.15 5.41795: UDP, length 1336 11:10:48.564358 IP ec2-54-145-94-27.compute-1.amazonaws.com.62715 > 192.168.1.15 5.41795: UDP, length 848 11:10:48.591875 IP ec2-54-145-94-27.compute-1.amazonaws.com.62715 > 192.168.1.15 5.41795: UDP, length 1119 11:10:48.617617 IP ec2-54-145-94-27.compute-1.amazonaws.com.62715 > 192.168.1.15 5.41795: UDP, length 1418 11:10:48.617819 IP ec2-54-145-94-27.compute-1.amazonaws.com.62715 > 192.168.1.15 5.41795: UDP, length 318 11:10:48.680864 IP ec2-54-145-94-27.compute-1.amazonaws.com.62715 > 192.168.1.15 5.41795: UDP, length 1267 11:10:48.685126 IP ec2-54-145-94-27.compute-1.amazonaws.com.62715 > 192.168.1.15 5.41795: UDP, length 1240 11:10:48.686517 IP 192.168.1.155.41795 > ec2-54-145-94-27.compute-1.amazonaws.co m.62715: UDP, length 70 11:10:48.734833 IP ec2-54-145-94-27.compute-1.amazonaws.com.62715 > 192.168.1.15 5.41795: UDP, length 45I’ll keep digging,
i started a thread on the Amazon Dev forum from the link you sent as well
-
Asked Alexa to show Demo DIRECT
Here is the USG tcpdump targeting source port 192.168.1.155 (Lenovo WIFI)
https://1drv.ms/t/s!AsWlCkfB-HIupUlIanrbjjrFzHt0?e=gSfiZzNote that the camera feed was successful
Interestingly enough a search for the IP address (54.82.183.8) the capture doesn’t find :(For contrast i tried Demo Proxy as well
Asked Alexa to show Demo Proxy
Here is the USG tcpdump targeting source port 192.168.1.155 (Lenovo WIFI) -
Well, we know the tablet is certainly accessing that address if the demo camera is getting displayed.
demo.mproxy.io(54.82.183.87)
Can you see this IP using the onboard packet capture tool on the tablet?
Thanks, Robert
-
Indeed, i need to find a better packet sniffer because the one i was using wouldn’t render the camera feed when the VPN connection was enabled.
I need to take a look at it though, to at least see if it attempted.
I will keep digging on this though.
-
Apparently i should be able to run a TCPDUMP from my Unify AC Pro as well. I am reticent to root the device because of voiding the warranty to install a legit packet capture app. I think this should actually be better than the USG since its internal with one interface on the LAN. I have never SSH into but i will work on that and reproduce the issue and capture using TCPDUMP on the AP.
-
Okay so i was able to do some packet captures using the Access point.
I said Show Demo Proxy which is using @tunnel
One thing that i noticed was that it looks like this when i ping 192.168.1.26 from the Lenovo (over wifi 192.168.1.155)
192.168.1.155 > unifi: ICMP echo request, id 1, seq 1, length 64 19:40:04.752834 IP (tos 0x0, ttl 128, id 2498, offset 0, flags [none], proto ICMP (1), length 84) unifi > 192.168.1.155: ICMP echo reply, id 1, seq 1, length 64 19:40:05.758661 IP (tos 0x0, ttl 64, id 25693, offset 0, flags [DF], proto ICMP (1), length 84)Notice it says Unifi which is actually because this server is also the controller for all the Unify products… anyway if you see unifi = 192.168.1.26
Here is the packet capture.
https://1drv.ms/t/s!AsWlCkfB-HIupUpKkIIBkKU9CDCD?e=FgT0JUI did some searches and found no references to unifi or 192.168.1.26
Is there anything you can glean from this?
-
I was narrowing in on the time frame
52.94.235.50.443 > 192.168.1.155.33771: Flags [P.], cksum 0xe339 (correct), seq 8443:8553, ack 84128, win 9788, length 110 23:43:22.907668 IP (tos 0x6c, ttl 229, id 16801, offset 0, flags [DF], proto TCP (6), length 78) 52.94.235.50.443 > 192.168.1.155.33771: Flags [P.], cksum 0xfb9e (correct), seq 8553:8591, ack 84128, win 9788, length 38 23:43:22.910222 IP (tos 0x0, ttl 64, id 32646, offset 0, flags [DF], proto TCP (6), length 40) 192.168.1.155.33771 > 52.94.235.50.443: Flags [.], cksum 0x576d (correct), seq 84128, ack 8553, win 303, length 0 23:43:22.910854 IP (tos 0x0, ttl 64, id 32647, offset 0, flags [DF], proto TCP (6), length 40) 192.168.1.155.33771 > 52.94.235.50.443: Flags [.], cksum 0x5747 (correct), seq 84128, ack 8591, win 303, length 0 23:43:22.938190 IP (tos 0x6c, ttl 236, id 41559, offset 0, flags [DF], proto UDP (17), length 102) ec2-52-23-239-191.compute-1.amazonaws.com.55067 > 192.168.1.155.37404: [udp sum ok] UDP, length 74 23:43:22.940422 IP (tos 0xcc, ttl 64, id 5467, offset 0, flags [none], proto ICMP (1), length 130) 192.168.1.155 > ec2-52-23-239-191.compute-1.amazonaws.com: ICMP 192.168.1.155 udp port 37404 unreachable, length 110 IP (tos 0x6c, ttl 236, id 41559, offset 0, flags [DF], proto UDP (17), length 102) ec2-52-23-239-191.compute-1.amazonaws.com.55067 > 192.168.1.155.37404: [udp sum ok] UDP, length 74 23:43:22.977216 IP (tos 0x6c, ttl 236, id 41561, offset 0, flags [DF], proto UDP (17), length 114) ec2-52-23-239-191.compute-1.amazonaws.com.55067 > 192.168.1.155.37404: [udp sum ok] UDP, length 86 23:43:22.980255 IP (tos 0xcc, ttl 64, id 5468, offset 0, flags [none], proto ICMP (1), length 142) 192.168.1.155 > ec2-52-23-239-191.compute-1.amazonaws.com: ICMP 192.168.1.155 udp port 37404 unreachable, length 122 IP (tos 0x6c, ttl 236, id 41561, offset 0, flags [DF], proto UDP (17), length 114) ec2-52-23-239-191.compute-1.amazonaws.com.55067 > 192.168.1.155.37404: [udp sum ok] UDP, length 86 23:43:23.056402 IP (tos 0x6c, ttl 229, id 16802, offset 0, flags [DF], proto TCP (6), length 250) 52.94.235.50.443 > 192.168.1.155.33771: Flags [P.], cksum 0x35d0 (correct), seq 8591:8801, ack 84128, win 9788, length 210 23:43:23.056466 IP (tos 0x6c, ttl 229, id 16803, offset 0, flags [DF], proto TCP (6), length 1500) 52.94.235.50.443 > 192.168.1.155.33771: Flags [.], cksum 0x06ab (correct), seq 8801:10261, ack 84128, win 9788, length 1460 23:43:23.056489 IP (tos 0x6c, ttl 229, id 16804, offset 0, flags [DF], proto TCP (6), length 1500) 52.94.235.50.443 > 192.168.1.155.33771: Flags [.], cksum 0x5607 (correct), seq 10261:11721, ack 84128, win 9788, length 1460 23:43:23.056510 IP (tos 0x6c, ttl 229, id 16805, offset 0, flags [DF], proto TCP (6), length 1500) 52.94.235.50.443 > 192.168.1.155.33771: Flags [.], cksum 0x5b4d (correct), seq 11721:13181, ack 84128, win 9788, length 1460 23:43:23.057899 IP (tos 0x6c, ttl 229, id 16806, offset 0, flags [DF], proto TCP (6), length 1500) 52.94.235.50.443 > 192.168.1.155.33771: Flags [.], cksum 0x87a1 (correct), seq 13181:14641, ack 84128, win 9788, length 1460 23:43:23.057957 IP (tos 0x6c, ttl 229, id 16807, offset 0, flags [DF], proto TCP (6), length 1500) 52.94.235.50.443 > 192.168.1.155.33771: Flags [.], cksum 0x7911 (correct), seq 14641:16101, ack 84128, win 9788, length 1460I notice right around the time when she says “Camera doesn’t Support that” there is a couple UDP ports that show as unreachable, the only errors that i can detect. Ive isolated it here:
192.168.1.155 > ec2-52-23-239-191.compute-1.amazonaws.com: ICMP 192.168.1.155 udp port 37404 unreachable, length 110 IP (tos 0x6c, ttl 236, id 41559, offset 0, flags [DF], proto UDP (17), length 102) ec2-52-23-239-191.compute-1.amazonaws.com.55067 > 192.168.1.155.37404: [udp sum ok] UDP, length 74 23:43:22.977216 IP (tos 0x6c, ttl 236, id 41561, offset 0, flags [DF], proto UDP (17), length 114) ec2-52-23-239-191.compute-1.amazonaws.com.55067 > 192.168.1.155.37404: [udp sum ok] UDP, length 86 23:43:22.980255 IP (tos 0xcc, ttl 64, id 5468, offset 0, flags [none], proto ICMP (1), length 142) 192.168.1.155 > ec2-52-23-239-191.compute-1.amazonaws.com: ICMP 192.168.1.155 udp port 37404 unreachable, length 122Its always the lenovo as the source and some ec2 instance on some high UDP port. Changes everytime actually but show up in all the testing that i have done. This one in particular was Demo Proxy and does show up in Monocle WebUI log as well as the same behavior that i have posted earlier where by it shows the stream intializing on the gateway but then doesn’t show socket connection attempt. Its as if the alexa doesn’t actually get the information to connect locally.
-
I checked our Amazon services and those are not any of our IP addresses. I did not expect them to be, but I just wanted to make sure. The tablet should be in communication with Alexa web services and obtain the camera feed information from them. (not monocle directly) Of course after obtaining the camera connection info, I would expect the tablet to then attempt a connection to the camera stream; the monocle gateway instance in this case.
Is it possible to follow this exact procedure on the “Demo Direct” and get confirmation that you can see TCP traffic to the “demo.mproxy.io (54.82.183.87)” address? This would at least tell us that the packet capture method should be showing us the local gateway IP when attempting against “Demo Proxy”.
Thanks, Robert
