Jump to content


SpaceRat

Member Since 6 Apr 2012
Offline Last Active 02 Oct 2023 20:50
*****

#1368002 no way to connect to ssh via authorized_keys

Posted by SpaceRat on 27 July 2021 - 16:59

What could be stolen from the box? Is it hiding gold and diamonds? :) Apart from the emulator and the playlist, there's nothing else to steal. :))

[ ] You have understood networking.

 

The box could serve as a zombie inside a botnet and/or be abused to attack the rest of the network.

It is very unlikely for Joe Average to have his home network split up into networks for "secure" devices and "insecure" devices separated from each other.

The box could trace any network packet passing by, even if not designared for the box but from e.g. your tablet to your online banking.

 

For botnets, see:

https://en.wikipedia...Mirai_(malware)




#1194834 merge requests for PLi's git

Posted by SpaceRat on 29 April 2020 - 16:26

 

Following standards is inevitable.

 

 

Tabs are the de facto standard in E2 code.

 

There is almost no active developer left, why NOW waste the time to touch 90% of all code just to change indent?

 

There are myriads of bugs and quirks in E2, why not FINALLY fix at least SOME of them instead?




#1194806 merge requests for PLi's git

Posted by SpaceRat on 29 April 2020 - 16:06

Personally, I prefer Tabs.

Spaces simply don't make ANY sense.

 

Tabs are much easier to handle, because in Python it's a big difference if you have 7 or 8 spaces after a line with 8 or 7 spaces, while counting the silly spaces is a major PITA in nowadays editors due to non-fixed width fonts.

And you do not always have editors at hand that do auto-indenting for you.

 

Tabs are everything: Lean, clean, easy to read.

 

And they are much more comfortable when writing code due to the silly "indentation also replaces { }" policy in Python: I would rather like to delete or add ONE tab rather than having to add/delete 4 spaces (yikes).

 

The devs of E2 decided against spaces for a reason ...




#1050301 Neues Cam Plugin

Posted by SpaceRat on 4 May 2019 - 17:33

Zum CCcam 2.3.8 steht hier eigentlich alles, was man wissen muß, um ihn nicht haben zu wollen:

https://www.digital-...m-2-3-8.473896/

 

Ich hatte ihn mal für OpenATV abgepackt, dann aber doch wieder auf 2.3.2 reverted.




#839456 merge requests for PLi's git

Posted by SpaceRat on 4 February 2018 - 14:01

PS, can you post a guide, yml for that?

Well, for simple projects it's no rocket science, the travis.yml for oscam-smod contains only

language: cpp
script: ./config.sh -E all && make
For OpenWebif its a bit more sophisticated but still nothing that isn't more or less self-explaining:
language: python

python:
- "2.7"

install:
- pip install cheetah
- pip install twisted
- pip install pyopenssl
- pip install bandit

script: 
- python -m compileall -l . -l plugin -l plugin/backport -l plugin/controllers -l plugin/controllers/models
- cheetah compile -R plugin
- python testsuite/evil_eval.py

after_success:
- bandit -r plugin -f html -o bandit.html
- ./create_ipk.sh
- export PKG=$(ls -1 *.ipk)
- mkdir Rel
- mv "${PKG}" ./Rel
- mv bandit.html ./Rel

deploy:
  provider: pages
  local_dir: Rel
  github_token: $GITHUB_TOKEN
  skip_cleanup: true
  target_branch: gh-pages
  on:
    branch: master
For enigma2 you would need something like

script:
- git clone oe-core
- cd oe-core
- something to make oe-core initialize a build directory for a selected machine
- cd builds/MACHINE/blah
- source env.source
- bitbake -f -c compile enigma2


#824039 Receiver no longer time synced

Posted by SpaceRat on 6 January 2018 - 12:51

In my situation, with a 3 min lag between the DM7020HD with OpenPli 4 and correct time, how do I setup a NTP update that will actually correct the time on the DM7020HD?
 
 
BTW this is a recent issue as for many months/year I never had a time synchronisation issue with any of my STBs and their overnight recordings. I would say it changed during the last 3 months or so.

I would say: Impossible.
You are talking about OpenPLi 4, which is EOLed.

So actually you are just confirming that this problem has always existed.

Note: The problem to exist doesn't necessarily mean it has to occur always and for everybody (Which is what sometimes makes it somewhat hard to understand for some why it needs to get fixed anyways).
Reports of STB clocks being minutes or even hours ahead/behind (But mostly ahead) exist for years. If or how often it happens for a single user highly depends on a lot of circumstances like
- the stations (and thus transponders) used
- how often the box gets fully powered off
- how often the box gets restarted
- which softcam (and which version of it) gets used
- network configuration (There is only a very specific configuration for which the one-shot-NTP-sync at boot worked)
- ...

I am using OSCAM, so from your statement above, all I can do is a power off/on to correct the time.

Yes.

 

My understanding is that the time is set at power-up (Sky News 28E) and when I power-up the time is set correctly. Also, once set to the correct transponder time, and kept powered up, the time cannot be reset/adjusted. How then a few days later does it skip to 3 mins lag if, from what I read here, it cannot be corrected after power-up due to OSCAM?

You have to understand that every method to measure something also has certain faults, so that people invented ways to compensate them.
Roughly said: oscam does not prevent the fault, it only invalidates the compensation.

To make it somewhat more simple to understand (At least for people old enough to remember conventional wristwatches):
At time A you adjusted your wristwatch, usually according to a so-called "master clock" (Historically found at train stations, airports, ...).
In Germany, one would usually pick a clock which has the "TeleNorma" brand on it (TeleNorma = "Telefon und Normalzeit" = "Telephone and master time").

Without touching the adjustments again (Equalling oscam's CLOCKFIX mode), you then compare your wristwatch's time with a master clock again at time B (Several days/weeks/months later, depending on if the watch is Chinese or Swiss/Saxonian Made :) ) and notice a more or less big time disparity.
How can this be as you didn't change the watch's time?

Well, time can not be measured at all, only the "effects of time".
A wristwatch only counts moves of mechanical parts ("Unruh", "balance-wheel") or the disintegration of a quar(t)z.
Even if the wristwatch might be designed for X movements of the balance-wheel or X% of disintegration per second, might actually do X+/-Y movements/percent of disintegration per second, so it will not move exactly 1 second per real second, but let's say 0.95 or 1.05 shown seconds per real second.

So from time to time it needs re-adjustment.

The very same still applies to modern computers and thus also your STB:
The computer simply counts "ticks" since it was started. Consequently writing a tool to check the Windows uptime involves invoking the "GetTickCount" function, not a "GetUpTime" function!

Supposed result:
"The return value is the number of milliseconds that have elapsed since the system was started."

No matter what, at some level of the hardware that performs the counting we will end up with it actually just being a counter for swings of a resonant circuit or disintegration of a quar(t)z too.
21st century or not, the TickCount suffers from the same inherent inaccuracies as the wristwatch.

oscam's CLOCKFIX can do nothing about this inherent tick inaccuracy (it can't or it would need to hold on time at all), just like any other program it will live with the fact that 1000 ticks are only close but not 100% equal to 1000ms.
Let's claim that your tick counter actually does 1000.05 ticks per second.
That changes "nothing" for timings, but still: Your clock will go 60003 ticks per minute, 3600180 ticks per hour, 86404320 ticks per day. So per day, it will have advanced additional 4.32 seconds.

This is still no problem, as that's what NTP (or DVB) syncs are for: To get the system clock back in sync. For the example above, E2 will simply adjust the clock back by 1 sec about every 6 hrs and we are all fine ...
.. but wait, here is where oscam's CLOCKFIX steps in and forwards the system clock by 1 sec again instantly to prevent the time from going backwards.

So oscam does not prevent the addition (the real fault) of 4.32 seconds per day (in this example), but only the correction of them.

And now imagine your clock does 1000.5 or even 1001 ticks per second ... at 1000.5 ticks per second, after only 3days E2 would even give up adjusting the time at all, as the disparity now exceeds 120sec (3x43.2 seconds)!

In the end it doesn't matter at how many ticks per second your counter ("system clock") really runs, as long as it is slightly above 1000.00000000000000000000000000000000000000000000000000000000000000 ticks/sec it will be ahead by 1sec, 2sec, ... sooner or later.

And now the reason why NTP worked better:
Even if NTP sees your system time being ahead it won't turn back time, it will only change the speed at which it continues to advance!
It calculcates a correction factor which will slightly overcompensate the existing disparity, so if your counter normally does 1000.05 ticks/second, it might modify it to do 999.92 ticks/second.
-0.05 ticks to compensate the already summed up drift over a specific time and additional -0.03 ticks to compensate future drift.
After multiple syncs, the clock will then go at a rate much closer to 1000 ticks/sec.
As the clock still continues to advance only, oscam doesn't prevent this (even with CLOCKFIX enabled!).

That's what I've added to E2 too, but for OpenPLi it will only be in 6.1 or even 6.2 and not inside your ancient OpenPLi 4.0:
The E2 DVB-sync will now also use the mechanism described above and called "slewing".
E2 will then only slow down or speed up the counter driving the system time, as long as the disparity is within a time period that can be slewed inside a foreseeable future resp. is irrelevant enough.
Time will no longer be set back by 1, 2 or 14 seconds, which would drive oscam mad, but only move on ... slower if necessary, but still forward.

The ultra-short version:
oscam's CLOCKFIX means nothing else but "forward ever, backward never" and allows forward corrections as well as forward faults/drift.
As slewing turns backward corrections into slower advancing of the clock, it should work even for oscam's with CLOCKFIX.

The reasons why CLOCKFIX should be disabled anyways are:
  • It's much more unlikely that it will ever step in under normal circumstances
  • If the system clock is that much ahead that it would need to be stepped back rather than slewed, it's most probably for a reason.
    In such a case it's probably much better to lose 1 second of a recording due to decryption problems than to make the whole recording useless due to missed beginnings or ends.



#821642 Receiver no longer time synced

Posted by SpaceRat on 2 January 2018 - 17:33

I decided to start at the beginning and finish at the end ... :)

https://github.com/O...igma2/pull/1192

It doesn't address all known issues, but only one.
Instead of stepping each and every time difference dvbtime.cpp finds, smaller ones are now slewed, that means the clock will gradually drift towards the desired time, rather than jumping to it.

That means this effect ...
19:31:09.9116 [   ] dvb/dvbtime.cpp:468 updateTime [eDVBLocalTimerHandler] Transponder time is 01.01.2018 19:31:11
19:31:09.9117 [   ] dvb/dvbtime.cpp:481 updateTime [eDVBLocalTimerHandler] diff is 2
19:31:09.9123 [   ] dvb/dvbtime.cpp:581 updateTime [eDVBLocalTimerHandler] set Linux Time
19:31:11.9127 [   ] dvb/dvbtime.cpp:592 updateTime [eDVBLocalTimerHandler] time after update is 19:31:11
(note the 2 seconds time warp from 19:31:09.9123 to 19:31:11.9123)

... is gone ...

16:56:44.5658 [   ] dvb/dvbtime.cpp:468 updateTime [eDVBLocalTimerHandler] Transponder time is 02.01.2018 16:56:42
16:56:44.6767 [   ] dvb/dvbtime.cpp:588 updateTime [eDVBLocalTimerHandler] slewing Linux Time by -02 seconds
16:56:44.6773 [   ] dvb/dvb.cpp:2415 getDemux [eDVBChannel] getDemux cap=00
16:56:44.6796 [   ] dvb/pmt.cpp:950 SDTScanEvent [eDVBServicePMTHandler] sdt update done!
16:56:44.8041 [   ] dvb/epgcache.cpp:1594 startEPG [eEPGCache] start caching events(1514908604)
(note that time appears to continue normally)

... the clock gets slowed down ultraslightly, so that it will eventually (in about 1-2hrs) have lost the 2 seconds it was ahead of the transponder.

So this fix should be enough though to make the CLOCKFIX in oscam obsolete.


#818378 Receiver no longer time synced

Posted by SpaceRat on 27 December 2017 - 15:18

a.) If we are trying to find a real solution to the core problem, we should split this discussion off into some development thread.
b.) To make sure we all are discussing the same, we should point out some differences between OpenPLi on the one hand and other distros on the other.

b.)
This is the boot process of OpenPLi (and older OpenViX/OpenATV/OpenHDF/...):

From power off:
1. Yocto starts to boot. System time is 1970-01-01 0:00 UTC
2. Stuff that uses certs fails in init with "certificate not valid yet"
3. One-shot NTP sync (in yocto) fails even on networked boxes due to ntpsync called too fast after ifup -> Time remains to be 1970-01-01 0:00 UTC plus current runtime
4. E2 GUI starts, restores the pseudo-RTC from front panel (which also contains 1970-01-01), checks "now < 2004?" -> True, so do a full transponder sync ONCE, no matter if that time is good or not

From reboot/deep standby:
1. Yocto starts to boot. System time is 1970-01-01 0:00 UTC
2. Stuff that uses certs fails in init with "certificate not valid yet"
3. One-shot NTP sync (in yocto) fails even on networked boxes due to ntpsync called too fast after ifup -> Time remains to be 1970-01-01 0:00 UTC plus current runtime
4. E2 GUI starts, restores the pseudo-RTC from front panel, checks "now < 2004?" -> False, so NEVER do a full transponder sync, even if the current system time has been borked by drift before

Problems:
- Cert based stuff on boot fails
- box time can drift wherever it wants to drift to (See the links from one of my previous posts), ONLY recoverable by FULLY POWERING the box OFF
- if the box powers on on a bad transponder, it will get a bad time right from the start and never fix it, also ONLY recoverable by FULLY POWERING the box OFF



This is the boot process in recent OpenViX/OpenATV/OpenHDF/...:

