NilsOF

https://blog.checkpoint.com/2020/02/05/the-dark-side-of-smart-lighting-check-point-research-shows-how-business-and-home-networks-can-be-hacked-from-a-lightbulb/ De fjern-innstallerte ny firmware på lyspæra over ZigBee -protokollen. Og via denne firmwaren brøt de seg videre inn i huben som hadde en svakhet i programmvaren. At det er mulig å reprogrammere en lyspære bare man har radiokontakt åpner opp for noen spennende scenarioer.

Jeg kan godt ta i bruk oppgange etter trivsel. Jeg ble tørr i kjeften bare med å skanne fort over de første sidene..

679 sider krever to veldig gode porsjoner apetitt og motivasjon.. Det er raskere å få seg noen empiriske data med en varmepistol og ett velvalgt regelsett. Jeg spanderer valgfri bitter og valgfri øl på valgfritt sted til den som har lest blekka og kan si at blekka er forstått ?

@Moskus tror jeg skjønner. Ser at Homeseer klassifiserer overheat som "system notification". Mens beskrivelsen i Openhab er som alarm. Viktig forskjell som jeg håper alle utviklere har fått med seg.. (jeg aner hvordan dette gjenspeiler seg i API). Ikke for det, om temperaturen i en veggboks er faretruende høy skulle jeg gjerne sett at det kunne varsles ganske så aggressivt. (Jeg har jo den muligheten via. Controller)

Godt spørsmål fra @PerH dette. Man kan også sette hvordan dimmer2 skal respondere på "alarm frames". Ser ut som disse er: overtemperatur, "water Flooding", general purpose alarm, og co2/røyk. Man kan blinke med lasten, eller slå av eller på last. samt ignorere. Det store spørsmålet er om disse "alarm frames" kan komme fra hvilken som helst z-wave-dings eller om de skal komme fra controller? I openhab er det også mulig å tilordne tre forskjellige "Items" man kan bruke i regler: Heat, power og system som da vil "taimot" alarmer fra dimmeren. Disse vil sikkert ha verdier tilsvarende bildene @Moskus klippet inn. Så var det forskjellen mellom "alarm frames" og alarm fra dimmeren. Det kan jo virke som dette er to separate greier..? Eller vil "overheat" fra en dimmer2 plukkes opp av andre dingser som en "alarm frame"?

Lagt inn mere info om statiske IP-adresser, dhcpcd, /etc/network/interfaces, wpa_supplicant osv.

@Moskus Isolasjonen mellom kjeller og etasjen over har ingen sett på 60 år (muligens isopor) og 70 år (kubbegulv). Jeg vet ikke tilstanden. Jeg tror jeg ser en kombinasjon mellom den naturlige jordvarmen i jordkjelleren og utette kjellermurer samt isolasjonsevnen i etasjeskillet. Meningen med varmeovnen i kjelleren er som frostvakt. 10 grader ble satt som ett eksperiment og avglemt helt til jeg så det i grafene.. Kjelleren er også ganske stor, sikkert 125+ kvm med jordgulv og gråsteinsmurer. Det skal noe helsikes med energi til for å løfte den iboende temperaturen på denne massen. Sånn sett lyver den målte temperaturen da sensoren står ganske nær varmeovnen. Sensoren sitter også i kjellertaket (dær vannrørene er) Men ovnen slår altså ikke inn før temperaturen ute er under null. Over null i utetemp flyter tempen i kjelleren.

Fikk omsider Grafana til å lese verdier ut fra Influxdb. Legger ved ett eksempel med temperaturer fra kjelleren (jordkjeller). Varmeovnen i kjelleren vil regulere til 10 grader kun når det er minusgrader ute. Ikke forseggjordt, "Lum" på høyresiden av grafen er en feil. Legg merke til hvordan temperaturen i kjelleren øker når temperaturen ute synker og motsatt. Dette vil jeg tro er lekasje fra stua med varmepumpa i etasjen over. Jeg kan med fordel sette ned reguleringen til 8 grader (eller noe sånt) for å utnytte denne lekasjen mere effektivt. Edit: Jeg har også en varmelekasje fra kjelleren mot utetemperatursensoren. Når Varmeovnen slår inn øker utetempen.. Dette vises ikke 2/3, da hadde jeg måket snø mot murene.

De to orginale postene i denne tråden er blitt redigerte.

reservert for rapportering av ledig disk og minne cpu osv. over MQTT (vel, ikke hold pusten..)

root og sudo: ---------------------- I eksemplene nedenfor har jeg ikke giddet å putte sudo foran alle komandoene. Når man skal jobbe som root bør man være root ? Når man ikke jobber som root skal man heller ikke være det! #bli root og ta med envioment fra gjeldende bruker: sudo su - Merk bindestreken etter su wpa_supplicant: ---------------------------- For at WiFi skal kunne fungere trenger man en /etc/wpa_supplicant/wpa_supplicant.conf som ser ut noe slik: ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=netdev update_config=1 country=NO network={ ssid="PST-OSL-Utepatrulje" psk="VeldigHemmelig" key_mgmt=WPA-PSK } network={ ssid="PST-Hovedkvarter" psk="ExxxtraHemmmeliigOgVaaanskelig" key_mgmt=WPA-PSK } #Etter edit av fil for å aktivere nytt oppsett: wpa_cli -i wlan0 reconfigure #For å aktivere feks. dhcpcd for statisk eller dynamisk IP: service dhcpcd restart #Sjekk resultat: ip address list Jobbe over ssh med nettverksinnstillinger på headless system. ------------------------------------------------------------------------------------------------ Når man jobber med ett headless system er det viktig at man ikke sager over greina man sitter på. Altså: IKKE rekonfigurer interfacet man er logget inn over. I praksis så kan man gjøre dette med å sette op både ethernett og wifi interfacet slik at de nåes på samme subnett. De vil da ha hver sin IP-adresse. dhcp er ett ok utgangspunkt for begge interfacene. #Finn den rette adressa å logge inn på: ip route show Logg ut og inn igjen på IP-adressa som tilhører interfacet man IKKE skal jobbe med. dhcpcd ------------ Kan ikke akkurat si at jeg tok bølgen da jeg oppdaget at default maskineri for adresse-styring i Rasbian er dhcpcd.. Den tar som default ALLE nettverksinterfacer som kommer opp og vil forsøke å hente IPer fra dhcp-server og binde IPer til interface. Der jeg kommer fra er slikt direkte farlig. Menmen, for de fleste bruksomeråder oppleves det sikkert som helt greit. Statiske IP-adresser på Rasbian kan gjøres veldig enkelt: Sette statiske IP-adresser ved å editere eksempelene i /etc/dhcpcd.conf: nano /etc/dhcpcd.conf #Se hva man har før aktivering av endringer: ip address list #Restart så dhcpcd for aktivere endringene: service dhcpcd restart #Sjekk hva som skjedde: ip address list Observer at interfacet nå har både statisk IP og adresse fra dhcp. (helt til reboot eller dhcp-IPn fjernes manuelt fra interfacet. Hva som skjer når dhcp-leasen går ut ventet jeg ikke på for å finne ut.. ? Alle adresser blir publisert av avahi over mDNS som <hostname>.local Ta ett interface ut av dhcpcd sin kontroll ------------------------------------------------------------- Siden dhcpcd allerede har konfigurert interfacene må noen tilltak taes (bruker wlan0 som eksempel): editer /etc/dhcpcd.conf: Legg inn "denyinterfaces wlan0" i toppen av fila #restart dhcpcd for aktivere nye innstillinger: service dhcpcd restart #ta ned Interfacet: ip link set wlan0 down #fjern alle IP-adresser på interfacet: ip addr flush dev wlan0 #opsjonelt: prøv å ta interfacet opp igjen: ip link set wlan0 up #opsjonelt: sjekk om noen adresser er tildelt (skal ikke noen, samt ha "state DOWN"): ip address list Merknad1: dhcpcd liker tydeligvis ikke at man tukler med interfacene og adressene den mener den har ansvar for. Den MÅ først fortelles hva den IKKE har ansvar for! (med "denyinterfaces <ifacenavn>" og påfølgende restart av service) Ellers opplevde jeg at dhcpcd gikk fullstendig i frø og tok alle nettverk med seg i fallet. Spesielt ved jobbing på eth0. Merknad2: Dersom man tar ett interface ut med "denyinterfaces <ifacenavn>" samt konfigurer interfacet med /etc/network/interfaces for så å reboote så vil dhcpd nekte å starte. Den sier "Failed to start dhcpcd on all interfaces" Løsningen er å gjøre seg ferdig med /etc/network/interfaces før man rebooter. Det er lurt å flytte ett interface om gangen. Inkludert testing. I tilfelle rottefelle så bør man uansett deklarere alle utflyttede interfacer ettervert som de flyttes: "denyinterfaces <ifacenavn1> <ifacenavn2>" skilt med mellomrom. Det kan jo hende at dette er en bug som plutselig blir fikset.. Bruke Debians /etc/network/interfaces --------------------------------------------------------- Dette er aktuelt om man vil bruke VLAN på nettverksinterfacene, eller bruke Bridging, eller kanskje Bonding (sette samen flere fysiske interfacer) For min egen del er det vanen, jeg vil bruke /etc/networking/interfaces som på en ordentlig Debian installasjon. Jeg har også funnet dette som en utmerket måte å gjøre nettverksendringer på maskiner i drift uten at det merkes på de andre interfacene. Jeg liker også at alle interfacene er ganske oversiktelig og komprimert listet i en fil. (noe rotete) dokumentert: https://wiki.debian.org/NetworkConfiguration Ellers er "man" et fint verktøy: "man interfaces", "man ifup" feks. Kort intro: -------------- "ifup <ifacenavn>" og "ifdown <ifacenavn>" er kommandoene man bruker for å ta opp og ned interfacene. Om man vil legge til ett interface: 1: legg inn interfacet med innstillinger i /etc/networking/interfaces 2: ifup <ifacenavn> Om man vil endre ett interface: 1: ifdown <ifacenavn> 2: editer interfacets innstillinger i /etc/networking/interfaces 3: ifup <ifacenavn> For all del: Migrer kun over ett interface ut fra /etc/dhcpd.conf i gangen og test det før man tar neste (eller rebooter, se merknader under avsnittet "Ta ett interface ut av dhcpcd sin kontroll"). Eksempel på /etc/networking/interfaces man kan bruke som utgangspunkt: # Include files from /etc/network/interfaces.d: source-directory /etc/network/interfaces.d ##eksempel: eth0 med dhcp #auto eth0 #allow-hotplug eth0 # iface eth0 inet dhcp ##eksempel: eth0 med statisk IP og opsjonell DNS-server for ifacet #auto eth0 #allow-hotplug eth0 # iface eth0 inet static # address 192.168.1.22/24 # gateway 192.168.1.7 # dns-nameservers 192.168.1.7 ##eksempel: wlan0 med dhcp og link til wpa_supplicant.conf #auto wlan0 #allow-hotplug wlan0 #iface wlan0 inet dhcp # wpa-conf /etc/wpa_supplicant/wpa_supplicant.conf ##eksempel: trådløs med statisk IP #auto wlan0 #allow-hotplug wlan0 #iface wlan0 inet static # address 192.168.1.23/24 # gateway 192.168.1.7 # dns-nameservers 192.168.1.7 # wpa-conf /etc/wpa_supplicant/wpa_supplicant.conf Når alt er plass bør man disable dhcpd: systemctl disable dhcpcd.service Alternativer til dhcpcd og /etc/network/interfaces for konfig av IP og interfacer --------------------------------------------------------------------------------------------------------------- Jadda, de er der! Alt1: ip link add name br0 type bridge ip link add name veth0 type veth peer name veth1 ip link set veth0 master br0 ... ip link set br0 up Da har man fullstendig kontroll på detaljene. Det blir ganske fort uoversiktelig, men er absolutt gjenomførbart. Helt nødvendig for lavnivå kontroll, oppretting,prototyping eller endring av interfacer, IPadresser og routing. Al2: Bruke systemd. Dokumentert https://www.freedesktop.org/software/systemd/man/systemd.network.html og https://www.freedesktop.org/software/systemd/man/systemd.netdev.html Servicen systemd-networkd er innstallert som default på Rasbian, men ikke aktivert. En kjapp titt sier meg at det er gjennomførbart. Om noen vil prøve seg, så vil jeg gjerne lese om det. ?

tullebukk, ustabilitet er drepen for effektiv jobbing ?

Win10 er treg å boote under virtualbox også. Edit: hjertesukk følger; Jeg har aldri hatt noen forhåpninger i noen som helst retning mht. det OSet, så jeg oppfattet dette som normalt. Med mindre kjerna er oppdatert har jeg aldri skjønt poenget med reboot som løsenet på alt. I steden for å fikse problemene så legger Lilleblaut innsatsen inn for raskere boot.. og observerer også at saueflokken tar bølgen over forbedringen..! Jeg kaller fenomenet for Windos-syken, og observerer at det smitter.

Cleverio fra Kjell virker på meg å være rebadget skrot fra Kina. Skrev litt om temperatursensoren hær: Fint om flere kunne skrive litt når man kommer over produkter som er elendige.

Har ett gammelt tømmerhus og dette er absolutt merkbart. Styringen av varmepumpa er nå stort sett på plass og gjør nå bare mindre justeringer på logikken. Dvs. etter temperaturføler i rommet. Jeg prøvde først med tabeller å justere innetemperatur som funksjon av utetemperatur, men oppdaget at problemet er mere komplekst og feil ende å begynne på. Blant annet oppleves det som om det blir kaldere inne når temperaturen ute stiger fra minusgrader til plussgrader. Til en viss grad kan jeg også måle dette, men det forklarer ikke hele opplevesen. Den som har prøvd å fyre opp ei tømmerbu som har stått uten oppvarming i uker/måneder vet hvor tungstartede slike hus kan være. Planlegger å loppe værmeldingen fra yr.no for å justere i forkant av svingninger i temperaturen. Hær i villatrekkfullkulla spiller også vindretning og vindstyrke en rolle. Jeg er en sterk tilhenger av å måle først og sette inn tilltak etterpå når problemet er forstått. Å se målinger og eventer grafisk i samenheng over tid savner jeg akkurat nå. Håper jeg kan få bedre innsikt når jeg får Grafana til å lese data fra Influxdb. Er iallefall sikker på at det mest effektive tiltaket hær blir med hammer og spiker.

Tja, jeg kan jo avsløre vårt effektive tillfelle: (Høres veldig overbevisende brutalt ut, men hun vil bare ha kos, alle som kommer er potensielt koseobjekt) Så lenge dyret blir regelmessig foret er det ikke observert problemer. ps: dama i leopardgenser er erfaringsmessig skikkelig ille å komme på kant med..

Jodda, spørsmålet er hvor man skal legge energien. Jeg har ingen problemer med å pønske ut og lodde opp en opamp feks. Å bestille mange "padder" uten datablad er ikke min stil, så jeg ser definitivt fordelen med en veiecelle. (Uten data er den også verdiløs). Hver mann sin høne osv. ? jeg foretrekker storfe. Til syvende og sist: De forskjellige oppfatninger av "bra nok" (patent pending) ?

Ettersom du har ssh tilgang så kan du sjekke om z-wave dingsen er sløyfet ut på IP med: netstat -l -n Man skal forhåpentligvis kunne se at port 2001 er bundet opp til noe. Edit: netstat -lnp vil vise noe sånt som 0.0.0.0:"portnummer" under Local Address For å være sikker på at servicene går riktig så sett inn dongla før boksen bootes opp. Jeg bruker nmap for å scanne hvilke porter som er oppe/tilgjengelige over nettet fra PC. Hvordan man kjører nmap fra Windos kan ikke jeg fortelle.. Uansett nmap blir evt. neste skritt.

@Luftvaffel Om det er noe som er blokkert, så skjer i det mest sannsynlig i z-net - boksen. (jeg vet ikke engang om den har en firewall innebygd) Det er sikkert bare en kneppefeil i Sophos -brannmuren. Jeg ville rettet på dette først uansett om det er årsak til problemet eller ikke. Før eller siden vil ett eller annet ha problemer med å virke. Ikke godt å si hva det blir. Jeg anntar at find.homeseer.com gjør noe lurt i nettleseren for å finne boksen. Heller ikke godt å si om det ligger noe filter dær, men ikke usannsynlig det heller. Vær litt obs på at alle dingser i nettet vil slutte å virke når du endrer. Alt må ha ny IP-addresse.!

Vil tro at routingen virker hos @Luftvaffel, den svarer på ping. Herfra svares det ikke. Det er mange måter man kan eksponere ting på internet ved en tabbe. (ikke at jeg tror det er tilfelle hær) Å blokkere tilgang til ssh (og andre porter også) fra offentlige IP-adresser er rett og slett fornuftig å gjøre ? At boksen svarer på ping er rett og slett god høflighet, samtidig som det har liten sikkerhetsmessig betydning.

IP-adressa er utenfor den private serien. Det er ikke usannsynlig at det er lagt inn blokkering av offentlige IP-adresser for å forhindre at noen plugger remediene rett på internet.

Dumpet over denne: https://www.suphammer.net/suphacap Står tilogmed Made In Norway på den. Det ser ut som om suphacap viser hvilke noder trafikken routes igjennom utifra screenshotene. Hvilke andre sniffere finnes? Spørsmålet er hvilke typer trøbbel man kan avsløre med en sniffer. Dårlig dekning? (det hadde vært fint å se en røff signalstyrke) Noder som overbelaster nettet? Noder som ikke svarer på tiltale?

Jeg har en full kasse med z-wave dingser som skulle vært i drift nå. Men jeg løse ustabilitet og backup først. Som @gullfrodesier, det er uaktuelt å utvide og sette i drift mere z-wave før skikkelig backup er på plass. Det ser ut som om Silicon Labs har noen verktøy som kan brukes til feilsøking også, jeg må bare dekryptere hva som er hva av de. Det virker fryktelig rotete. Step en blir å anskaffe en UZB1.

Ahh, dette skal sjekkes ut ?

@gullfrodejepp, pi4 har visst en Via-chip som styrer USB. Denne Via-chippen går dårlig overens med Aeotec-stikka. Med en USB- hub (som ikke har en slik Via-chip) så vil inkompabiliteten maskeres bort, sett fra rpi4. Slik har jeg forstått det.. ?