Raspberry Pi: Ervaringen en Discussie - deel 2

[Tmr]

Ik ben eindelijk begonnen met het bouwen van een Pi NAS.

Daarvoor heb ik deze waveshare box besteld (Box C). Ik heb de versie met M.2 extension board.

Voorlopig draait hij nog van de SD kaart (ik moet nog een SSD toevoegen) maar vooralsnog is bevalt de case prima. Er zitten 2 full size HDMI poorten op en er is genoeg ruimte om aan het werk te kunnen.

Uiteindelijk is het de bedoeling dat hier NextCloud + Memories op te draaien, en wat andere kleine services zoals een VPN naar huis. Voorlopig heb ik nog niet meer tijd gehad dan het installeren van pi-hole, maar dat is ook al leuk

[nero355]

Tmr schreef op maandag 16 september 2024 @ 16:01:
Ik ben eindelijk begonnen met het bouwen van een Pi NAS.

Check effe nero355 in "Raspberry Pi: Ervaringen en Discussie - deel 2"

[Raven]

Weet iemand toevallig hoe je RPi OS kunt forceren de arp-entries na te lopen en oude te verwijderen indien niet bereikbaar? Dat lijkt namelijk niet automatisch te gebeuren.

Afgaand op Google komt dit door gc_thresh1 die op 128 staat, pas als er meer dan 128 entries zijn gaat garbage collection draaien. Het is mij niet duidelijk of die verlagen neveneffecten heeft,

[nero355]

Raven schreef op woensdag 18 september 2024 @ 10:09:
Weet iemand toevallig hoe je RPi OS kunt forceren de arp-entries na te lopen en oude te verwijderen indien niet bereikbaar? Dat lijkt namelijk niet automatisch te gebeuren.

Is het een optie om alles weg te pleuren en daarna ping -B 255.255.255.255 te doen

Beetje ranzig, maar stiekem wel leuk !!!

[Raven]

@nero355 Hmm, later eens in een VM proberen

Maar zoiets zou automatisch moeten gebeuren, althans het checken wat verouderd is en dan verwijderen, maar dat werkt blijkbaar pas als er minimaal 128 entries in de tabel staan. Zoveel clients zijn er niet hier in het netwerk

[nero355]

Raven schreef op donderdag 19 september 2024 @ 09:00:
Maar zoiets zou automatisch moeten gebeuren, althans het checken wat verouderd is en dan verwijderen, maar dat werkt blijkbaar pas als er minimaal 128 entries in de tabel staan.

Zoveel clients zijn er niet hier in het netwerk

Een Switch doet dat elke 300 seconden IIRC en Linux lijkt ook zoiets te hebben :
- https://serverfault.com/q...default-arp-cache-timeout
- https://askubuntu.com/que...s-an-arp-entry-cached-for
- https://manpages.ubuntu.c...acular/en/man7/arp.7.html

Voor nog meer leesplezier zie : https://duckduckgo.com/?q=arp+table+refresh+time+linux

Al zou zoiets misschien handiger zijn nou ik erover nadenk : https://duckduckgo.com/?q=arp+table+entry+timeout+time+linux of iets in die richting, want elke entry heeft een aparte TTL als het goed is

[Raven]

@nero355 Maar het punt is dat er pas wat gebeurt wanneer er minimaal 128 entries zijn en die zijn er niet:
https://man7.org/linux/man-pages/man7/arp.7.html

gc_thresh1 (since Linux 2.2)
The minimum number of entries to keep in the ARP cache.
The garbage collector will not run if there are fewer than
this number of entries in the cache. Defaults to 128.

gc_thresh2 (since Linux 2.2)
The soft maximum number of entries to keep in the ARP
cache. The garbage collector will allow the number of
entries to exceed this for 5 seconds before collection
will be performed. Defaults to 512.

gc_thresh3 (since Linux 2.2)
The hard maximum number of entries to keep in the ARP
cache. The garbage collector will always run if there are
more than this number of entries in the cache. Defaults
to 1024.

Hmm, de switch, is een oude TL-SG3216 (1.0) en kan SNMP doen.

Heb het Python-script dat van de arp-tabel gebruik maakt inmiddels voorzien van een ping-test om te kijken of een IP-adres actief is, beetje workaround om oude/dooie entries te negeren, maar dat werkt

[nero355]

@Raven

Maar heb je al met ALLE variabelen zitten rommelen of niet

Als het echt zo werkt zoals jij zegt dan heeft de boel IMHO een flinke redesign nodig!

[Raven]

@nero355 Nope, deze variabelen staan allemaal standaard, nooit aan gezeten.

Wist tot voor kort niet eens van deze arp-gerelateerde variabelen af. Kwam ze tegen na te Googlen op oude entries in arp-tabel die niet verdwijnen, ook niet nadat eenzelfde apparaat/MAC-adres met nieuw IP-adres opgepikt wordt. De oude entry blijft gewoon staan en wordt ook dan niet opnieuw gecheckt en daarna verwijdert

[nero355]

Raven schreef op donderdag 19 september 2024 @ 18:07:
Nope, deze variabelen staan allemaal standaard, nooit aan gezeten.

Ik bedoel nu juist wel/niet om te testen ??

Wist tot voor kort niet eens van deze arp-gerelateerde variabelen af. Kwam ze tegen na te Googlen op oude entries in arp-tabel die niet verdwijnen, ook niet nadat eenzelfde apparaat/MAC-adres met nieuw IP-adres opgepikt wordt.
De oude entry blijft gewoon staan en wordt ook dan niet opnieuw gecheckt en daarna verwijdert

W-T-F ?!?!

Dat lijkt me dus ook niet echt de bedoeling...


In het verleden had de Ubiquiti UniFi USG door een of andere bug ook zoiets en dat zorgde echt voor hele rare problemen IIRC

[Raven]

@nero355 Nope, ik wil eerst zeker weten of er geen neven-effecten optreden en daar kan ik niet wat over vinden. Uiteindelijk ping-test toegevoegd aan het script om de oude te laten negeren.

De arp tabel van de RPi heeft (zo op het oog) op dit moment 14 oude/dooie entries erin staan, van de 41 en als ik de adressen goed herinner, zijn die al een tijdje buiten gebruik (na overstap naar static-dhcp).

edit: @nero355 Hmm, eigenlijk had ik er een compleet niet meer gebruikt subnet in die lijst verwacht, toen de EB kwam (dubbel NAT....) zat die gelockt in een door mij gebruikt subnet waarvan de inhoud is verplaatst naar een ander. Die clients zie ik er niet in staan, met het oude subnet bedoel ik dan.

Toen bedacht ik mij dat er een paar keer downtime (stroomuitval) is geweest, niet van de Pi (noodstroomvoorziening) maar van de switch, ik gok dat de down (en later weer up) gaande LAN-interface de arp-tabel heeft gereset toen, anders was de lijst met oude/dooie entries nog veel langer geweest

[ Voor 42% gewijzigd door Raven op 19-09-2024 19:37 ]

[Raven]

Gister maar eens de boot-partities van een 0W, 2x Pi2 en 1x Pi3 zitten vergroten (beter laat dan nooit ), dat ging makkelijker dan verwacht al is er wel een Pi eigenwijs aan het doen.

Het vergroten van de bootpartitie (en daarvoor het iets verkleinen van de data-partitie) ging zonder problemen, al beweerde GParted wel telkens dat de data-partitie verschoven was terwijl ik deze alleen aan de linkerkant iets verkleind had, met als gevolg dat deze telkens enkele GB's aan data ging verschuiven i.p.v. alleen de data op het verkleinde deel

Eenmaal klaar rpi-update op de Pi's gedraaid, geen melding van te kleine partitie meer, herstart, om daarna apt aan het werk te zetten.

Bij 3 van de 4 Pi's ging dat goed, bij de 0W kreeg ik na de herstart na rpi-update geen beeld meer, ook de regenboogkleuren direct na power on niet (no signal), de Pi doet wel (via ssh). Google verwees naar No HDMI output after update en de (soort van) fix was dtoverlay=vc4-kms-v3d toevoegen aan /boot/config.txt

Soort van in de zin van dat er nu wel beeld komt, maar pas op het moment dat login op de terminal verschijnt (plus de laatste paar bootmessages), daarvoor nog steeds niet, ook de regenboogkleuren niet.

In dmesg heb ik niets iets opvallends voorbij zien komen dat dit zou kunnen verklaren, iemand enig idee? In het genoemde topic hebben ze het over EDID dat bij bepaalde monitors niet goed zou zijn en dat sinds een bepaalde update voor problemen zorgt, maar 3 van de 4 RPi's hebben er geen last van

[nero355]

Raven schreef op maandag 23 september 2024 @ 14:28:
Bij 3 van de 4 Pi's ging dat goed, bij de 0W kreeg ik na de herstart na rpi-update geen beeld meer, ook de regenboogkleuren direct na power on niet (no signal), de Pi doet wel (via ssh). Google verwees naar No HDMI output after update en de (soort van) fix was dtoverlay=vc4-kms-v3d toevoegen aan /boot/config.txt

Soort van in de zin van dat er nu wel beeld komt, maar pas op het moment dat login op de terminal verschijnt (plus de laatste paar bootmessages), daarvoor nog steeds niet, ook de regenboogkleuren niet.

Iemand enig idee?

Niet toevallig zitten rommelen met

disable_splash

If disable_splash is set to 1, the rainbow splash screen will not be shown on boot. The default value is 0.

Verder vind ik dit wel interessant :
- https://forums.raspberryp...b34f458a92adbca4#p1951931
- https://forums.raspberryp...b34f458a92adbca4#p1952270

Dus afhankelijk van welke distro je draait en of die support wel/niet aanwezig is kan je ervaring/kunnen de resultaten flink verschillen ?!

En daarnaast zou het ook nog eens gewoon een bug kunnen zijn, zoals mijn ervaring met meerdere interfaces en het koppelen van daemons/services aan één van die interfaces

[Raven]

nero355 schreef op maandag 23 september 2024 @ 15:59:
[...]

Niet toevallig zitten rommelen met

[...]

Niet dat ik mij kan herinneren, maar voor het draaien van rpi-update was er niks aan de hand, pas daarna gebeurde het. Verder niks verandert, buiten daarna dus toevoegen die dtoverlay optie om (pas bij login) beeld te krijgen.

nero355 schreef op maandag 23 september 2024 @ 15:59:
Verder vind ik dit wel interessant :
- https://forums.raspberryp...b34f458a92adbca4#p1951931
- https://forums.raspberryp...b34f458a92adbca4#p1952270

Dus afhankelijk van welke distro je draait en of die support wel/niet aanwezig is kan je ervaring/kunnen de resultaten flink verschillen ?!

En daarnaast zou het ook nog eens gewoon een bug kunnen zijn, zoals mijn ervaring met meerdere interfaces en het koppelen van daemons/services aan één van die interfaces

fkms heb ik nooit wat mee gedaan., sterker nog, tot gister nog nooit een beeldgerelateerde dtoverlay optie gebruikt.

De Pi's draaien allen RaspbianRPi OS.

[nero355]

Raven schreef op maandag 23 september 2024 @ 17:01:
De Pi's draaien allen RaspbianRPi OS.

Welke precies

Je hebt de boel zitten resizen om te kunnen updaten, toch ??

[Raven]

@nero355 12, oftewel Bookworm.

Ja, de bootpartitie. Die is enkele versies terug (tussen 9 en 10 toch?) vergroot i.v.m. firmware voor RPi 4's, maar ik doe telkens een upgrade i.p.v. nieuwe versie te flashen, waardoor ik de bootpartities met de hand heb moeten aanpassen. Dit heb ik echter pas recent dus gedaan, beetje laat

[DjoeC]

Misschien een vraag die niet hier maar in een ander/eigen topic thuis hoort maar toch begin ik hier omdat de Raspberry mijn klokserver is....

Ik gebruik een Pi2 met adafruit GPS ontvanger icm Chrony om de tijd te bepalen. De GPS staat als "voorkeurs" tijdserver, internet servers als secundair. Uiteindelijk acteert deze Pi als Stratum-1 server binnen het netwerk:

code:

MS Name/IP address         Stratum Poll Reach LastRx Last sample
===============================================================================
#x GPS                           0   4   377    16   -541ms[ -541ms] +/-  106ms
#* PPS                           0   4   377    16   +548ns[ +712ns] +/-  312ns
^- server01.colocenter.nl        2  10   377   798   +986us[ +992us] +/-   28ms
^- 158.101.216.150               2  10   377     9    +73us[  +73us] +/- 4388us
^- 193.123.37.231                3  10   377   424  +1341us[+1346us] +/- 8989us
^- y.ns.gin.ntt.net              2   8   377   108   +869us[ +869us] +/-   95ms
^- leontp2.office.panq.nl        1  10   377   825   +176us[ +182us] +/- 4098us
^- leontp1.office.panq.nl        1  10   377   379    +85us[  +89us] +/- 4041us
^- ext.e-zu.co.uk                2  10   377   415   -537us[ -533us] +/-   31ms
^- 193.123.56.220                2  10   377   629   -105us[ -101us] +/- 4304us

en heeft ook daar een "voorkeurs" positie. Dit levert een redelijk nauwkeurige tijd op de netwerk computers zoals hier op een Pi4:

code:

MS Name/IP address         Stratum Poll Reach LastRx Last sample
===============================================================================
^* pi2                           1   6   377    28   -105us[ -103us] +/-  712us
^- gowest.hojmark.net            2   9   377   372  -1051us[ -960us] +/-   30ms
^- 193.148.248.179               2  10   377   684    +42us[ +117us] +/- 2967us
^- connected.by.freedominte>     2  10   377   478    +54us[ +150us] +/- 4344us
^- hosted.by.xyphen.it           2  10   377   351   -369us[ -278us] +/- 4065us
^- 185.45.112.121                2  10   377   374   -136us[  -45us] +/- 6409us
^- 5.255.99.180                  2  10   377   182    +23us[ +123us] +/-   15ms
^- pve1-thg.hostin.cc            2  10   377   171   +181us[ +282us] +/- 6282us
^- time3.panq.nl                 2  10   377   754   -451us[ -379us] +/- 4330us
$

Tijd wordt steeds belangrijker om zaken goed te besturen, om events "volgtijdelijk" correct te registreren, denk aan dag/nacht bepaling, thuisautomatisering database timestamps, etc. Het zou wat worden als door wisselende tijdstippen bijvoorbeeld de rolluiken op en neer blijven gaan......

Nu zie ik steeds meer berichten over de toename van GPS spoofing en dat ook als iets dat niet beperkt blijft tot crisisgebieden. Omdat lokatiebepaling via GPS eigenlijk gebeurt via de (zeer nauwkeurige) klokinformatie vraag ik me af of, ik ben er eigenlijk wel zeker van dat, dit de nauwkeurigheid van mijn lokale tijdserver kan beinvloeden en of daar lokaal mitigerende maatregelen tegen te treffen zijn?

[Falco]

DjoeC schreef op dinsdag 24 september 2024 @ 12:11:
Misschien een vraag die niet hier maar in een ander/eigen topic thuis hoort maar toch begin ik hier omdat de Raspberry mijn klokserver is....

Ik gebruik een Pi2 met adafruit GPS ontvanger icm Chrony om de tijd te bepalen. De GPS staat als "voorkeurs" tijdserver, internet servers als secundair. Uiteindelijk acteert deze Pi als Stratum-1 server binnen het netwerk:

code:

MS Name/IP address         Stratum Poll Reach LastRx Last sample
===============================================================================
#x GPS                           0   4   377    16   -541ms[ -541ms] +/-  106ms
#* PPS                           0   4   377    16   +548ns[ +712ns] +/-  312ns
^- server01.colocenter.nl        2  10   377   798   +986us[ +992us] +/-   28ms
^- 158.101.216.150               2  10   377     9    +73us[  +73us] +/- 4388us
^- 193.123.37.231                3  10   377   424  +1341us[+1346us] +/- 8989us
^- y.ns.gin.ntt.net              2   8   377   108   +869us[ +869us] +/-   95ms
^- leontp2.office.panq.nl        1  10   377   825   +176us[ +182us] +/- 4098us
^- leontp1.office.panq.nl        1  10   377   379    +85us[  +89us] +/- 4041us
^- ext.e-zu.co.uk                2  10   377   415   -537us[ -533us] +/-   31ms
^- 193.123.56.220                2  10   377   629   -105us[ -101us] +/- 4304us

en heeft ook daar een "voorkeurs" positie. Dit levert een redelijk nauwkeurige tijd op de netwerk computers zoals hier op een Pi4:

code:

MS Name/IP address         Stratum Poll Reach LastRx Last sample
===============================================================================
^* pi2                           1   6   377    28   -105us[ -103us] +/-  712us
^- gowest.hojmark.net            2   9   377   372  -1051us[ -960us] +/-   30ms
^- 193.148.248.179               2  10   377   684    +42us[ +117us] +/- 2967us
^- connected.by.freedominte>     2  10   377   478    +54us[ +150us] +/- 4344us
^- hosted.by.xyphen.it           2  10   377   351   -369us[ -278us] +/- 4065us
^- 185.45.112.121                2  10   377   374   -136us[  -45us] +/- 6409us
^- 5.255.99.180                  2  10   377   182    +23us[ +123us] +/-   15ms
^- pve1-thg.hostin.cc            2  10   377   171   +181us[ +282us] +/- 6282us
^- time3.panq.nl                 2  10   377   754   -451us[ -379us] +/- 4330us
$

Tijd wordt steeds belangrijker om zaken goed te besturen, om events "volgtijdelijk" correct te registreren, denk aan dag/nacht bepaling, thuisautomatisering database timestamps, etc. Het zou wat worden als door wisselende tijdstippen bijvoorbeeld de rolluiken op en neer blijven gaan......

Nu zie ik steeds meer berichten over de toename van GPS spoofing en dat ook als iets dat niet beperkt blijft tot crisisgebieden. Omdat lokatiebepaling via GPS eigenlijk gebeurt via de (zeer nauwkeurige) klokinformatie vraag ik me af of, ik ben er eigenlijk wel zeker van dat, dit de nauwkeurigheid van mijn lokale tijdserver kan beinvloeden en of daar lokaal mitigerende maatregelen tegen te treffen zijn?

Ik weet niet hoe nauwkeurig het moet, maar ik gebruik de NTP servers van Time.nl. Deze heb ik toegevoegd aan mijn Openwrt hoofdrouter en die fungeert als time server voor de rest van het netwerk. Tot dusver geen issues gehad.

[MaffeMaarten]

DjoeC schreef op dinsdag 24 september 2024 @ 12:11:
Misschien een vraag die niet hier maar in een ander/eigen topic thuis hoort maar toch begin ik hier omdat de Raspberry mijn klokserver is....

Ik gebruik een Pi2 met adafruit GPS ontvanger icm Chrony om de tijd te bepalen. De GPS staat als "voorkeurs" tijdserver, internet servers als secundair. Uiteindelijk acteert deze Pi als Stratum-1 server binnen het netwerk:

code:

MS Name/IP address         Stratum Poll Reach LastRx Last sample
===============================================================================
#x GPS                           0   4   377    16   -541ms[ -541ms] +/-  106ms
#* PPS                           0   4   377    16   +548ns[ +712ns] +/-  312ns
^- server01.colocenter.nl        2  10   377   798   +986us[ +992us] +/-   28ms
^- 158.101.216.150               2  10   377     9    +73us[  +73us] +/- 4388us
^- 193.123.37.231                3  10   377   424  +1341us[+1346us] +/- 8989us
^- y.ns.gin.ntt.net              2   8   377   108   +869us[ +869us] +/-   95ms
^- leontp2.office.panq.nl        1  10   377   825   +176us[ +182us] +/- 4098us
^- leontp1.office.panq.nl        1  10   377   379    +85us[  +89us] +/- 4041us
^- ext.e-zu.co.uk                2  10   377   415   -537us[ -533us] +/-   31ms
^- 193.123.56.220                2  10   377   629   -105us[ -101us] +/- 4304us

en heeft ook daar een "voorkeurs" positie. Dit levert een redelijk nauwkeurige tijd op de netwerk computers zoals hier op een Pi4:

code:

MS Name/IP address         Stratum Poll Reach LastRx Last sample
===============================================================================
^* pi2                           1   6   377    28   -105us[ -103us] +/-  712us
^- gowest.hojmark.net            2   9   377   372  -1051us[ -960us] +/-   30ms
^- 193.148.248.179               2  10   377   684    +42us[ +117us] +/- 2967us
^- connected.by.freedominte>     2  10   377   478    +54us[ +150us] +/- 4344us
^- hosted.by.xyphen.it           2  10   377   351   -369us[ -278us] +/- 4065us
^- 185.45.112.121                2  10   377   374   -136us[  -45us] +/- 6409us
^- 5.255.99.180                  2  10   377   182    +23us[ +123us] +/-   15ms
^- pve1-thg.hostin.cc            2  10   377   171   +181us[ +282us] +/- 6282us
^- time3.panq.nl                 2  10   377   754   -451us[ -379us] +/- 4330us
$

Tijd wordt steeds belangrijker om zaken goed te besturen, om events "volgtijdelijk" correct te registreren, denk aan dag/nacht bepaling, thuisautomatisering database timestamps, etc. Het zou wat worden als door wisselende tijdstippen bijvoorbeeld de rolluiken op en neer blijven gaan......

Nu zie ik steeds meer berichten over de toename van GPS spoofing en dat ook als iets dat niet beperkt blijft tot crisisgebieden. Omdat lokatiebepaling via GPS eigenlijk gebeurt via de (zeer nauwkeurige) klokinformatie vraag ik me af of, ik ben er eigenlijk wel zeker van dat, dit de nauwkeurigheid van mijn lokale tijdserver kan beinvloeden en of daar lokaal mitigerende maatregelen tegen te treffen zijn?

Goeie vraag, nog nooit zo bij stil gestaan. Voor mijn werk hebben we ook wat apparaten die GPS als tijdsbron gebruiken, dus wat rondgegoogled.

Één van de dingen die ik tegenkwam:
https://www.reuters.com/t...searchers-say-2024-08-10/

In an interview with Reuters, Munro cited a recent incident in which an aircraft operated by a major Western airline had its onboard clocks suddenly sent forward by years, causing the plane to lose access to its digitally-encrypted communication systems.

Interresant

[stormfly]

DjoeC schreef op dinsdag 24 september 2024 @ 12:11:
Misschien een vraag die niet hier maar in een ander/eigen topic thuis hoort maar toch begin ik hier omdat de Raspberry mijn klokserver is....

Ik gebruik een Pi2 met adafruit GPS ontvanger icm Chrony om de tijd te bepalen. De GPS staat als "voorkeurs" tijdserver, internet servers als secundair. Uiteindelijk acteert deze Pi als Stratum-1 server binnen het netwerk:

code:

MS Name/IP address         Stratum Poll Reach LastRx Last sample
===============================================================================
#x GPS                           0   4   377    16   -541ms[ -541ms] +/-  106ms
#* PPS                           0   4   377    16   +548ns[ +712ns] +/-  312ns
^- server01.colocenter.nl        2  10   377   798   +986us[ +992us] +/-   28ms
^- 158.101.216.150               2  10   377     9    +73us[  +73us] +/- 4388us
^- 193.123.37.231                3  10   377   424  +1341us[+1346us] +/- 8989us
^- y.ns.gin.ntt.net              2   8   377   108   +869us[ +869us] +/-   95ms
^- leontp2.office.panq.nl        1  10   377   825   +176us[ +182us] +/- 4098us
^- leontp1.office.panq.nl        1  10   377   379    +85us[  +89us] +/- 4041us
^- ext.e-zu.co.uk                2  10   377   415   -537us[ -533us] +/-   31ms
^- 193.123.56.220                2  10   377   629   -105us[ -101us] +/- 4304us

en heeft ook daar een "voorkeurs" positie. Dit levert een redelijk nauwkeurige tijd op de netwerk computers zoals hier op een Pi4:

code:

MS Name/IP address         Stratum Poll Reach LastRx Last sample
===============================================================================
^* pi2                           1   6   377    28   -105us[ -103us] +/-  712us
^- gowest.hojmark.net            2   9   377   372  -1051us[ -960us] +/-   30ms
^- 193.148.248.179               2  10   377   684    +42us[ +117us] +/- 2967us
^- connected.by.freedominte>     2  10   377   478    +54us[ +150us] +/- 4344us
^- hosted.by.xyphen.it           2  10   377   351   -369us[ -278us] +/- 4065us
^- 185.45.112.121                2  10   377   374   -136us[  -45us] +/- 6409us
^- 5.255.99.180                  2  10   377   182    +23us[ +123us] +/-   15ms
^- pve1-thg.hostin.cc            2  10   377   171   +181us[ +282us] +/- 6282us
^- time3.panq.nl                 2  10   377   754   -451us[ -379us] +/- 4330us
$

Tijd wordt steeds belangrijker om zaken goed te besturen, om events "volgtijdelijk" correct te registreren, denk aan dag/nacht bepaling, thuisautomatisering database timestamps, etc. Het zou wat worden als door wisselende tijdstippen bijvoorbeeld de rolluiken op en neer blijven gaan......

Nu zie ik steeds meer berichten over de toename van GPS spoofing en dat ook als iets dat niet beperkt blijft tot crisisgebieden. Omdat lokatiebepaling via GPS eigenlijk gebeurt via de (zeer nauwkeurige) klokinformatie vraag ik me af of, ik ben er eigenlijk wel zeker van dat, dit de nauwkeurigheid van mijn lokale tijdserver kan beinvloeden en of daar lokaal mitigerende maatregelen tegen te treffen zijn?

Heb jij deze? https://www.adafruit.com/product/2324

[DjoeC]

Falco schreef op dinsdag 24 september 2024 @ 12:28:
[...]
Ik weet niet hoe nauwkeurig het moet, maar ik gebruik de NTP servers van Time.nl. Deze heb ik toegevoegd aan mijn Openwrt hoofdrouter en die fungeert als time server voor de rest van het netwerk. Tot dusver geen issues gehad.

Tja, "zo nauwkeurig mogelijk" natuurlijk - zoals dat een tweaker betaamt. Maar, dat internet servers kunnen weet ik, tot internet "niet beschikbaar" is. Dingen als Rubidium klokken kunnen natuurlijk ook maar het gaat me er eigenlijk om of er een soort veiligheids voorziening te maken is die "detecteert" dat er gespoofd wordt.

Nu kun je Chrony al instellen dat ie geen grote sprongen per keer mag maken en zijn er in Chrony vast nog wel wat (mij onbekende) instellingen maar gezien ik geen RTC gebruik start bijvoorbeeld de Pi2 "tijdloos" op na power off/reboot. M'n PC heeft wel een tijdgeheugen, maar ja - die tijd varieert nogal door de dag heen.

[DjoeC]

stormfly schreef op dinsdag 24 september 2024 @ 12:36:
[...]


Heb jij deze? https://www.adafruit.com/product/2324

Ja, soortgelijk en nu ik m weer zie - moet eens checken of ik er een batterij in kan en of ik die er ingestoken heb en als dat zo is of die nog goed is. Het ding draait al jaaaaren. Ik meen dat adafruit later een andere chip is gaan gebruiken omdat de oorspronkelijke uit produktie ging.

[DjoeC]

MaffeMaarten schreef op dinsdag 24 september 2024 @ 12:30:
[...]


Goeie vraag, nog nooit zo bij stil gestaan. Voor mijn werk hebben we ook wat apparaten die GPS als tijdsbron gebruiken, dus wat rondgegoogled.

Één van de dingen die ik tegenkwam:
https://www.reuters.com/t...searchers-say-2024-08-10/

[...]


Interresant

Zakelijk zal er vast professionele apparatuur (Meinberg, HP, Agilent oid) gebruikt worden met ingebouwde backup en/of aangesloten Rubidium referentie/zeer stabiele kristal oven oid maar dat valt ruim buiten een prive of kleinzakelijk budget.

Gelukkig kunnen vliegtuigen nog zonder GPS vliegen. Er zijn nog steeds radiobakens/waypoints maar voor piloten zal dat vast schrikken/aanpassen zijn.

Maar, hoe dus voor het thuisnetwerk/lokale automatisering als GPS gesppofd is en internet eruit ligt? Heeft mijn Raspi dan nog mogelijkheden?

[MaffeMaarten]

Er bestaat ook nog steeds het oude MSF signaal, waar "radiogestuurde" horloges en klokken op werken. Volgens mij heb ik wel eens proof of concepts gezien waarbij dat kanaal met een draadje op de gpio van de pi uit de lucht kon worden getrokken.

Misschien interessant als backup. (Hoewel dat waarschijnlijk nog veel makkelijker gespoofd zou kunnen worden natuurlijk, maar als backup, of los hobby-projectje sowieso leuk natuurlijk.)

[DjoeC]

MaffeMaarten schreef op dinsdag 24 september 2024 @ 15:35:
Er bestaat ook nog steeds het oude MSF signaal, waar "radiogestuurde" horloges en klokken op werken. Volgens mij heb ik wel eens proof of concepts gezien waarbij dat kanaal met een draadje op de gpio van de pi uit de lucht kon worden getrokken.

Misschien interessant als backup. (Hoewel dat waarschijnlijk nog veel makkelijker gespoofd zou kunnen worden natuurlijk, maar als backup, of los hobby-projectje sowieso leuk natuurlijk.)

Ik kwam dit artikel tegen. Omdat het gaat om lokatie in combinatie met tijd zou ik een foute tijd moeten kunnen detecteren omdat mijn lokatie dan afwijkt van "normaal". Geen oplossing maar wel een signaal.

Of dat eenvoudig te programmeren is? Geen idee maar het is vast wel iets dat een Raspi aankan. Afwijking meer dan 100 meter: probleem.

[nero355]

DjoeC schreef op dinsdag 24 september 2024 @ 12:11:
Tijd wordt steeds belangrijker om zaken goed te besturen, om events "volgtijdelijk" correct te registreren, denk aan dag/nacht bepaling, thuisautomatisering database timestamps, etc.

Het zou wat worden als door wisselende tijdstippen bijvoorbeeld de rolluiken op en neer blijven gaan......

"I think you are waaaaay overthinking it!"

Begrijp me niet verkeerd : Ik ben dol op dingen "overengineeren"
Maar dit lijkt me echt overkill voor thuisgebruik...

Nu zie ik steeds meer berichten over de toename van GPS spoofing en dat ook als iets dat niet beperkt blijft tot crisisgebieden. Omdat lokatiebepaling via GPS eigenlijk gebeurt via de (zeer nauwkeurige) klokinformatie vraag ik me af of, ik ben er eigenlijk wel zeker van dat, dit de nauwkeurigheid van mijn lokale tijdserver kan beinvloeden en of daar lokaal mitigerende maatregelen tegen te treffen zijn?

GPS Spoofing doe je toch op het ontvangende apparaat en niet ergens daar boven in de lucht op de GPS Satelliet zelf

** Iets met die gekke Pokémon spelende kindertjes en zo

DjoeC schreef op dinsdag 24 september 2024 @ 12:52:
Maar, hoe dus voor het thuisnetwerk/lokale automatisering als GPS gesppofd is en internet eruit ligt?

Heeft mijn Raspi dan nog mogelijkheden?

Je gaat echt niet opeens knipperende "00:00" zien op al je apparaten als je effe zonder GPS of NTP data zit dus ik zie het probleem niet echt ?!

En anders inderdaad dit :

MaffeMaarten schreef op dinsdag 24 september 2024 @ 15:35:
Er bestaat ook nog steeds het oude MSF signaal, waar "radiogestuurde" horloges en klokken op werken. Volgens mij heb ik wel eens proof of concepts gezien waarbij dat kanaal met een draadje op de gpio van de pi uit de lucht kon worden getrokken.

Misschien interessant als backup. (Hoewel dat waarschijnlijk nog veel makkelijker gespoofd zou kunnen worden natuurlijk, maar als backup, of los hobby-projectje sowieso leuk natuurlijk.)

Mijn alarmklok is er dol op al een jaar of 25 of zo en als ik op mijn PC/Laptop/Telefoon kijk dan loopt de tijd altijd synchroon tussen de twee

[DjoeC]

nero355 schreef op dinsdag 24 september 2024 @ 16:01:
[...]
"I think you are waaaaay overthinking it!"

Begrijp me niet verkeerd : Ik ben dol op dingen "overengineeren"
Maar dit lijkt me echt overkill voor thuisgebruik...
[...]

Maar natuurlijk..... En dat maakt het leuk en dus de vraag relevant

GPS Spoofing doe je toch op het ontvangende apparaat en niet ergens daar boven in de lucht op de GPS Satelliet zelf

** Iets met die gekke Pokémon spelende kindertjes en zo
[...]

Ja, maar dan op grotere schaal. Wat jij beschrijft is "lokaal", apparaatje tegen de antenne aan en gaan met die banaan. Het echte spoofen gebeurt met flink hogere vermogens over een veel groter gebied. Pokemon kiddies is maar gerommel in de marge in de context waar ik het over heb.

De bedoeling is om het signaal van 1 of meerdere satellieten te overstemmen. Dat kan vanaf de aarde maar OOK vanuit de ruimte. Zie hier de schaal waarop dat gebeurt.

Je gaat echt niet opeens knipperende "00:00" zien op al je apparaten als je effe zonder GPS of NTP data zit dus ik zie het probleem niet echt ?!

En anders inderdaad dit :

[...]

Mijn alarmklok is er dol op al een jaar of 25 of zo en als ik op mijn PC/Laptop/Telefoon kijk dan loopt de tijd altijd synchroon tussen de twee

