Completely wrong. P2P services such as the ones Wyze employs exist exactly because most people have router/firewalls. The P2P servers hosted on the Internet help establish a point to point connection between the viewing device and the camera, “penetrating” any firewalls along the way. Thar is exactly their purpose.
“MrEngineer” writes that ‘the cloud “service” that allows your app to connect to your camera from outside your house.’ and then that ‘a cloud “service” is needed to connect the app with the camera’ and then you needlessly “correct” him by simply repeating that using the word phone instead of app? What the heck.
I totally understand that you have your own desired use case (use your own server). But you either misunderstood what I was saying, or your view on certain things in incorrect.
You first say “The cameras initiate the connection to the remote service from inside your network”
Then you say “The cameras can’t connect directly to the app on my phone, not because my phone’s IP is unknown, but because that’s not how it works.”
So, why do you think the camera makes that outgoing connection? According to you a camera connecting “to” the app is “not how it works”.
If the “correct” way is for the app to connect “to” the camera (like you browser analogy explains), then why doesn’t it just do that, because if it did that then a cloud service wouldn’t even be needed! …It is EXACTLY because the user’s firewall won’t allow that. So a reverse connection scheme is needed to BYPASS the firewall.
I honestly don’t even know where to begin.
You are absolutely WRONG.
There, that’s a good start.
So, the first thing you need to understand is that the main reason why the camera makes an “outgoing” connection is to BYPASS the security of the firewall. Because if it did not do this, then there would be no way for the app to directly connect “to” the camera because the firewall would block that incoming attempt from the app because it is an unsolicited incoming packet. But of course if you are a techie, then you could setup a port-forwarding rule to allow such unsolicited packets to be routed directly to the camera, in essence you are “authorizing” those packets to go through the firewall. But using a port forwarding method has its own set of challenges - you need to either manually configure the camera to have a fixed IP on your network so the rule will stay working. Or some routers allow you to use a MAC address instead of an IP address so the rule will still work even if the camera’s IP changes (because it’s MAC address will always stay the same). But then who is going to configure their router this way? It definitely won’t be the typical user of wyze cameras that’s for sure.
Second, accessing your camera on your local network when you are home is completely different from accessing it from outside your house. When home, you don’t need to deal with a firewall and the IP address used to connect to the camera is totally different between the two.
Third, because most users don’t have a guaranteed fixed IP address for their home, a DDNS service is needed to reliably connect into your home even when it’s IP address changes.
For ALL of the above reasons (and many more), that’s why almost every IoT company uses a cloud service so that the user doesn’t need to deal with any of this technical stuff - the user just wants a plug and play experience.
And since there isn’t a standard protocol for cloud services for IoT devices yet, each company has a proprietary system. So, what incentive does a company have to not only publicly provide the details of their protocol/API (potentially making it easier for hackers to exploit it), but then they would need to provide some sort of technical support for those who are trying to use it - all with the end goal of you not having to pay them anymore?
So again, I understand that you are technically capable to setup your own server, but techies like us are a VERY minor customer base and that’s why most companies won’t devote much resources to address our wishes.
Hi MrEngineer,
You are correct in that my comments appear to be conflicting. It was very late and I probably should have stopped typing hours before I did. Let me try to clear up some of the confusion.
Correct. Please recall the quote I was responding to…
I said “it doesn’t work that way” because
You imply the camera is somehow trying to connect with your phone at some point, which is patently false. That camera will never try to connect to your phone under any circumstances.
The IP of your phone is irrelevant since it is the one establishing the connection.
The fact that the camera does in fact connect with the service is a completely different topic/issue, and should not be confused with the camera trying to connect with an actual ‘device’.
The cameras connect to the service (as I’ve said before) so that your phone (or any other device you are using to view your feeds) can FIND the camera. NOT so that it can connect with your phone, and NOT to bypass any security. (Being a legitimate connection established from within your network, it is ‘allowed’ through the firewall. It does not ‘go around’ it.)
BINGO! You hit the nail right on the head! A service really ISN’T required to accomplish this task (*). But it does make the connection a whole lot easier to create, and more importantly it provides your phone with access multiple devices on the other side. Without the service, you would need to establish a connection to each camera individually, and yes, deal with the firewall.
(* It is not required in theory. In practice Wyze’s implementation is what demands it today, not the technology).
I disagree. The underlying reason for the service is not to get around the firewall. While it does make it a whole lot easier, that is not it’s purpose - that is basically a beneficial side-effect. I can just as easily connect with any device on my network without the service, provided I know the appropriate IPs and Ports (and whatever security protocols my camera may be using - another thing the service handles for us).
The reverse connection scheme is used because that is the only way for the SERVICE to know your cameras IPs. It has no way of ‘finding’ your cameras, so the cameras need to be the ones that ‘start the conversation’.
Touche! (Well played)
The main reason the camera makes an outgoing connection (to the service) is because that is (currently) the only way the service, your phone, or any other device can find your camera.
As stated above, being allowed through (not bypassing) the firewall is a secondary beneficial happenstance, which could easily be achieved in other ways. But since the service is there anyway, why would you not take advantage of that extra benefit?
You are correct in that the connection established between camera and service does allow your phone to connect to your camera (via the service) a lot easier, but that is certainly not the only way it can be done.
The fact that your network may be setup to block all unsolicited traffic is an issue between you and your network. Personally, I cannot recall ever encountering a network setup that way (though I concede that certainly does not mean they don’t exist).
Typically, the router/firewall are setup to block “unwanted” traffic, i.e., inbound-traffic on ports you have not designated as valid (open). If I were to block all unsolicited traffic at my router, every one of my servers would cease to function (from the WAN). If all networks were setup that way the Internet would simply and literally vanish. (poof).
Close enough. And the problem is…?
True enough. This may not be for the typical or average user, but does that mean everyone needs to be lowered to that level? Are we supposed to design and build hardware and software just to satisfy the lowest common denominator? Should the abilities of the hardware and software be limited by/to the skill-level of the average user?
Except with the way Wyze has things setup, that is not true. You connect exactly the same way at home (LAN) and away (WAN). Today, if you have no internet, you have no access to your cameras, even if you are sitting right next to them, because the “app” can’t login to the “service” which runs exclusively on the Wyze servers.
What you said would be true if
you were self-hosting, with the “service” running on your own network.
you were able to connect directly to the (Wyze) camera without the service, which you can’t do today. And the reason you can’t do it today is because of how everything was implemented, not because it isn’t possible.
Again, I don’t see any problem with this.
I will concede that making things easier on the user is A reason (and a pretty darn good one too). The typical users you refer to are not equipped to handle all of the things that would be need to be handled, so letting someone else deal with it all is the perfect thing. (When I say “not equipped”, I’m not being condescending, I’m being literal - they don’t have the networking hardware, the static IPs, etc.).
But anyone who thinks control (and hence revenue) is not a major contributing factor, IMO, they are fooling only themselves. As pointed out above, there is no technological reason you can’t connect directly to the cameras, nor run any necessary service on your own network. But by forcing you to go through a service that they have exclusive control over, you become reliant upon them.
Having said that, I acknowledge that is certainly not true for ALL IoT “services” - there are plenty that really wouldn’t be able to function if they were not centralized. This service is not one of those.
All with the end goal of not being dependent upon them, or any other servers they have in their authentication-chain (China). I would HAPPILY pay handsomely for the ability to self-host. So if you think this is just about the $$$, I think I somehow sent you the wrong message at some point. Sure, it would be nice to not have to pay for it, but what are we talking about here, each camera would cost about $20~$25 a year? Maybe $50 if they get carried away with it? I pay 7-times that for Internet access every month.
But to address your comment on how each IoT company has a “proprietary system”, I will agree that is true far more often than not (there is overlap), but I don’t care about every IoT device out there - I am currently focused on just this one. And the incentive for developing a similar yet separate API would of course be money. I can’ t speak for everyone, but I do not expect sh*t for free. If they can make a working stable self-serve product, I believe they would open themselves to a market they have yet to tap.
You go on to suggest that they would need to expose their existing internal service’s API, which is inaccurate. For starters, their existing API relies upon multiple external servers, and that reliance would absolutely need to be removed from any end-user API, else it totally defeats the goal of self-reliance. That means replacing the authentication mechanism, which I am guessing is a major portion of the logic/code they wouldn’t want being in the public domain. Similar steps can be taken for any other ‘sensitive’ sections of logic/code.
No big arguments here. It became clear early on that we were talking about two distinctly different groups of users. I might be tempted to argue that the ‘techie’ group is larger than you think, but it is equally possible it is smaller than I think.
The only other thing I would add is that developing the ‘self-serve’ service and API shouldn’t be that big a task. It really all depends on how well the existing service and API were developed (reusability). If it was done poorly, then yes, there is a lot more work that would need to be done. If it was done well, they should be more than 50% there already (and if REALLY well done 75%!).
In closing - Thank you for the robust debate. It is refreshing to see people who can give it as well as take it, without anyone getting their panties in a bunch.
Yes, which is their primary function and purpose in life. They would continue to function equally well, and would be just as valuable, in an environment void of any firewall.
First, “penetrating”, “bypassing” “getting around”. these are all inappropriate terms and I would like to see everyone (me included) stop using them in this context. It makes it sound like Wyze had to hack around your network which is incorrect and misleading. Let’s try “granted passage”, or “allowed through”. Either of those are much more in-tune with what is actually occurring.
And not having to deal with your firewall is a nice bonus, nothing more. That same task could be accomplished in a number of different ways, the most obvious being manually configuring the firewall to allow that traffic through.
If your proposition were correct, then P2P wouldn’t need services in the absence of firewalls, which of course is absurd (in a world full of dynamic IPs).
If you read my reply, then you know that I agreed with that first part. The service does allow your app/phone to connect to your camera.
But the second part of his quote you listed was only half of the comment I was replying to, and it’s the part you left off I was correcting. Here is the whole part I was commenting on…
…to which I replied…
So you see, I wasn’t just trying to be a d*ck, I was making a valid point. Sequence and order are kind-of an important thing.
I really don’t know why you can’t understand that the MAIN reason why the cameras make that outgoing connection is to BYPASS the firewall - and yes I stand firmly behind using the word BYPASS because one of it’s very definitions is “a secondary channel, pipe, or connection to allow a flow when the main one is closed or blocked.” (and it is not inherently a malicious act)
So, let me provide some proof that your understand is incorrect…
You first claim that the reason of why the camera makes an outgoing connection is so that the cloud service will know the cameras IP address (you said “The camera maintains a periodic connection with the service so the service always knows what the camera’s IP is.”)
Well, for the moment, lets say that is true. So now that the cloud service knows the IP address of the camera, big deal, so now what? It’s not like the cloud service can then use that IP info to then initiate a “new” connection to the camera because the firewall will block it!
You could then reply “well, the cloud doesn’t need to initiate a “new” connection, it could just use the existing “OUTGOING” connection from the camera to talk to the camera”.
And you would be 100% correct!
But then by saying that, you are admitting that the cloud service NEEDS to use that “OUTGOING” connection from the camera, and that knowing the IP address of the camera is actually useless because even if the cloud service knows a camera’s IP address, it can’t use it to initiate a new connection to the camera because the firewall will block it! So it absolutely NEEDS to use that “outgoing” connection from the camera to get around the users firewall and connect to the camera - there is absolutely NO other way to connect to the camera (for the 90%+ use case of typical users) - so it is ESSENTIAL and the MAIN reason for that outgoing connection.
So, this definitively proves that “knows what the camera’s IP is” is absolutely useless info and thus is definitely NOT the main reason for the outgoing connection, and unequivocally proves that the MAIN (and probably ONLY) reason why the camera makes that outgoing connection is to BYPASS or “GET AROUND” the firewall.
You then say “… “bypassing” “getting around”. these are all inappropriate terms and I would like to see everyone …try “granted passage”, or “allowed through”. Either of those are much more in-tune with what is actually occurring.”
Which is also the wrong way to look at this.
Since you like analogies, try this one…
Lets say there is a bar that you want to visit, but a bouncer at the front door won’t let you enter. So, you then “go around” to the back of the building and enter using the back door, thus “BYPASSING” or “GETTING AROUND” the bouncer.
Did the bouncer “grant you passage” or “allow you through” that back door? Of course not.
For the 10% of users who could create a port-forwarding rule in their router to allow a new “incoming” connection from the cloud service to the camera, then you could claim that they are “granting passage” or “allow through” the firewall. But since 90%+ of wyze users do not know how to (or even want to) setup port forward rules, that is EXACTLY why wyze chose to have the cameras make that outgoing connection so that they can BYPASS or GET AROUND the users firewall,
If this doesn’t clear things up for you, then I don’t know what will, so I guess you will just have to continue thinking something that is incorrect.
(update: it should be obvious, but just in case you don’t realize this…when I say the “IP of the camera”, it is actually the IP of the router, but in the context of the service connecting to the camera, the two are the same)
Okay at this point I’m just skimming because you are so off base it almost comes off as trolling. But once more into the breach (no pun intended).
No, you can’t. I’m beginning to think you’re under the impression that devices on home LANs have public IP addresses. They don’t.
The P2P service doesn’t know your camera’s IP address. It knows your router’s IP address.
This is completely wrong. Buy a SOHO router. Hook it to your home broadband. All ports will be blocked.
Either you are trolling or don’t have the experience you claim.
The dynamic public IP addresses aren’t the issue. NAT is the issue.
This quote from Mr. Engineer is what you’ve hung your entire argument on. You took it out of context, as I tried to show you the first time. He had already indicated twice that the connection is initiated on the app, and he was talking about how the camera responds. He simply left out the word “back”! As in, “the camera is unable to connect directly back to your phone”. Please give it a rest.
Yes, I can, because I know my routers (public) Static-IP, I know my devices (private) Static-IPs, and I know how to route traffic. I simply did not feel the need to delve into the 27 steps that would be necessary to do it. Perhaps you may not know how, so you feel it just can’t be done.
No, I don’t think that, I just know how to use the NAT.
You speak about it in other parts of your post - why pretend it doesn’t exist here?
100% Accurate. But I would argue that is a distinction without a difference (at least in this case). If it makes you happier, I will amend/“correct” that statement to read “…for the SERVICE to know the IP where it can find your camera.”. Better?
Clearly you have never run a server or service “on” the internet, else you would know how wrong that statement was. If you block all unsolicited traffic - nothing would get in because ALL incoming traffic is unsolicited until the connection is established. This is precisely why servers have an OPEN “listening port” (e.g. port 80), to watch for incoming connection requests.
As a typical/average user, you can probably get away with blocking everything because nothing (legitimate) is trying to connect with you (your network , devices, et al), so the scorched-earth method IS a viable option for you. Not so much for those of us with an internet presence (as simple and humble as it may be).
But I’m always willing to admit when and if I am wrong - so I ask you with honest interest - If every network on the internet blocked all unsolicited traffic, please explain to me how I would be able to do something as simple as viewing a website? What is the sequence of events from your perspective? (That is not rhetorical - I would very much appreciate an answer to that).
NAT you say? I thought you said it was to get past the firewall?
But I’m flexible - let’s discuss dynamic-IPs and NAT.
So in the absence of a centralized service (which was the scenario being discussed), and where everyone has dynamic-IPs, how exactly would someone on a P2P network find anyone else? Should we just scan every IP on the internet until we find the one we are looking for?
As for NAT, nothing outside your network gives a flip about your NAT. Regardless of what might be trying to connect with your network (or anything on it), “it” doesn’t know nor care if you use NAT or not. That’s not to say you don’t need NAT, maybe you do, maybe you don’t, but it is not a requisite part of the equation, and certainly not a consideration for anything outside your LAN. (You are expected to keep your own house in order).
I will agree that I can be a stickler for details, especially when we are discussing the details. I’m funny that way.
While it may just be semantics to some people, the camera doesn’t “connect” nor “connect back”. It simply accepts (or rejects) the incoming connection request. Those are distinctly different things.
UPDATE 2022.03.04.18.42: (just adding - not editing)
I find myself in the awkward position of probably needing to retract that statement. MrEngineer was finally able to beat a *little* sense into me with regard to the required sequence of events, so yes - I will concede that the camera may in fact be the one that ultimately establishes the connection between camera and app/phone. My analogy below may sound good, but it is not representative of the situation here, and so it does not apply.
Think about your phone - when someone calls you, and you accept the call, do you imagine your phone is now responsible for "connecting back" to the person calling? Of course not. It simply acknowledges and accepts the incoming request and allows the connection to be made.
In closing, having made it through your whole post - I would like to revisit one comment of yours…
I know I can get a little harsh, and even rude (occasionally) in my replies, but I do not think I’ve ever accused anyone of trolling just because I disagreed with them. NOTHING I have said is inflammatory, irrelevant, or offensive (at least I hope I haven’t actually offended anyone).
If I wanted to offend anyone, I would simply mention that my issue is just a low-tolerance for stupid - but I recognize that as being inappropriate, offensive, and not at all helpful - so I normally refrain, and instead I engage in debate and conversation.
Just because my statements, thoughts, and ideas conflict with your picture of the world, that doesn’t make me a troll. It just means we have different opinions, view-points, and experiences.
As for my “experience”, let me start off by clarifying that I do not now, nor have I ever claimed to be some networking guru. I HATE networking. But it is a necessary evil in my line of work.
Do I run my own network? Yes. Do I have WAN accessible servers and services on that network? Yes (8 of them if we are counting). Did I personally develop and write some of those services? Yes.
So I ask you - does my meager experience actually doing that which we are talking about count? Or does your experience of NOT doing ANY of that (based on your own comments) somehow trump my experience? Inquiring minds want to know.
UPDATE 2022.03.04.18.53: (more adding - still not editing)
Okay, that last paragraph was a little harsh and a little more than self-righteous - sorry about that. Additionally, I should have also pointed out that I recognize that the services I've written do not function the same way, and should not be taken as me being an expert by any stretch of the imagination. But that does not mean I am speaking from a position of zero experience, it just means my experience is not as applicable here as I would like to think, and may in fact be 'corrupting', or at least influencing, my point of view. That being said, my experience in this general area is exactly how and why I know this is not the only way to get this job done.
Happy trails.
Hi Mr.Engineer - Thank you! You bring up a few points that I either glossed over or didn’t consider/address. And some of it does make me “re-think” how this all works together.
I think we agree that the service does need to use the outgoing connection established by the camera (to the service) to facilitate communications.
It was my belief that it used that initial connection to create new secondary connection(s) with the camera(s), that in turn would get handed off to the the requester (user/app/phone).
Now that was a bit of an eye opener for me when I typed it out, because it made me realize one of my talking-points is at least inaccurate, and possible down right wrong.
Specifically, I’ve said “the camera never connects with anything” (except the service). That is at the very least technically inaccurate. Establishing that initial connection to the service is not the only time it needs to do that. If my scenario is correct, then when the service contacts the camera to open a new connection, it is the camera that has to initiate that new outgoing connection (on a new/different port), and, exactly for the reasons you (and others) have stated - to avoid needing to navigate the firewall. (Though I still contest that is just a benefit, not it’s primary function - to serve as a globally-accessible single-point-of-contact for all your cameras).
Until now, I have envisioned that secondary connection being established between the camera and the service, which then gets handed off to the app/phone/user (by the service). Problem with that is that I do not think you can open a secure/authenticated connection on one IP and then just transfer it to a completely different IP. Seems problematic for the security among other things (but I’ve been wrong before - recently).
A different way for that to go down, which I admit makes more sense and is far more in-line with what you have been saying, is for the service to make the request on behalf of the app/phone/user, in which case the camera would then make the secondary connection back to the app/phone/user directly. (You have no idea how hard that was for me to type). I still have issues thinking of that in terms of the camera making the connection since it is really just responding to a request, but I will concede that details and terminology aside, I was wrong. (The app/phone/user may have been the one to initiate the process to create the connection, but that is NOT the same as actually opening/creating the connection - and THAT is where I was failing to connect the dots).
(See “Customer” - I CAN admit when I’m wrong!)
Okay, just one more…
In your analogy (and I do like them btw), you really are circumventing the bar’s security. In this case, there is a real security-breach meaning the bouncer failed to do his job. (He should be watching ALL the doors, like a good little firewall, err, bouncer).
The analogy breaks down when you consider that all traffic (in both directions, on all connections, for all interfaces, devices, and services) must pass through the firewall, no exceptions, and the traffic on this particular connection is allowed to pass through as legitimate traffic.
In a (functioning) firewall, there is no backdoor. You can not circumvent it’s security, otherwise it wouldn’t be a very good firewall. As far as I am aware, the DMZ is the only way to allow traffic in or out without passing through the firewall, but I very seriously doubt anyone here is using that, especially for this purpose.
That’s the point I was trying (and failing) to make.
It may be possible that people are thinking because they didn’t have to do anything to the firewall to make this work, that that somehow equates to the firewall not paying attention or something. I assure you the firewall is fully aware of that traffic, and is dutifully analyzing every packet. If you have a router that lets you analyze the traffic, you may be able to see this in action in it’s GUI/web-interface.
But, as I am always willing to admit, I could be wrong! I would love for an actual networking-engineer to pipe in on this one;
Is this type of traffic considered to be by-passing the firewall, circumventing it’s security? Or, does the firewall simply allow it to pass? (Or is it something in between?)
(and per your UPDATE - I got you. We’re on the same page there - just don’t tell Customer - pretty sure he/she thinks I’m a moron and I don’t want to disappoint).
I think many of the issues were caused by you thinking in the 10% use-case context of self hosting and Customer and I are in the 90% use-case context of wyze’s cloud service.
AMEN!!! I feel the exact same way and I think you and I should start our own cost effective camera business that functions off you personal LAN first and only pushes to remote servers when use is needed to connect and view remotely… Also, produce some outdoor PTZ cameras with all the cameras having the capabilities to connect via CAT5 ~ CAT7 cable for certain areas where wireless is not the most effective solution and therefore allow all our customers the FREEDOM of use of their cameras THEY PAID FOR 100% and well market it that way with even a slightly higher price than wyze cams but absolute access and control with a few more hardware features and I think we could be fairly successful. Its not like Wyze is going to do it…
