-
Notifications
You must be signed in to change notification settings - Fork 1
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Lorex 2K doorbell connection fails; port closed? #4
Comments
Hi, I switched to reolink but still have my old lorex 2k doorbell. I can get it set up this evening and make some changes to the code to try the new port. With any luck, it's just switching port # to get things working. |
If you want to try something quick: Edit https://github.com/baudneo/dahuavto2mqtt/blob/master/clients%2FDahuaClient.py#L50 this line to port 35000, build a new container with that modified code and try it. So clone repo, edit file, make sure you're in the root of the repo dir, then issue I'll add an env var to configure which port to connect to vto devices as well. |
I tried changing the port and now just get:
|
Not good, hopefully it's something simple rather than their efforts to lock it down |
Hey @baudneo , any updates on this? I'm encountering the same error as Mike. Appreciate your help with this! |
I tried playing a bit but didn't get anywhere. I should have some time tonight to try again. |
It seems to me they changed how to login. Currently, after updating firmware, when we send a bad login request to get data needed to create a good login request, as soon as we send it data, it closes the connection (EOF). Im still playing around a bit, but....
|
Could you use a packet sniffer to watch the traffic when using the app to log in to see what it sends first? The interesting thing is, the app needs to work with both the old and new firmware, so maybe it's simply that the login method you're using isn't intended and they just "fixed" the firmware to work the way it was intended, and the app itself has always logged in the "correct" way. I wish I could afford to help more, but I only have the one doorbell and rely on it functioning in Home Assistant too much to be able to update the firmware. If it could help, I could see about possibly sniffing traffic from the app to my doorbell as it is right now (working firmware). |
Just thought of this - normally a port change is usually because something changed with the protocol that would render any attempt to be backwards compatible impossible. Do you currently do any kind of TLS negotiation when you initially connect to port 5000? Maybe the new port is TLS first and that's why it's killing the connection as soon as you try? |
dahuavto2mqtt/clients/DahuaAPI.py Line 349 in 8b91e3d
It seems to be a pretty standard login. The premise is we send a bad login and the device replies with data we need to send a good login. Fwict, this login method is standard dahua stuff, but I don't have the knowledge to say for sure. If we were sending bad data, I would expect an error msg (there is logic in the callback for error msgs), instead the device closes the socket (aka "fuc* off") and we need to start again. I'm assuming it's looking for a certain data struct before it starts talking at all. Pkt caps between comp and device won't be much help because the device isn't sending any data at all, just closing the connection. IME, we need mitm comms between a lorex NVR/lorex cloud and the device. Edit: In regards to your SSL hypothesis, it would be sending data to let us know its expecting a handshake or whatever to start the exchange. FWICT, it's just sitting there waiting for the proper data and closes the socket after a timeout delay of not receiving the proper data. |
Sorry, that's what I meant. I think I should be able to set up intercepting all packets to the doorbell in my network and just have it run very briefly as I load up the app so it should be the only thing communicating with it. I'll give it a shot when I have some time (not until end of this week) and see if it shows anything useful. |
That may be the best bet, capturing packets from the app to the device. I have some omada APs that do pcaps, I'll see if I can get the filter syntax correct to capture packets between my phone and the device as well. |
Not great so far, seems maybe they have gotten smart and instead use the cloud as a relay no matter what. I assume they have done that to keep comms encrypted using TLS/SSL. The sort of goods news, if that assumption is correct is, there are ways to inject your own TLS/SSL certs into android apps, but it is extremely involved. I interacted with the device through the lorex app and all I can see in the pcap is an ARP frame.
The other option is to try and mitm (proxy) using |
Yeah, it is using the cloud only, even when on local LAN, the app uses the cloud as a relay to talk to the device. Edit: I'll try and isolate the device and see if I can force local comms |
Hey everyone, thanks again for helping troubleshoot this issue. The new firmware update seems like a headache. You mentioned earlier that you're using a Reolink doorbell—could you let me know which model it is? If it's the PoE version, will it be compatible with the Lorex NVR? Also, does the Reolink image display in portrait or landscape mode? I really appreciate your help—thanks again! |
If the lorex NVR allows any onvif compliant device to be added, it should work. If lorex only allows lorex devices, then it wont. I had nothing but trouble with lorex CS and their products, YMMV. I would highly recommend setting something like ZoneMinder, Frigate, BlueIris, etc. up as a local NVR, you have so much more control and options that way, there is a learning curve with each system though. I use both ZoneMInder and Frigate for my setup, but ZoneMinder is my 'production' NVR. There are 2 versions of the POE doorbell with different aspect ratios (black is 4:3, white is 3:4, hardware based FOV). There are also different hardware versions which use different frequencies to communicate with the wireless chime boxes. v1 uses 433 MHz and v2 uses 915 MHz, the v2 allows for up to 5 chime boxes to be paired with the doorbell. The reason I mention the chime stuff is that it only used to allow 1 and we were all coming up with esp based solutions to add mechanical chime and other audible alerts. If you run custom NVR and Home Assistant, there are multiple ways to enable two-way talk, so you dont ever need to use the reolink app after initial setup and there are no cloud relays involved. All local and secure. |
Thank you for the information! I currently have this NVR: [https://help.lorextechnology.com/series/n845-series-4k-fusion-wired-nvr-system]. Right now, I’m using SCRYPTED to integrate all my cameras into the Apple Home app, which also enables recording to iCloud. Since my Lorex 2K doorbell is no longer sending alerts in Apple Home, I’m looking for a replacement. I’m debating whether to get a native HomeKit-compatible doorbell or go with something like Reolink and continue using Scrypted. Im looking for 2K or higher resolution, but it's very limited at this time. I’ll need to do some more research on this. Thanks again! |
Hello again! I set up the Reolink 2K Doorbell (White) using Scripted, and everything worked perfectly at first. But now, I’m not receiving motion or doorbell press notifications in the Apple Home app—only in the Reolink app. Have you experienced this issue? Would you recommend Home Assistant instead ? |
I've just installed a Lorex 2k Doorbell (Model B451AJ) and have been having trouble getting it set up in mqtt, namely every addon I've been trying including this one results in an error similar to:
'01/27/25 14:26:01.0558' ERROR DahuaClient:63 -> Connection failed, Error: [Errno 111] Connect call failed ('xxx.xxx.xx.xx', 5000), Line: 55
I've enabled API_DEBUG as suggested on the Supported Models page, but still no luck.
Full Log (loops repeatedly):
From what I've been searching, it sounds like newer firmware versions may have locked down port 5000 and now use port 35000? Would this change be possible, or am I just doing something else wrong?
Edit: Current Doorbell firmware version is
2.820.010000000.28.R.20240520
The text was updated successfully, but these errors were encountered: