Argus 2 and other battery camera #91
Labels
Comments
|
Duplicate of #30 |
|
To summarise #30. Battery cameras use a different protocol (UDP) Which we do not currently support. Not because we can't do it but because none of the developers had a camera to reverse engineer. Someone has kindly sent @thirtythreeforty a camera so we can start work on it. Unfortunately we have yet to really have the time :(. |
|
Not sure where you got that info but my Reolink Argus Pro and Argus PT can be pinged on my local net. I can see they received a local network address from the DHCP of my router.
On Sunday, November 22, 2020, 3:45:32 PM EST, surfzoid <notifications@github.com> wrote:
Hi
I would like to find an solution to watch the video of my reolink argus 2 camera under linux, wath i know is , those came use only an uid , send to an amazon p2p server whose send back video and info to the oficialy reolink windows or android client.
Can you implement an function of connect with only uid ?
If needed, i can provide an wireshark file packet .
thank
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub, or unsubscribe.
|
|
Lanwalker is quite right that there must be an ip address else messages will not be route-able in general. I suspect surfzoid attached his client app via autoconnect, in which case the app only reports the uuid (from the front screen, see pic). However the ip is still assigned and viewable in the advance setting of the app (see other pic).
What I am not sure about is how the command and control works on the battery model. For example does it shutdown the network card periodically and only wake up to poll the amazon server for updates that have been cached into their server. Perhaps you (lanwalker) can tell me if you can connect a client over ip only maybe even with the camera blocked from accessing the outside network. |
|
Hi, if i remember corectly, to connect my first argus 2 i used the sharing wifi of my Phone and then scan the qr code on the Cam with the Android app, but this is only setup for link app and cam, after Wath, the stream use the amazon p2p streaming server, aws |
|
For me that's logical the fact of the Cam have ip, this need to have internet conection and send mail notification, but the main goal is video stream. If there is french People here, can we exchange technical info ? It should be more accurate |
|
it isn't more easy to reverse the android application/apk? |
|
At this point I am not sure reverse engineering the the android application will be any easier. We already have most of the protocol understood. Regardless only one developer has a battery camera at the moment and they are busy at the moment with other things. If you are interested in helping with the addition of UDP based cameras pull requests and just general discussions are more than welcome. You said you could give us wireshark dumps? If you can connect an official client and give us the dumps during login and streaming that would be good. But please remember that these dumps contains password and things. |
|
oki, so i could send the dump packet file to thirtythreeforty in private |
|
If you want to not send passwords and make the dump public the best way would be to start the dump after the client has logged in and don't press any of the setting just stream and quit |
|
I think we already have a few dumps provided in #30 anyway though so this is more to do with not enough time at the moment |
|
yes the most important packet is the authenticate one, to get amazon acces, i also can set an tempory stupid passwaord, but there is already uuid who is the most important part when conecting to the aws author server |
|
Do we have to connect to the aws server is there no way to connect directly over lan |
yep, my usage is cam at work and view at home, with an linux rpm based distro, mageia, so, no reolink client, after, argus2 don't permit to save video in an loacal pc via samba, ftp or other, reolink cloud don't aviable in europe (reolink don't care about the fact they say argus 2 as an security cam but not in fact) in issue #30 jdillenkofer say is had sucess to view localy the camera |
|
Right neolink works by exposing a camera on the local network to rtsp. It is effectively a reolink to rtsp translator. If you can connect to the camera locally at work then neolink can provide an rtsp link to it. You can then connect through normal rtsp client software. Does this setup satisfy your needs? |
|
well if am i rigth, at this time, neolink don't work with argus 2 camera? |
|
It appears jdillenkofer already has UDP BC cameras working. This python code would need to be re-implemented in Rust in Neolink. |
|
Not at the moment no. I am looking over the dumps now actually: Normal header for tcp is starts with You can see the normal magic |
|
jdillenkofer also modified the dissector for UDP use: |
|
Oh cool I was just writing a dissector update. jdillenkofer's one needs updating to our new dissector format though so I'll try that |
|
Interesting some of the udp packets have extra obsfucation... Will need more work sigh |
|
Fortuantly jdillenkofer seems to have done most of the heavy lifting so can look into that :) |
jdillenkofer as say in his comment of issue #30 fell free to use his code in neolink |
|
I have not tried to use these cameras just on my own LAN... it would defeat my purpose of even getting them if they couldn't get out of the local area network... but I do like the fact I do not have to mess with my router like I had to do with my web server both to receive and send information with the UID.
I do not use the Reolink ' cloud '... I did set it up initially to test it but they only let you use it for a month for 1 camera and I do not have the funds on my Social Security Disability to finance their operation<G>.
I send emails out and have notifications turned on for my Microsoft system using their outlook client on the PC and on my dumb android ' smart phone ' and it is fairly quick surprisingly.
These cameras do record to a PC without the memory cards but need the memory cards when recording for the smart phones ?? Still a lot of questions I am digging for answers for yet... sure wish they would release interface code for their cameras like my interface system vendors did when I was programming, it would save us all a lot of headaches<G>... I had to read and write to hardware memory locations when I first started working with that type equipment with assembly, pascal ( The Germans loved Pascal for some reason ) and C.
That would be an interesting test if somebody had a place like in a deep basement to shield the WiFi signals from the devices. I used to have access to that type of test hardware ( $60,000 HP Logic analyzer with multi-channel high speed oscilloscopes and dedicated packet capture devices for the networks ) many years ago and a very old warehouse building with 3 foot thick walls of lead glaze coated bricks that our maintenance guys hated me for when they had to run wire or fiber optics thru them so my network equipment could get access<G>
|
|
I rather do not like the UUID, it works only because it phones home to the reolink server. The client connects to the server and then the server sets up the hole punched connection. I rather prefer to setup home assistant or similar software on my local network to at act as the gateway to the WAN with reolink cameras only able to talk to neolink. But to each their own method. Anyways I shall try and get the udp working at some point jdillenkofer work will help for sure. But I have other commitments too. |
|
Are you sure about that ? I do not use the Reolink cloud and have had no problem with remote connections yet.
|
|
Yes, you do not need to subscribe or have cloud for this service. There is no magic way of bypassing a NAT/firewall with some UUID. Relink set up the hole punching and run it for free.
|
I don't know how, but he use only uuid and send broadcast to local network only, 255.255.255.255 see for that his udp layer code file |
|
Client broadcast 255.255.255.255 on some port: "Hello I am looking for UUID=AUUID please respond to me if its you" I'd have to look at the details of the code for its exact code but its usually a broadcast to learn the ip and then use that from then on |
|
@luizbon was the PC running Neolink on bare metal or was it in Docker? It seems the common story is Neolink in Docker has poor performance and unstable. |
|
Rust is quite nice in that it makes it obvious when you do a copy (it calls it a clone) and a share (a reference). Most of the time it is shared and not copied. On the neolink side there will probably only be 1 copy at a time (maybe two if it needs buffering but I still try to keep it at one where ever possible), on the gstreamer side I am not too sure. |
I was running on bare metal as well. |
That sounds like a great idea.
Just tried with a laptop running Ubuntu 18.04 live connected via LAN (100mb only but should be enough), and still the same. |
sudo docker run --rm -p 8559:8554 --volume=/usr/local/etc/neolink_config.toml:/etc/neolink.toml quantumentangledandy/neolink:rpi-docker sudo docker run --rm -p 8559:8554 --volume=/usr/local/etc/neolink_config.toml:/etc/neolink.toml quantumentangledandy/neolink:udp_docker root@raspberrypi:/home/super# docker run --rm quantumentangledandy/neolink:rpi-docker date Of course, you are not interested in dealing with the problems of configuring someone else's Docker, but answer the question - if the problem is in my Docker, then how are two releases installed so strangely, with rpi-docker, the time of image is correct, but not with udp_docker? Maybe the variables of these assemblies are described differently in the Dockerfile? |
|
Everyone stay civil please... Reverse engineering is difficult enough, everyone is working in good faith, we're all on the same team here. @VikeDragon I think you're either running an outdated image (remember to (Side note, issues like these are why Docker can be frustrating to support (hence the readme disclaimer) even though it's more convenient for users.) |
I'm sorry, I didn't mean to offend anyone. Perhaps it is translation difficulties. I'm just trying to figure out how it works. I understand you perfectly, because I myself earn my bread by programming, however, I have a different specialization and I don't understand everything with Docker. And I realize how difficult it is to switch from the main task to all sorts of distracting questions.I interviewed all my friends and climbed many forums with this problem - everyone does not understand how this can happen. While I'm not distracting you anymore, I'll try to use your recommendations. I am very grateful to you for your work! This is really a great job! I really wish that everything turned out as you planned! |
|
Sorry if that came over a little strongly. The docker image is just a standard Debian:bullseye image that we put neolink on. I don't think we do anything with it to brake the datetime. There are various things that can be done to force the time to be in sync with the host. Things like mounting Perhaps we should see if it's something to do with the base image. The reason I do not think it is to do with the docker variable used in the DockerFile is that it works on my own rpi with the same image. But maybe we should try a clean setup:
docker system prune
docker pull quantumentangledandy/neolink:udp_docker |
|
@Morphy99 Here's a build that will save the stream to file too. ( It will save to the current working directory (of neolink) a mkv file named It will only save this write while an rtsp client is connected. This is a debug feature so it is quite inflexible and the place it saves to is not configurable. Might write an export command at some point to do this properly but not until this is all done |
|
@QuantumEntangledAndy you have the patience of a saint, kudos for taking the time to explain things out of the remit of this project, for myself included! The recorded file is the same as the stream I'm afraid. Here are samples of both apps. Neolink: I had to change the extension of the neolink.mkv to mp4 so I could upload it. |
|
Thanks I'm glad we manage eliminate the network component it helps pin down the error. I've been thinking about it the last day and I have a theory for its source. But it's not UDP related (although udp makes it have a stronger effect than TCP) I'll try and explain UDP packets can come in any order. Because of this we buffer and rearrange. But we have to read from the buffer sequentially. Let's says we have up to packet 50 sequentially. We also have got packets 54-60 and 68-90 We send resend requests for packets 51-53 and 61-67. Camera resends these packets and also 91-100 During all this time we are effectively paused because we timestamp based on the clock as it leaves the rtsp pipeline and we can't add to the rtsp payloads until 51 arrives. Then when the missing packets finally arrive we now have all pakcets 50-100 without any delay. They all get pushed into the rtsp as fast as we can read bytes. These frames all get nearly identical timestamps on the clock. I've exaggerated a bit because it probably only 5-10 frames out of sync at a time. But this might be our source. It's not strictly speaking the UDP layer that is wrong. Udp layer is doing its job fine. Timestamping should be handled in the Bc layer that these packets represent. I had a go at making neolink use the timestamps the camera gave us a year ago but it didn't work as expected because of how we share the same rtsp media across all clients. If I use automatical timestamping (from the clock) then each client gets its own clock based timestamps. If I do it manually this happens: Client 1 connects and the timestamping starts at 0:00 5 mins later client 2 connects. But they don't get packets timestamped at 0:00 the pakcets they get are shared with client 1 so the stamps are 5:00. Client 2 gets these frames timestamped thinking they are future frames it needs to play later. Client 2 complains for 5 mins about no data until 5 mins have passed and it now thinks it's time to start playing that frame it got 5 mins ago. To do this I need to change how neolink sends and configurs the rtsp layer. So we don't share the buffers and I need to keep track of each client's starttime so I can stamp the buffers differently for everyone. It's not a small job I'll see what I can do but it might take me while and it won't be a part of the UDP PR but a separate timestamp related PR |
|
Another behaviour I notice is when neolink can connect to the cameras straight away, the stream works. |
|
Not sure what's causing that issue with the relogin. The camera and gstreamer parts are kept quite independent so that the source of gstreamer data should not really matter. It's just bytes coming from somewhere as far as the rtsp is concerned. I'll have a think about it and review the pipeline. |
|
What error do you get with the rtsp connection when it's a relogin? You could try it with export GST_DEBUG=3Set so that gstreamer prints out it's logs. But gstreamer prints a lot of logs which makes it difficult to read. |
|
Sorry for the late reply |
|
After getting a stable connection I setup a daemon and let it run for a whole day. |
|
currently neolink is setup to connect all the time and for it to stream the video all the time even when your not watching it. We can parse motion detection just fine. Neolink can be set up to post messages to an mqtt server when motion is detected but this feature is not in stable neolink yet. |
|
I've created an issue to track the power usage at #204. Is there anything else that might need addressing? |
|
Thanks @QuantumEntangledAndy. |
|
@luizbon and any other folks who have been running this software for the past month--how has the battery life fared on your cameras? And has the software been stable with the connections and the streams? Any feedback would be appreciated, thanks. |
|
I'm thinking of getting an Argus 3 Pro, was wondering what the current status is on support? |
|
Im also wondering what is the state. According to the documentation, battery powered cameras should now work. |
|
Tested today with an argus pt but no luck. I made a wireshark dump of a login with the windows Client to try to see if I can figure it out |
I'm in the same boat. Going to take a look at the initial exchange on the network using the dissector when I have time to try and figure out what's missing. |
Try this fork: quantumentangledandy/neolink:refractor-gts_rework. Still some battery drain issues, but its almost there. |
|
If you have any contribution please do add it on my fork. This original repo is mostly unmaintained now. We have more features and support more cameras there. |
Nope, same connection issue. I've verified the UID and u/p to make sure it's not that, but it looks like I'll have to take the time to debug the connection... |
|
The feature I think you need isn't in that branch. Gts_rework is quite far behind. Please try with latest. And ensure you put in both uid and the addr. If you supply a uid and an addr using latest it will enable an extra connection mode that will bypass the need for local discovery. Also be aware that by using docker you have extra complications because of the network bridges may block the udp broadcasts. |
@QuantumEntangledAndy Sorry for the OT, but has the issue with cameras not waking up from sleep been fixed in the main branch (i needed to switch from main to gts_rework to fix that a few weeks ago)? |
|
I think so. You'd need to check it yourself to be sure. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Hi
I would like to find an solution to watch the video of my reolink argus 2 camera under linux, wath i know is , those came use only an uid , send to an amazon p2p server whose send back video and info to the oficialy reolink windows or android client.
Can you implement an function of connect with only uid ?
If needed, i can provide an wireshark file packet .
thank
The text was updated successfully, but these errors were encountered: