• Register
    • Login
    • Search
    • Categories
    • Recent
    • Tags
    • Popular

    Foscam R2 with Lenovo Smart Tab [SOLVED]

    Foscam
    2
    95
    5548
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • Monocle
      Monocle @skarragallagher last edited by Monocle

      @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

      Monocle: https://monoclecam.com
      Getting Started | Troubleshooting Guide | FAQ | Contact Support

      1 Reply Last reply Reply Quote 0
      • Monocle
        Monocle @skarragallagher last edited by

        @skarragallagher

        I did not see address “192.168.1.26” in the TCPDUMP file either.

        Monocle: https://monoclecam.com
        Getting Started | Troubleshooting Guide | FAQ | Contact Support

        1 Reply Last reply Reply Quote 0
        • S
          skarragallagher last edited by

          Let me see if can get a better packet capture, helps to know what you are looking for.

          1 Reply Last reply Reply Quote 0
          • S
            skarragallagher last edited by skarragallagher

            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 server

            Here 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

            Monocle 1 Reply Last reply Reply Quote 0
            • Monocle
              Monocle @skarragallagher last edited by

              @skarragallagher

              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

              Monocle: https://monoclecam.com
              Getting Started | Troubleshooting Guide | FAQ | Contact Support

              1 Reply Last reply Reply Quote 0
              • S
                skarragallagher last edited by

                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

                1 Reply Last reply Reply Quote 0
                • S
                  skarragallagher last edited by skarragallagher

                  @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 45

                  I’ll keep digging,

                  i started a thread on the Amazon Dev forum from the link you sent as well

                  1 Reply Last reply Reply Quote 0
                  • S
                    skarragallagher last edited by skarragallagher

                    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=gSfiZz

                    Note 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)

                    https://1drv.ms/t/s!AsWlCkfB-HIupUjsG7ZIWgy48L0M?e=1IxVMr

                    Monocle 1 Reply Last reply Reply Quote 0
                    • Monocle
                      Monocle @skarragallagher last edited by

                      @skarragallagher

                      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

                      Monocle: https://monoclecam.com
                      Getting Started | Troubleshooting Guide | FAQ | Contact Support

                      1 Reply Last reply Reply Quote 0
                      • S
                        skarragallagher last edited by skarragallagher

                        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.

                        1 Reply Last reply Reply Quote 0
                        • S
                          skarragallagher last edited by

                          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.

                          1 Reply Last reply Reply Quote 0
                          • S
                            skarragallagher last edited by

                            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=FgT0JU

                            I did some searches and found no references to unifi or 192.168.1.26

                            Is there anything you can glean from this?

                            1 Reply Last reply Reply Quote 0
                            • S
                              skarragallagher last edited by

                              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 1460

                              I 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 122

                              Its 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.

                              Monocle 1 Reply Last reply Reply Quote 0
                              • Monocle
                                Monocle @skarragallagher last edited by

                                @skarragallagher

                                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

                                Monocle: https://monoclecam.com
                                Getting Started | Troubleshooting Guide | FAQ | Contact Support

                                1 Reply Last reply Reply Quote 0
                                • S
                                  skarragallagher last edited by

                                  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
                                  1 Reply Last reply Reply Quote 0
                                  • S
                                    skarragallagher last edited by

                                    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]

                                    1 Reply Last reply Reply Quote 0
                                    • S
                                      skarragallagher last edited by skarragallagher

                                      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=IpwgMX

                                      From Access Point (UAP)
                                      https://1drv.ms/u/s!AsWlCkfB-HIupUszwjJE9gYd3HPU?e=daTj8x

                                      i 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.

                                      1 Reply Last reply Reply Quote 0
                                      • S
                                        skarragallagher last edited by

                                        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=9goaH9

                                        From Access Point (UAP)
                                        https://1drv.ms/u/s!AsWlCkfB-HIupU45oMRbeFJetz7t?e=5MMG4U

                                        I 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

                                        1 Reply Last reply Reply Quote 0
                                        • S
                                          skarragallagher last edited by

                                          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.

                                          Monocle 1 Reply Last reply Reply Quote 0
                                          • Monocle
                                            Monocle @skarragallagher last edited by

                                            @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.io it 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: https://monoclecam.com
                                            Getting Started | Troubleshooting Guide | FAQ | Contact Support

                                            1 Reply Last reply Reply Quote 0
                                            • First post
                                              Last post
                                            Privacy Policy  |  Terms & Conditions

                                            © 2018 shadeBlue, LLC.