Skip to content
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

Open
Mike5357 opened this issue Jan 27, 2025 · 20 comments
Open

Lorex 2K doorbell connection fails; port closed? #4

Mike5357 opened this issue Jan 27, 2025 · 20 comments

Comments

@Mike5357
Copy link

Mike5357 commented Jan 27, 2025

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

'01/27/25 14:15:21.0396' INFO BaseClient:46 -> Starting to connect MQTTClient, Should connect: True
'01/27/25 14:15:21.0396' INFO BaseClient:27 -> Initialize DahuaClient
'01/27/25 14:15:21.0396' INFO BaseClient:46 -> Starting to connect DahuaClient, Should connect: True
'01/27/25 14:15:22.0396' INFO MQTTClient:55 -> Trying to connect to MQTT Broker...
'01/27/25 14:15:22.0397' INFO DahuaClient:43 -> Connecting
'01/27/25 14:15:22.0397' DEBUG selector_events:64 -> Using selector: EpollSelector
'01/27/25 14:15:22.0783' INFO MQTTClient:93 -> Connected to MQTT broker with result code: Success
'01/27/25 14:15:29.0420' ERROR DahuaClient:63 -> Connection failed, Error: [Errno 111] Connect call failed ('xxx.xxx.xx.xx', 5000), Line: 55
'01/27/25 14:15:29.0421' INFO DahuaClient:68 -> Disconnected, will try to connect in 30 seconds

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

@Mike5357
Copy link
Author

Port scan:
Image

@baudneo
Copy link
Owner

baudneo commented Jan 28, 2025

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.

@baudneo
Copy link
Owner

baudneo commented Jan 28, 2025

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 docker build -t baudneo/dahuavto2mqtt:latest .

I'll add an env var to configure which port to connect to vto devices as well.

@Mike5357
Copy link
Author

I tried changing the port and now just get:

'01/28/25 11:55:57.0939' INFO DahuaAPI:323 -> pre_login:: Preparing first message to elicit a challenge...
'01/28/25 11:56:52.0944' INFO DahuaAPI:265 -> Server sent EOF message

@baudneo
Copy link
Owner

baudneo commented Jan 28, 2025

Not good, hopefully it's something simple rather than their efforts to lock it down

@ferreira520
Copy link

Hey @baudneo , any updates on this? I'm encountering the same error as Mike. Appreciate your help with this!

@baudneo
Copy link
Owner

baudneo commented Mar 11, 2025

I tried playing a bit but didn't get anywhere. I should have some time tonight to try again.

@baudneo
Copy link
Owner

baudneo commented Mar 12, 2025

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

  1. I dont use the lorex doorbell. I had an incident where my wifi went down and the lorex wouldnt record to the sd card while the internet was down. I replaced it with a reolink POE.
  2. I only did some basic digging to get the lorex working reliably in the first place, I dont have knowledge about dahua and their systems, so I dont really know where to look or commands to try and poke around.
  3. Lorex did this on purpose, so they may have made it harder to get in.

@esand
Copy link
Contributor

esand commented Mar 12, 2025

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

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

@esand
Copy link
Contributor

esand commented Mar 12, 2025

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?

@baudneo
Copy link
Owner

baudneo commented Mar 12, 2025

request_data = {

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.

@esand
Copy link
Contributor

esand commented Mar 12, 2025

IME, we need mitm comms between a lorex NVR/lorex cloud and the device.

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.

@baudneo
Copy link
Owner

baudneo commented Mar 13, 2025

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.

@baudneo
Copy link
Owner

baudneo commented Mar 13, 2025

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.

  • 10.0.1.2 is my phone
  • 10.0.1.134 is the 2k doorbell

Image

The other option is to try and mitm (proxy) using socat and a self signed cert with proper CN, if the lorex device does not verify SSL, the connection is encrypted but we can MITM. If the device does cert verification, we need to inject our own cert so we can decrypt the comms. Either way, it is a lot more involved.

@baudneo
Copy link
Owner

baudneo commented Mar 13, 2025

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

@ferreira520
Copy link

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!

@baudneo
Copy link
Owner

baudneo commented Mar 15, 2025

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.

https://reolink.com/product/reolink-video-doorbell/

@ferreira520
Copy link

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!

@ferreira520
Copy link

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 ?

@baudneo
Copy link
Owner

baudneo commented Mar 17, 2025

I don't use scripted or homekit secure video. I use zoneminder and frigate and they work great. The Hass reolink integration allows for all events from camera and configuring it.

Image

Image

Image

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants