neolink
neolink copied to clipboard
Argus 2 and other battery camera
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
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 <[email protected]> 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 https://support.reolink.com/hc/en-us/articles/360007010033-What-is-Reolink-P2P-Server
Do we have to connect to the aws server is there no way to connect directly over lan
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. Under the UDP layer it just looks like standard BC modern protocol.
This python code would need to be re-implemented in Rust in Neolink. https://github.com/jdillenkofer/camera_proxy/blob/master/src/baichuan_udp_layer.py
Not at the moment no. I am looking over the dumps now actually:
Normal header for tcp is starts with f0 de bc 0a
The udp one start like this:
10 cf 87 2a b0 02
00 00 00 00 00 00 00 00 00 00 32 05 00 00 f0 de
bc 0a 01 00 00 00 2c 07 00 00 00 00 00 01 01 dc
You can see the normal magic f0 de bc 0a
start a little later. Currently we haven't worked out what these extra bytes do but it is on the todo list.
jdillenkofer also modified the dissector for UDP use: https://github.com/jdillenkofer/camera_proxy/blob/master/wireshark-dissector.lua
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 :)
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 add an option to conected bridge to cam through internet should be good, take also in consideration, the setting file of jdillenkofer don't need ip, uid is enought
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 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.
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
255.255.255.255
is broadcast to everything on the local network. It will work something like this:
Client broadcast 255.255.255.255 on some port: "Hello I am looking for UUID=AUUID please respond to me if its you" Camera: "Oh that's me I have this IP = MY.IP.IS.THIS please contact me there"
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
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.
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
It is in: def discover_device(self):
Sends a discovery packet and learns the IP just like the official client can.
Might be nice to add discovery to neolink but it will be local only since broadcast is restricted to local networks and we don't talk to the reolink servers for hole punching
Just static assign the IP on the camera or reserve an IP on their DHCP server. UID really doesn't serve much purpose on the local network, just use the LAN IP.
Yes static ip on local is more than enough. I just wanted to try and clear up this misconception about UUID... I think I didn't help though :( so sad
But argus2 on local network don't provide an standard stream, i never get vidéo with vlc, gstreamer or other, so there is something more
They provide a stream of BC formatted data you cannot get it to go to vlc without a translator like neolink. That's neolink purpose to transform a BC stream into a rtsp stream.
yes, bashuan protocol is the main job of yours hacking , it is nice, but, for battery cam they pass through aws whose seem to be more standard, so is there any chance of reolink encapsulate it in their protocol for the battery cams, or they "convert", so, for not local watching stream, but from my linux box through internet, do you think there is a way to get this "normal" stream not directly from the cam but from the amazon server by providing the uuid ?
Battery camera do not have to pass through aws. We already have dumps of them talking locally. Neolink talks locally to the camera translate to rtsp its then a standard stream you can read and send elsewhere.
yes, bashuan protocol is the main job of yours hacking , it is nice, but, for battery cam they pass through aws whose seem to be more standard, so is there any chance of reolink encapsulate it in their protocol for the battery cams, or they "convert", so, for not local watching stream, but from my linux box through internet, do you think there is a way to get this "normal" stream not directly from the cam but from the amazon server by providing the uuid ?
If your cam is at home/work you would want Neolink running on a device at home/work connecting to the cam on the LAN. You could then use VPN to access your LAN remotely.
Or you could port forward on your home router to get access, but BC device security is extremely weak and you should not expose them to the internet. Neolink security also may not be suitable for exposing to the internet.
I do not believe anyone has looked into the UID connection protocol. It almost certainly exposes the same weak security of BC devices and should simply be disabled. UID hole punch connection via Reolink servers(AWS) is available on almost all BC devices not just the battery ones. The battery cams do not appear to be significantly technically different to other BC products. They are just optimized UDP/TCP, packet loss resilience etc for internet data transfer instead of LAN data transfer.
I just emailed Reolink support ( [email protected], [email protected] and [email protected] ) asking about the ' UID ' and if it does go thru external servers and to explain the process if possible. It sometimes gets a quick return, sometimes it takes them a couple of days of bantering to get anything out of them<G>
Let us know what they say. But the answer likely depends on the technical knowledge of the representative.
You should already be aware of the difficulty with NAT because I think you mentioned that you had to set up port forwarding on your router before. If getting through a router was as easy as a UUID why don't we all just use that for everything? The answer is we can't use this technique (hole punching) without a middle man to facilitate the connection.
Please do read up on NAT transverse and hole punching. It's used in a lot of locations like video calls and multiplayer video games.
Perhaps you could also look at the link posted before it mentions that the register UUID on the sever and RELAYs connections when what they call p2p fails. In all likelyness this p2p is a p2p setup through hole punching
I guess the ' UUID ' just didn't register since it is called a ' UID ' in the user interfaces.
I am still hoping Reolink will ' explain ; it to make it clearer.
http://www.internet-computer-security.com/VPN-Guide/NAT-T.html
Thank you. Still getting myself back up to speed... a lot has changed in 20 years <G.
Regarding NVR RLN8-410 UID:
NVR init: NVR does DNS for p2p.reolink.com (in my case response was 54.210.7.156)
Data between NVR and Reolink 54.210.7.156 is UDP. NVR contacts Reolink at port 9999 from port 38991 Reolink respond to NVR at port 38991 from port 9999 NVR contacts Reolink at port 58200 from 38991 and continues to do this every 10 seconds from here Reolink contacts NVR at port 38991 from 58200 but only the first time and not every 10 seconds after.
Data payload appears to have a magic of 3a cf 87 2a (2a 87 cf 3a?). All data in both directions use this magic. After magic appears to be 4 byte payload size which is always 20 bytes short of payload size. This likely indicates a 20 byte BC header in the payload. 4 bytes, always 01 00 00 00 1 byte incrementing message handle. 1 byte always 03 2 bytes always 00 00 4 bytes no pattern noticed, all 4 bytes always different data. Payload looks encrypted with chunks of same data in multiple different messages, which to me indicates this is likely text/xml with a single scramble key run over it like other BC messaging.
UID connection from NVR side: Many messages between Reolink and NVR occur using the same ports, magic and format as before.
UID connections from client side: DNS lookup of apis.reolink.com (52.5.228.193 3.224.113.94) Establishes a very Brief TLS 1.2 connection with Reolink. Then soon enough my client has switched to a direct connection to the public IP 54.210.7.156 The data between the client and 54.210.7.156 uses same magic and format as before.
There appeared to be a terminate packet of 28 bytes: 20 cf 87 2a f8 00 00 00 00 00 00 00 00 00 ...
Don't suppose you could send a packet with the encrupted data. I want to see if it's the same encryption used for the UDP data or BC XML. (Will need header for the key too)
3a cf 87 2a is the exact same magic used for UDP connections. I've just finished my BC dissector for UDP that can decrypt those. Is this really public? Because it's not really encrypted again. I'll post my UDP dissector and you can check it out too.
UDP dissector is in #94
It is across the public internet. It is just the BC UDP protocol!
Adding these cleared up everything to all the servers and the XML is all readable. -- UID DissectorTable.get("udp.port"):add(2018, bc_protocol) DissectorTable.get("udp.port"):add(9996, bc_protocol) DissectorTable.get("udp.port"):add(9999, bc_protocol) DissectorTable.get("udp.port"):add(18430, bc_protocol) DissectorTable.get("udp.port"):add(18432, bc_protocol) DissectorTable.get("udp.port"):add(38991, bc_protocol) DissectorTable.get("udp.port"):add(58200, bc_protocol)
The TLS section that appears to prime the UID connection is maybe a harder hurdle to break in to random devices as it may be difficult.
But eavesdropping a connection is simple.
A user connecting to their BC device via IP vs UID gives near identical eavesdropping protection. In that both offer only the most basic protection that has been fully defeated by multiple projects now. The UID or IP, username and password is easily obtained from the messages.
For random attacks from those that can not eavesdrop. Direct IP does require a port forward which if not restricted does leave the BC device open to brute force and other exploits. UID would require brute force attacks to the p2p/AWS servers. I assume you would need UID, username and password before the p2p servers would give you the direct connection details.
Thank you for that information. Yes, security from packet capture can be a serious problem and our networks need to be aware of it.
Do the battery powered units have the ability to use https ? I thought browsers were not supported on those ( possibly for that reason )...
I have actually debugged access database issues across the WAN with packet capture years ago... somebody moved a database on a Dearborn server but many users and routines were still trying to use them and when they hit those routines, their forms either hung up or gave an error but for some reason ( possibly database security or Novell network issues ), it didn't really give the correct reason.
Thank you. Troubleshooting network connectivity issues as we brought different technology into our international automotive assembly locations ( Vax, Novell, HPUX, WinNT, mainframe, printer servers, video information systems,... etc ) is how I was pulled from building and or assisting many of our test and control programming projects... too much time needed invested tracking those issues down for me to dedicate some of my time helping out our new system designers and maintenance groups. I sure miss those challenges... damn this physical disability crap and the companies that infringe on us by keeping us out of the job markets for that reason but will not admit to it.
I am not sure who wanted updates on this but Reolink support finally replied.
Dear Robert Gamble, Thank you very much for your reply. In that case, you cannot access the cameras via UID if there is no internet access. You can only access the cameras via IP address, instead of UID. Anything we can help you, please do not hesitate to keep us informed. Have a nice day! Best Regards Reolink Support Team – Ivy
I think their reply is technically incorrect because you can do discovery using the uuid on the local net to learn the IP with broadcasts. It's what jdillenkofer does in his program. My I ask what you wrote to them? It would help with the context of their reply. But I suppose I shouldn't be surprised with this sort of answer
I would not regard UID as something you can connect to. UID is simply used as a method for a client to automatically learn the IP path to the device.
The UID function has a different method of informing a client the IP path if the client is local or remote to the device.
UID exists in OSI layer 5 and 7. I would consider you connect to things in Layer 1, 2 or 3. Layers 4 or higher no longer connect devices, they manage data and offer functions.
This is the scenario I gave them... loss of internet connectivity ( just like if the wire is cut, power outages, etc.. ). We had to have multiple routes for communications ( in case ) for our systems backup when dealing with our automotive customers ( Ford, Honda, Toyota, etc ) with the use of internal and external servers and databases as our systems matured in the automotive industry. I had to install modems and 800 numbers as a possibility could shut down our production and our clients production ( and Ford charged us about a million a day if we shut them down )
Sally, Thank you. We are trying to work on local applications inside a LAN with no internet access to the outside world and wondering how these will work in that environment ? Can our computers still access these cameras thru our isolated local area network ? This is a security concern since there will not be any routers connecting to a path for the cameras to reach outside and the clients ( cell phones and PCs ) will be trying to watch the cameras from our isolated LAN.
"will be trying to watch the cameras from our isolated LAN." The Reolink support agent answered wrongly. The UID method of informing a local client of the devices IP would continue without internet access. That method for local devices is via broadcast discovery and has no dependency on the internet.
Thank you.
See, this is the type of information you have to dig out of people. When I leave Florida for my doctors in Ohio, I want the cameras watching this place and I'll be remote for possibly 2 months ( or longer.. last trip was an unplanned 14 months due to vehicles and the Chinese Virus crap ) at times. My neighbor has access to my additional WiFi router and can access my network if my AT&T router stops working for some reason ( or his ). I want him to be able to watch over the place while I am gone too ( he can use the cameras to watch his back entrances ). I use TeamViewer for remote control of my network(s) either here in Florida or at my girlfriend's Ohio location ( where I am going to install the next batch of cameras when I return this spring )... a neighbor in Ohio also has access to my additional WiFi router so they can do things up there also and may even get a few of these cameras for their place as another viewpoint.
I am one of a very few national admins for the United States Minutemen ( we used to have a structure on facebook with nearly 4000 groups and pages that was destroyed on August 19, 2020 at about 4:30 PM EST... it took me and a few others about 7 months to create that in 2011-2012 and with no previous notification, FB destroyed all of our data that was not backed up to our private web server we used as a common point for all the groups and pages ) so I have a lot of friends and members looking for security solutions right now with all the destruction and violence going on. We now have spread our internet presence among a lot of the alternate social media sites to prevent that total destruction of our structure(s) in the future ( We call MeWe.com our 'new' home.
I am physically disabled ( got smashed by a drunk in a F150 4x4 ( 45 mph ) from the left side while coming home from work on my motorcycle ( 25 mph ) ), 82nd Airborne Artillery ( 1977 ), Test and Control Systems Engineer / IT Analyst now on Social Security Disability because no company would hire me after our company sold out and the buying company sold our assembly lines to Mexico, South Korea and China... so this is what I do as support for the US Minutemen since I can not physically do much else for our country in my condition. I am now trying to get back into the programming I used to do ( along with everything else in my free time<G> ) so I can implement these cameras into our systems as well. We have members in RVs, out in the deep boondocks and many other places so I get asked questions and I hunt the answers down and hopefully solutions as I can... and some just can not be resolved with canned software like the Reolink clients used with these cameras. ( the reason I am reviewing all these different conversations on Github and other places ) as I pull my software development system(s) together.
http://iii.thruhere.net/Social-Media-Sites/united_states_minutemen.html
Wireshark is good for showing the layers.
I had the Novell version called Lanalyzer and often told our corporate network management where some of our network problems were... even debugged a stupid access database with an excell part and found out somebody had moved one of the linked databases and had not updated the remote plant clients setup... our Dearborn offices tried but many did not even know what you were talking about. When Lear bought that place and tied their WindowsNT network in thru our routers their broadcast storms of print servers they placed across that link about killed our network and I went and pulled the damn cord from the router until they fixed it since they wouldn't give me access to it to fix it myself.
Wireshark is good for showing the layers.
For Light think i use Sometime the gnome network analyser https://etherape.sourceforge.io/
To grab video or frame from Reolink battery camera is my wish. If contributor need argust2 or some other model I am willing to send him.
Hi, here it s some info i found on the net : an unluky windows dll https://www.wasteofcash.com/BCConvert/ an good description of the BC protocol https://www.wasteofcash.com/BCConvert/BC_fileformat.txt there is an generic android client for all BC camera : steamview : https://wasteofcash.com/BCConvert/Downloadlinks.html and more an question, is ispy can acces on our cam ? : https://www.ispyconnect.com/download.aspx
Hi, here it s some info i found on the net : an unluky windows dll https://www.wasteofcash.com/BCConvert/ an good description of the BC protocol https://www.wasteofcash.com/BCConvert/BC_fileformat.txt there is an generic android client for all BC camera : steamview : https://wasteofcash.com/BCConvert/Downloadlinks.html and more an question, is ispy can acces on our cam ? : https://www.ispyconnect.com/download.aspx
wasteofcash is my website and Neolinks active developers are well aware of the content I have written.
Hi, here it s some info i found on the net : an unluky windows dll https://www.wasteofcash.com/BCConvert/ an good description of the BC protocol https://www.wasteofcash.com/BCConvert/BC_fileformat.txt there is an generic android client for all BC camera : steamview : https://wasteofcash.com/BCConvert/Downloadlinks.html and more an question, is ispy can acces on our cam ? : https://www.ispyconnect.com/download.aspx
wasteofcash is my website and Neolinks active developers are well aware of the content I have written.
haha i made an good joke then :-)
Definitely well aware of it :) Thank you for all your good work @twistedddx !!
From the logs on ispy it seems it cannot access BC camera directly, it works on generic rtsp cameras and ONVIF, so it should work if neolink does the translation for it as the middle man. Personally though I prefer to setup mine with something like homeassistant or zoneminder or some other nice and free and open source software to manage the cameras.
@QuantumEntangledAndy and/or @twistedddx: are y'all interested in trying development for Argus? If so would you like for me to set up my Argus on a VLAN and get you access to it? (You can have a VM on the network too)
@QuantumEntangledAndy and/or @twistedddx: are y'all interested in trying development for Argus? If so would you like for me to set up my Argus on a VLAN and get you access to it? (You can have a VM on the network too)
idea is good, but vlan will block broadcast.
@surfzoid how do you mean? Neither the VM nor camera will be aware they're on a VLAN. (They can have internet access.)
@QuantumEntangledAndy and @twistedddx i trying the folowing very interesting basic test : first get the two soft here : https://medium.com/level-up-programming/how-to-reverse-engineering-an-android-app-be5835f6fa1e and test them on this apk (the oldest i found) : https://apkpure.com/reolink/com.mcu.reolink/download/217-APK?from=versions%2Fversion We can see BC work, P2P ect :-)
@surfzoid how do you mean? Neither the VM nor camera will be aware they're on a VLAN. (They can have internet access.)
i spent lot of hours to have argus 2 and jdillenkofer prog work through vlan (vpn) because the cam conect with broadcast and random port but why not
More simply, don't you have icq, discord or other chanel where to discuss?
@QuantumEntangledAndy and @twistedddx i trying the folowing very interesting basic test : first get the two soft here : medium.com/level-up-programming/how-to-reverse-engineering-an-android-app-be5835f6fa1e and test them on this apk (the oldest i found) : apkpure.com/reolink/com.mcu.reolink/download/217-APK?from=versions%2Fversion We can see BC work, P2P ect :-)
I have disassembled their app multiple times but apart from poking around in their aws buckets and finding the endpoints i wasn't able to do much. point is, you can't just hijack the endpoints, something else seems to be missing.
//edit: what i mean by that is they're doing lots of JNI stuff. So unless someone can decompile .so files the app isn't really any help. Same goes for the desktop app btw.
If you tell me exactly what you're looking for, I have decompiled their .so's before 😎. A spelunking adventure of "how does it work?" is probably too broad, but "I can't figure out how they're validating the endpoint" might be feasible to answer.
More simply, don't you have icq, discord or other chanel where to discuss?
We could make a Discord if everyone agrees it would be better, but I don't want to split the discussion between GitHub and Discord - empirically, GitHub is working pretty well so far. It's difficult for users to find info if you spread it out in too many platforms. I like the fact that GitHub discussions are easily searched by anyone.
The android.bc.api namespace sets up callback and commands. I assume the libBCP2P_API.so
is the corresponding JNI target, so having a decompiled version of that binary that would be awesome. my other interests would be libIOTCAPIs.so
libRDTAPIs.so
and libp2pc.so
Let me know how we can share the files and/or decompiled binaries. I don't think GH is the right place ;)
More simply, don't you have icq, discord or other chanel where to discuss?
We could make a Discord if everyone agrees it would be better, but I don't want to split the discussion between GitHub and Discord - empirically, GitHub is working pretty well so far. It's difficult for users to find info if you spread it out in too many platforms. I like the fact that GitHub discussions are easily searched by anyone.
yes your are right, i don't really no if in hacking and reverse everything can be public :-)
The android.bc.api namespace sets up callback and commands. I assume the
libBCP2P_API.so
is the corresponding JNI target, so having a decompiled version of that binary that would be awesome. my other interests would belibIOTCAPIs.so
libRDTAPIs.so
andlibp2pc.so
Let me know how we can share the files and/or decompiled binaries. I don't think GH is the right place ;)
i like .so file, i'm linux user and really would like to have an linux reolink client also, a way to handle motion detection and save video on pc rather reolink cloud :-)
The android.bc.api namespace sets up callback and commands. I assume the
libBCP2P_API.so
is the corresponding JNI target, so having a decompiled version of that binary that would be awesome. my other interests would belibIOTCAPIs.so
libRDTAPIs.so
andlibp2pc.so
Let me know how we can share the files and/or decompiled binaries. I don't think GH is the right place ;)i like .so file, i'm linux user and really would like to have an linux reolink client also, a way to handle motion detection and save video on pc rather reolink cloud :-)
well unless your linux is running on an armeabi/arm64-v8 device you won't be very happy with the .so files ;)
yes, need to recompil source of course
Vlan for the camera sounds fun to play with.
With regards to getting broadcasts to work it's not about the internet access that's important but the type of adapter. I belive the tap adapter supports multicasts but the tun adapter does not (possibly the other way round but it definitely works on one and not the other as I've had to use broadcasts over VPN in a previous project)
Yup, you'd need layer 2 bridging to make everything truly seamless. I'm using ZeroTier as the "virtual Ethernet" tap adapter. I'll shoot you an email with the details.
Yup, you'd need layer 2 bridging to make everything truly seamless. I'm using ZeroTier as the "virtual Ethernet" tap adapter. I'll shoot you an email with the details.
I'm interested by this détails because i switched ftom open vpn routed to bridge and broadcast don't work
I belive for broadcasts to work on openvpn all participants need to be using the tap interface. Is this the case? You'll probably also need things like client-to-client
turned on as well but I don't have a setup to test this.
I belive for broadcasts to work on openvpn all participants need to be using the tap interface. Is this the case? You'll probably also need things like
client-to-client
turned on as well but I don't have a setup to test this.
yes i did, i don't have lot of option on server side, because, openvpn is component of my isp box (french freebox one)
I thought the idea was a VM and camera within the same VLAN. There is no VPN between the VM and camera from what I read.
Connection method for access to the VM were not given yet but assuming ssh access to Linux or Team Viewer to Windows or VPN or whatever. The VM will see a broadcast, the connection to the VM will not prevent extracting dumps of broadcasts etc.
I don't think broadcasts will even play any significant role in getting an Argus to connect locally. jdillenkofer already did the hardwork in adapting Neolinks code to support BC UDP protocol, Neolink needs a port of jdillenkofer's code. The access to an Argus will be great for testing that the ported code actually works correctly.
PS. I am not the man for the job of writing Neolink code relating to Argus.
Yes I think that's our setup too SSH in or maybe SSH + VPN (mostly for the NAT transversal if done this way) and then play.. I mean reverse engineer... from the VM. I'm not sure if UDP uses a fixed port though maybe the UDP discovery will be nessecary to get the ports. Will need investigating.
Yes I think that's our setup too SSH in or maybe SSH + VPN (mostly for the NAT transversal if done this way) and then play.. I mean reverse engineer... from the VM. I'm not sure if UDP uses a fixed port though maybe the UDP discovery will be nessecary to get the ports. Will need investigating.
for the argus 2, the udp port is random
soudnlike to save battery life, the cam canot be pinged, have no port open, but, when i'm conect to it with the jd prog, the cam become pingable, so is, the udp broadcast the only way to wake up the cam ?
More simply, don't you have icq, discord or other chanel where to discuss?
We could make a Discord if everyone agrees it would be better, but I don't want to split the discussion between GitHub and Discord - empirically, GitHub is working pretty well so far. It's difficult for users to find info if you spread it out in too many platforms. I like the fact that GitHub discussions are easily searched by anyone.
re: chat, GitHub just launched a new feature called Discussions that might be more in line with this. I think I'll start to direct support requests over to Discussions. Features and bug reports (such as this ticket) can remain Issues.
Very Nice idea @thirtythreeforty, i would be glade to be include in the Discussions.
The android.bc.api namespace sets up callback and commands. I assume the
libBCP2P_API.so
is the corresponding JNI target, so having a decompiled version of that binary that would be awesome. my other interests would belibIOTCAPIs.so
libRDTAPIs.so
andlibp2pc.so
Let me know how we can share the files and/or decompiled binaries. I don't think GH is the right place ;)
@thirtythreeforty please let me know if you think it's worth pursuing the reverse engineering approach and need the binaries and/or the decompiled android code. Unfortunately I don't have the tools/licenses to decompile ARM-based .so binaries, so I would need your help here to proceed further.
Appreciate the offer - you can shoot me an email: [email protected].
I don't think we have a hard requirement on them, since jdillenkofer's tool is able to establish comms. But it would definitely be a good thing to have if you've already done some work.
I think how local connection works is known but I believe some Argus users are keen for remote connection. The VPN issue mentioned I think is a concern they will not be able to wake their device remotely via some VPN due to lack of broadcasts.
Reolink connection with UID via AWS servers is not known.
There is 2 distinct feature requests. Only the first is actively being worked on. The second still requires a willing dev to take on reverse engineering and implementation. 1)Local network support of devices that use BC UDP such as Argus - jdillenkofer has working code already 2)Remote network support via Reolink UID/AWS system - I don't believe much work has occurred.
There is 2 distinct feature requests. Only the first is actively being worked on. The second still requires a willing dev to take on reverse engineering and implementation.
- Local network support of devices that use BC UDP such as Argus - jdillenkofer has working code already
- Remote network support via Reolink UID/AWS system - I don't believe much work has occurred.
Great point. I had not really considered (2) because from my point of view the phone-home stuff is an antifeature that I firewall off. But I can see how some people might like it.
We'd have to be really careful with such an implementation. While Reolink would hardly care if users are streaming via their LAN, if Neolink were to start using their cloud, they might very much care about increased load, since Argus cams typically do not stream 24/7. How does this get reconciled with RTSP clients/NVRs that do expect to stream 24/7?
To summarize - I'm completely game for (1). (2) we will have to approach carefully, with a clear description of how it ought to work. At any rate, (1) is a prerequisite of (2).
In fact, the impedance mismatch of Argus cams' periodic streaming with NVRs' expectations of 24/7 streaming will need to be solved for LAN-only traffic, or else Neolink will drain cameras' batteries pretty quickly. So I think it would be good to discuss how that ought to work.
The new Reolink E1 Pro firmware update now has the cameras using ' wlan0 ' as their preferred names in the ROUTER... every one of them has the same ' name ' appended to their address in my AT&T ROUTER... the Argus units at least append their MAC address so every one of them are a different name in the DNS generated when the DHCP assigns the IP address to the cameras DHCP client. I just sent that piece of information to REOLINK SUPPORT.
I had a Reolink E1 Pro I bought from the Reolink site that would not eject the MicroSD card and had to return it... I purchased 2 other E1 Pro cameras from Amazon since the Amazon price was lower at the time.
The 2 cameras from Amazon showed the same name ( Wlan0 ) in the DHCP of my router but the camera from Reolink showed ( E1 ) appended to the address. Pinging the ' name ' ( Wlan0 ) would return one address the first time and the 2nd address the next time I pinged them... ( I noticed this because somebody was talking about using the DNS names of the cameras and this would cause confusion with the names being the same in the local DNS table of the ROUTER.
When I received the replacement E1 Pro camera from Reolink it must have had the older firmware revision and showed ( E1 ) appended. AFTER UPGRADING THE FIRMWARE, all 3 cameras now show ( Wlan0 ) and pinging the name ( Wlan0 ) gives me the different addresses ( and how the ROUTER selects which local IP address to use is unknown but it did not repeat the address but used the next ( Wlan0 ) in the ROUTER DHCP table ?? )
Most devices append their MAC to the preferred name the DHCP client acquires and helps identify the device for troubleshooting and also keeps it as a unique identifier in the local DNS system. I am not sure if the local ROUTER sends the local DNS names when the router tables are updated but this would cause some confusion since 3 devices on the local LAN DNS would have the same name if we only used their DNS NAMES in addressing them.
Just some interesting facts I found out in the last few days trying to figure out why the ' new ' E1 Pro camera quit responding to the network ( but still recorded to the local MicroSD memory card after pulling it and looking at the dates and times of the file names ) and Reolink support telling me to check the latest firmware and I updated the camera to the latest firmware on their site.
To the members 'testing ' the application and collecting network traffic... try isolating the Argus battery powered cameras on their own WiFi router with a workstation running Wireshark as the cameras are powered up. That may be a way of isolating the process used by the UID for those cameras. I'm not sure what you will see but at least you should have some fairly isolated traffic to sort thru. All the cameras have an IP address assigned to them, even with the UID being used for remote access thru the Amazon servers.
Too bad we can not get some cooperation from Reolink Support for the software routines of the newer battery powered cameras ( Yet )... I've asked and get the run-around and an older PDF file about accessing the older cameras thru IP.
Parts of the Argus cameras electronics must ' stay alive ' for motion detection and network responses... maybe some type of network request / query for a camera status would not drain the batteries too much ??
Reolink seems to have gutted some of the code compared to their other camera systems... just like the recent ' updated clients ' for the PCs and the Android phones took the ' zoom / magnify ' function from them ( and put in a stupid ' clip ' that MAGNIFIES an area in the picture <G> ).
I quit using the Reolink ' cloud ' due to costs and limitations of 1 camera free ( for a month trial period )... I have 2 outside Argus battery powered cameras ( on stationary, the other a PT unit ) and 3 inside E1 Pro units. I am on a fixed income ( SSD if you want to call below survival as any type of income <G> )
@Lanwalker you say:
trying to figure out why the ' new ' E1 Pro camera quit responding to the network ( but still recorded to the local MicroSD memory card after pulling it and looking at the dates and times of the file names ) and Reolink support telling me to check the latest firmware and I updated the camera to the latest firmware on their site.
Did updating the firmware improve its behavior on the network?