[HN Gopher] OpenIPC: Alternative open firmware for your IP camera
___________________________________________________________________
OpenIPC: Alternative open firmware for your IP camera
Author : danboarder
Score : 207 points
Date : 2023-10-08 16:57 UTC (6 hours ago)
(HTM) web link (github.com)
(TXT) w3m dump (github.com)
| elromulous wrote:
| OpenIPC really didn't mean what I thought it did.
|
| I was 100% sure it would be some kind of inter-process
| communication abstraction / framework.
| mikepurvis wrote:
| Yeah I think IPC has too much of an established meaning here.
| Something like OpenIPCam might be a little safer.
| efrecon wrote:
| A long time ago, I built a business around off-the-shelf IP
| cameras. The field was full of buggy firmware with enormous
| security holes (biggest I found was to be able to acquire
| pictures without even being authorised!). Hardly none of these
| firmware would get updated, they were abondonware right out of
| the package.
|
| Even though this doesn't seem to be entirely open, any kind of
| move into that direction is a bit of fresh air.
| the_biot wrote:
| OpenIPC is one of those projects where the core team is Russian,
| and their communication is Russian, and they use Telegram (or a
| bridge) for everything. As a non-Russian speaker you're pretty
| lost trying to contribute, and as a result they attract hardly
| anyone outside the russosphere. I've tried telling them they're
| artifically limiting their project, but was predictably ignored.
| This project has so much potential, but it will never be
| achieved.
|
| I've seen this before; projects like that tend to stagnate and
| die. Openinkpot comes to mind.
|
| BTW not a rant against Russians; open source projects do best
| when they have a lot of contributors from across the world, and
| that means English.
| 0xDEADFED5 wrote:
| First of all, software projects in general tend to stagnate and
| die.
|
| If you really want to contribute, I'm sure you can figure out a
| way. You can always fork it and do your own thing, that's
| potentially a contribution in itself. It's a little selfish to
| expect other people to become fluent in technical English and
| rearrange their project to suit your desires.
| nirav72 wrote:
| For those curious if their devices are supported. The list is
| here:
|
| https://github.com/OpenIPC/wiki/blob/master/en/guide-support...
| snvzz wrote:
| Finally, a way to decide which IP camera to buy.
| [deleted]
| bradknowles wrote:
| Wow. I've only heard of two of those brands of cameras.
|
| And I didn't recognize any that were among the known thousands
| of re-brands/sub-brands of HikVision and Daihua, both of which
| have been implicated in the suppression of the Uighur people in
| China (and which have been banned by the NDAA, see
| https://ipvm.com/reports/ban-law).
| saidinesh5 wrote:
| The interesting thing about this project is that they're
| repurposing cheap ip camera hardware to work as surprisingly
| decent, low latency digital video system for fpv drones:
|
| https://m.youtube.com/watch?v=wZAHkWHfBF4
|
| Mostly a continuation of the OpenHD project. But it's quite
| promising.
| [deleted]
| bastard_op wrote:
| Having looked into this myself prior was mostly asking for
| disappointment. Getting a random Chinese IP camera to convert to
| open firmware is great in theory, but the problem is actually
| buying a camera or 10, or buying more over time.
|
| You never really know what hardware ships internally at any given
| time, ie what SoC a camera _really_ is. They change frequently in
| random Chinese manufacturers with internal SoC hardware update
| with constant improvement (in their margins at least), if
| reported by someone at a point in time, buying the same model a
| 6mo-1yr later you cannot expect the same model number to be the
| same hardware.
|
| It is rarely stated on a site selling them what SoC they use, or
| the vendors sites, assuming you can find and/or translate
| anything usable, or if the vendor is even still around more than
| a few months under that name. Therefore there is no repeatable
| source of products you can get reliably across time without
| simply testing a sample and hacking your own as you go.
|
| I really wish someone would take initiative to sell/resell a line
| of camera hardware with openipc or other open firmware on them.
| It's a business opportunity sorely missing with nothing to offer
| home/business users ip cameras with open sterile and guaranteed
| secure firmware vs. random pure Chinese jank.
| squarefoot wrote:
| When in doubt, I take for granted that every camera with closed
| firmware contains malware that phones home or waits dormant to
| be used to steal sensitive video+audio or to take part in a
| botnet, which already happened several times. The solution as
| of today is to put a firewall in between that blocks any
| traffic to the LAN and from the outside, except from trusted
| applications. There are many multi ETH port mini PCs that can
| be repurposed as firewalls so that the video surveillance
| subnet can be physically separated from the rest by connecting
| all cameras (for obvious reasons I wouldn't take WiFi into
| consideration) to a switch, possibly with PoE support.
| matisseverduyn wrote:
| I bought a box of these on Amazon Prime Day / Black Friday in
| 2019 (6 for ~$7 each), and connected them all to an isolated
| / offline router.
|
| They come with a web interface for setup/control that uses JS
| (which was easy to reverse engineer [@]) to interact with the
| device's API (not as easy to figure out).
|
| -- also stripped the wifi, mic, and speakers, and put the
| chip+camera in a new casing (waterproof outdoor outlet cover)
| --
|
| I then bought a few more from various sources (different
| colors / casings) and, even though they all had slightly
| different web interfaces, under the hood, they were all
| running roughly the same code under the hood (MIPCM). Some
| didn't come with a web interface, but still responded to the
| same requests.
|
| [@] If you're/anyone's interested in the camera API wrapper-
| code, happy to send it via Twitter.
| neodypsis wrote:
| > I really wish someone would take initiative to sell/resell a
| line of camera hardware with openipc or other open firmware on
| them. It's a business opportunity sorely missing with nothing
| to offer home/business users ip cameras with open sterile and
| guaranteed secure firmware vs. random pure Chinese jank.
|
| Manufacturers could do it themselves, but the license prohibits
| commercial use.
| KennyBlanken wrote:
| > OpenIPC source code is released under one of the most
| simple open source license agreements, MIT License, giving
| users express permission to reuse code for any purpose, even
| as part of a proprietary software. We only ask you politely
| to contribute your improvements back to us. We would be
| grateful for any feedback and suggestions.
|
| Edit: since people are arguing with me, the text I quoted is
| right of the main page for OpenIPC, and everything here is
| MIT licensed too: https://github.com/OpenIPC
| tpmx wrote:
| Except they're not releasing the source of the core parts.
| They say (or at least very heavily imply they are), but
| they aren't. See other comments.
| neodypsis wrote:
| > Majestic code while is not open, provides unprecedented
| performance and capabilities for a wide range of hardware.
| The author of Majestic streamer is looking into
| possibilities to open-source the codebase after he secures
| enough funds to support further open development. You can
| help to make it happen sooner.
|
| Source: https://openipc.org/
| KennyBlanken wrote:
| I can't find that text anywhere on the page (the word
| "Majestic" literally doesn't appear anywhere).
| chefandy wrote:
| It's right before the "Why OpenIPC Firmware?" headline.
| wtf_is_this wrote:
| Couldn't agree more with this comment. I've had exactly the
| same frustration trying to get cameras months/years apart that
| will work. You have to open each one up and hack it yourself
| (and OpenIPC may support it or not), and nowadays they are
| protected from loading firmware easily (tiny UART/debug ports,
| disabled UBoot loader, etc.).
|
| I also wish there were an option for someone to buy cameras
| with open HW/SW, to get away from the random cloud services
| they want you to open your network up to with cheap cameras.
| dang wrote:
| Related:
|
| _OpenIPC: Alternative open firmware for your IP camera_ -
| https://news.ycombinator.com/item?id=35975383 - May 2023 (1
| comment)
| snthd wrote:
| https://openipc.org/support-open-source
|
| >It's Open Source
|
| >Price of the Firmware
|
| >The right to use the OpenIPC firmware and its components is
| granted to all users free of charge and only for personal, non-
| commercial purposes. If you are interested in using OpenIPC for
| your business projects, please contact our team.
| neilv wrote:
| I wonder whether they really want open source, or this is a
| commercial effort that's trying to leverage 'the community' to
| get the hard part of the engineering for free.
|
| For really wanting open source, the OpenWrt model has seemed
| pretty good, and the nature of the engineering work seems
| similar. Some hardware vendors use OpenWrt for their firmware,
| which seems to help the mainline open source OpenWrt also have
| good support for that hardware.
| papercrane wrote:
| That's confusing, because the GitHub repo has an MIT license.
| Is there some kind of secret sauce they add to the compiled
| binaries that the non-commercial clause applies to maybe?
| orra wrote:
| Their "Magestic" app, which sounds like it provides key
| functionality, is closed source.
| snthd wrote:
| Another IP Camera thread:
| https://news.ycombinator.com/item?id=36447024
| fcpk wrote:
| Totally random question there but... Any recommendations of
| cameras that are currently easily available(say amazon,
| aliexpress, etc) and support this while having good/verygood
| image quality?
| s1gnp0st wrote:
| Seconded. I previously bought some that I thought were
| supported, before finding out that they are not. It'd be great
| to know whether anyone has had success with particular
| hardware.
| tpmx wrote:
| Seems like e.g. (most of) the sensor drivers are binary blobs.
|
| Some examples:
|
| Ambarella S3L:
| https://github.com/OpenIPC/firmware/tree/master/general/pack...
|
| Some HiSilicon chipset:
| https://github.com/OpenIPC/firmware/tree/master/general/pack...
|
| Edit: A smaller subset of sensors have some code here:
|
| https://github.com/OpenIPC/sensors
| alufers wrote:
| Yup, also the userspace application that does the actual
| streaming is closed-source as well:
| https://github.com/OpenIPC/majestic
|
| (The git repo is for bug reports only, no source-code there)
| jauntywundrkind wrote:
| Oh man I didn't realize that when I last ran into this
| project.
|
| I wonder how hard it would be to run your own streamer
| pipeline or whatnot on these things? How far a starting place
| do we get when we install our own Linux; do peripherals
| (camera networking) work or is there a bunch of special sauce
| in userland running half the hardware?
| scottlamb wrote:
| > I wonder how hard it would be to run your own streamer
| pipeline or whatnot on these things?
|
| Agree with the_biot: The actual streaming component is not
| too hard. If this were the biggest problem, I'd be thrilled
| to contribute to (or just write) an open source streaming
| server to complement my open source NVR. [1] The driver
| situation is indeed a bit harder--these things don't just
| have mainline Linux support with v4l2 for the video capture
| and encoding. Or open source drivers of any kind to crib
| from AFAIK.
|
| The biggest problem IMHO is that there just aren't any good
| cameras to buy, even completely ignoring the software
| aspect. I want a camera that:
|
| 1. doesn't support genocide. Nothing that involves Dahua,
| Hikvision, or Huawei. See IPVM articles on the subject. And
| a _lot_ of available cameras are relabeled Dahua /Hikvision
| stuff and/or use Huawei components.
|
| 2. is legal for sale / authorized for use in the US. (See
| the Secure Equipment Act of 2021.) Mostly this excludes the
| same companies.
|
| 3. has good night mode performance: IR/day switch, a sensor
| that is at least 1/1.8", reasonable resolution (somewhere
| from HD to 4k).
|
| 4. has an "eyeball" or "turret" form factor rather than
| "bullet". The latter seems to really attract spiders, so
| you end up with a really nice video of a web...
|
| 5. supports PoE.
|
| 6. is weatherized (IP66 or so).
|
| 7. is reasonably priced.
|
| If you ignore #1 and #2, there's some nice hardware out
| there, but I'm not willing to do that. If you ignore #3,
| there are a few options (GeoVision, maybe Reolink, maybe
| Hanwha.) If you ignore #4 and #7, there might be a couple
| (Axis, maybe Hanwha.) Nothing that ticks all the boxes.
|
| Hard to get excited about investing a lot in the software
| when the hardware isn't there.
|
| [1] https://github.com/scottlamb/moonfire-nvr
| the_biot wrote:
| That's the problem right there: the Linux kernel
| situtation. As OP noted they just use the vendor's (long
| outdated) Linux kernel, with the vendor's (typically crap)
| kernel drivers. They just don't clean up that situation in
| that project, let alone try to mainline the drivers. It's
| where I thought I could help, but... see my other post on
| why that didn't work out.
|
| With mainline-supported cameras using a standard API, a
| userland application that does streaming and all kinds of
| neat stuff is just much more doable IMHO.
|
| They're not the only project that builds a ton of userland
| stuff on top of a rotten kernel foundation: oe-alliance has
| _nine_ distros downstream from it, and hundreds of
| supported hardware platforms. As far as I can tell it 's
| all ancient vendor kernels with un-upstreamable drivers.
| protastus wrote:
| That's the rotten situation with embedded Linux. Nearly
| all silicon vendors ship a highly modified kernel with
| proprietary drivers and firmware. Nothing gets
| upstreamed. The code quality is low and the changes are
| not architecturally sound, so patches wouldn't get
| accepted by OSS maintainers in their current state.
| Vendors end up with countless forks of the kernel, system
| libraries and system services (at least one for each
| SoC), which they don't maintain because it's too much
| work (of course).
|
| Security in this space is a absolute disaster.
| stefan_ wrote:
| They are using the ancient vendor kernels too, anything from
| 3.x to 4.x to 5.x which sort of defeats the purpose. Most of
| those are pretty small too, they would be better off reversing
| them..
|
| Strong Android homebrew firmware vibe.
___________________________________________________________________
(page generated 2023-10-08 23:00 UTC)