Foscam R2 with Lenovo Smart Tab [SOLVED]
-
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
-
Another interesting fact gleaned from the inspections of the tcpdump from my access point, was that when accessing the Demo Direct feed (the only one that works so far)
I seem nothing in the logs coming from the IP address you mentioned for the demo feed. All packets are coming from an EC2 instance
ec2-3-84-170-146.compute-1.amazonaws.com.58690 > 192.168.1.155.55267: [udp sum ok] UDP, length 106 23:59:20.702793 IP (tos 0x6c, ttl 236, id 41891, offset 0, flags [DF], proto UDP (17), length 1446) ec2-3-84-170-146.compute-1.amazonaws.com.58690 > 192.168.1.155.55267: [udp sum ok] UDP, length 1418 23:59:20.702869 IP (tos 0x6c, ttl 236, id 41892, offset 0, flags [DF], proto UDP (17), length 307) ec2-3-84-170-146.compute-1.amazonaws.com.58690 > 192.168.1.155.55267: [udp sum ok] UDP, length 279 23:59:20.746808 IP (tos 0x6c, ttl 236, id 41898, offset 0, flags [DF], proto UDP (17), length 1446) ec2-3-84-170-146.compute-1.amazonaws.com.58690 > 192.168.1.155.55267: [udp sum ok] UDP, length 1418 23:59:20.746896 IP (tos 0x6c, ttl 236, id 41899, offset 0, flags [DF], proto UDP (17), length 232) ec2-3-84-170-146.compute-1.amazonaws.com.58690 > 192.168.1.155.55267: [udp sum ok] UDP, length 204 23:59:20.752056 IP (tos 0x6c, ttl 236, id 41900, offset 0, flags [DF], proto UDP (17), length 1380) ec2-3-84-170-146.compute-1.amazonaws.com.58690 > 192.168.1.155.55267: [udp sum ok] UDP, length 1352 23:59:20.789567 IP (tos 0x6c, ttl 236, id 41908, offset 0, flags [DF], proto UDP (17), length 1280) ec2-3-84-170-146.compute-1.amazonaws.com.58690 > 192.168.1.155.55267: [udp sum ok] UDP, length 1252 23:59:20.821598 IP (tos 0x6c, ttl 236, id 41910, offset 0, flags [DF], proto UDP (17), length 1291) ec2-3-84-170-146.compute-1.amazonaws.com.58690 > 192.168.1.155.55267: [udp sum ok] UDP, length 1263 23:59:20.829315 IP (tos 0x6c, ttl 236, id 41911, offset 0, flags [DF], proto UDP (17), length 1231) ec2-3-84-170-146.compute-1.amazonaws.com.58690 > 192.168.1.155.55267: [udp sum ok] UDP, length 1203 23:59:20.849761 IP (tos 0x0, ttl 64, id 15430, offset 0, flags [DF], proto UDP (17), length 74) 192.168.1.155.55267 > ec2-3-84-170-146.compute-1.amazonaws.com.58690: [udp sum ok] UDP, length 46 23:59:20.893548 IP (tos 0x6c, ttl 236, id 41920, offset 0, flags [DF], proto UDP (17), length 1259) ec2-3-84-170-146.compute-1.amazonaws.com.58690 > 192.168.1.155.55267: [udp sum ok] UDP, length 1231 23:59:20.938793 IP (tos 0x6c, ttl 236, id 41921, offset 0, flags [DF], proto UDP (17), length 1254) ec2-3-84-170-146.compute-1.amazonaws.com.58690 > 192.168.1.155.55267: [udp sum ok] UDP, length 1226 23:59:20.981805 IP (tos 0x6c, ttl 236, id 41931, offset 0, flags [DF], proto UDP (17), length 1189) ec2-3-84-170-146.compute-1.amazonaws.com.58690 > 192.168.1.155.55267: [udp sum ok] UDP, length 1161 23:59:20.986660 IP (tos 0x6c, ttl 236, id 41932, offset 0, flags [DF], proto UDP (17), length 1410) ec2-3-84-170-146.compute-1.amazonaws.com.58690 > 192.168.1.155.55267: [udp sum ok] UDP, length 1382 23:59:21.026054 IP (tos 0x6c, ttl 236, id 41940, offset 0, flags [DF], proto UDP (17), length 1446) ec2-3-84-170-146.compute-1.amazonaws.com.58690 > 192.168.1.155.55267: [udp sum ok] UDP, length 1418 23:59:21.026162 IP (tos 0x6c, ttl 236, id 41941, offset 0, flags [DF], proto UDP (17), length 153) ec2-3-84-170-146.compute-1.amazonaws.com.58690 > 192.168.1.155.55267: [udp sum ok] UDP, length 125 -
I actually typed the above message out last night / early this morning.
from the tests i have done both on the USG and the AP with tcpdump. I see nothing ever from that specific ip address. The above log shows the UDP streaming traffic as coming from Amazon servers not directly from the the stream. I will run a capture on both the AP and USG firewall to show you.
I am pretty confident that i am capturing all the traffic inbound and outbound as i am running the tcpdump on the Access point and the USG. I will follow up with complete logs on both during Demo Direct.
I just purchased another one of these Lenovo Smart Tabs . I am open to sending it to you if your interested in troubleshooting this and adding it to your list of supported device. Obviously when you are done you can send it on to me. As you can see i am very invested in getting this to work and if your willing please email me. [email protected]
-
So I dumped the files to pcap files and scp’d in and grabbed them and uploaded them to one drive
Demo Direct (Successfully showed camera stream)
From Firewall (USG)
https://1drv.ms/u/s!AsWlCkfB-HIupUxipRTg6qV4zkSi?e=IpwgMXFrom Access Point (UAP)
https://1drv.ms/u/s!AsWlCkfB-HIupUszwjJE9gYd3HPU?e=daTj8xi didn’t see anything from the actual IP address 54.82.183.87
I will run the same exact test again for Demo Proxy cam and export -->pcap file since it seems to capture much more data than printing out to the console.
-
Demo Proxy (Showed splash page, connecting to Demo Proxy, 5 seconds later, “Camera Doesn’t Support That”)
Note, i performed the two full times in the capture because i was in the other room the first time so i wanted to be sure to capture the behavior
From Firewall (USG)
https://1drv.ms/u/s!AsWlCkfB-HIupU0PijjS-dPLjdT2?e=9goaH9From Access Point (UAP)
https://1drv.ms/u/s!AsWlCkfB-HIupU45oMRbeFJetz7t?e=5MMG4UI do see the UDP port errors but i will take a closer look at the captures as it looks to have significantly more information than the previous console dumps.
Thanks again
-
So in my analysis (its been a while since my CCNA has expired) comparing Demo Direct to Demo Proxy on the Access Point Capture:
We see the handshake process appears to succeed in both demo proxy and demo direct however we see the previously noted UDP port unreachable error shortly after. The Direct one starts flowing video UDP frames where the proxy appears to get disconnected from the amazon server which appears to be proxying or tunneling everything.
No direct connections anywhere. Very interesting.
-
@skarragallagher said in Foscam R2 with Lenovo Smart Tab:
Yes, that’s what I was starting to think as well. The Demo Direct stream is hosted on an Amazon EC2 server, but not using the IP address or EC2 hostname that you are getting in the capture log. Also, I’m certain that we are not exposing any UDP ports from this demo server, only TCP ports 443 and 554.
So it “feels” like some middleware is connecting to the stream and then re-proxying the stream via UDP to your Alexa tablet. That seems far fetched to me, but would explain what we are seeing.
In that light … as a test, you could try exposing your Monocle Gateway instance publicly over the Internet and then we can see if the tablet can then establish a connection to your gateway instance and access the camera streams. To do this you would need to be able to expose port 443 on your Internet gateway/router and point it internally to the gateway instance. Additionally, you would need to configure the Monocle Gateway with your custom public IP address instead of the auto-detected private/internal IP of the gateway server. Please see: https://monoclecam.com/monocle-gateway/custom-configuration#override-auto-detected-ip-address
On restarting the gateway, it should display a config like this:
------------------------------------------------- MONOCLE RTSP SERVICE - INITIALIZED ------------------------------------------------- FQDN = 46224620-b4e1-424d-abce-1ddb866d01f8.mproxy.io HOST = X.X.X.X (YOUR PUBLIC IP ADDRESS) PORT = 443 -------------------------------------------------And if you attempt to resolve
46224620-b4e1-424d-abce-1ddb866d01f8.mproxy.ioit should resolve (DNS) to your public IP. Please note that it may take an hour or so for the DNS IP change to fully propagate.
As for your offer to send along a Lenovo Smart Tab, I appreciate the offer but would certainly prefer if we can figure this out without all that hassle. So lets hold off on that and see if we can learn a bit more about what’s really going on with this EC2 server and UDP packets.
Thanks, Robert
-
@Monocle
Thanks Robert,
I have a dynamic IP address assigned to my public interface. I use a Dynamic DNS provider. Can I use a namespace instead of the public address since it will change when DHCP refreshes? -
I opened up a port forwarding rule for port 443
Edited the config and adjusted the host with my current public IP****************************************************************** * __ __ ___ _ _ ___ ___ _ ___ * * | \/ |/ _ \| \| |/ _ \ / __| | | __| * * | |\/| | (_) | .` | (_) | (__| |__| _| * * |_| |_|\___/|_|\_|\___/ \___|____|___| * * * ****************************************************************** ------------------------------------------------- MONOCLE RUNTIME ENVIRONMENT ------------------------------------------------- VERSION = 0.0.4-3 OS/ARCH = win32\x64 PROCESS = monocle-gateway (PID=31116) TIMESTAMP = 2020-01-24T18:33:24.579Z ------------------------------------------------- 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=34472) [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 = 108.231.61.93 PORT = 443 -------------------------------------------------DNS is showing correct for internal and external
C:\>nslookup 46224620-b4e1-424d-abce-1ddb866d01f8.mproxy.io Server: ubnt Address: 192.168.1.1 Name: 46224620-b4e1-424d-abce-1ddb866d01f8.mproxy.io Address: 108.231.61.93 C:\>nslookup 46224620-b4e1-424d-abce-1ddb866d01f8.mproxy.io 8.8.8.8 Server: dns.google Address: 8.8.8.8 Non-authoritative answer: Name: 46224620-b4e1-424d-abce-1ddb866d01f8.mproxy.io Address: 108.231.61.93I will wait a couple hours to make sure DNS propagates before testing. I will produce some pcap files as well from the access point
-
Boooom! we have Demo Proxy working
-
WOW. Just WOW. I can’t believe they are proxying the stream like this. This is not the case for any other Alexa devices that we have worked with. This of course adds latency and is potentially very undesirable from a security standpoint as your audio and video data is getting passed through some server. The packets are encrypted, but still.
Is it working now for your real Foscam camera stream? Make sure to use
@tunneland the camera has “Foscam” listed as the manufacturer in the Monocle web portal.I have a dynamic IP address assigned to my public interface. I use a Dynamic DNS provider. Can I use a namespace instead of the public address since it will change when DHCP refreshes?
Not without some changes – but it should be possible. The Alexa system will only connect to DNS hostnames with valid SSL certificates. Do you want to setup a real SSL certificate for your domain? Apart from acquiring the SSL certificate, we would also need to provide some configuration method to allow your to include your own certificate and private key to the Monocle gateway on startup.
Thanks, Robert
-
Very interesting indeed and ironically different than any other alexa device is even more boggling.
thank you for working with me on this, i really appreciate it.
I think a simpler solution would be to configure my IP with a static. I think direction i would go with this. I keep getting these nagging monthly mails to update my DNS record etc… so it would do away with that.
I expect more of these devices like this to come out though. Would be nice to see continued development on this. At least we have a workaround at this point.
-
Yes btw the foscam works!!!
-
Glad to hear the Foscam is working.
If we are going to leave port 443 open to the Internet it would be prudent for us to add some form of authentication to the monocle service to prevent unauthorized access. The current exposure is pretty limited but security by obscurity is really not a good solution. At the moment any consumer would need to know the unique STREAM ID and SESSION ID to be able to get access to any camera streams but a proper authentication mechanism would be better.
Thanks, Robert
-
Yes i agree. I will work on adding the Static IP address to my internet plan. I am assuming that auth would be handled on the gateway which would mean the a new version would need to be developed by you?
If i can assist in any way by testing or whatever you need, i happy to do so. I really appreciate the help in getting this to work.
Many Thanks!
Ryan -
Yes we will need to add support for this in the software … let me look into this next week and maybe we can get a copy out to test with .
Thanks, Robert
-
Thanks, i have most of cameras working now. My doorbird is not working and then a few combined views from BlueIris but i haven’t spent time investigating.
I created a couple other support threads in the lenovo forums
https://forums.lenovo.com/t5/Lenovo-Smart-Tablets-with-Amazon/Lenovo-smart-tab-m10-Camera-Streaming/m-p/4633642/highlight/falseWe will see if the can escalate this and resolve this as well although we have a workaround.
No rush, but once you have a version you would like to test let me know here and i will give it a go.
