firmware 2.8.3

[Kandersen]

Er der nogen der kender forskellen/ændringer fra firmware 2.7.220 -> 2.8.3 ??

[Lars1]

Primært udløbne certifikater. Prøv at kigge i tråden Java problemer igen igen igen. Der plejre jeg at beskrive hvad der er nyt i de enkelte firmware versioner.

[Kandersen]

Ahh ja. Tænkte ikke lige på at læse i den tråd for at se ændringerne 

[Kandersen]

1 time siden, Lars1 skrev:

Primært udløbne certifikater. Prøv at kigge i tråden Java problemer igen igen igen. Der plejre jeg at beskrive hvad der er nyt i de enkelte firmware versioner.

Læste lige dit første indlæg i tråden, 'Java problemer igen igen igen'. 
Er det ikke Fw 2.8.4 som kom med IOS 11 support? Det er nemlig ikke umiddelbart skrevet i ændringerne i tråden. Det bør du måske indføre, da det er en rimelig væsentlig detalje. 
 

[Lars1]

IOS11 krypterings understøttelse kom med i 2.8.1 såvidt jeg ved. Det står der ikke direkte, men det var såvidt jeg ved, den ændring, som gjorde at LK ikke længere ville supporter HW 6.1. I 2.8.4 røg brugen af MD5 certifikater, hvilket løste problemer med manglende support for MD5 i Java. Jeg har dog ikke nærstuderet IOS11 ændringen, så jeg ved ikke præcist hvad det er de har droppet at supporter. Men LK henviser altid til deres seneste firmware, også selvom problemet reelt vil være løst med en tidligere firmware.

Kryptering er en jungle. Der findes mange forskellige algorithmer, men de har alle det fælles træk at de baser sig på krypterings nøgler eller certifikater. Når man for 20 år siden talte om stærk kryptering var disse nøgler eller certifikater ofte på 256 bit. I dag supporteres 256bit nøgler eller certifikater stortset ikke. Når man idag taler om stærk kryptering er disse nøgler eller certifikater på 1024 bit eller mere. Jeg har fornylig set et req. på et 2048 bit certifikat. Hvergang du tilføjer en bit, fordobler du antallet af mulige kombinationer, så du kan selv gætte på hvad det gør ved en CPU når den skal krypter eller dekrypter, selvom den kender nøglene eller certifikaterne.

[Kandersen]

45 minutter siden, Lars1 skrev:

IOS11 krypterings understøttelse kom med i 2.8.1 såvidt jeg ved. Det står der ikke direkte, men det var såvidt jeg ved, den ændring, som gjorde at LK ikke længere ville supporter HW 6.1. I 2.8.4 røg brugen af MD5 certifikater, hvilket løste problemer med manglende support for MD5 i Java. Jeg har dog ikke nærstuderet IOS11 ændringen, så jeg ved ikke præcist hvad det er de har droppet at supporter. Men LK henviser altid til deres seneste firmware, også selvom problemet reelt vil være løst med en tidligere firmware.

Okay.. Problemet, i mit tilfælde, er nok også den anden vej rundt, i IOS enhederne/appen. Uanset hvad jeg gør med controlleren, så falder hammeren når jeg opdatere IOS enheden, så vidt jeg har forstået det.

Det som jeg jagter pt. det er den firmware der bedst virker til HW 6.2, med IOS 11/appsene OG OpenHab/3.part. 
Hvis jeg opdatere HW 6.2 controlleren til 2.8.4, så løses problemet med IOS 11/Appsene. Men jeg risikere problemer med 3.part.
Hvis jeg ikke opdatere til 2.8.4, så løses problemet med 3.part, men det er no go med IOS11/appsene. 

Det er noget af et dilemma!
Der er dog nogen der melder, at det fungere fint med OpenHab2 og 2.8.4 (og dermed også IOS appsene) på en HW 6.2 controller. Og så lander jeg der hvor det omvendt hedder 'prøv dig frem' 

Jeg er med på hvad krypteringen gør. Men det gør jo bare det hele så meget mere vanskeligt at regne med. 

[Lars1]

21 timer siden, Kandersen skrev:

Det som jeg jagter pt. det er den firmware der bedst virker til HW 6.2, med IOS 11/appsene OG OpenHab/3.part. 
Hvis jeg opdatere HW 6.2 controlleren til 2.8.4, så løses problemet med IOS 11/Appsene. Men jeg risikere problemer med 3.part.
Hvis jeg ikke opdatere til 2.8.4, så løses problemet med 3.part, men det er no go med IOS11/appsene.

Det er nok nærmest ligegyldig hvilken firmware være du vælger. Problemet er at de stærke krypterings nøgler/certifikater som IOS11 kræver lægger meget load på CPU'en og dermed gør controlleren ustabil, især når den bruges med 3 parts integration via API'et i controlleren.

21 timer siden, Kandersen skrev:

Det er noget af et dilemma!
Der er dog nogen der melder, at det fungere fint med OpenHab2 og 2.8.4 (og dermed også IOS appsene) på en HW 6.2 controller. Og så lander jeg der hvor det omvendt hedder 'prøv dig frem' 

Jeg er med på hvad krypteringen gør. Men det gør jo bare det hele så meget mere vanskeligt at regne med. 

Jeg tror ikke der er anden vej. Der er for mange variabler som har indflydelse på resultatet, men du burde kunne få en idee om det vil virke eller ej hvis du vurder din installation på nedenstående parameter.

• Stærk eller svag kryptering. (før eller efter firmware 2.8.x) Stærk kryptering giver mere load på CPU'en.
• 3 parts integration via LK IHC api'et. 3 parts produkter læser typisk samtlige parameter i programmet hvergang de poller. Dette giver selvfølgelig ekstra arbejde for CPU'en da hver parameter skal polle individuelt, og der skal svare på hvert poll individuelt.
• Mange parameter i dit program, incl. flag, interne parameter etc. Specielt hvis du har 3 parts integration via API'et giver dette ekstra load på CPU'en.
• Temp sensor hvad enten disse er med gulv føler, lux måler eller fugt måler. Disse sender en bit strøm gennem en on/off indgang. Dette belaster CPU'en. Benyttes Zigza senso sendes der informationer til controlleren 10 gange så ofte som med LK's sensor.

Der er ikke en af ovenstående som giver problemer alene, men når de bruges i kombination, så er det problemerne opstår.

[Kandersen]

På 14/10/2017 at 12:54 , Lars1 skrev:

Der er ikke en af ovenstående som giver problemer alene, men når de bruges i kombination, så er det problemerne opstår.

Yep det er jeg klar over. Men som jeg ser det, så må det være IOS11 som er den største synder, hvis den benytter sig af en markant højere bit kryptering.

[Lars1]

53 minutter siden, Kandersen skrev:

Yep det er jeg klar over. Men som jeg ser det, så må det være IOS11 som er den største synder, hvis den benytter sig af en markant højere bit kryptering.

Det er jeg ikke enig. Det eneste IOS11 har gjort er at disable support for forældet krypterings standard som ikke burde have været i brug i flere år. Deruover gør IOS11 ikke andet end hvad Java gjorde for et par år siden da de droppede supporten af MD5, men i Java kan du reenable MD5. Jeg ved ikke om IOS11 har samme mulighed med det som er blevet disablet i den. TLS 1.0 er bare et trejde eksempel på en forældet krypterings algorithme, som ikke længere supporteres, og som LK også var længe om at skifte væk fra.

[Kandersen]

Det som jeg mener er, at når IOS11 har disablet nogle gamle krypteringsformer som controlleren (Fw) kører med. Så må det betyde, at med IOS11 apps og nyeste Fw, så benyttes nyere kryptering, og deraf større belastning på controlleren.

For hvad bruger IHC Captain og Openhab ellers?

[Lars1]

På serversiden kan du kun understøtte en version af algorithmerne, så her skal man vælge. Firmware version. 2.7.x og ældre understøtter kun de gamle algorithmer. Firmware 2.8.x og nyer understøtter kun de nye algorithmer.

På klient siden kan man sagtens understøtte flere algorithmer. IOS, Java, IHC Captain, OpenHab etc. har i flere år understøttet både de gamle og nye algorithmer samtidig. Det er først inden for de sidste par år de er begyndt at droppe de gamle algorithmer.

[Kandersen]

57 minutter siden, Lars1 skrev:

På serversiden kan du kun understøtte en version af algorithmerne, så her skal man vælge. Firmware version. 2.7.x og ældre understøtter kun de gamle algorithmer. Firmware 2.8.x og nyer understøtter kun de nye algorithmer.

På klient siden kan man sagtens understøtte flere algorithmer. IOS, Java, IHC Captain, OpenHab etc. har i flere år understøttet både de gamle og nye algorithmer samtidig. Det er først inden for de sidste par år de er begyndt at droppe de gamle algorithmer.

Meget apropos ovenstående, så havde jeg nok den mest mystisk oplevelse i går i mit skift af controller og efterfølgende opdatering af fw. Skal forsøge gør det kort og "forståeligt". 

Min HW 6.1 kørte med fw .199. Den kørte fint med IHC Captain og OpenHab2. Den brugte IKKE standard porte, hverken web eller ssl. (vigtig detalje)
Min HW 6.2 blev i først omgang installeret med fw .220, nyt ip, men præcis samme porte som HW 6.1, fordi det var nemmest da jeg skulle udskifte den gamle. Så skulle jeg ikke til at rode med java og Visual. Jeg kunne derfor bare udskiftet controlleren, skifte IP i IHC Captain og OpenHab. Så kørte hele installationen med den nye HW 6.2 controller. 

Derefter gik jeg i gang med at opdatere fw til 2.8.4.. Først på HW 6.1. Men den er ikke så vigtig, da den er pillet ud af installationen. Det var bare en "fordi man kan" årsag.
HW 6.2éren blev opdateret til 2.8.4. Og præcis som jeg forventede, så røg jeg ind i ballade med Java og Visual.. Det var heldigvis hurtigt løst ved at installere nyeste Java, (og så huske at genstarte controlleren, ellers "hænger" java fast i den gamle). 

IHC Captain og OpenHab ville ikke forbinde til controlleren mere. IHC Captain skulle "gen-opdage" controlleren på porten. Dvs IP nummeret som jeg tidligere havde skiftet, var ikke nok med fw 2.8.4. Men det mærkelige er, at den skulle det på ssl porten. Den stod standard til 443 i IHC Captain. Og da jeg skiftede den til det som jeg havde sat controlleren op til, så virkede det. 
OpenHab var langt mere underligt, for jeg har faktisk haft lavet en fejl i config filen til bindingen lige siden start for snart flere måneder siden. Jeg havde blot angivet IP nummeret til controlleren og intet andet.. Dvs. OpenHab burde slet ikke have virket på noget tidspunkt. Men det var først da jeg opdaterede controlleren til fw 2.8.4, at jeg fik problemer med OpenHab. Efter jeg rettede config filen til IP:port (ssl) så virkede den også igen.

Så fra fw .220 (.199) og til 2.8.4, så sker der altså et eller andet omkring ssl. Og når jeg såen tænker lidt over det, set i bagspejlet, så har ssl nok slet ikke virket på hverken .199 eller .220. Hvad mere underligt er, at både IHC Captain og OpenHab begge har kunnet kommunikere med controlleren, men ikke på de rigtige porte, (web porten i IHC Captain var sat til det rigtige, måske derfor). Det har jeg godt nok aldrig set før. Og jeg fatter simpelthen ikke hvordan pokker det har været muligt for OpenHab. Hvis controllerne have været sat op til standard porte (dvs 80 og 443) så kunne jeg forstå indstillingen som en default. Men det var ikke tilfældet, da jeg jo har kørt med andre porte i controllerne lige fra start. Og alligevel har det virket lige indtil fw 2.8.4.. Vildt underligt!

 

[Lars1]

Jeg tror mere dit problem har været at din controller har skiftet til en anden krypterings algorithme, og det har dine klienter ikke opdaget før du har refreshet deres konfiguration.

[Kandersen]

Du har muligvis ret i noget af det. Men det stemmer ikke overens med OpenHab.
I OpenHab configurationen har jeg ikke på noget tidspunkt sat SSL porten. Kun IP nummeret. Og det har virket, lige indtil jeg opdaterede Fw (og skiftet controller). Husk på, jeg har hele tiden brugt ikke-default SSL port. Og det eneste jeg har skiftet, det er controller og IP nummer til den nye controller. OpenHab burde slet ikke have virket med hverken den ene eller den anden controller, og hverken før eller efter opdatering af controller fw. 

Til gengæld røg jeg ind i store problemer med OpenHab sent i går aftes. Pludselig fik jeg timeout til controlleren, men kun når jeg sendte en kommando TIL controlleren. Jeg får/fik fint meldinger den anden vej, dvs fra controller til OpenHab. Det har kørt ca 1 døgn uden problemer. 
Jeg gad ikke lige rode med det kl lort i nat, så den fik bare lov at køre. Her til formiddag er problemet stadigvæk det samme. Får fint melder fra controlleren, men kommandoer til controller timer ud og fejler. 

Det er foreløbig løst ved at sætte time out tiden op i ihc.cfg filen til OpenHab. (den stod til 5000, men nu er den sat til 6000). Nu kan jeg igen sende kommandoer til controlleren uden timeout. Jeg tror det er det problem som andre også har haft med OpenHab, hvor nogen har løst det med en rule, og ca. hvert kvarter sendt en "dummy" kommando til IHC controlleren.