MaffeMaarten schreef op dinsdag 24 september 2024 @ 15:35:
Er bestaat ook nog steeds het oude MSF signaal, waar "radiogestuurde" horloges en klokken op werken. Volgens mij heb ik wel eens proof of concepts gezien waarbij dat kanaal met een draadje op de gpio van de pi uit de lucht kon worden getrokken.

Misschien interessant als backup. (Hoewel dat waarschijnlijk nog veel makkelijker gespoofd zou kunnen worden natuurlijk, maar als backup, of los hobby-projectje sowieso leuk natuurlijk.)

Ja, MSF, DCF77, WWV, WWVH, etc zijn opties - en misschien niet eens zo gek.... Had ik nog niet aan gedacht! En blijkbaar voor een prikkie te maken: https://www.reichelt.com/...vangstmodule_dcf_77-57772

Hmm, leuk om eens uit te zoeken of dat in Chrony te integreren is.......

[Xyphoid]

Ik heb nu een Raspberry Pi 4 met HA op een USB stick draaien. Daarnaast ook een Raspberry Pi 3 met PiOS Lite op een USB stick met een touchscreen, als dashboard.

Ik dacht dat een USB stick wat stabieler zou zijn dan een SD kaart. Als het draait, is het wel stabieler. Ook na een (geplande) reboot start het elke keer op, terwijl dat met een SD kaart net Russische roulette was.

Alleen is mijn Pi waar de dashboard op draait al twee keer gecrashed. De eerste keer met onbekende oorzaak. De tweede keer een stroomstoring in de buurt. Hierbij is twee keer de USB stick op write only gezet (is dit iets dat alleen Sandisk doet??). Ben nu dus 2 sticks kwijt, want ik krijg met geen mogelijkheid die readonly er af.

Nu heb ik laatst een externe SSD van Samsung geprobeerd aan te sluiten. Het werkte wel, maar moest wel het scherm met een aparte voeding aansluiten, omdat de Pi anders na het booten ging rebooten.
Ik zit er aan te denken om een USB hub met voeding te kopen en daar alles op aan te sluiten. Zal dit helpen? De voeding die ik nu gebruik, is 5V - 3A - 65 Watt. Lijkt me genoeg, maar het scherm en de SSD worden door de Pi gevoed, dus misschien dat daarom de Pi elke keer ging rebooten.

Een andere vraag is dan of een SSD wel een powerloss overleeft en niet net als een SD kaart of USB stick ook corrupt raakt.

En als dit niet op te lossen is, wat is dan een goed alternatief om Home assistant te draaien?

Voor het dashboard kan ik altijd een tablet gebruiken. Wilde een DIY oplossing, zodat ik niet aan Android vast zit (heb een oude tablet die ik niet kan gebruiken, omdat er een veel te oude Android op staat) en ook een groot touchscreen kan gebruiken. Maar als het niet anders kan, dan moet ik wel een tablet gebruiken.

[nero355]

Xyphoid schreef op dinsdag 24 september 2024 @ 17:36:
Ik heb nu een Raspberry Pi 4 met HA op een USB stick draaien. Daarnaast ook een Raspberry Pi 3 met PiOS Lite op een USB stick met een touchscreen, als dashboard.

Ik dacht dat een USB stick wat stabieler zou zijn dan een SD kaart. Als het draait, is het wel stabieler. Ook na een (geplande) reboot start het elke keer op, terwijl dat met een SD kaart net Russische roulette was.

Alleen is mijn Pi waar de dashboard op draait al twee keer gecrashed. De eerste keer met onbekende oorzaak. De tweede keer een stroomstoring in de buurt.

USB Sticks zijn geen goede oplossing voor zoiets

Hierbij is twee keer de USB stick op write only gezet (is dit iets dat alleen Sandisk doet??).

Ik had vroeger een collega die net zo koppig was als jij en meerdere merken USB Sticks heeft gesloopt dus : NEE !!! Absoluut niet !!!

Nu heb ik laatst een externe SSD van Samsung geprobeerd aan te sluiten. Het werkte wel, maar moest wel het scherm met een aparte voeding aansluiten, omdat de Pi anders na het booten ging rebooten.
Ik zit er aan te denken om een USB hub met voeding te kopen en daar alles op aan te sluiten.

Zal dit helpen?

Zeker weten!

De voeding die ik nu gebruik, is 5V - 3A - 65 Watt. Lijkt me genoeg, maar het scherm en de SSD worden door de Pi gevoed, dus misschien dat daarom de Pi elke keer ging rebooten.

Zou goed kunnen

Een andere vraag is dan of een SSD wel een powerloss overleeft en niet net als een SD kaart of USB stick ook corrupt raakt.

Dat is een heel interessant onderwerp waar ik dol op ben, maar niemand nog wat om lijkt te geven op wat Server/Workstation/OpenZFS NAS gebruikers na

Je hebt namelijk meerdere types SSD's :
A. Zonder Cache RAM
B. Met Cache RAM
C. Met Cache RAM en Elco's aan boord die bij stroomverlies twee dingen kunnen doen :
1. Alleen de "Index" van de SSD beschermen.
2. Alles beschermen en dus ook de data in de Cache RAM bij de volgende boot gereed houden !!

Wat je eigenlijk als SSD wilt is dus Type C want die zijn gewoon het beste als je data je lief is

Maar...

Van al die hippe bekende SSD's die men over het algemeen tegenwoordig koopt en helaas ook door een heleboel bekende merken worden gemaakt is 98% van het Type A of Type B helaas !!!

Om je wat Type A voorbeelden te geven :
- WD Green SSD's
- Kingston A2000
- Alle andere goedkope rotzooi...

Maar ook dure SSD's hebben dat probleem, echter zijn dit Type B SSD's :
- WD Black Series
- Samsung 850 Pro en 980 Pro achtigen.
- Whatever iets van Gaming in de naam heeft of heel veel gamers zogenaamd als helemaal geweldig bestempelen...


Maar wat zijn dan WEL fatsoenlijke SSD's zal je nu ongetwijfeld denken

Nou...

Die kosten een flinke duit en zijn dus over het algemeen op de ECHTE Pro markt gericht, echter waren er in het verleden een aantal relatief betaalbare pareltjes die ik nog steeds zeer lief en daarom ook nog steeds gebruik en al jarenlang in mijn Workstation/Game PC zitten :
- Intel 320 Series = Type C #2 SSD
- Crucial M500 = Type C #1 SSD
Van deze laatste was er ook een M500 DC versie die stiekem een Pro model van Micron was en een Type C #2 SSD was

Dat waren overigens allemaal SATA modellen, maar er zijn tegenwoordig ook nieuwe NVMe modellen tekoop in zowel M.2 PCIe x4 en x8 uitvoering als 2,5 inch U.2 uitvoering :
- product: Intel DC P3700 PCI Express
- product: Intel DC P3700 2,5"
Dit was één van de eerste NVMe SSD's die liet zien wat NVMe in de praktijk kon doen!

Ondertussen zijn er natuurlijk veel meer zoals deze : uitvoering: Samsung PM9A3 M.2 960GB
Daar zie je heel mooi 6 chipjes die de Stroomverlies regelen

Wat andere random modellen van het oh zo populaire Samsung voor de liefhebbers :
- uitvoering: Samsung PM893 240GB
- uitvoering: Samsung PM1653 960GB
- uitvoering: Samsung PM983 M.2 960GB <= Check die 4 chipjes!


En nog als laatste :

Hoe beschermt dan bijvoorbeeld een Kingston A2000 of Samsung 850 Pro of 980 Pro de boel tegen stroomverlies

Dat gebeurt via een zogenaamde "Write Back" methode die een beetje lijkt op een File System Check dat je OS doet nadat die niet fatsoenlijk is afgesloten.
Daarbij wordt dan de data en de index van al die data op de SSD dus op fouten gecheckt en dan heb je kans dat een stukje corrupt weggeschreven data wordt weggegooid !!

LET OP : Dit is dus geen File System Check, want dat doet je OS nadat je systeem is geboot !!


Zoo... dat was het verhaal denk ik wel zo'n beetje

En als dit niet op te lossen is, wat is dan een goed alternatief om Home assistant te draaien?