From any state:
1. Yocto starts to boot. System time is 1970-01-01 0:00 UTC
2. In early boot, fake-hwclock sets the system time to image build time or last shutdown
3. A bit later in boot (After the box drivers were loaded), stb-hwclock restores the pseudo-RTC from front panel as long as it is ahead of the time restored by fake-hwclock and sets system time accordingly
4. Stuff that uses certs succeeds in most cases (Unless it's happening between 2. and 3. AND the cert was issued between image build time/last shutdown and the real "now", very unlikely)
5. E2 GUI starts -> ALWAYS does a full transponder sync ONCE, no matter if that time is good or not

Problems:
- box time can drift wherever it wants to drift to (See the links from one of my previous posts), but will be recovered by ANY E2 restart, even only GUI restart
- if the box powers on on a bad transponder, it will get a bad time right from the start and never fix it, also recoverable only by E2 restart (but GUI restart is sufficient)

If you look carefully into any decent Linux distro and/or the yocto core, you will notice that the current OpenATV/OpenHDF/OpenViX/... behaviour is inline with normal Linux behaviour and yocto design.

It was previously (and still is in OpenPLi) behaving differently due to quirks and bugs in oe-a and OpenPLi core:I would say it's rather safe to assume that having a decently proper system time at boot is a good idea, as any Linux distro out there does its best in order to maintain this.
In systemd, advancing the system clock to at least systemd build time even is a built-in feature.

Tell me whatever you want, but I can't consider a workaround in E2 that relies on everything around it to fail (NTP one shot, systemd) or to be patched to death (save-rtc.sh) as "best practice".

For that reason, I removed the bad workaround in E2 instead ...
https://github.com/O...e341aaae6a07f77
https://github.com/o...151b4ac04616692
https://github.com/o...d63387c1889eb1f
... because the problem is not that Linux distros give their best to maintain some decent system time but E2 making false assumptions about it.

Tests so far have proven that it's the correct direction, boxes without network (NTP) now also get a time sync (transponder) again ... and we got rid of one more bad workaround.

What's not evaluated so far is, if this might result in one "jump" of the clock under some conditions:
NTP time at boot -> transponder sync on GUI start -> back to NTP time again

The behaviour here might differ between OpenPLi and others though, as from this thread I have learned that OpenPLi users need yet another plugin for NTP, while NTP sync is a built in feature in at least OpenATV, but probably also OpenViX, OpenBH and others:
OpenATV users can toggle between NTP and transponder sync without the need for additional plugins, so selecting NTP disables transponder sync anyways, but only conditional (if the time makes sense).


Some thoughts:
The difference between transponder and box time should be "reconsidered" from time to time. It doesn't make sense to ask the transponder about its time, only to ignore it later.
One idea would to use modulo: Subtract full half hours from the difference, e.g. if the difference is 3800 seconds, it appears more probable to me that the transponder delivers a correct time that is simply in local time, rather than it being entirely wrong.
Subtracting 3600 sec = 1 hr would result in a difference of 200 seconds, which we could still sync with.

If transponder times really are that bad, why sync with them at all? Wouldn't it be more honest then to say "Your cheap-a$$ box vendor was too niggard to include a 20 Cent RTC in your box, you need network for NTP time!"?

If only some transponders deliver a good time, wouldn't it be more elegant to let E2 shortly tune to them at boot, rather than to advise the users to make the box come up with some - maybe unwanted - channel on such a transponder, just to get some good time?

Also: Why not include a list of "known-good" transponders/sat positions for time sync, so that E2 at least re-syncs when switching to them, rather than to preserve the bad offset it stored on first sync on a bad one?
From what I learned so far, bad time sync is a problem that doesn't really exist on Astra or Hotbird = most of our users.
Why does the whole world need to suffer from bad code written for down under (It was mentioned that Aussie sat positions DO deliver bad times)?


#816356 Receiver no longer time synced

Posted by SpaceRat on 22 December 2017 - 18:12

OpenPLi:
https://forums.openp...ng-system-date/
https://forums.openp...ing-wrong-time/
https://forums.openp...time-displayed/
https://forums.openp...-time-and-date/

OpenATV:
https://www.opena.tv...lsche-zeit.html
https://www.opena.tv...ay-uhrzeit.html
https://www.opena.tv...eit-falsch.html
https://www.opena.tv...0-zeit-bug.html

OpenViX:
http://www.world-of-...show-wrong-time
http://www.world-of-...g-date-and-time
http://www.world-of-...wing-on-VIX-2-4
http://www.world-of-...lashing-VIX-2-1

...

Indeed, there are more important problems to solve ... maybe some whitespace fixes or rewriting counted for loops to do ... while?

WanWizard once asked me why I'm such an asshole sometimes.

It's simple:
Because I deem the OpenPLi devs to be very competent coders - if not the most competent remaining in the scene - and you can definitely take that as a compliment, but they are wasting their time rewriting the working parts of E2 again and again (I refer to OpenPLi as OpenReInventingTheWheel), not touching any of the true problems.
There is a shitload of bugs and ugly limitations in E2 and for years I eagerly waited for the time when some E2 box is ready for end users (That means: I would recommend my parents to get one).

If a bug that affects any box and any distro and loads of users is not worth being fixed, I don't know what is worth being fixed.


#810580 merge requests for PLi's git

Posted by SpaceRat on 9 December 2017 - 16:55

Let's rephrase:
It's a misleading output :)

E2 is very talkative about nonsense but it sometimes hides important stuff very well ...

The output should rather look like
[MAIN] Loading spinners ...
[MAIN] found 7 spinner!
(Nobody cares it found just 7 spinners because it didn't find an eigth' spinner: It found 7 spinners, that's the message)

or

[MAIN] Loading spinners ...
[MAIN] found no spinners in /usr/share/enigma2/skin_default/spinner/!
E2 is full of such redundant log bloat.


#797354 Mediaportal

Posted by SpaceRat on 14 November 2017 - 11:15

OpenPLi merged doch eh nix, wozu also Zeit damit verschwenden, Euch was auf dem Silbertablett zu servieren?
Wir gucken doch auch selber nach, ob wir was aus pli-oe-core gebrauchen können.

Aber weil Du es bist:
https://github.com/o...7f2379eca0222f2


#792479 Mediaportal

Posted by SpaceRat on 3 November 2017 - 09:08

Hatte doch noch etwas Zeit zum Suchen:
https://github.com/o...2e9a8f355757f52

[python-certifi] Optimize
- Include python-package-split
- Make /usr/lib/python2.7/site-packages/certifi/cacert.pem a link to /etc/ssl/certs/ca-certificates.crt, saving space


/usr/lib/python2.7/site-packages/certifi/cacert.pem muß also existieren oder ein Link auf /etc/ssl/certs/ca-certificates.crt sein.
Wenn /usr/lib/python2.7/site-packages/certifi/cacert.pem eine Datei ist sollte sie natürlich auch halbwegs aktuell sein, der Link ist also besser ...

Das war's jedenfalls im Falle von OpenATV.

Natürlich muß auch /etc/ssl/certs/ca-certificates.crt existieren (Stammt aus dem Paket ca-certificates), wäre aber ein schlechter Witz wenn nicht.


#792470 Mediaportal

Posted by SpaceRat on 3 November 2017 - 08:11

Ich denke nicht, daß er das wirklich weiß.
Er benutzt sie (die Abhängigkeiten) ja nur.

Aber ich weiß es, bzw. glaube es zu wissen, da ich das Problem im entsprechenden Python-Paket korrigiert habe (Es GAB denselben Fehler auch in OpenATV).
Da ich aber nur ein Idiot bin und OpenPLi fehlerfrei ist, während OpenATV Tausende von ungefixten Fehlern enthält, kann das ja nicht sein.

Falls Du es genauer wissen willst, müsstest Du mal meine (Schimmelreiter) commits im oe-alliance core (Branch 4.1) durchsehen. Ist schätzungsweise 2-4 Wochen her.
Es reichen die, die Python-Pakete betreffen und davon die, die irgendwas mit Certs bzw. SSL zu tun haben.

Eines dieser Pakete bringt seinen eigenen certstore mit, der wurde ihm aber entrissen (Die Datei hat die Erweiterung .txt und landete deshalb im -doc-Unterpaket). Ich habe das Problem so gelöst, daß der systemeigene certstore auf den Namen verlinkt wird, unter dem das Python-Paket ihn erwartet, das war die dümmstmögliche Lösung:
Es gibt keine zwei verschiedenen certstores und damit keinen doppelten Platzbedarf und Drift zwischen den beiden und trotzdem kriegt das Python-Paket seine Extrawurst (Nutzlosen zweiten certstore).

Genauer kann ich es Dir momentan tatsächlich nicht sagen, da ich fast jeden Tag neue Fehler und Bugs in OpenATV oder oe-alliance core einbaue, ich müsste selber anhand der o.g. Infos suchen.

Gesendet von meinem SM-N910F mit Tapatalk


#792347 Mediaportal

Posted by SpaceRat on 2 November 2017 - 20:04

Vielleicht sollten adenin und ich noch etwas mehr zum MediaPortal beitragen, damit das auch so bleibt ;)


#791957 Mediaportal

Posted by SpaceRat on 2 November 2017 - 09:36

Frag einfach nicht, schau einfach nur auf die URL, in welchem Forum Du bist :)