Posts by SpaceRat

    I am documenting this as I am doing it, if anyone is interested.

    Just to see how straight forward it all is. Having fun :)

    What am I up to? - My General Waffle Thread


    I don't want to disturb your "blog", so I'll comment on some of your statements here instead:

    Part 7: Softcams


    As I believe we can no longer install softcams 2 or 3 or 6 ipks. (I maybe wrong)

    That 6.Plus IPK was accidently spread, it's about the same as 4.3-r0 and should work, but no warranty if it doesn't.

    The actual feed contained in 6.Plus, 4.3-r0, 4.3-r1, 4.3-r2 is the very same, r1 and r2 just added some cleanup actions intended to make OpenATV switch from usage of SoftCAM-Panel to SoftCAM-Setup, as soon as the new feed gets installed, as SoftCAM-Panel is not able to handle the new CAMs.


    Sadly some users chose the hard path and messed around with the image to make SoftCAM Panel re-appear and then used a sledge hammer to control the new CAMs with old SoftCAM Panel or at least installed old and new CAMs in parallel ... with varying luck ... varying only between bad and tough luck though ...


    ... so instead of waiting for more users to lose their pay CS lines (One team member did, by running two oscams, each completely configured incl. the CS line, in parallel), I pulled the plug to the old SoftCAM Panel entirely.


    Originally it was meant to stay there for old CAMs for a bit longer to make the transition smoother: Old CAMs, e-g. from settings restore, would have continued to work in SoftCAM-Panel while newly installed ones would disable the SoftCAM Panel and enable SoftCAM Setup instead.



    Now about the versions 2 and 3 of the feed:

    That feed was taken down for a completely different reason ....

    ... the old secret feed was hosted in Russia and some day Vodafone (At least Vodafone in Germany and Austria) stopped routing to that server ... no idea if it was on behalf of Vodafone or some peer of them, but all out of sudden like 50% of our users were cut off from the feed, resulting in problems when trying to install additional plugins or performing online updates.


    As a large part of OpenATV users was affected, a new server had to be put up and the chance was used to clean up the old CAM mess on the feed.


    Actually, even if you install softcam-feed-universal 2 or 3, you should also get the current feed on performing "opkg update && opkg upgrade", as the only package that is still on the old server is softcam-feed-universal 4.3-r2 ... there is just no reason to give it a try if you can instantly have the correct one installed instead :)


    The fact that plenty of our users simply had no, zero, nil feed anymore thanks to Vaderphone was the reason why everything was done in quite a rush ... I did half of the work on it from a hotel room with Morse WiFi (On, off, on, off, on, off) on a business trip ...



    Er no. Where has oscam-atv gone. Er.. Do I use EMU, Stable or TRUNK.

    oscam-atv is quite a good example of why the old feed needed a cleanup ...


    Excerpt from the old feed:

    Code
    22.04.2019  13:21           881.246 enigma2-plugin-softcams-oscam-atv-emu-arm_1.2_11444-r783_aarch64.ipk
    22.04.2019  13:20           781.198 enigma2-plugin-softcams-oscam-emu-atv_1.2_11398_armv7a-vfp.ipk
    22.04.2019  13:20           522.084 enigma2-plugin-softcams-oscam-atv-emu-arm_1.2_11353_all.ipk
    22.04.2019  13:20           585.332 enigma2-plugin-softcams-oscam-emu-atv_1.2_9659_armv7a-vfp.ipk
    22.04.2019  13:20           588.132 enigma2-plugin-softcams-oscam-atv-emu_1.2_11353_all.ipk

    Note that you didn't even get the same version of oscam on two different architectures ... let alone that in some cases it was named "oscam-emu-atv" in some other cases "oscam-atv-emu".


    The IPKs on the feed were just a pile of losely collected packages created by volunteers for the machines they own themselves ... in this case for example, nobody with a Spark Triplex (sh4) cared about oscam-atv-emu, so there was no package oscam-atv-emu (or oscam-emu-atv) for sh4 ...


    If volunteer A had a mipsel box, he created an IPK for mipsel and if volunteer B had an aarch64 box, he created an IPK for aarch64 ... at different times with different versions of oscams inside and different sample configs.

    If you used boxes with different architectures, it was a grab bag if you could get similar softcams for all of them or not ...

    ... it was also entirely by accident if the CAM really worked on your box, because the feed covered versions 6.0 to 6.3 of OpenATV, not considering that they contain different libs ... so if someone compiled oscam with HAVE_SSL using a toolchain with OpenSSL 1.0.2, it would work on OpenATV 6.3 and 6.2, but probably not on 6.0 (Dunno exactly when OpenATV switched from OpenSSL 1.0.0 to 1.0.1 and then to 1.0.2).


    Now compare to the new feed:


    You will see that you get the very same version of oscam-emu for any architecture and any version of OpenATV you use the feed on.

    The version numbers at the beginning match the oe-a core, not the openatv version, so 3.4 is for OpenATV 5.3, 4.0 is for OpenATV 6.0 and so on.


    Each package will contain the same init.d script and the same sample config, so if you set oscam-whatever on your own aarch64 box and then you have to set up your parent's mipsel box, don't think about it, just use the very same oscam-whatever, just for mipsel instead of aarch64!

    This is the normal path "/etc/tuxbox/config" not "/etc/tuxbox/config/oscam-trunk"

    Yes and no ...

    Indeed, just "/etc/tuxbox/config" is the original default path for oscams config files, in so far you are right.


    On the other hand, OpenPLi and others have started years ago to add another directory level "name of oscam variant" to that path, so that users can easily have multiple different oscams with different configs on hand.


    The additional directory level allows the user to have

    • Multiple identical oscams using different configuration sets
    • Multiple different oscams using identical configuration sets (By either copying all files to or more sophisticated by making e.g. oscam-set2 a symlink to oscam-set1)
    • Multiple different oscams using different configuration sets


    Hell no, I know no real-world scenario in which this would be useful but neither do I know a second real-world scenario in which putting some "own"¹ oscam on the box makes any sense.


    The one scenario in which that makes sense (Thus "no second" instead of "no") is if someone built an oscam for you - probably after you paid him - that has additional keys compiled in, e.g. to decrypt certain channels using already paired cards or stuff like that.


    Neither does putting mgcamd and other legacy shit like that on the feeds make any sense in 2019 and I do it anyways, as there is demand for it ...


    ¹ Of course "own" does not really mean "own" here, in terms of "compiled myself", but just "extracting an oscam compiled with some broken toolchain from some silly 3rd-party IPK"

    The old feeds became unreachable for many users, depending on their internet provider.

    For that reason they were wiped, except the package for the new feed ...

    ... so if you install old feeds and perform an online update, your box will either get stuck (due to the feed being not reachable) or it will get an update to the new feed :)

    Using your own oscam is even simplier ...


    • Install any oscam from the feed (oscam-trunk, oscam-stable, oscam-smod, any will do).
    • Locate the file "softcam.<oscam you just installed>", e.g. "softcam.oscam-stable" in /etc/init.d and make a copy of it in the same place, changing the name of the copy to "softcan.<whatever you want your oscam to be named>", e.g. "softcam.oscam-own".
    • Once you select this new softcam "oscam-own" in SoftCAM Setup, it will start /usr/bin/oscam-own (so put your own oscam there) and expect its configs in /tec/tuxbox/config/oscam-own (So place your configs there if your oscam requires configs).
    • Once done, you can uninstall the oscam from step 1 again.


    You can repeat this with as many copies of "softcam.<oscam you just installed>" as you like.

    It will work for any oscam and most subvariants, definitely it works for NCam and most probably it works for doscam too.

    The recommended way of installing the OpenATV secret feed is typing this one line on a shell session on the box:

    Code
    wget -O - -q http://updates.mynonpublic.com/oea/feed | bash


    The easiest method of getting a shell session to the box is the "Terminal" in OpenWebif, but feel free to use puTTy or whatever you already use.

    That one-liner makes sure you get the latest version of the feed for your actual image version and architecture.


    No need to download the IPK, copy it to the box and installing it through GUI or shell when using the one-liner but you are still free to use an IPK, if you insist on it.

    Use version 4.3r2 or later in that case.


    The new feed supports OpenATV 5.3 through 6.3, that is "the last 5 versions of OpenATV".


    In OpenATV 5.3 to 6.1 you will only have one place to configure the CAMs, that is in "Menu -> Settings -> Decryption", because it would probably cause more problems to patch it into old versions of E2, while that hook in "Menu -> Settings -> Decryption" is just a plugin.


    Starting as of OpenATV 6.2 (Images 2019-06-15 and later), the softcams can be configured in three places:

    - "Menu -> Info Panel", just as before with softcam panel

    - "Quick Menu" (In most cases on blue key or long blue key), just as before with softcam panel

    - "Menu -> Settings -> Decryption and parental protection", as it is the most logical place to search at if you aren't already used to the other places


    The softcam panel was entirely removed due to user problems, e.g. one team member losing his line due to double logins (He had two oscams running in parallel, one through the new method, one through the old one), so to avoid problems, having both methods inside the image appeared a bigger problem than making a cut here.


    Installing the feed through older IPKs, like versions 2.0 or 3.0, will only get you an empty secret feed, except for one package: The new secret feed :)


    The new feed has multiple advantages:

    • All CAMs that can be built from source code (All OScams and Ncam) are built from source code using the matching OpenATV build environment, that means they perfectly fit the libraries inside the actual image.

      oscams on the feed for OpenATV 6.3 are built inside the OpenATV 6.3 build environment, oscams on the feed for OpenATV 6.2 are built inside the OpenATV 6.2 build environment, oscams on the feed for OpenATV 6.1 are built inside the OpenATV 6.1 build environment and so on.

      Most CAMs you can download from forums are simply built in generic cross-compiler environments that do usually not really contain the matching libs ...

    • All OScams and Ncam are built every night if their sources get updated.

      If you install oscam-trunk, you will always get the latest one with a maximum delay of 24h.

      For conservative users that do not want to live on the edge, there is oscam-stable, which will give you oscam svn11518 until there is some really important change in trunk and that change has proved being stable (By not being changed again within the next weeks).

    • Starting CAMs through init.d is more robust and stable than forking them as childs of E2 (That's why there isn't a "watchdog" anymore, it's simply not needed)
    • CAMs started through init.d are easier to maintain remotely

      You can simply start/stop/restart them from the shell

      Code
      root@quad4k ~ # /etc/init.d/softcam stop
      Stopping Softcam service oscam-smod: OK
      root@quad4k ~ # /etc/init.d/softcam start
      Starting Softcam service oscam-smod: OK
      root@quad4k ~ # /etc/init.d/softcam restart
      Stopping Softcam service oscam-smod: OK
      Starting Softcam service oscam-smod: OK
      root@quad4k ~ # /etc/init.d/softcam status
      Softcam service oscam-smod: Running.

      e.g. after editing config files.

      No need to mess around with "kill", "killall" commands or figuring out if you need to background the cam manually or if it will background automatically if you start it directly via shell.

    • CAMs started through init.d are ready when you are ...

      As the CAM starts early during boot, it has time enough to initialize card readers or server connections to decrypt instantly as soon as E2 can tune.

      Python CAM start added a delay, because starting the CAM didn't happen any earlier than tuning the startup/previous station