Ik kwam laatst tijdens wat browsen dit tegen : v&a aangeboden: Touchscreen panel PC (17") voor home assistent / pfSense / Kassa

Dus een All-in-One Kassa PC met Touchscreen van 17 inch

Lijkt me wel gaaf voor een heleboel dingen, maar heb daar effe geen plek voor dus misschien wat voor jou ??

[DjoeC]

@Xyphoid klinkt mij toch als vooral een voedingsprobleem. 65W zegt niks bij max 5V 3A want da's maar 15W. Wat heeft je display nodig? Ik zou het display apart voeden en de pi met een echte Raspberry voeding.

Vwb de SSD sluit ik me aan bij @nero355 . Gebruik een echte SSD. ik gebruik een Samsung T7 2TB. Nog geen enkel probleem bij crashes. De door @nero355 genoemde MX500 heb ik jaren gebruikt in m'n PC, die heeft een beperkte power failure beveiliging. SSD en pi doen het prima op de 3A voeding van Raspberry, ook met een Zigbee stick erbij.

[nero355]

DjoeC schreef op dinsdag 24 september 2024 @ 20:03:
De door @nero355 genoemde MX500 heb ik jaren gebruikt in m'n PC, die heeft een beperkte power failure beveiliging.

Die noem ik niet, maar is opzich ook wel een redelijke oplossing inderdaad, want die heeft ook iets van bescherming tegen stroomverlies, maar dan weer op een hele andere manier dan de rest, echter nog steeds IMHO beter dan de "Write Back" methode

Zit hier ook in één van de laptops al een aantal jaren zonder enig probleem!

[DjoeC]

nero355 schreef op dinsdag 24 september 2024 @ 22:51:
[...]

Die noem ik niet

Sorry, ik las M500 als MX500..... Beiden van Crucial al lijkt de M500 van een oudere, nog solidere generatie.

[nero355]

DjoeC schreef op woensdag 25 september 2024 @ 12:33:
Sorry, ik las M500 als MX500..... Beiden van Crucial al lijkt de M500 van een oudere, nog solidere generatie.

YUP!

Die had nog MLC i.p.v. TLC NAND

[Raven]

nero355 schreef op dinsdag 24 september 2024 @ 18:36:
Die kosten een flinke duit en zijn dus over het algemeen op de ECHTE Pro markt gericht, echter waren er in het verleden een aantal relatief betaalbare pareltjes die ik nog steeds zeer lief en daarom ook nog steeds gebruik en al jarenlang in mijn Workstation/Game PC zitten :
- Intel 320 Series = Type C #2 SSD
- Crucial M500 = Type C #1 SSD
Van deze laatste was er ook een M500 DC versie die stiekem een Pro model van Micron was en een Type C #2 SSD was

* Raven heeft 2e hands 40GB Intel 320's aan de Pi's hangen, doen het prima

[nero355]

Raven schreef op woensdag 25 september 2024 @ 17:28:
* Raven heeft 2e hands 40GB Intel 320's aan de Pi's hangen, doen het prima

NICE!!!

Zijn tweedehands ook heel populair voor OpenZFS gebruik
Maar er zijn ook latere SATA modellen die voor hetzelfde doel worden gebruikt!

[Xyphoid]

nero355 schreef op dinsdag 24 september 2024 @ 18:36:

[...]

Ik kwam laatst tijdens wat browsen dit tegen : v&a aangeboden: Touchscreen panel PC (17") voor home assistent / pfSense / Kassa

Dus een All-in-One Kassa PC met Touchscreen van 17 inch

Lijkt me wel gaaf voor een heleboel dingen, maar heb daar effe geen plek voor dus misschien wat voor jou ??

Thanks voor de info! Ik ga gelijk browsen naar een goede SSD en USB hub.
Die kassa is wel grappig, maar 6,5 kilo aan de muur is ook weer zo overdreven...

[Raven]

nero355 schreef op woensdag 25 september 2024 @ 18:23:
[...]

NICE!!!

Zijn tweedehands ook heel populair voor OpenZFS gebruik
Maar er zijn ook latere SATA modellen die voor hetzelfde doel worden gebruikt!

Wel een klein minpuntje, vergeten te vermelden, dit type SSD plus de gebruikte USB-SATA adapter trekken nét iets te veel stroom bij inschakelen. De instelling voor hogere stroomlimiet wordt helaas niet vroeg genoeg actief, dus hubje met aparte voeding er bij nodig.

[babbelbox]

Ik gebruik deze adapter en heb nog geen issues gehad met voeding of wat. Met diverse SSD disks in gebruik.

[Raven]

@babbelbox De voeding is het probleem niet (die kan het met gemak aan), de RPi's USB-poorten hebben standaard een limiet van 600mA en met een instelling kan dat 1200mA zijn, alleen lijkt die instelling niet vroeg genoeg actief te worden. Met de SSD+USB-adapter achter een hubje gaat het goed.

[babbelbox]

Uit jouw vorige post maakte ik op dat de disk+adapter te veel stroom nodig hebben om knap te starten.
Ik moet toegeven dat ik er niet zo in thuis ben qua stroom verbruik, maar de adapter die ik dus linkte is qua functionaliteit gelijk aan de jouwe, maar ik ervaar geen probleem, en heb ook geen aanpassingen gedaan voor meer vermogen over USB.
Zoals gezegd, weinig kunde over benodigd vermogen voor de diverse SSD disks of adapters.

[ Voor 11% gewijzigd door babbelbox op 27-09-2024 20:20 ]

[DjoeC]

Raven schreef op vrijdag 27 september 2024 @ 19:44:
@babbelbox De voeding is het probleem niet (die kan het met gemak aan), de RPi's USB-poorten hebben standaard een limiet van 600mA en met een instelling kan dat 1200mA zijn, alleen lijkt die instelling niet vroeg genoeg actief te worden. Met de SSD+USB-adapter achter een hubje gaat het goed.

Mijn oude Intel X25's in externe 2.5" kastjes deden het overigens prima op een Pi3B(+). En ik ga er eigenlijk van uit dat die (13 jaar oude) SSD's niet zoveel minder verbruiken dan een "moderne" SSD. Mijn Samsungs lopen allemaal tegen een Pi4 met originele 3A Raspi PSU.

Ik kan me niet herinneren dat ik de voeding omhoog heb gezet - volgens mij is dat alleen bij de Pi5 een optie als die detecteert dat je niet de originele 5A PSU gebruikt.

[Raven]

DjoeC schreef op zaterdag 28 september 2024 @ 12:04:
[...]

Mijn oude Intel X25's in externe 2.5" kastjes deden het overigens prima op een Pi3B(+). En ik ga er eigenlijk van uit dat die (13 jaar oude) SSD's niet zoveel minder verbruiken dan een "moderne" SSD. Mijn Samsungs lopen allemaal tegen een Pi4 met originele 3A Raspi PSU.

Tsja, zonder hub lijkt de adapter (en daarmee SSD) niet in te schakelen, met hub wel. De enige Pi's waarmee ik dit probleem niet heb zijn de 0W, waar een

aan vast zit en een RPi3 met

waarmee de USB devices rechtstreeks door de(zelfde type) voeding gevoed worden en niet via de Pi's USB-poorten.

DjoeC schreef op zaterdag 28 september 2024 @ 12:04:
[...]
Ik kan me niet herinneren dat ik de voeding omhoog heb gezet - volgens mij is dat alleen bij de Pi5 een optie als die detecteert dat je niet de originele 5A PSU gebruikt.

De optie "max_usb_current" bestaat al jaren

[DjoeC]

Raven schreef op zaterdag 28 september 2024 @ 12:38:
[...]

Tsja, zonder hub lijkt de adapter (en daarmee SSD) niet in te schakelen, met hub wel. De enige Pi's waarmee ik dit probleem niet heb zijn de 0W, waar een
[Afbeelding: Zero4U: 4-Port USB Hub for Raspberry Pi Zero]
aan vast zit en een RPi3 met
[Afbeelding: BIG7: 7-Port MTT USB Hub for Raspberry Pi (Rev 2)]
waarmee de USB devices rechtstreeks door de(zelfde type) voeding gevoed worden en niet via de Pi's USB-poorten.


[...]

De optie "max_usb_current" bestaat al jaren

Specs zijn:
Maximum Output Current: 2A for all ports in self-power mode, 500mA for all ports in bus-power mode
en
Maximum Output Current: 3A for all ports in self-power mode, 500mA for all ports in bus-power mode

Ik vermoed dus dat je de pogo pins gebruikt anders zit je met 500mA wel erg aan de lage kant voor een hub, die zal zelf ook wel "iets" verbruiken als ie uit stby komt. En dan denk ik: Misschien zou je de hub wel moeten voeden vanaf de 5V meteen op de ingang ipv via de pogo pins (hack) of een eigen voeding moeten geven.

[Raven]

@DjoeC De hubs van die pics maken gebruik van de pogo-pins, oftewel 5V-pins van de USB-poorten hangen rechtstreeks aan de voeding (dus niet via de RPi), als ik de SSD's aan die hubs hang is er niks aan de hand.

De andere RPi's, die niet dergelijke hubs hebben, krijgen de rechtstreeks aangesloten SSD niet ingeschakeld maar als ik er een rondslingerende hub a la

aanhang en de SSD daar weer aan dan is er niks aan de hand.

Daarom denk ik dus dat de inschakelstroom net iets te hoog is voor wat de USB-poorten van die RPi's standaard kunnen leveren.

[DjoeC]

@Raven Bijzonder. Maar, natuurlijk wel mogelijk dat het aan de piek inschakelstroom ligt: Pi en SSD zijn gelijktijdig hard aan t werk.

Nou heb ik (ooit...) bij een externe 4TB WD-HD (aan Pi3B) via de USB poort een config parameter gebruikt waarmee je het opstarten iets kon vertragen. Misschien kan dat een optie zijn om eens te proberen?

Ik kan mijn notities van toen zo even niet vinden maar dit https://forums.raspberrypi.com/viewtopic.php?t=41911 lijkt er erg op....

<edit> In m'n hoofd zwerft een waarde van "100" (milliseconden) rond.

[ Voor 6% gewijzigd door DjoeC op 28-09-2024 14:25 ]

[nero355]

DjoeC schreef op zaterdag 28 september 2024 @ 12:04:
Mijn oude Intel X25's in externe 2.5" kastjes deden het overigens prima op een Pi3B(+).

En ik ga er eigenlijk van uit dat die (13 jaar oude) SSD's niet zoveel minder verbruiken dan een "moderne" SSD.

Mijn Samsungs lopen allemaal tegen een Pi4 met originele 3A Raspi PSU.

Onder andere vanwege het verhaal dat ik eerder heb gepost zal de Intel waarschijnlijk ietsjes meer verbruiken dan de rest

De zuinigste SATA SSD die ik ken is de WD Green in principe, maar er zijn genoeg andere nieuwerwetse SSD modellen die zeer dicht in de buurt komen!

[DjoeC]

nero355 schreef op zaterdag 28 september 2024 @ 15:07:
[...]

Onder andere vanwege het verhaal dat ik eerder heb gepost zal de Intel waarschijnlijk ietsjes meer verbruiken dan de rest

De zuinigste SATA SSD die ik ken is de WD Green in principe, maar er zijn genoeg andere nieuwerwetse SSD modellen die zeer dicht in de buurt komen!

Dat lijkt dus best wel mee te vallen: Wikipedia: X25-M 150mA ofwel < 1W voor de Intel vs ~ 2W voor de WD Green: https://www.digit.in/revi...-240-gb-review-57243.html

[nero355]

DjoeC schreef op zaterdag 28 september 2024 @ 15:16:
Dat lijkt dus best wel mee te vallen: Wikipedia: X25-M 150mA ofwel < 1W voor de Intel vs ~ 2W voor de WD Green: https://www.digit.in/revi...-240-gb-review-57243.html

Interessant, maar het is maar net welke waardes je met elkaar vergelijkt : IDLE scheelt een hoop!

En eigenlijk moet je ze ergens in een Review tegenkomen waarbij beiden op dezelfde manier zijn getest

/EDIT :

DjoeC schreef op zaterdag 28 september 2024 @ 15:52:
Zo'n vergelijking zal er niet zijn. Daar zitten TE veel jaren tussen.....

Yep!

[ Voor 16% gewijzigd door nero355 op 28-09-2024 16:51 ]

[DjoeC]

nero355 schreef op zaterdag 28 september 2024 @ 15:25:
[...]

Interessant, maar het is maar net welke waardes je met elkaar vergelijkt : IDLE scheelt een hoop!

En eigenlijk moet je ze ergens in een Review tegenkomen waarbij beiden op dezelfde manier zijn getest

Zo'n vergelijking zal er niet zijn. Daar zitten TE veel jaren tussen.....

[Piet91]

Probleempje met mijn een uitvoering: Raspberry Pi model B (512MB).
Hier heb ik ruim een week geleden Tailscale op geïnstalleerd (ook als subnet router).
Deze hangt in het netwerk van familie van mij zodat die een aantal IP-camera's kunnen zien.

Maar al vrij snel stond deze RPi niet meer connected bij Tailscale. Ben toen langs geweest, stekker eruit en weer er in en toen leek het weer te doen. Maar al vrij snel weer disconnected.
Daarna is ie nog eenmaal kort (misschien enkele minuten) connected geweest volgens Tailscale.

Heb al wat rondgezocht, maar heeft iemand een idee wat het probleem hier kan zijn?
Een probleem met geheugenkaart of voeding zou wel héél toevallig zijn, want exact dezelfde hardware heeft jarenlang prima gedraaid met Wireguard.

Ik kan hier op afstand, ingelogd bij Tailscale; zo ook geen logs o.i.d. vinden.

[Raven]

@Piet91 Hangt er geen monitor aan? Misschien handig om te doen, als er iets misgaat zouden er meldingen op de monitor kunnen verschijnen, daar dan een foto van naar je laten (Whats)appen zodat je daar op kan Googlen.

[Piet91]

Raven schreef op dinsdag 1 oktober 2024 @ 17:31:
@Piet91 Hangt er geen monitor aan? Misschien handig om te doen, als er iets misgaat zouden er meldingen op de monitor kunnen verschijnen, daar dan een foto van naar je laten (Whats)appen zodat je daar op kan Googlen.

Nee, hij ligt daar gewoon in de netwerkkast.
Ik denk dat ik 'm maar even ophaal, hier aan het netwerk hang en dan kijken wat er gebeurd.

[Piet91]

Heb de RPi hier aan het netwerk gehangen en ook hier valt de connectie weg na een tijdje.
Er is nog netwerkverkeer (ik kan de RPi pingen) en ik kan bijvoorbeeld ook met Putty d.m.v. SSH inloggen maar dat laatste is tergend langzaam.

Eens kijken of ik ergens logs o.i.d. kan vinden. Of misschien eens ander geheugenkaartje proberen o.i.d.

[Piet91]

Ik denk dat er met de RPi wat aan de hand is want pingen gaat prima, maar benaderen via Putty/WinSCP gaat ook langzaam.

[ Voor 6% gewijzigd door Piet91 op 02-10-2024 13:44 ]

[DjoeC]

Piet91 schreef op woensdag 2 oktober 2024 @ 13:39:
Ik denk dat er met de RPi wat aan de hand is want pingen gaat prima, maar benaderen via Putty/WinSCP is tergend langzaam.

Ik denk dat je toch de relevante logs eens zou moeten bekijken. Mij is niet duidelijk of de service Tailscale bij je uitvalt/je netwerk verbindingen verstiert/iets anders.

Misschien moet je voordat je concludeert dat het aan de Pi ligt Tailscale eens complete moeten verwijderen. Zeker als je het niet in een container draait zal dat product z'n tengels best wel diep in je netwerk configuratie hebben....

O ja, of SD kaartje misschien aan het overlijden? Veroorzaakt Tailscale soms erg veel IO?

Ik heb mijn VPN van buiten als Wireguard naar de Fritzbox staan, daarmee wordt ik gewoon een standaard client naar het lokale netwerk waarna ik alles verder "lokaal" af kan.

[Piet91]

@DjoeC Ik heb uiteindelijk wat Tailscale logs kunnen vinden. Ergens in die 3500+ regels kan ik op een gegeven moment wel zien dat er iets niet goed gaat maar wat precies wordt mij niet helemaal duidelijk.
Gaat mij iets boven het hoofd.

Ondertussen heb ik nog een exact dezelfde setup gemaakt (had nog een zelfde RPi liggen, daar opnieuw RPi OS op gezet en Tailscale geïnstalleerd (op de officiële manier: https://tailscale.com/download/linux/rpi-bullseye). Zeg maar een kopie van de eerste/andere.
Beide systemen hangen nu hier in het netwerk en nu aankijken wat ze gaan doen.
Of die 'kapotte' versie weer wegvalt of niet. Ondertussen (hoewel ik er niets mee heb gedaan) hangt die ook al een aantal uur online en connected.

Zit overigens met een schuin oog te kijken naar een goedkope 2e-hands hardware voor hun, iets als een thin-client, NUC of HP/Dell PC om daar iets als Proxmox (mij nog niet echt bekend) of ander OS op te installeren zodat hetzelfde systeem op termijn ook iets als een Omada/Unifi controller kan draaien en iets voor backup van PC/smartphones. Maar dat is een rabbit hole waar je je helemaal in kunt verliezen zo'n groot aanbod daar voor is.

[ Voor 3% gewijzigd door Piet91 op 02-10-2024 15:31 ]

[nero355]

Piet91 schreef op woensdag 2 oktober 2024 @ 15:26:
Zit overigens met een schuin oog te kijken naar een goedkope 2e-hands hardware voor hun, iets als een thin-client, NUC of HP/Dell PC om daar iets als Proxmox (mij nog niet echt bekend) of ander OS op te installeren zodat hetzelfde systeem op termijn ook iets als een Omada/Unifi controller kan draaien en iets voor backup van PC/smartphones.

Maar dat is een rabbit hole waar je je helemaal in kunt verliezen zo'n groot aanbod daar voor is.

In principe heb je gelijk, maar als je tweedehands shopt voor zoiets dan wordt het een stuk simpeler en ga je gewoon de "grootste gemak toer" op :

- Prijs zo laag mogelijk.
- Eventueel iemand die in de buurt woont.
- Eventueel niet te oud model qua SoC/CPU/Chipset.
- Of simpelweg zo zuinig mogelijk!

En gaan met die banaan!

Dus blader effe categorie: Pc's of categorie: Barebones door

[DjoeC]

Piet91 schreef op woensdag 2 oktober 2024 @ 15:26:
@DjoeC Ik heb uiteindelijk wat Tailscale logs kunnen vinden. Ergens in die 3500+ regels kan ik op een gegeven moment wel zien dat er iets niet goed gaat maar wat precies wordt mij niet helemaal duidelijk.
Gaat mij iets boven het hoofd.

Ondertussen heb ik nog een exact dezelfde setup gemaakt (had nog een zelfde RPi liggen, daar opnieuw RPi OS op gezet en Tailscale geïnstalleerd (op de officiële manier: https://tailscale.com/download/linux/rpi-bullseye). Zeg maar een kopie van de eerste/andere.
Beide systemen hangen nu hier in het netwerk en nu aankijken wat ze gaan doen.
Of die 'kapotte' versie weer wegvalt of niet. Ondertussen (hoewel ik er niets mee heb gedaan) hangt die ook al een aantal uur online en connected.

Zit overigens met een schuin oog te kijken naar een goedkope 2e-hands hardware voor hun, iets als een thin-client, NUC of HP/Dell PC om daar iets als Proxmox (mij nog niet echt bekend) of ander OS op te installeren zodat hetzelfde systeem op termijn ook iets als een Omada/Unifi controller kan draaien en iets voor backup van PC/smartphones. Maar dat is een rabbit hole waar je je helemaal in kunt verliezen zo'n groot aanbod daar voor is.

Zou je dat stukje van het log kunnen plakken (in MO tags als code)? Misschien dat iemand hier begrijpt wat er aan de hand is?

Enneh, thinclient/watdan ook - wat wil je op de remote lokatie precies bereiken? Ik vermoed dat het om "ouderen" gaat waar je hulp wilt bieden? In dat geval KISS.... Als het niet werkt mag jij weer op pad. Als er op een verkeerd knopje gedrukt wordt mag jij op pad. Blijf eenvoudige apparatuur en oplossingen gebruiken.....

Backups laat ik door Nextcloud clients regelen naar een container op een Raspberry (met 2TB SSD). Gedeelde agenda trouwens ook ;-) Geen externe cloud.

<aanvulling> @Piet91 als je een stuk log plakt - kijk eerst even dat je bijvoorbeeld IP nummers tot bijvoorbeeld 192.xx.xx.xx omvormt en evt gevoelige info <bleep> maakt.

[ Voor 4% gewijzigd door DjoeC op 02-10-2024 16:51 ]

[Piet91]

nero355 schreef op woensdag 2 oktober 2024 @ 16:30:
[...]

In principe heb je gelijk, maar als je tweedehands shopt voor zoiets dan wordt het een stuk simpeler en ga je gewoon de "grootste gemak toer" op :

- Prijs zo laag mogelijk.
- Eventueel iemand die in de buurt woont.
- Eventueel niet te oud model qua SoC/CPU/Chipset.
- Of simpelweg zo zuinig mogelijk!

En gaan met die banaan!

Dus blader effe categorie: Pc's of categorie: Barebones door

Nou ja; ik ging van een 2 tientjes HP T530 voor puur Tailscale en controller naar Optiplex systemen met ruimte voor een 2.5" schijf en alles daar tussen in.

Ondertussen heb ik ook een 2e RPi opgezet; exact zelfde hardware en installatie. Beide systemen (laten we ze RPi1 en RPi2 noemen) verbonden zich met Tailscale en vielen weer weg.

Pingen vanaf mjn laptop naar beide systemen gaat prima.
Verbinden via Putty of WinSCP gaat, maar het tot stand komen van de verbinding gaat traag.
WinSCP geeft vaak aan dat host niet aan het communiceren is voor x-aantal seconden en komt dan vaak wel weer terug.

Probeer er nu weer mee bezig te gaan, maar RPi1 is nog zichtbaar in ons thuisnetwerk (in router en ook met de app WiFiman op telefoon) maar RPi2 is nergens zichtbaar. Beide systemen lijken wel wat netwerkverkeer te doen want de LED's van de switchpoorten knipperen.
Maar nu probeer ik met Putty op RPi1 in te loggen, naast dat dit tergend langzaam gaat werd ik er ook eerst 2 keer uitgegooid (server unexpectedly closed network connection).
Nu ben ik wel door maar alles is tergend langzaam.
Doe:

code:

sudo apt-get update
sudo apt-get install tailscale

En zit momenteel op dit:


Zoals gezegd, tergend langzaam; toen ik dit deed bij de verse installatie kwam ik heir nog vrij vlot door heen.
Probeer met Putty een 2e verbinding op te zetten om naar de CPU/Memory e.d. te kijken (om te kijken of dat misschien overbelast wordt) maar die 2e verbinding kan ik niet eens opzetten. Putty blijft zwart of als ik net de username heb ingevoerd klapt de verbinding weer weg.

Ik snap er in ieder geval helemaal niets meer van. Beide systemen zijn opgezet en geïnstalleerd precies zoals Tailscale het aangeeft en in mijn netwerk heb ik ook niets apart ingesteld. (sowieso bij de familie waar RPi1 stond niet). Hier alleen op de router DNS bij Google gezet.

@DjoeC Hier bijvoorbeeld een stukje log (tailscaled.service) van RPi1 van gisteren toen de verbinding met Tailscale om 17:10 uur eruit viel:

code:

Oct 03 15:25:30 raspberrypi tailscaled[1282]: derphttp.Client.Recv: connecting to derp-14 (ams)
Oct 03 15:25:35 raspberrypi tailscaled[1282]: wgengine: set DNS config again after major link change
Oct 03 15:25:42 raspberrypi tailscaled[1282]: onPortUpdate(port=41641, network=udp6)
Oct 03 15:25:42 raspberrypi tailscaled[1282]: onPortUpdate(port=41641, network=udp4)
Oct 03 15:25:42 raspberrypi tailscaled[1282]: Rebind; defIf="eth0", ips=[192.168.1.112/24 fe80::3b84:a9ac:4e6a:3ba2/64]
Oct 03 15:25:42 raspberrypi tailscaled[1282]: magicsock: closing connection to derp-14 (rebind-no-localaddr), age 12s
Oct 03 15:25:42 raspberrypi tailscaled[1282]: magicsock: closing connection to derp-16 (rebind-no-localaddr), age 15s
Oct 03 15:25:42 raspberrypi tailscaled[1282]: magicsock: closing connection to derp-1 (rebind-no-localaddr), age 14s
Oct 03 15:25:42 raspberrypi tailscaled[1282]: magicsock: 0 active derp conns
Oct 03 15:25:43 raspberrypi tailscaled[1282]: dns: Set: {DefaultResolvers:[] Routes:{tail1efe5b.ts.net.:[] ts.net.:[199.247.155.53 2620:111:8007::53]}+65arpa SearchDomains:[tail1efe5b.ts.net.] Hosts:5}
Oct 03 15:25:49 raspberrypi tailscaled[1282]: magicsock: adding connection to derp-14 for home-keep-alive
Oct 03 15:25:49 raspberrypi tailscaled[1282]: dns: Resolvercfg: {Routes:{.:[8.8.8.8 8.8.4.4] ts.net.:[199.247.155.53 2620:111:8007::53]} Hosts:5 LocalDomains:[tail1efe5b.ts.net.]+65arpa}
Oct 03 15:25:49 raspberrypi tailscaled[1282]: dns: OScfg: {Nameservers:[100.100.100.100] SearchDomains:[tail1efe5b.ts.net.] }
Oct 03 15:25:49 raspberrypi tailscaled[1282]: magicsock: 1 active derp conns: derp-14=cr0s,wr0s
Oct 03 15:25:49 raspberrypi tailscaled[1282]: magicsock: endpoints changed: 217.121.141.84:41641 (stun), 192.168.1.112:41641 (local)
Oct 03 15:25:50 raspberrypi tailscaled[1282]: derphttp.Client.Recv: connecting to derp-14 (ams)
Oct 03 15:25:51 raspberrypi tailscaled[1282]: wgengine: set DNS config again after major link change
Oct 03 15:25:51 raspberrypi tailscaled[1282]: onPortUpdate(port=41641, network=udp6)
Oct 03 15:25:51 raspberrypi tailscaled[1282]: onPortUpdate(port=41641, network=udp4)
Oct 03 15:25:51 raspberrypi tailscaled[1282]: Rebind; defIf="eth0", ips=[192.168.1.112/24 fe80::3b84:a9ac:4e6a:3ba2/64]
Oct 03 15:25:51 raspberrypi tailscaled[1282]: magicsock: closing connection to derp-14 (rebind-no-localaddr), age 1s
Oct 03 15:25:51 raspberrypi tailscaled[1282]: magicsock: 0 active derp conns
Oct 03 15:25:51 raspberrypi tailscaled[1282]: magicsock: adding connection to derp-14 for home-keep-alive
Oct 03 15:25:51 raspberrypi tailscaled[1282]: magicsock: 1 active derp conns: derp-14=cr0s,wr0s
Oct 03 15:25:51 raspberrypi tailscaled[1282]: derphttp.Client.Recv: connecting to derp-14 (ams)
Oct 03 15:25:52 raspberrypi tailscaled[1282]: DetectCaptivePortal(found=false)
Oct 03 15:26:02 raspberrypi tailscaled[1282]: magicsock: [0x352be08] derp.Recv(derp-14): derphttp.Client.Recv connect to region 14 (ams): context deadline exceeded: write tcp4 192.168.1.112:45096->176.58.93.154:443: use of closed network connection
Oct 03 15:26:02 raspberrypi tailscaled[1282]: derphttp.Client.Recv: connecting to derp-14 (ams)
Oct 03 15:26:06 raspberrypi tailscaled[1282]: magicsock: derp-14 connected; connGen=1
Oct 03 15:26:07 raspberrypi tailscaled[1282]: health(warnable=no-derp-connection): ok
Oct 03 15:29:47 raspberrypi tailscaled[1282]: monitor: time jumped (probably wake from sleep); synthesizing major change event
Oct 03 15:30:39 raspberrypi tailscaled[1282]: LinkChange: major, rebinding. New state: interfaces.State{defaultRoute=eth0 ifs={eth0:[192.168.1.112/24 llu6] tailscale0:[100.97.114.32/32 fd7a:115c:a1e0::fa01:7220/128 llu6]} v4=true v6=false}
Oct 03 15:32:24 raspberrypi tailscaled[1282]: dns: Set: {DefaultResolvers:[] Routes:{tail1efe5b.ts.net.:[] ts.net.:[199.247.155.53 2620:111:8007::53]}+65arpa SearchDomains:[tail1efe5b.ts.net.] Hosts:5}
Oct 03 15:38:41 raspberrypi tailscaled[1282]: control: map response long-poll timed out!
Oct 03 17:07:38 raspberrypi tailscaled[1282]: health(warnable=mapresponse-timeout): error: Tailscale hasn't received a network map from the coordination server in 2m15s.
Oct 03 17:10:35 raspberrypi tailscaled[1282]: logtail: upload: log upload of 261 bytes not-compressed failed: Post "https://log.tailscale.io/c/tailnode.log.tailscale.io/a06818b42802e9cceedab6d4eb8bc2de7e275ef1f084a917433b66543cc8685a": context deadline exceeded
Oct 03 17:14:50 raspberrypi tailscaled[1282]: portmapper: createOrGetMapping: write udp4 0.0.0.0:37162->192.168.1.1:5351: use of closed network connection
Oct 03 17:15:37 raspberrypi tailscaled[1282]: health(warnable=mapresponse-timeout): error: Tailscale hasn't received a network map from the coordination server in 3m23s.
Oct 03 17:15:45 raspberrypi tailscaled[1282]: health(warnable=mapresponse-timeout): error: Tailscale hasn't received a network map from the coordination server in 1h30m9s.
Oct 03 17:16:06 raspberrypi tailscaled[1282]: health(warnable=mapresponse-timeout): error: Tailscale hasn't received a network map from the coordination server in 1h38m35s.
Oct 03 17:18:38 raspberrypi tailscaled[1282]: magicsock: [0x352be08] derp.Recv(derp-14): derp.Recv: read tcp4 192.168.1.112:59992->176.58.93.154:443: i/o timeout
Oct 03 17:19:22 raspberrypi tailscaled[1282]: health(warnable=mapresponse-timeout): ok
Oct 03 17:20:01 raspberrypi tailscaled[1282]: dns: Resolvercfg: {Routes:{.:[8.8.8.8 8.8.4.4] ts.net.:[199.247.155.53 2620:111:8007::53]} Hosts:5 LocalDomains:[tail1efe5b.ts.net.]+65arpa}
Oct 03 17:20:17 raspberrypi tailscaled[1282]: monitor: time jumped (probably wake from sleep); synthesizing major change event
Oct 03 17:20:17 raspberrypi tailscaled[1282]: health: connectivity impacted; triggering captive portal detection
Oct 03 17:20:17 raspberrypi tailscaled[1282]: health: connectivity impacted; triggering captive portal detection
Oct 03 17:20:17 raspberrypi tailscaled[1282]: dns: OScfg: {Nameservers:[100.100.100.100] SearchDomains:[tail1efe5b.ts.net.] }
Oct 03 17:20:17 raspberrypi tailscaled[1282]: health(warnable=mapresponse-timeout): ok
Oct 03 17:20:17 raspberrypi tailscaled[1282]: health(warnable=mapresponse-timeout): error: Tailscale hasn't received a network map from the coordination server in 3m18s.
Oct 03 17:20:17 raspberrypi tailscaled[1282]: health: connectivity impacted; triggering captive portal detection
Oct 03 17:20:17 raspberrypi tailscaled[1282]: health: connectivity impacted; triggering captive portal detection
Oct 03 17:20:18 raspberrypi tailscaled[1282]: health(warnable=no-derp-connection): error: Tailscale could not connect to the 'Amsterdam' relay server. Your Internet connection might be down, or the server might be temporarily unavailable.
Oct 03 17:20:19 raspberrypi tailscaled[1282]: health: connectivity impacted; triggering captive portal detection
Oct 03 17:20:19 raspberrypi tailscaled[1282]: [RATELIMIT] format("health: connectivity impacted; triggering captive portal detection")
Oct 03 17:20:28 raspberrypi tailscaled[1282]: LinkChange: major, rebinding. New state: interfaces.State{defaultRoute=eth0 ifs={eth0:[192.168.1.112/24 llu6] tailscale0:[100.97.114.32/32 fd7a:115c:a1e0::fa01:7220/128 llu6]} v4=true v6=false}
Oct 03 17:20:28 raspberrypi tailscaled[1282]: derphttp.Client.Recv: connecting to derp-14 (ams)
Oct 03 17:20:30 raspberrypi tailscaled[1282]: control: controlhttp: failed dialing using DialPlan, falling back to DNS; errs=multiple errors:
Oct 03 17:20:30 raspberrypi tailscaled[1282]:         context deadline exceeded
Oct 03 17:20:30 raspberrypi tailscaled[1282]:         connection attempts aborted by context: context deadline exceeded
Oct 03 17:20:30 raspberrypi tailscaled[1282]:         context deadline exceeded
Oct 03 17:20:30 raspberrypi tailscaled[1282]:         context deadline exceeded
Oct 03 17:20:30 raspberrypi tailscaled[1282]:         context deadline exceeded
Oct 03 17:20:30 raspberrypi tailscaled[1282]:         context deadline exceeded
Oct 03 17:20:30 raspberrypi tailscaled[1282]:         context deadline exceeded
Oct 03 17:20:30 raspberrypi tailscaled[1282]:         context deadline exceeded
Oct 03 17:20:30 raspberrypi tailscaled[1282]:         context deadline exceeded
Oct 03 17:20:30 raspberrypi tailscaled[1282]:         context deadline exceeded
Oct 03 17:20:30 raspberrypi tailscaled[1282]:         context deadline exceeded
Oct 03 17:20:30 raspberrypi tailscaled[1282]:         context deadline exceeded
Oct 03 17:20:30 raspberrypi tailscaled[1282]:         context deadline exceeded
Oct 03 17:20:30 raspberrypi tailscaled[1282]:         context deadline exceeded
Oct 03 17:20:30 raspberrypi tailscaled[1282]:         context deadline exceeded
Oct 03 17:20:30 raspberrypi tailscaled[1282]:         context deadline exceeded
Oct 03 17:20:30 raspberrypi tailscaled[1282]:         context deadline exceeded
Oct 03 17:20:30 raspberrypi tailscaled[1282]:         context deadline exceeded
Oct 03 17:20:30 raspberrypi tailscaled[1282]:         context deadline exceeded
Oct 03 17:20:30 raspberrypi tailscaled[1282]:         context deadline exceeded
Oct 03 17:20:30 raspberrypi tailscaled[1282]:         context deadline exceeded
Oct 03 17:20:30 raspberrypi tailscaled[1282]:         context deadline exceeded
Oct 03 17:20:30 raspberrypi tailscaled[1282]:         context deadline exceeded
Oct 03 17:20:30 raspberrypi tailscaled[1282]:         context deadline exceeded
Oct 03 17:20:30 raspberrypi tailscaled[1282]:         context deadline exceeded
Oct 03 17:20:30 raspberrypi tailscaled[1282]:         context deadline exceeded
Oct 03 17:20:30 raspberrypi tailscaled[1282]:         context deadline exceeded
Oct 03 17:20:30 raspberrypi tailscaled[1282]:         context deadline exceeded
Oct 03 17:20:30 raspberrypi tailscaled[1282]:         context deadline exceeded
Oct 03 17:20:30 raspberrypi tailscaled[1282]:         context deadline exceeded
Oct 03 17:20:30 raspberrypi tailscaled[1282]:         context deadline exceeded
Oct 03 17:20:30 raspberrypi tailscaled[1282]:         context deadline exceeded
Oct 03 17:20:44 raspberrypi tailscaled[1282]: health: connectivity impacted; triggering captive portal detection
Oct 03 17:20:44 raspberrypi tailscaled[1282]: health: connectivity impacted; triggering captive portal detection
Oct 03 17:20:44 raspberrypi tailscaled[1282]: health: connectivity impacted; triggering captive portal detection
Oct 03 17:20:47 raspberrypi tailscaled[1282]: magicsock: [0x352be08] derp.Recv(derp-14): derphttp.Client.Recv connect to region 14 (ams): context deadline exceeded
Oct 03 17:20:52 raspberrypi tailscaled[1282]: Received error: PollNetMap: context canceled
Oct 03 17:20:52 raspberrypi tailscaled[1282]: wgengine: set DNS config again after major link change
Oct 03 17:20:56 raspberrypi tailscaled[1282]: derphttp.Client.Recv: connecting to derp-14 (ams)
Oct 03 17:20:57 raspberrypi tailscaled[1282]: monitor: time jumped (probably wake from sleep); synthesizing major change event
Oct 03 17:20:57 raspberrypi tailscaled[1282]: dns: Set: {DefaultResolvers:[] Routes:{tail1efe5b.ts.net.:[] ts.net.:[199.247.155.53 2620:111:8007::53]}+65arpa SearchDomains:[tail1efe5b.ts.net.] Hosts:5}
Oct 03 17:20:57 raspberrypi tailscaled[1282]: onPortUpdate(port=41641, network=udp6)
Oct 03 17:20:57 raspberrypi tailscaled[1282]: LinkChange: major, rebinding. New state: interfaces.State{defaultRoute=eth0 ifs={eth0:[192.168.1.112/24 llu6] tailscale0:[100.97.114.32/32 fd7a:115c:a1e0::fa01:7220/128 llu6]} v4=true v6=false}
Oct 03 17:20:57 raspberrypi tailscaled[1282]: onPortUpdate(port=41641, network=udp4)
Oct 03 17:21:09 raspberrypi tailscaled[1282]: Rebind; defIf="eth0", ips=[192.168.1.112/24 fe80::3b84:a9ac:4e6a:3ba2/64]
Oct 03 17:21:13 raspberrypi tailscaled[1282]: magicsock: closing connection to derp-14 (rebind-no-localaddr), age 1h55m18s
Oct 03 17:21:13 raspberrypi tailscaled[1282]: dns: Resolvercfg: {Routes:{.:[8.8.8.8 8.8.4.4] ts.net.:[199.247.155.53 2620:111:8007::53]} Hosts:5 LocalDomains:[tail1efe5b.ts.net.]+65arpa}
Oct 03 17:21:24 raspberrypi tailscaled[1282]: magicsock: 0 active derp conns
Oct 03 17:21:24 raspberrypi tailscaled[1282]: dns: OScfg: {Nameservers:[100.100.100.100] SearchDomains:[tail1efe5b.ts.net.] }
Oct 03 17:21:26 raspberrypi tailscaled[1282]: netcheck: DetectCaptivePortal(found=false)
Oct 03 17:21:26 raspberrypi tailscaled[1282]: magicsock: adding connection to derp-14 for home-keep-alive
Oct 03 17:21:26 raspberrypi tailscaled[1282]: magicsock: 1 active derp conns: derp-14=cr0s,wr0s
Oct 03 17:21:38 raspberrypi tailscaled[1282]: derphttp.Client.Recv: connecting to derp-14 (ams)
Oct 03 17:21:40 raspberrypi tailscaled[1282]: magicsock: [0x71b3ec8] derp.Recv(derp-14): derphttp.Client.Recv connect to region 14 (ams): context deadline exceeded: context deadline exceeded

De log van RPi2 is anders, maar kan ik hier niet in de post gooien want dan heeft de post teveel karakters volgens Tweakers.


Dit gaat mijn kennis geloof ik te boven. Of ik ga er maar weer Wireguard op zetten (liever niet; bij Caiway schijn je relatief vaak van WAN-IP te wisselen) of maar gewoon P2P verbinding met de camera's (dat heb ik liever helemaal niet).

[DjoeC]

@Piet91 Ik ben ook geen Raspi held. Paar dingen:
Ik vermoed dat je draait met 32-bit Raspian en niet met 64-bit Raspberry Os (debian), tenministe de sources bij update suggereren dat.
Dan is de vraag: Installeer je 32 of 64 bit Tailscale (je printscreen zegt dat er 2 versies zijn - geen idee hoe de versie gekozen wordt.

Dan zie ik deze melding:

code:

Tailscale hasn't received a network map from the coordination server

wat ik vooral voor Android zie terug komen: https://github.com/tailscale/tailscale/issues/13352 en https://www.reddit.com/r/...ork_map_response_timeout/

Grappig om te zien: Het lijkt een product dat als een wrapper om Wireguard zit. Het lijkt ook alsof het verkeer door Tailscale afgehandeld wordt, beetje Teamviewer achtig? Maar ik ken het produkt verder niet....

Ik zie ook een "captive portal" melding.

code:

health: connectivity impacted; triggering captive portal detection
en
[RATELIMIT] format("health: connectivity impacted; triggering captive portal detection")

Geen idee wat ze daarmee willen: https://tailscale.com/kb/1457/captive-portals
Ahh, ik zie dat je op een ander forum die vraag al gesteld hebt ;-) https://www.reddit.com/r/...ecting_and_disconnecting/
en da's misschien een betere plek dan hier....

Ik onthoud me dus even van verder commentaar, beter om iemand meer meer ervaring te laten antwoorden....

Zou je naar een ander soort oplossing willen - bijvoorbeeld voor je camera's - dan heb ik dat als volgt opgelost:
- Docker op een Raspi (in mijn geval een 4)
- Container qmcgaw/ddns-updater om je IP adres bij Cloudflare op orde te houden
- Container Nginx Proxy Manager als reverse proxy
- Container Fail2Ban

- eigen domeinnaam bij namecheap (een .nl rond de 70 euro voor 8 jaar door aan te vragen en meteen te verlengen.
- DNS inrichten via Cloudflare, alles https met Letencrypt certificaten.
- Op cloudflare voor je interen devices subdomeinen aanmaken
- in NPM subdomeinen doorverwijzen naar interne devices - eventueel met IP filtering en userid/wachtwoord bescherming
- in Cloudflare filters aanbrengen en alleen - bijvoorbeeld - IP adressen van je eigen provider doorlaten/bots blokkeren/continenten blokkeren/etc.

In je router poort 80/443 vanuit extern doorverwijzen naar NPM

Niet persee in die volgorde maar volgens mij ben je dan al een heel eind op weg naar een toegankelijk maar toch (redelijk) veilige toegang tot je netwerk.

Overigens, ook bij CAIway zou je een Fritzbox kunnen gebruiken als router met daarop Wireguard......

[Piet91]

DjoeC schreef op vrijdag 4 oktober 2024 @ 12:58:
@Piet91 Ik ben ook geen Raspi held. Paar dingen:
Ik vermoed dat je draait met 32-bit Raspian en niet met 64-bit Raspberry Os (debian), tenministe de sources bij update suggereren dat.

Klopt. De Raspberry Pi imager geeft ook alleen maar de keuze voor 32-bit voor deze 1st. gen RPi.
Kan kiezen uit Bookworm (recommended) of Bullseye (legacy)

Dan is de vraag: Installeer je 32 of 64 bit Tailscale (je printscreen zegt dat er 2 versies zijn - geen idee hoe de versie gekozen wordt.

Geen idee, ik zie dat ook nergens langskomen.

Dingetje is wel; ik installeer dus RPi OS gebaseerd op Bookworm, maar bij de Tailscale instructies kun je kiezen uit Stretch, Buster en Bullseye, niet uit Bookworm. Ik gebruik dan maar de instructies voor Bullseye.
Misschien een van de RPi's even weer schoon installeren met nu Bullseye (legacy) en de Tailscale instructies van Bullseye.

EDIT: zie hier wel instructies staan om Tailscale te installeren op Bookworm. Die instructies zijn ook iets anders dan bij Bullseye.

Grappig om te zien: Het lijkt een product dat als een wrapper om Wireguard zit. Het lijkt ook alsof het verkeer door Tailscale afgehandeld wordt, beetje Teamviewer achtig? Maar ik ken het produkt verder niet....

Klopt, Tailscale is inderdaad gebaseerd op Wireguard maar heeft een aantal voordelen t.o.v. Wireguard.

Ik zie ook een "captive portal" melding.

code:

health: connectivity impacted; triggering captive portal detection
en
[RATELIMIT] format("health: connectivity impacted; triggering captive portal detection")

Geen idee wat ze daarmee willen: https://tailscale.com/kb/1457/captive-portals
Ahh, ik zie dat je op een ander forum die vraag al gesteld hebt ;-) https://www.reddit.com/r/...ecting_and_disconnecting/
en da's misschien een betere plek dan hier....

Ik onthoud me dus even van verder commentaar, beter om iemand meer meer ervaring te laten antwoorden....

Zou je naar een ander soort oplossing willen - bijvoorbeeld voor je camera's - dan heb ik dat als volgt opgelost:
- Docker op een Raspi (in mijn geval een 4)
- Container qmcgaw/ddns-updater om je IP adres bij Cloudflare op orde te houden
- Container Nginx Proxy Manager als reverse proxy
- Container Fail2Ban

- eigen domeinnaam bij namecheap (een .nl rond de 70 euro voor 8 jaar door aan te vragen en meteen te verlengen.
- DNS inrichten via Cloudflare, alles https met Letencrypt certificaten.
- Op cloudflare voor je interen devices subdomeinen aanmaken
- in NPM subdomeinen doorverwijzen naar interne devices - eventueel met IP filtering en userid/wachtwoord bescherming
- in Cloudflare filters aanbrengen en alleen - bijvoorbeeld - IP adressen van je eigen provider doorlaten/bots blokkeren/continenten blokkeren/etc.

In je router poort 80/443 vanuit extern doorverwijzen naar NPM

Niet persee in die volgorde maar volgens mij ben je dan al een heel eind op weg naar een toegankelijk maar toch (redelijk) veilige toegang tot je netwerk.

Om eerlijk te zijn gaat dat ook wel wat boven mijn verstand. En al helemaal als het voor iemand anders (huishouden) is bedoeld.

Overigens, ook bij CAIway zou je een Fritzbox kunnen gebruiken als router met daarop Wireguard......

Zou kunnen, maar hou liever de eigen hardware van Caiway; minder gezeur.

[ Voor 3% gewijzigd door Piet91 op 04-10-2024 14:43 ]

[DjoeC]

@Piet91 Ik meen dat er in Bookworm nogal wat netwerk dingetjes veranderd zijn. Dus, misschien gewoon 1 van je 2 Pi's volgens de nieuwe instructies en dan vergelijken?

[Piet91]

DjoeC schreef op vrijdag 4 oktober 2024 @ 14:56:
@Piet91 Ik meen dat er in Bookworm nogal wat netwerk dingetjes veranderd zijn. Dus, misschien gewoon 1 van je 2 Pi's volgens de nieuwe instructies en dan vergelijken?

Ik ga dat inderdaad maar eens proberen. Heb toch niets te verliezen.

EDIT: geen succces. Klopt er binnen 5 minuten al uit. Probeer hier en op Reddit ook logs te plaatsen maar die zijn te lang/groot want bij het posten wordt de post geweigerd.

[ Voor 20% gewijzigd door Piet91 op 04-10-2024 17:17 ]

[nero355]

Piet91 schreef op vrijdag 4 oktober 2024 @ 12:14:
Of ik ga er maar weer Wireguard op zetten (liever niet; bij Caiway schijn je relatief vaak van WAN-IP te wisselen)

Daar heb je DynDNS/DuckDNS/enz. voor

_{(Is wel één van de redenen dat ik die club ga verlaten en naar een andere ISP overstap trouwens!)}

Piet91 schreef op vrijdag 4 oktober 2024 @ 14:14:
Klopt. De Raspberry Pi imager geeft ook alleen maar de keuze voor 32-bit voor deze 1st. gen RPi.
Kan kiezen uit Bookworm (recommended) of Bullseye (legacy)

Ik zit me eigenlijk een beetje af te vragen of zo'n Raspberry Pi 1B niet gewoon te weinig capaciteit heeft voor die hele toestand

Vooral de 256 MB RAM zou eventueel wel krap kunnen worden denk ik ?!
Of zeg ik nou wat raars ?

[Freee!!]

nero355 schreef op vrijdag 4 oktober 2024 @ 23:08:
[...]
Daar heb je DynDNS/DuckDNS/enz. voor

Duckdns heeft zelfs een Docker container om het gemakkelijk up-to-date te houden.

Ik zit me eigenlijk een beetje af te vragen of zo'n Raspberry Pi 1B niet gewoon te weinig capaciteit heeft voor die hele toestand

Vooral de 256 MB RAM zou eventueel wel krap kunnen worden denk ik ?!
Of zeg ik nou wat raars ?

Volgens mij zeg je daar wat zinnigs, maar ik kan het mis hebben, kleinste wat ik had draaien was een 3B+ met 1 GB RAM. Nu 3 4B's met 2 GB en 3 4B's met 8 GB, geen geheugenproblemen.

[ed1703]

nero355 schreef op vrijdag 4 oktober 2024 @ 23:08:
[...]

Daar heb je DynDNS/DuckDNS/enz. voor

_{(Is wel één van de redenen dat ik die club ga verlaten en naar een andere ISP overstap trouwens!)}


[...]

Ik zit me eigenlijk een beetje af te vragen of zo'n Raspberry Pi 1B niet gewoon te weinig capaciteit heeft voor die hele toestand

Vooral de 256 MB RAM zou eventueel wel krap kunnen worden denk ik ?!
Of zeg ik nou wat raars ?

Hij zegt in een eerdere post dat hij een 1B met 512 mb heeft.

Wel 3 jaar geleden maar toch wel relevant:

InvaderGlorch
•
3y ago
•
I have an lxc container running for it, it needs ~2GB of space for the boot disk and ~512MB of ram.

I have a pi1 and a pi zero also running it. almost zero resources needed.

Als het een resources probleem is zou je al denken aan ram en gaat hij flink lopen swappen?

[Piet91]

nero355 schreef op vrijdag 4 oktober 2024 @ 23:08:
Ik zit me eigenlijk een beetje af te vragen of zo'n Raspberry Pi 1B niet gewoon te weinig capaciteit heeft voor die hele toestand

Vooral de 256 MB RAM zou eventueel wel krap kunnen worden denk ik ?!
Of zeg ik nou wat raars ?

Van wat ik heb gelezen zouden de RPi's dit makkelijk moeten aankunnen.
Heb ook wel eens naar de CPU/Memory load gekeken en dit was hooguit enkele procenten.

Hier de bad-rpi_tailscale.log van vandaag, toen deze RPi er (volgens Tailscale) om 12:27 uit klapte:

code:

Oct 05 12:21:13 raspberrypi tailscaled[3209]: magicsock: [0x28d3c88] derp.Recv(derp-19): derphttp.Client.Recv connect to region 19 (mad): context deadline exceeded: write tcp4 192.168.1.146:43556->45.159.97.233:443: use of closed network connection
Oct 05 12:21:14 raspberrypi tailscaled[3209]: derphttp.Client.Recv: connecting to derp-19 (mad)
Oct 05 12:21:14 raspberrypi tailscaled[3209]: magicsock: home is now derp-4 (fra)
Oct 05 12:21:14 raspberrypi tailscaled[3209]: health(warnable=no-derp-connection): error: Tailscale could not connect to the 'Frankfurt' relay server. Your Internet connection might be down, or the server might be temporarily unavailable.
Oct 05 12:21:14 raspberrypi tailscaled[3209]: health: connectivity impacted; triggering captive portal detection
Oct 05 12:21:14 raspberrypi tailscaled[3209]: control: NetInfo: NetInfo{varies=false hairpin= ipv6=false ipv6os=true udp=true icmpv4=false derp=#4 portmap= link="" firewallmode="ipt-default"}
Oct 05 12:21:17 raspberrypi tailscaled[3209]: magicsock: [0x28d3448] derp.Recv(derp-4): derphttp.Client.Recv connect to region 4 (fra): context deadline exceeded: write tcp4 192.168.1.146:45016->185.40.234.77:443: use of closed network connection
Oct 05 12:21:17 raspberrypi tailscaled[3209]: derphttp.Client.Recv: connecting to derp-4 (fra)
Oct 05 12:21:17 raspberrypi tailscaled[3209]: magicsock: [0x28d3508] derp.Recv(derp-14): derphttp.Client.Recv connect to region 14 (ams): context deadline exceeded: write tcp4 192.168.1.146:49284->176.58.93.154:443: use of closed network connection
Oct 05 12:21:18 raspberrypi tailscaled[3209]: derphttp.Client.Send: connecting to derp-14 (ams)
Oct 05 12:21:18 raspberrypi tailscaled[3209]: [RATELIMIT] format("%s: connecting to derp-%d (%v)")
Oct 05 12:21:18 raspberrypi tailscaled[3209]: DetectCaptivePortal(found=false)
Oct 05 12:21:26 raspberrypi tailscaled[3209]: magicsock: [0x28d3c88] derp.Recv(derp-19): derphttp.Client.Recv connect to region 19 (mad): context deadline exceeded: write tcp4 192.168.1.146:40900->45.159.97.233:443: use of closed network connection
Oct 05 12:21:26 raspberrypi tailscaled[3209]: derphttp.Client.Recv: connecting to derp-19 (mad)
Oct 05 12:21:27 raspberrypi tailscaled[3209]: magicsock: home is now derp-14 (ams)
Oct 05 12:21:27 raspberrypi tailscaled[3209]: health(warnable=no-derp-connection): error: Tailscale could not connect to the 'Amsterdam' relay server. Your Internet connection might be down, or the server might be temporarily unavailable.
Oct 05 12:21:27 raspberrypi tailscaled[3209]: health: connectivity impacted; triggering captive portal detection
Oct 05 12:21:27 raspberrypi tailscaled[3209]: control: NetInfo: NetInfo{varies=false hairpin= ipv6=false ipv6os=true udp=true icmpv4=false derp=#14 portmap= link="" firewallmode="ipt-default"}
Oct 05 12:21:31 raspberrypi tailscaled[3209]: magicsock: derp.Send(127.3.3.40:14): derphttp.Client.Send connect to region 14 (ams): context deadline exceeded: write tcp4 192.168.1.146:49432->176.58.93.154:443: use of closed network connection
Oct 05 12:21:31 raspberrypi tailscaled[3209]: magicsock: [0x28d3448] derp.Recv(derp-4): derphttp.Client.Recv connect to region 4 (fra): context deadline exceeded: write tcp4 192.168.1.146:41426->185.40.234.77:443: use of closed network connection
Oct 05 12:21:31 raspberrypi tailscaled[3209]: derphttp.Client.Recv: connecting to derp-14 (ams)
Oct 05 12:21:31 raspberrypi tailscaled[3209]: derphttp.Client.Recv: connecting to derp-4 (fra)
Oct 05 12:21:31 raspberrypi tailscaled[3209]: [RATELIMIT] format("%s: connecting to derp-%d (%v)")
Oct 05 12:21:33 raspberrypi tailscaled[3209]: DetectCaptivePortal(found=false)
Oct 05 12:21:36 raspberrypi tailscaled[3209]: magicsock: [0x28d3c88] derp.Recv(derp-19): derphttp.Client.Recv connect to region 19 (mad): context deadline exceeded: derp.Client: failed to send client key: write tcp4 192.168.1.146:47058->45.159.97.233:443: use of closed network connection
Oct 05 12:21:39 raspberrypi tailscaled[3209]: magicsock: derp-4 connected; connGen=1
Oct 05 12:21:39 raspberrypi tailscaled[3209]: magicsock: derp-14 connected; connGen=1
Oct 05 12:21:39 raspberrypi tailscaled[3209]: health(warnable=no-derp-connection): ok
Oct 05 12:21:40 raspberrypi tailscaled[3209]: magicsock: derp-19 connected; connGen=1
Oct 05 12:22:06 raspberrypi tailscaled[3209]: magicsock: closing connection to derp-18 (idle), age 1h22m24s
Oct 05 12:22:06 raspberrypi tailscaled[3209]: magicsock: closing connection to derp-19 (idle), age 1m12s
Oct 05 12:22:06 raspberrypi tailscaled[3209]: magicsock: 2 active derp conns: derp-4=cr1m0s,wr52s derp-14=cr1m0s,wr12s
Oct 05 12:22:21 raspberrypi tailscaled[3209]: magicsock: closing connection to derp-4 (idle), age 1m30s
Oct 05 12:22:21 raspberrypi tailscaled[3209]: magicsock: 1 active derp conns: derp-14=cr1m0s,wr27s
Oct 05 12:22:28 raspberrypi tailscaled[3209]: netcheck: DetectCaptivePortal(found=false)
Oct 05 12:26:07 raspberrypi tailscaled[3209]: control: map response long-poll timed out!
Oct 05 12:27:03 raspberrypi tailscaled[3209]: health(warnable=mapresponse-timeout): error: Tailscale hasn't received a network map from the coordination server in 2m55s.
Oct 05 12:27:03 raspberrypi tailscaled[3209]: health(warnable=derp-timed-out): error: Tailscale hasn't heard from the 'Amsterdam' relay server in 3m1s. The server might be temporarily unavailable, or your Internet connection might be down.
Oct 05 12:27:29 raspberrypi tailscaled[3209]: health(warnable=derp-timed-out): ok
Oct 05 12:27:30 raspberrypi tailscaled[3209]: health(warnable=mapresponse-timeout): ok
Oct 05 12:27:38 raspberrypi tailscaled[3209]: monitor: time jumped (probably wake from sleep); synthesizing major change event
Oct 05 12:28:50 raspberrypi tailscaled[3209]: LinkChange: major, rebinding. New state: interfaces.State{defaultRoute=eth0 ifs={eth0:[192.168.1.146/24 llu6] tailscale0:[100.64.31.25/32 fd7a:115c:a1e0::d101:1f19/128 llu6]} v4=true v6=false}
Oct 05 12:32:47 raspberrypi tailscaled[3209]: dns: Set: {DefaultResolvers:[] Routes:{tail1efe5b.ts.net.:[] ts.net.:[199.247.155.53 2620:111:8007::53]}+65arpa SearchDomains:[tail1efe5b.ts.net.] Hosts:5}
Oct 05 12:33:59 raspberrypi tailscaled[3209]: Received error: PollNetMap: context canceled
Oct 05 12:35:15 raspberrypi tailscaled[3209]: monitor: time jumped (probably wake from sleep); synthesizing major change event
Oct 05 12:36:41 raspberrypi tailscaled[3209]: logtail: upload: log upload of 435 bytes compressed failed: Post "https://log.tailscale.io/c/tailnode.log.tailscale.io/b85231f1182060ad6acd0984738f0cc000b8ad0a81c9e6a45f1d6007c2793579": context deadline exceeded
Oct 05 12:37:09 raspberrypi tailscaled[3209]: health(warnable=not-in-map-poll): error: Unable to connect to the Tailscale coordination server to synchronize the state of your tailnet. Peer reachability might degrade over time.
Oct 05 12:37:53 raspberrypi tailscaled[3209]: dns: Resolvercfg: {Routes:{.:[8.8.8.8 8.8.4.4] ts.net.:[199.247.155.53 2620:111:8007::53]} Hosts:5 LocalDomains:[tail1efe5b.ts.net.]+65arpa}
Oct 05 12:39:37 raspberrypi tailscaled[3209]: monitor: time jumped (probably wake from sleep); synthesizing major change event
Oct 05 12:39:38 raspberrypi tailscaled[3209]: LinkChange: major, rebinding. New state: interfaces.State{defaultRoute=eth0 ifs={eth0:[192.168.1.146/24 llu6] tailscale0:[100.64.31.25/32 fd7a:115c:a1e0::d101:1f19/128 llu6]} v4=true v6=false}
Oct 05 12:39:46 raspberrypi tailscaled[3209]: dns: OScfg: {Nameservers:[100.100.100.100] SearchDomains:[tail1efe5b.ts.net.] }
Oct 05 12:39:46 raspberrypi tailscaled[3209]: LinkChange: major, rebinding. New state: interfaces.State{defaultRoute=eth0 ifs={eth0:[192.168.1.146/24 llu6] tailscale0:[100.64.31.25/32 fd7a:115c:a1e0::d101:1f19/128 llu6]} v4=true v6=false}
Oct 05 12:39:53 raspberrypi tailscaled[3209]: control: controlhttp: failed dialing using DialPlan, falling back to DNS; errs=multiple errors:
Oct 05 12:39:53 raspberrypi tailscaled[3209]:         connection attempts aborted by context: context deadline exceeded
Oct 05 12:39:53 raspberrypi tailscaled[3209]:         context deadline exceeded
Oct 05 12:39:53 raspberrypi tailscaled[3209]:         context deadline exceeded
Oct 05 12:39:53 raspberrypi tailscaled[3209]:         context deadline exceeded
Oct 05 12:39:53 raspberrypi tailscaled[3209]:         context deadline exceeded
Oct 05 12:39:53 raspberrypi tailscaled[3209]:         context deadline exceeded
Oct 05 12:39:53 raspberrypi tailscaled[3209]:         context deadline exceeded
Oct 05 12:39:53 raspberrypi tailscaled[3209]:         context deadline exceeded
Oct 05 12:39:53 raspberrypi tailscaled[3209]:         context deadline exceeded
Oct 05 12:39:53 raspberrypi tailscaled[3209]:         context deadline exceeded
Oct 05 12:39:53 raspberrypi tailscaled[3209]:         context deadline exceeded
Oct 05 12:39:53 raspberrypi tailscaled[3209]:         context deadline exceeded
Oct 05 12:39:53 raspberrypi tailscaled[3209]:         context deadline exceeded
Oct 05 12:39:53 raspberrypi tailscaled[3209]:         context deadline exceeded
Oct 05 12:39:53 raspberrypi tailscaled[3209]:         context deadline exceeded
Oct 05 12:39:53 raspberrypi tailscaled[3209]:         context deadline exceeded
Oct 05 12:39:53 raspberrypi tailscaled[3209]:         context deadline exceeded
Oct 05 12:39:53 raspberrypi tailscaled[3209]:         context deadline exceeded
Oct 05 12:39:53 raspberrypi tailscaled[3209]:         context deadline exceeded
Oct 05 12:39:53 raspberrypi tailscaled[3209]:         context deadline exceeded
Oct 05 12:39:53 raspberrypi tailscaled[3209]:         context deadline exceeded
Oct 05 12:39:53 raspberrypi tailscaled[3209]:         context deadline exceeded
Oct 05 12:39:53 raspberrypi tailscaled[3209]:         context deadline exceeded
Oct 05 12:39:53 raspberrypi tailscaled[3209]:         context deadline exceeded
Oct 05 12:39:53 raspberrypi tailscaled[3209]:         context deadline exceeded
Oct 05 12:39:53 raspberrypi tailscaled[3209]:         context deadline exceeded
Oct 05 12:39:53 raspberrypi tailscaled[3209]:         context deadline exceeded
Oct 05 12:39:53 raspberrypi tailscaled[3209]:         context deadline exceeded
Oct 05 12:39:53 raspberrypi tailscaled[3209]:         context deadline exceeded
Oct 05 12:39:53 raspberrypi tailscaled[3209]:         context deadline exceeded
Oct 05 12:39:53 raspberrypi tailscaled[3209]:         context deadline exceeded
Oct 05 12:39:53 raspberrypi tailscaled[3209]:         context deadline exceeded
Oct 05 12:39:54 raspberrypi tailscaled[3209]: monitor: time jumped (probably wake from sleep); synthesizing major change event
Oct 05 12:39:55 raspberrypi tailscaled[3209]: LinkChange: major, rebinding. New state: interfaces.State{defaultRoute=eth0 ifs={eth0:[192.168.1.146/24 llu6] tailscale0:[100.64.31.25/32 fd7a:115c:a1e0::d101:1f19/128 llu6]} v4=true v6=false}
Oct 05 12:39:58 raspberrypi tailscaled[3209]: wgengine: set DNS config again after major link change
Oct 05 12:40:19 raspberrypi tailscaled[3209]: dns: Set: {DefaultResolvers:[] Routes:{tail1efe5b.ts.net.:[] ts.net.:[199.247.155.53 2620:111:8007::53]}+65arpa SearchDomains:[tail1efe5b.ts.net.] Hosts:5}
Oct 05 12:40:21 raspberrypi tailscaled[3209]: onPortUpdate(port=41641, network=udp6)
Oct 05 12:40:24 raspberrypi tailscaled[3209]: onPortUpdate(port=41641, network=udp4)

Ik ben er ondertussen wel klaar mee. Ik vrees omdat het bij 2 verschillende RPi's speelt, ik ook bij eventuele andere hardware (thin client/NUC whatever) hetzelfde kan krijgen.
Ga de camera's wel via P2P aan de app koppelen. Had ik liever niet (wil liever niet via de cloud/fabrikant) maar hier zit nu niets anders op.

EDIT: probeer ook wat op Reddit hierover te posten; maar elke post die ik probeer wordt door Reddit tegengehouden. Handig...

[DjoeC]

@Piet91 Als ik het log bekijk valt mij vooral dit opt:

code:

Oct 05 12:21:27 raspberrypi tailscaled[3209]: health(warnable=no-derp-connection): error: Tailscale could not connect to the 'Amsterdam' relay server. Your Internet connection might be down, or the server might be temporarily unavailable.
Oct 05 12:21:27 raspberrypi tailscaled[3209]: health: connectivity impacted; triggering captive portal detection
O

En dat doet mij denken dat er iets aan de hand is met je DNS servers en/of je overige (gateway?) netwerk instellingen.

Ik zie ook nog andere DNS setting meldingen. Maar, een oplossing heb ik zo niet voor je, dan zou ik echt in Tailscale moeten duiken (vandaag niet...).

[DjoeC]

Hmm, wat ik me wel realiseer - je hebt nu vast 2x Pi met dezelfde hostname. Mogelijk gaat daar al iets mis? Krijgen ze wel de "juiste" IP adressen, gateway, DNS resolvers?

Enneh, staan port 443/80 wel correct geforward in je router?
-----

Dat hoeft blijkbaar niet (altijd):
https://tailscale.com/kb/1082/firewall-ports

[ Voor 16% gewijzigd door DjoeC op 05-10-2024 15:42 ]

[nero355]

Piet91 schreef op zaterdag 5 oktober 2024 @ 15:01:
Van wat ik heb gelezen zouden de RPi's dit makkelijk moeten aankunnen.
Heb ook wel eens naar de CPU/Memory load gekeken en dit was hooguit enkele procenten.

Als jij het zegt!

Hier de bad-rpi_tailscale.log van vandaag, toen deze RPi er (volgens Tailscale) om 12:27 uit klapte:

code:

Oct 05 12:27:38 raspberrypi tailscaled[3209]: monitor: time jumped (probably wake from sleep); synthesizing major change event

Oct 05 12:28:50 raspberrypi tailscaled[3209]: LinkChange: major, rebinding. New state: interfaces.State{defaultRoute=eth0 ifs={eth0:[192.168.1.146/24 llu6] tailscale0:[100.64.31.25/32 fd7a:115c:a1e0::d101:1f19/128 llu6]} v4=true v6=false}

Oct 05 12:33:59 raspberrypi tailscaled[3209]: Received error: PollNetMap: context canceled
Oct 05 12:35:15 raspberrypi tailscaled[3209]: monitor: time jumped (probably wake from sleep); synthesizing major change event

- Tijd die jumped...
- CG-NAT IPv4 Range die ze gebruiken om de een of andere reden...

Vaag gedoe...

Ik ben er ondertussen wel klaar mee.

Kan ik me voorstellen

Ik vrees omdat het bij 2 verschillende RPi's speelt, ik ook bij eventuele andere hardware (thin client/NUC whatever) hetzelfde kan krijgen.
Ga de camera's wel via P2P aan de app koppelen. Had ik liever niet (wil liever niet via de cloud/fabrikant) maar hier zit nu niets anders op.

Kan je niet effe een VM aanslingeren en alles daarin installeren

EDIT: probeer ook wat op Reddit hierover te posten; maar elke post die ik probeer wordt door Reddit tegengehouden. Handig...

Reddit sucks!

Nooit een fan van geweest, maar blijkbaar is alles wat ik een ramp vind één groot hype feest ?! LOL!!!

[DjoeC]

@Piet91 Waarom zie je camera's P2P als enige alternatieve oplossing? Zet wireguard aan en stel een dyndns in (duckdns.org, gratis. Je wordt dan bijvoorbeeld piet91.duckdns.org).

Mijn camera's hangen niet aan de cloud, zijn benaderbaar via VPN (wireguard) of als sitenaam (cam01.xxxx.yy via Cloudflare en NPM). Ik doe dat type dingen never nooit via de cloud en al helemaal niet via leverancier app.....

Gebruik ipv een Pi1 een Pi3 of een Pi4 en rommel wat met Docker - ik heb er geen spijt van ;-) Wel dit jaar helemaal opnieuw ingericht om eerdere "leermomenten" te herstellen. Kost wat tijd maar is wel LEUK!

[Piet91]

DjoeC schreef op zaterdag 5 oktober 2024 @ 15:30:
@Piet91 Als ik het log bekijk valt mij vooral dit opt:

code:

Oct 05 12:21:27 raspberrypi tailscaled[3209]: health(warnable=no-derp-connection): error: Tailscale could not connect to the 'Amsterdam' relay server. Your Internet connection might be down, or the server might be temporarily unavailable.
Oct 05 12:21:27 raspberrypi tailscaled[3209]: health: connectivity impacted; triggering captive portal detection
O

En dat doet mij denken dat er iets aan de hand is met je DNS servers en/of je overige (gateway?) netwerk instellingen.

Ik zie ook nog andere DNS setting meldingen. Maar, een oplossing heb ik zo niet voor je, dan zou ik echt in Tailscale moeten duiken (vandaag niet...).

Die kant zit ik ook op te denken maar ik zou niet weten wat. Ik heb hier thuis geen aparte (netwerk)instellingen gedaan en bij mijn familie (waar de RPi stond) al helemaal niet.
Enige is dat ik de primaire en secondary DNS van de router op 8.8.8.8. en 8.8.4.4. heb ingesteld.

DjoeC schreef op zaterdag 5 oktober 2024 @ 15:40:
Hmm, wat ik me wel realiseer - je hebt nu vast 2x Pi met dezelfde hostname. Mogelijk gaat daar al iets mis? Krijgen ze wel de "juiste" IP adressen, gateway, DNS resolvers?

Heb ze allebei aparte naam gegeven. En dan zou het probleem ook niet spelen met 1 RPi alleen in ons of hun netwerk.

nero355 schreef op zaterdag 5 oktober 2024 @ 16:13:
Reddit sucks!

Nooit een fan van geweest, maar blijkbaar is alles wat ik een ramp vind één groot hype feest ?! LOL!!!

Mwah, ben daar af en toe toch best behulpzame mensen tegengekomen hoor.

DjoeC schreef op zaterdag 5 oktober 2024 @ 16:36:
@Piet91 Waarom zie je camera's P2P als enige alternatieve oplossing? Zet wireguard aan en stel een dyndns in (duckdns.org, gratis. Je wordt dan bijvoorbeeld piet91.duckdns.org).

Mijn camera's hangen niet aan de cloud, zijn benaderbaar via VPN (wireguard) of als sitenaam (cam01.xxxx.yy via Cloudflare en NPM). Ik doe dat type dingen never nooit via de cloud en al helemaal niet via leverancier app.....

Gebruik ipv een Pi1 een Pi3 of een Pi4 en rommel wat met Docker - ik heb er geen spijt van ;-) Wel dit jaar helemaal opnieuw ingericht om eerdere "leermomenten" te herstellen. Kost wat tijd maar is wel LEUK!

Jaren geleden heb ik Wireguard op dezelfde RPi geïnstalleerd en kan me nog levendig herinneren hoe traag die installatie ging: Piet91 in "Raspberry Pi: Ervaringen en Discussie - deel 2"
Maar goed; sindsdien heeft het wel sinds die tijd eigenlijk altijd gewerkt.

Maar ik heb geen zin om weer mee bezig te gaan. Ik heb ook een afkeer van alles wat cloud e.d. nodig heeft, maar hun boeit dat wat minder. Heb vanmiddag dus ook maar gewoon P2P aangezet; kunnen ze in ieder geval voorlopig buitenshuis de camera's zien.

En een Pi3 of nieuwer begin ik niet aan; dan liever een Dell/HP PCtje. Voor dit soort doeleinden geniet de RPi eigenlijk niet meer de voorkeur.

Voorlopig jullie hartelijk bedankt voor de moeite.

[ Voor 5% gewijzigd door Piet91 op 06-10-2024 20:29 ]

[Raven]

YouTube: Raspberry Pi PCIe Shenanigans: Using Pi 5 in all the wrong ways!

Piet91 schreef op zaterdag 5 oktober 2024 @ 21:35:
[...]

Jaren geleden heb ik Wireguard op dezelfde RPi geïnstalleerd en kan me nog levendig herinneren hoe traag die installatie ging: Piet91 in "Raspberry Pi: Ervaringen en Discussie - deel 2"
Maar goed; sindsdien heeft het wel sinds die tijd eigenlijk altijd gewerkt.

Heeft dat niet met het genereren van certificaten ofzo te maken? Iets dat op een hedendaagse x86-CPU zo snel gaat dat ik mij afvraag of het mis is gegaan

[Piet91]

Raven schreef op zondag 6 oktober 2024 @ 10:10:
Heeft dat niet met het genereren van certificaten ofzo te maken? Iets dat op een hedendaagse x86-CPU zo snel gaat dat ik mij afvraag of het mis is gegaan

Ik heb die ervaring proberen te verdringen , maar blijkbaar ging het lang duren bij stap 8; de stap waar je voor OpenVPN of Wireguard kiest; dus de installatie van Wireguard.

[ZuinigeRijder]

Voor diegene die de laatste -n regels van een Raspberry Pi log-file (of andere file) op een telefoon, tablet of PC willen bekijken, zonder in te loggen op de Raspberry Pi, heb ik een tool gemaakt: tail2GoogleSheet.

[DjoeC]

ZuinigeRijder schreef op zondag 20 oktober 2024 @ 10:45:
Voor diegene die de laatste -n regels van een Raspberry Pi log-file (of andere file) op een telefoon, tablet of PC willen bekijken, zonder in te loggen op de Raspberry Pi, heb ik een tool gemaakt: tail2GoogleSheet.

Mooi initiatief en leuke oplossing! Alleen heb ik he-le-maal niks met dat soort cloud services. Ik vermoed dat als googledocs ontvanger kan zijn dat ook Nextcloud ontvanger zou kunnen zijn, een leuk uitzoekklusje voor laat in de winter - begin van de winter heb ik al een grote klus gepland staan

[nero355]

DjoeC schreef op zondag 20 oktober 2024 @ 12:12:
Ik vermoed dat als googledocs ontvanger kan zijn dat ook Nextcloud ontvanger zou kunnen zijn.

+1

Des te minder Apple/Google/Microsoft des te beter !!!

[Sjarel81]

Ik ben bezig met mijn eerste Raspberry Pi projectje maar helemaal op het einde loop ik vast.
Heb een RP 4B, Picoreplayer geïnstalleerd, alles werkt (Spotify, internetradio, muziek afspelen van nas en usb stick. Dan het officiële 7 inch touch screen aangesloten, Jivelite bediening geïnstalleerd, werkt ook. Dan een behuizing voor het scherm gekocht van Oneninedesign. Scherm staat 180° gedraaid maar dit kan je roteren door in de config.txt lcd_rotate=2 aan te passen.
Maar nu komt het probleem, het scherm is wel 180° gedraaid maar de touch functie niet.
Heb al uren gezocht op Youtube filmpjes, op forums maar heb de gouden tip nog niet gevonden. Mocht iemand mij in de juiste richting kunnen helpen?

[The Zep Man]

Sjarel81 schreef op dinsdag 22 oktober 2024 @ 20:36:
Heb al uren gezocht op Youtube filmpjes, op forums maar heb de gouden tip nog niet gevonden. Mocht iemand mij in de juiste richting kunnen helpen?

10 seconden zoeken op Google. Waarschijnlijk een goed startpunt, want dat betreft het officiële touchscreen.

[ Voor 7% gewijzigd door The Zep Man op 23-10-2024 08:08 ]

[Piet91]

Even een update over Tailscale problemen hier.
Zaterdag 12 oktober weer Tailscale geïnstalleerd op een RPi.
Dit keer gebaseerd op Bullseye met 1 verschil t.o.v. de vorige pogingen; deze keer heb ik onderstaande niet overgeslagen:

code:

sudo apt-get update && sudo apt-get upgrade

Ondertussen draait deze hier - voor zover ik kan zien - stabiel. Verschillende momenten check ik of deze nog verbonden is met het Tailscale netwerk en elke keer is dat het geval.

Daarom paar dagen later op een 2e Pi geprobeerd met Bookworm (inclusief dus update en Tailscale voor Bookworm gebruiikt) en dat is geen succes.
Ik weet niet meer welke, maar 1 stap duurde letterlijke uren en deze ligt ondertussen ook al weer uit het Tailscale netwerk.

Beetje raar allemaal, maar die eerste *lijkt* nu stabiel te draaien. Ze hebben dus nu misschien alsnog een alternatief voor P2P.

[nero355]

Sjarel81 schreef op dinsdag 22 oktober 2024 @ 20:36:
Heb een RP 4B, Picoreplayer geïnstalleerd, alles werkt (Spotify, internetradio, muziek afspelen van nas en usb stick.
Dan het officiële 7 inch touch screen aangesloten, Jivelite bediening geïnstalleerd, werkt ook.

Dan een behuizing voor het scherm gekocht van Oneninedesign.
Scherm staat 180° gedraaid maar dit kan je roteren door in de config.txt lcd_rotate=2 aan te passen.

Maar nu komt het probleem, het scherm is wel 180° gedraaid maar de touch functie niet.

Heb al uren gezocht op Youtube filmpjes, op forums maar heb de gouden tip nog niet gevonden. Mocht iemand mij in de juiste richting kunnen helpen?

Waarom laat je dat niet headless draaien op basis van Mopidy en bedien je het geheel niet gewoon via een webGUI of een applicatie dan wel mobile app ??

Sinds ik dat heb ontdekt wil ik eigenlijk niet meer anders

Dit heb ik draaien :
- Raspberry Pi 3B
- RaspBian/Raspberry Pi OS
- Mopidy
- Mopidy MPD plug-in
- Mopidy MusicBox webGUI plug-in
- Mopidy JellyFin plug-in

En vervolgens bedien ik alles dus via de webGUI vanaf een telefoon/tablet of Cantata vanaf mijn PC/Laptop

[Sjarel81]

nero355 schreef op woensdag 23 oktober 2024 @ 15:48:
[...]

Waarom laat je dat niet headless draaien op basis van Mopidy en bedien je het geheel niet gewoon via een webGUI of een applicatie dan wel mobile app ??

Sinds ik dat heb ontdekt wil ik eigenlijk niet meer anders

Dit heb ik draaien :
- Raspberry Pi 3B
- RaspBian/Raspberry Pi OS
- Mopidy
- Mopidy MPD plug-in
- Mopidy MusicBox webGUI plug-in
- Mopidy JellyFin plug-in

En vervolgens bedien ik alles dus via de webGUI vanaf een telefoon/tablet of Cantata vanaf mijn PC/Laptop

Ik ga die Mopidy eens bekijken, bedankt.

Ik wou de album art zichtbaar maken in de living, dus daarom niet headless. Maar daarvoor is dat 7" scherm feitelijk ook wat klein en te klein in resolutie heb ik nu gemerkt.

De link hier 2 post boven had ik al geprobeerd maar werkt niet, beeld en touch blijven 180° geroteerd van elkaar. Ik vermoed dat die Jivelite er voor iets tussenzit.

[Raven]

nieuws: Raspberry Pi OS stapt standaard over op Wayland
Opgepast, er zijn wat bugjes, waaronder het niet installeren van labwc, met zwart scherm en knipperende cursor i.p.v. desktop tot gevolg.

[DjoeC]

@Raven Zet er dan dit nieuws ook maar bij: https://www.raspberrypi.com/news/raspberry-pi-ai-hat/ Een nieuwe AI hat met meer dan verdubbelde snelheid. Dat wordt wel iets voor de (beveiligings)camera mensen.

[Mr_gadget]

Wie kan mij helpen met de 3.5 mm aansluiting?
Raspberry Pi 3, geen geluid uit 3.5 mm connector

[The Realone]

Ik heb een vraagje over een Pi gevoed door een 12V accu + zonnepaneel. Ik heb een zonnepaneel van een yard sale en die heeft een charge controller met 2 poorten. Input van het paneel en output naar een accu. Er is geen losse load poort o.i.d.

Hoe sluit ik nu de Pi (met 12 > 5V converter uiteraard) het beste aan zodat deze door de accu gevoed wordt en dat de accu tegelijkertijd geladen wordt door het zonnepaneel? Dien ik dan ook een charge controller tussen de Pi en accu te zetten en sluit ik het dan allemaal aan op de 2 accu polen?

[Septillion]

@The Realone Charge controller is dan alleen voor dat, het laden regelen.

Verbruiker sluit je gewoon aan op de accu zoals je ook zonder lader zou doen.

Enige dat je niet hebt is over discharge protection. Dat is wat in sommige charge controllers met een losse load-uitgang zit.

[The Realone]

Septillion schreef op vrijdag 8 november 2024 @ 21:29:
@The Realone Charge controller is dan alleen voor dat, het laden regelen.

Verbruiker sluit je gewoon aan op de accu zoals je ook zonder lader zou doen.

Enige dat je niet hebt is over discharge protection. Dat is wat in sommige charge controllers met een losse load-uitgang zit.

Dank je! Elektrotechniek is niet mijn sterkste van. Ik dacht eventueel dat zowel een paneel dat stroom voorziet alsook een batterij samen op hetzelfde circuit een probleem zou vormen. Maar dat is dus niet zo begrijp ik.
Kan ik dan eventueel wel nog accuraat de laadstatus van de accu uitlezen op deze manier, als ik dat zou willen?

[PrimusIP]

Ik heb sinds kort mijn RPI 4 onder het stof vandaan gehaald en er een externe schijf aangeklikt. Opzetje met Samba, qbittorent (daemon), plex server en nog een paar andere dingen. Werkt tot nu toe prima.
En ook maar gelijk Docker van mijn macbook afgegooid en op de RPI overgezet. (Die gebruikte ik vooral voor Paperless.)

[Septillion]

@The Realone De batterij en de PV zullen samen voor een spanning op de accu zorgen. De lader zal stroom de acuu in proberen te drukken maar circuit naar de Pi zal daar gewoon van nemen wat nodig is, de rest moet dan de accu in. Dus geen probleem.

Je zou de spanning op de accu kunnen meten, dat is een redelijke indicatie.

[Septillion]

@PrimusIP Klink als leuk projectje! De rest ook gelijk als docker erop gezet?

[PrimusIP]

Septillion schreef op zaterdag 9 november 2024 @ 10:04:
@PrimusIP Klink als leuk projectje! De rest ook gelijk als docker erop gezet?

Nee, ik zatber wel aan te denken, maar uiteindelijk toch maar niet gedaan. Las ergens dat Docker net een tikje performance kan schelen. Maar wie weet dat ik het in de toekomst wel anders ga doen.

Edit: stomme autocorrectie…

[ Voor 5% gewijzigd door PrimusIP op 09-11-2024 10:55 ]

[Septillion]

@PrimusIP Getver = docker?

Maar dat zal echt heeeeeeel marginaal zijn met docker. En onderhoud is zo veel makkelijker

[PrimusIP]

Na een apt full-upgrade met oa. plex in de lijst is die hele pi gecrasht en kreeg ik hem niet meer (headless) aan de praat. Dus mooie kans om de SD kaart te wipen en opnieuw te beginnen en jullie advies mee te nemen. Nu draai ik alles behalve Samba in Docker. Scheelt me hopelijk in de toekomst weer gedoe bij een volgende update met rampzalige gevolgen.

Wat ik met Docker wel merk is dat ik tegen nieuwe problemen aanloop bij software die ik eerder rechtstreeks draaide en goed ging. Zoals bijvoorbeeld een default inlog account voor de web interface dat niet werkt terwijl dat wel zou moeten. Uiteindelijk allemaal wel opgelost maar die images werken niet allemaal altijd even lekker 'out of the box'.

[DjoeC]

PrimusIP schreef op zaterdag 16 november 2024 @ 00:25:
Na een apt full-upgrade met oa. plex in de lijst is die hele pi gecrasht en kreeg ik hem niet meer (headless) aan de praat. Dus mooie kans om de SD kaart te wipen en opnieuw te beginnen en jullie advies mee te nemen. Nu draai ik alles behalve Samba in Docker. Scheelt me hopelijk in de toekomst weer gedoe bij een volgende update met rampzalige gevolgen.

Wat ik met Docker wel merk is dat ik tegen nieuwe problemen aanloop bij software die ik eerder rechtstreeks draaide en goed ging. Zoals bijvoorbeeld een default inlog account voor de web interface dat niet werkt terwijl dat wel zou moeten. Uiteindelijk allemaal wel opgelost maar die images werken niet allemaal altijd even lekker 'out of the box'.

Wip de SD kaart eruit en vervang die door een SSD... Ik zie SSD's (256GB) momenteel vanaf 20 euro, ik gebruik zelf een 2TB Samsung T7 voor data en booten maar die is flink in prijs gestegen het afgelopen jaar. Zonder SD kaart veel minder kans op issues al draait er bij mij 1 al een aantal jaren uitstekend in extreme condities (buiten in hitte en kou) met elke 30 dagen een clean-up reboot.

[Freee!!]

DjoeC schreef op zaterdag 16 november 2024 @ 12:39:
[...]
Wip de SD kaart eruit en vervang die door een SSD... Ik zie SSD's (256GB) momenteel vanaf 20 euro, ik gebruik zelf een 2TB Samsung T7 voor data en booten maar die is flink in prijs gestegen het afgelopen jaar. Zonder SD kaart veel minder kans op issues al draait er bij mij 1 al een aantal jaren uitstekend in extreme condities (buiten in hitte en kou) met elke 30 dagen een clean-up reboot.

Ik zie het nut van het vervangen van de SD kaart niet echt. Ik heb momenteel 6 RPi's draaien en die SD kaarten houden het allemaal al lang genoeg uit. Als er al eens één niet meer werkt (meestal door een update die niet helemaal goed gewerkt heeft), is het terugflashen van de dagelijkse backup zo gebeurd.
NB: Ik gebruik goede SD kaarten van 32 GB.

[nero355]

PrimusIP schreef op zaterdag 16 november 2024 @ 00:25:
Wat ik met Docker wel merk is dat ik tegen nieuwe problemen aanloop bij software die ik eerder rechtstreeks draaide en goed ging.

Zoals bijvoorbeeld een default inlog account voor de web interface dat niet werkt terwijl dat wel zou moeten. Uiteindelijk allemaal wel opgelost maar die images werken niet allemaal altijd even lekker 'out of the box'.

Je hoort dan eigenlijk ook zelf je Docker Containers te bouwen en naar je eigen systemen te verspreiden

Dat ondertussen die hele Docker toestand een soort KaZaA Lite P2P toestand is geworden is een ander verhaal...

DjoeC schreef op zaterdag 16 november 2024 @ 12:39:
Ik zie SSD's (256GB) momenteel vanaf 20 euro.

- knip -

Maar die is flink in prijs gestegen het afgelopen jaar.

Alleen 2,5 inch SATA modellen zijn nog een beetje cheapass verkrijgbaar heb ik het idee ?!

Alle computer gerelateerde hardware is de afgelopen jaren zoveel duurder geworden dat het gewoon niet meer leuk is als hobby wat mij betreft

Dacht laatst effe snel zoiets te bestellen : uitvoering: WD Green SN350 (TLC) 250GB
Want ik weet niet of mijn kastje zoiets slikt : uitvoering: WD Green SSD M.2 (2022) 240GB
En als je dat dan naast zoiets zet : uitvoering: WD Green SSD 2,5" (2022) 240GB
Die blijkbaar goedkoper is dan een kleiner model zelfs : uitvoering: WD Green SSD 2,5" (2022) 120GB

Dan slaat dat echt nergens op, want het zijn allemaal super simpele prut SSD's die wat mij betreft allemaal goedkoper kunnen...


Maar goed...


Het heeft voorlopig geen haast dus ik blijf het een beetje in de gaten houden en als er een leuke aanbieding voorbij komt dan pak ik die misschien wel mee

Freee!! schreef op zaterdag 16 november 2024 @ 14:31:
Ik zie het nut van het vervangen van de SD kaart niet echt. Ik heb momenteel 6 RPi's draaien en die SD kaarten houden het allemaal al lang genoeg uit. Als er al eens één niet meer werkt (meestal door een update die niet helemaal goed gewerkt heeft), is het terugflashen van de dagelijkse backup zo gebeurd.

NB: Ik gebruik goede SD kaarten van 32 GB.

Dat laatste is echt heel belangrijk !!

Zo heb ik toevallig gisteravond een heleboel corruptie gezien in de status file van dpkg op een oud simpel 16 GB microSDHC kaartje van Samsung dat ik een keer ergens effe snel vandaan heb gehaald om wat mee te experimenteren en voor zover ik weet heb ik toch echt elke keer netjes een shutdown -h now gedaan, echter is er toch iets misgegaan blijkbaar...

Geen ramp, maar wel een heel ander verhaal dan dat van een veel duurder Sandisk Extreme Pro Super Duper weet ik het wat allemaal wel niet microSDXC kaartje

Uiteindelijk trouwens maar de file verwijderd en een lege aangemaakt en apt update/apt (full-)upgrade gedraaid en het was gefixt

[DjoeC]

@nero355 Tja, ik heb ooit een paar externe 2.5" kastjes van Ali gehaald en die eten alle SSD's die ik sinds 2011 heb aangeschaft. Maar goed, mijn gewone PC heeft ook nog SATA SSD's, daar wacht op een aanbieding van de "grotere" capaciteiten (8TB+) maar dat gaat vast niet snel gebeuren. Waarschijnlijk komen er eerst Toshiba MG10 drives (20 of 22TB). Maar ook die willen maar niet in prijs dalen.

Het is inderdaad niet leuk meer.

Als SD kaartjes heb ik nog een paar speciale Apacer Industrial van 32GB. Snel met daarbij ook ECHTE specs... Voor de 32GB versie bijvoorbeeld 568TBW ofwel17.000x compleet beschrijven. De 64GB versie doet "maar" 129 TBW ofwel 1860x compleet beschrijven.

Niet alle 32GB kaartjes zijn slecht maar wil je endurance dan moet je een versie kopen zoals bedrijven die graag wegstoppen in hun "onderhoudsvrije" machines.

[nero355]

DjoeC schreef op zaterdag 16 november 2024 @ 15:39:
Als SD kaartjes heb ik nog een paar speciale Apacer Industrial van 32GB.
Snel met daarbij ook ECHTE specs...

Voor de 32GB versie bijvoorbeeld 568TBW ofwel17.000x compleet beschrijven.
De 64GB versie doet "maar" 129 TBW ofwel 1860x compleet beschrijven.

Dat is inderdaad wel een leuk microSDXC kaartje dat Endurance is en niet gelijk 20 MB/s Read/Write doet zoals de meeste Endurance modellen

/EDIT :

Ik kom dat model alleen niet tegen in de Pricewatch helaas...

Al zoekende kwam ik wel dit tegen : nero355 in "Centraal Aanbiedingentopic V2.0"
Mooie aanbieding wat mij betreft

[ Voor 15% gewijzigd door nero355 op 16-11-2024 23:05 ]

[True]

pimlie schreef op zondag 17 november 2024 @ 10:28:
[...]


Alhoewel dit eigenlijk off-topic is, voor Raspberry Pi's kan je tegenwoordig beter hun eigen sd cards kopen. Kost net zoveel, soortgelijke specs maar gegarandeerde compatibiliteit / stabiliteit: https://www.elektor.nl/pr...ard-32-gb?src=raspberrypi

Maar ik vraag mij af of dit wel meerwaarde biedt. De tekst heeft het over 'optimal performance', maar je wilt juist durability. Performance is m.i. nooit een probleem geweest met een hedendaags SD kaartje in een RPi.