Elli Wallbox eebus not detected

[vheat]

Today (2022-05-31) Elli distributed a new firmware of Elli Wallbox (ID.charger and other Volkwagen models).
This offers eebus interaction. However evcc-io/eebus does neither recognize the mDNS coming from the wallbox nor the wallbox lists the EVCC for a HEMS. Looks like the mDNS is also not recognized correctly by the box.

If needed I can provide a wireshark trace for the mDNS (both sources).

There are notices around that SMA can deal with the Elli for EEbus control, also the SMA looks to have some issues showing the Elli, but this is just early information.

I'm trying to get the EEbus SHIP specifcation to verify the mDNS records.

In EVCC log level trace there is not any indication of an mDNS entry being received (in [eebus] and other records)

[ginsolvibile]

Same here. evcc 0.94 and Elli Wallbox updated to the latest firmware.

I can confirm receiving mDNS / SHIP announcements from the wallbox, with tcpdump I see SRV records with apparently valid A and AAAA fields.

The "evcc charger" returns nothing, and from the wallbox web UI I see no available "energy managers".

@vheat the SHIP specs are publicly available, let me know if you did not find them.

My wallbox config block in evcc.yaml is

- type: template
  template: eebus 
  ski: ABxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx3A
  enforcePVLimits: true  
  name: wallbox3

I have some experience with Go and had a quick look at the SHIP and SPINE specifications, if there's anything I can do to help in debugging this issue I will be glad to.

[andig]

@ginsolvibile SHIP only happens after the discovery. Without any logging I'm still unsure what exactly fails during discovery.

@DerAndereAndi mentioned mDNS but I'm not sure what goes wrong.

It would probably help to have the Go mDNS listener to add some logging.

[DerAndereAndi]

I am on it with some success and some problems. Not done yet. The current implementation is not compatible, you need to wait.

[ginsolvibile]

@ginsolvibile SHIP only happens after the discovery. Without any logging I'm still unsure what exactly fails during discovery.

What I can see via wireshark is that the wallbox sends 3 mDNS queries (AAAA, A and SRV) and then immediately answers itself. The SRV query is:

Elli-Wallbox-1234xxxxxx._ship._tcp.local: type SRV, class IN, "QM" question
    Name: Elli-Wallbox-1234xxxxxx._ship._tcp.local
    [Name Length: 40]
    [Label Count: 4]
    Type: SRV (Server Selection) (33)

and the corresponding answer is

Elli-Wallbox-1234xxxxxx._ship._tcp.local: type SRV, class IN, cache flush, priority 0, weight 0, port 4712, target wallbox-1234xxxxxx.local
    Service: Elli-Wallbox-1234xxxxxx
    Protocol: _ship
    Name: _tcp.local
    Type: SRV (Server Selection) (33)
    .000 0000 0000 0001 = Class: IN (0x0001)
    1... .... .... .... = Cache flush: True
    Time to live: 120 (2 minutes)
    Data length: 27
    Priority: 0
    Weight: 0
    Port: 4712
    Target: wallbox-1234xxxxxx.local

@DerAndereAndi mentioned mDNS but I'm not sure what goes wrong.

It would probably help to have the Go mDNS listener to add some logging.

Let me know if you want me to do some tests on my network.

[ginsolvibile]

I am on it with some success and some problems. Not done yet. The current implementation is not compatible, you need to wait.

Thank you @DerAndereAndi and @andig for all the work you've done, implementing eebus from scratch must have been a challenging task. After 2 years waiting for Elli to deliver the protocol they promised :) I can certainly wait all the time you need.

I'm available for further testing, if you need.

[DerAndereAndi]

The problem with mDNS here is the zeroconf library. Elli can not see the mDNS entry from this library and the library only sometimes sees entries from the Elli wallbox. When it does see the Elli wallbox, there are always some mandatory items missing, either the network record or the TXT record.

I implemented a workaround to use the native avahi linux system when available. That way discovery works flawlessly. My desire to make zerconf work here is very very low.

For ship to work I already have some fixes, they were minor.
The bigger task is SPINE, as they use EEBUS very differently compared to Porsche/Audi and also very buggy (e.g. don't providing lots of mandatory data). I got the communication running, but the box still shows with its LED that the HEMS is not active and charging is fixed to 6A per current. All changes are accepted in EEBUS but ignored. I am trying to somehow get hold on someone at Elli.

The other remaining issue is the certificate Elli or better EVBox uses (they are the 3rd party building the wallbox and developing the software). The certificate is not conforming to the DER standard and marking the isCA flag with 0x1 for true instead of 0xFF and go crypto checks for 0xFF and rejects the certificate otherwise. More info here: https://forum.golangbridge.org/t/x509-certificate-parse-error-with-iot-device/27622/2

[andig]

Ich hab mal bei GE angefragt ob jemand von VW mit liest.

[andig]

@ginsolvibile

What I can see via wireshark is that the wallbox sends 3 mDNS queries

You could try the _ship._tcp queries in Go and check why Go doesn't decode the responses (if you can see them on tcpdump).

[vheat]

For more discussions see evcc-io/evcc#1217 (reply in thread)

[StefanSchoof]

I am not an asn.1 expert, but if I read https://docs.microsoft.com/en-us/windows/win32/seccertenroll/about-boolean correct the bool is a valid true.

[DerAndereAndi]

Here the expertise from an SSL expert (not me):

..., im Debugger sieht man dass im Zertifikat von der Elli eine 0x01 kommt, cryptobyte/asn1.go erwartet aber 0xFF.

In der zugehörigen Spec zu ASN.1 https://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC-X.690-202102-I!!PDF-E&type=items Chapter 8.2 steht aber, dass alles außer 0x00 dann TRUE ergeben soll.
Insofern ist go cryptobyte/asn1.go falsch.

Dann, der commit 06a226f
https://cs.opensource.google/go/x/crypto/+/793ad666bf5ec61392092b27061be9618e4e219b:cryptobyte/asn1_test.go;bpv=1;bpt=0;drc=06a226fb4e3765ef3f48aa2852b401bc7b98e981;dlc=18b771bd64f19baf6611ce73e30afe2e1a50082c
führt den Test ein und verweist hier auf DER in Chapter 11.1 und da steht dann tatsächlich, dass alle Bits 1 sein sollen.

...

... sage ich mal, BER oder DER beschreiben die „encoding rules“, also wie sollte es eingepackt werden. Cryptobyte macht das Decoding und da könnte man das m.E. etwas relaxter handeln. Frage für mich wäre, ob beim Cert irgendwas steht, das es DER encrypted ist, also der Decoder auch DER machen soll. Dann wäre das Problem bei Elli. Evtl kann man ja auch beim TLS einstellen, wie das Cert decodiert werden soll, ob DER oder BER. Da ich in Cryptobyte aber keine Möglichkeit sehe, zwischen BER und DER zu unterscheiden, ist das müßig zu diskutieren.

Ich denke, Cryptobyte sollte die Condition beim Decodieren relaxen. Beim Encodieren machen sie immer 0 oder FF. Sie scheinen den Anspruch zu haben einen ASN1 DER En-/Decoder zu haben.

...

Elli könnte man auch ansprechen, die X.509 Spec https://datatracker.ietf.org/doc/html/rfc5280#section-4.1 sagt, das ein V3 Cert nach DER encodiert sein soll. Hier ist Elli definitiv falsch.

Ich hab im Moment nur den RFC, die ISO wird dem aber vermutlich nicht widersprechen ISO/IEC 9594-8:2020 https://www.iso.org/standard/80325.html

[vheat]

Das Cert der Elli bekommt man mit
openssl s_client -connect 192.168.1.180:4712 -showcerts
Bitte IP und Port entsprechend dem mDNS Eintrag für SHIP der Elli setzen.
Für HTTPS/Port 443 ist das Cert korrekt (FF)

Aus dem Ergebnis das Cert ausschneiden (von BEGIN bis END CERTIFICATE und z.B. in wallbox.crt kopieren)
Das Cert der Elli kann dann man auseinander nehmen mit
:~/wallbox$ openssl asn1parse -in wallbox.crt
....
275:d=4 hl=2 l= 12 cons: SEQUENCE
277:d=5 hl=2 l= 3 prim: OBJECT :X509v3 Basic Constraints
282:d=5 hl=2 l= 5 prim: OCTET STRING [HEX DUMP]:3003010101
289:d=4 hl=2 l= 29 cons: SEQUENCE
...
Da sieht man sehr schön die fehlerhafte 01

Der freie OSS Nokalva ASN1 Decoder
https://asn1.io/PKI-inspector/default.aspx? (bitte X.509 auswählen)
markiert die BasicConstraints der Elli auch rot als Fehler, decodiert aber dennoch nach TRUE. Ein FF würde ohne Fehler angezeigt.

Da scheint die Elli intern die Certs für https und SHIP unterschiedlich zu erzeugen.

[andig]

Bzgl. SSL: https://letsencrypt.org/docs/a-warm-welcome-to-asn1-and-der/ schreibt:

ASN.1’s main serialization format is “Distinguished Encoding Rules” (DER). They are a variant of “Basic Encoding Rules” (BER) with canonicalization added. For instance, if a type includes a SET OF, the members must be sorted for DER serialization.

Ich würde das Go issue aufmachen, weiß aber nicht wie ich mit

Frage für mich wäre, ob beim Cert irgendwas steht, das es DER encrypted ist, also der Decoder auch DER machen soll.

umgehen soll. Kann der Experte vllt nochmal sagen, ob/wie man ihm das ansieht? Hilfreich wäre auch ein Callstack von der Stelle wo das Bool Decoding aussteigt- dann wüsste man wenigstens was Go da in den höheren Levels gerade versucht.

[andig]

Allerdings sieht das schlecht aus: golang/go#48210 (comment)

It looks like there's no plan to add BER support

[andig]

Aber vielleicht hilft das ja: https://github.com/go-asn1-ber/asn1-ber

[vheat]

Hallo, ich bedanke mich für die Blumen :-)
Also die ASN1 Spec findet man hier https://www.itu.int/rec/dologin_pub.asp?lang=e&id=T-REC-X.690-202102-I!!PDF-E&type=items

Direkt die Introduction in dieser Spec sagt, Seite v

This Recommendation | International Standard defines encoding rules that may be applied to values of types defined using
the ASN.1 notation. Application of these encoding rules produces a transfer syntax for such values. It is implicit in the
specification of these encoding rules that they are also to be used for decoding.

Damit ist Decoding wie Encoding und die Position von cryptobyte ist akzeptabel. Elli ist damit definitiv falsch.
Schaut man sich die Decodierung z.B. mit dem freien OSS Nokalva https://asn1.io/PKI-inspector/ an, meldet der zwar keinen harten Fehler, markiert die BasicConstraints aber rot, um das Problem anzuzeigen.

Persönlich fände ich auch gut, die Varianz im TLS Cert möglichst gering zu halten, insofern hat die TLS/X.509 Spec auch DER gewählt. Es stört uns nur im Moment... Aber ich denke kurz-/mittelfristig muss Elli hier nachbessern, Ich halte ein falsch encodiertes TLS Cert schon für problematisch.

[vheat]

Der asn1-ber vergleicht für BOOLEAN True mit
be.go line 365

		case TagBoolean:
			val, _ := ParseInt64(content)

			p.Value = val != 0

Ebenso beim Encoding Line 526, da wird einfach der Wert != 0 genommen.

func NewBoolean(classType Class, tagType Type, tag Tag, value bool, description string) *Packet {
	intValue := int64(0)

	if value {
		intValue = 1
	}
	p := Encode(classType, tagType, tag, nil, description)
	p.Value = value
	p.Data.Write(encodeInteger(intValue))

Sollten wir den BER Code allgemein verwenden, könnten wir an anderer Stelle in Problem laufen, sollte die Elli intern dann doch DER machen.

Nur als Randbemerkung, das Cert, dass die Elli für https / lokales Config Interface verwendet, ist korrekt mit 0xFF kodiert.

[andig]

Bleibt die Frage wie wir die Library überhaupt nutzen könnten:

	// VerifyPeerCertificate, if not nil, is called after normal
	// certificate verification by either a TLS client or server. It
	// receives the raw ASN.1 certificates provided by the peer and also
	// any verified chains that normal processing found. If it returns a
	// non-nil error, the handshake is aborted and that error results.
	//
	// If normal verification fails then the handshake will abort before
	// considering this callback. If normal verification is disabled by
	// setting InsecureSkipVerify, or (for a server) when ClientAuth is
	// RequestClientCert or RequireAnyClientCert, then this callback will
	// be considered but the verifiedChains argument will always be nil.

Der zweite Absatz dürfte der spannende sein. Jetzt müsste man mal testen, ob sich die Verifikation damit umgehen lässt. Ich fürchte aber auch das würde das Problem nicht lösen, da uns das Zertifikat denn nicht zum Verschlüsseln zur Verfügung stünde?

[DerAndereAndi]

Nein, die Methode kann man nicht verwenden, er steigt vorher aus.

In https://github.com/golang/go/blob/master/src/crypto/tls/handshake_client.go#L856 geht er aus verifyServerCertificate raus. In der gleichen Methode in https://github.com/golang/go/blob/master/src/crypto/tls/handshake_client.go#L892 würde VerifyPeerCertificate aufgerufen.

Hilft also leider nicht. Es scheint es gibt hier nur 2 Lösungen:

• Go erlaubt den invaliden Wert 1
• Elli erstellt auf den Geräten ein neues Zertifikat, was auch zur Konsequenz hätte dass alle bisher gekoppelten HEMS Systeme neu gekoppelt werden müssten

Übersehe ich eine Lösungsvariante?

[vheat]

Ich seh eigentlich nur die zweite Lösung, Elli benutzt hier ein formal inkorrektes Zertifikat (soll DER sein). Lösung 1 wäre für mich ein Workaround bis dahin. Gibt es bei Go eine Möglichkeit, privat einen Patch auf ein vorhandenes Paket zu setzen?

[StefanSchoof]

Ein anderer (aber auch kein schöne) Möglichkeit wäre das über einen Proxy, der das Zert akzeptiert und ein eignes Präsentiert laufen zu lassen.

[DerAndereAndi]

Ich hatte versucht das in ein eigenes gepatchtes Crypto Paket zu forken, aber die internen Abhängigkeiten sind recht groß, so dass ich davon abgelassen habe. Einen anderen Weg das "schön" zu patchen, ist mir nicht bekannt. Vielleicht hat da aber @andig eine Idee, er hat da viel mehr Erfahrung.

Ob und bis Elli das korrigiert, wird kein kurzfristiger Prozess sein, sondern eher Monate dauernd (nach meiner Erfahrung).

Ein Proxy zu nutzen ist nicht trivial möglich. Es muss zwischen den Geräten eine stehende TLS WebSocket Verbindung geben und Informationen aus dem Zertifikat in ein Proxy Zertifikat müssten transparent übersetzt werden, da diese Zertifikatsinfos auch in der weiteren Kommunikation relevant sind. Nach meiner Einschätzung wäre das extrem viel Arbeit und zu wissen ob das auch funktionieren könnte. Den Aufwand imho nicht Wert.

[andig]

Ich seh eigentlich nur die zweite Lösung, Elli benutzt hier ein formal inkorrektes Zertifikat (soll DER sein). Lösung 1 wäre für mich ein Workaround bis dahin. Gibt es bei Go eine Möglichkeit, privat einen Patch auf ein vorhandenes Paket zu setzen?

Ja, go mod replace. Das wäre auch die Lösung um die zeroconf ohne Codeänderungen auszutauschen. Ich weiss allerdings nicht, ob das auch mit internen Modulen funktioniert- wäre aber einen Versuch wert (kann ich auch testen).

Ein anderer (aber auch kein schöne) Möglichkeit wäre das über einen Proxy, der das Zert akzeptiert und ein eignes Präsentiert laufen zu lassen.

Coole Idee. Gibts da was?

[DerAndereAndi]

Ja, go mod replace. Das wäre auch die Lösung um die zeroconf ohne Codeänderungen auszutauschen. Ich weiss allerdings nicht, ob das auch mit internen Modulen funktioniert- wäre aber einen Versuch wert (kann ich auch testen).

Kann man damit auch einzelne Files ersetzen? Das Modul zu extrahieren um es zu patchen hatte ich versucht aber die internen Querverbindungen (Referenzen auf /internal im Root) waren mit dann zu viel.

Ich versuche das mal fix nur mit Cryptobyte

Update: bekomme es nicht hin.

[DerAndereAndi]

libp2p/zeroconf hat das Interface ganz leicht geändert. Man kann nun einige Zeilen Init Code (den Resolver) rauslassen. D.h. ich würde da schon wechseln und dann evtl. mit replace auf nen Fork gehen. Da das momentan noch nicht viel bringt, würde ich erst mal warten ob die das mergen bzw. wie lange das dort dauert.

[andig]

Ich versuche das mal fix nur mit Cryptobyte
Update: bekomme es nicht hin.

Ich denke das geht nur auf ganze Module und nicht einzelne Packages :( Und dann hängst Du wieder an den internal Dependencies. Geht wohl nicht :(

[andig]

https://groups.google.com/g/golang-nuts/c/-wJDIS2DZEI/m/JCVtzkpNAwAJ

[andig]

libp2p/zeroconf hat das Interface ganz leicht geändert.

@DerAndereAndi könntest Du den PR auch gegen die originale zeroconf auf machen? Der Fork ist nicht "offiziell" und es wäre zumindest schön auch Upstream die Möglichkeit zu geben, damit zu arbeiten und noch ist das Repo deutlich populärer. grandcat/zeroconf#27 (comment) scheint mir im Fork ebenfalls nicht gelöst zu sein. Ich kanns sonst auch gerne rüber schieben...

[StefanSchoof]

Ein anderer (aber auch kein schöne) Möglichkeit wäre das über einen Proxy, der das Zert akzeptiert und ein eignes Präsentiert laufen zu lassen.

Coole Idee. Gibts da was?

Ich habe noch nichts benutzt. Per Google habe ich welche gefunden. "Leider" viele in go geschrieben, so dass sie nicht wahrscheinlich helfen können (https://github.com/suyashkumar/ssl-proxy, https://github.com/ghostunnel/ghostunnel).
Gibt auch was in rust https://lib.rs/crates/proxyboi

[DerAndereAndi]

Update: hab es hinbekommen und den Branch einfach von nem älteren Commit gemacht: grandcat/zeroconf#108

[andig]

Ein anderer Weg wäre beim CI Build als Schritt vor dem eigentlichen Build die Datei asn1.go zu patchen.

Mein Vorschlag wäre ganz einfach: abwarten. Der ganze Proxykram nutzt uns sowieso nur wenn danach auch die Kommunikation funktioniert. Da ist Andi mit Elli dran. Wenn der Kontakt eh steht hätte ich auch die Hoffnung, dass sich beim Zertifikat was tut. Von daher würde ich da aktuell gar keinen Aufwand rein stecken. Wer jetzt testen will hat den Workaround mit lokal gepatchtem Go.

[DerAndereAndi]

Für das Zertifikatsthema wird höchstwahrscheinlich erst mal ein irgendwie gearteter Workaround notwendig sein.

Anders gesagt: Es wird hier keine kurzfristige Lösung von Elli geben. Eine Workaround wird wohl für dieses Jahr notwendig sein.

[matze-pe]

Hatte Elli etwas gesagt, wann sie einen fix dafür heraus bringen werden?
Nicht das wir jetzt wieder 2 Jahre auf eine Lösung von denen warten müssen. Ich hatte das bei Elli auch schon mal angefragt, ob sie nicht einen weiteren Bereich mit Beta User eröffnen um so die Qualität ihrer Software optimieren können. Leider ist das im Konzern nicht angedacht.

[DerAndereAndi]

@matze-pe Elli ist sehr daran interessiert dass die Wallbox mit möglichst vielen EEBUS HEMS Systemen funktioniert. Ich würde jetzt aber nicht davon ausgehen, dass nur für evcc ein Software Update außerhalb der geplanten Releases herauskommen wird.

[HeikoSausM]

Moin!
Ich kann zwar aufgrund Zeitmangel nicht viel beitragen, aber wenn es was zu testen gibt, kann ich vielleicht helfen bei folgender Konfiguration:
E3DC Hauskraftwerk (super erkannt)
Audi Wallbox Pro
Audi etron 55
Dienstliche Ladekarte
Wallbe Eco S (hier nicht relevant)
Und ich könnte mich bei Audi intern mal beschweren warum das Zertifikat so doof/ungültig ist. :-)

[DerAndereAndi]

@HeikoSausM Danke, es sind bereits alle Probleme bei Elli adressiert und bekannt.

[vheat]

Hallo @HeikoSausM,
lese ich das richtig, dass die Elli über EEbus sauber mit dem E3DC kommuniziert? Echtes PV Überschussladen ist möglich?
Gibt es Logs, aus denen man den detailierten Message Flow ersehen könnte?
Danke
vheat

[DerAndereAndi]

@vheat nein, evcc hat das E3DC System erkannt. Die können kein EEBUS, bzw. nur deren Mutterkonzern Hager hat bisher ein HEMS das EEBUS kann.

[DerAndereAndi]

@lansester Ich würde hier in diesem Ticket gerne nur um das eigentliche Thema diskutieren, hoffe auf dein Verständnis.

Als Hinweis: Du kannst die Box per DIP Schalter auch auf 4,2kW reduzieren. Ist im Handbuch dokumentiert.

[Gregor-de]

sehr ruhig geworden...

[DerAndereAndi]

Ich bin mit Elli im Kontakt und Elli ist sehr an einer Lösung interessiert. Wir können nur warten.

[Hofyyy]

@DerAndereAndi

Hallo,

ich habe Elli gerade auch wegen dem Thema angeschrieben, da ich das hier zu spät gelesen haben. :-(

Hast du irgendwelche Ticketnummern von Elli, oder ein paar Infos wie du mit ihnen in Kontakt stehst?
Ich finde die Aussage wir können nur warten ein wenig einfach :-)

Viele Grüße
Sebastian

[DerAndereAndi]

@Hofyyy Ich bin mit dem entsprechenden Projektverantwortlichen in Kontakt. Es braucht da keine Ticketnummern oder ähnliches.

Es gibt viele Audi/VW Mitarbeiter die bei dem Problem nachgefragt haben, weil sie selbst betroffen sind, die Manager wollen auch dass es Lösungen gibt, von Elli Seite ist da genug drive und Druck dahinter.

Auch wenn das nach außen wenig ist, ist es das einzige was ich sagen kann. Bitte um Verständnis.

P.S.: Wer einmal in so großen Firmen (habe ich) in der Automobilindustrie (habe ich auch) gearbeitet hat weiss, dass man da nicht einfach jemanden ein paar Stunden hinsetzen kann um das Problem zu finden, zu lösen und dann ein Bugfix zu veröffentlichen.

P.P.S.: Die Box wird nicht von Elli selbst entwickelt, sondern wird zugeliefert. Schaut mal auf die Plakette, da steht der Anbieter. Und der macht auch die Software, wobei da bei EEBUS ein weiterer Zulieferer im Boot ist.

[Hofyyy]

@DerAndereAndi
Vielen Dank für den Einblick. Dann warte ich mal ab was sie antworten und beobachte hier den Thread.

Deine P.P.S. Gründe kann ich nachvollziehen, allerdings besteht ja der Fehler darin, dass VW als Konzern es so organisiert und nicht die Fäden in der Hand behält.

Um es mal mit den Worten von Herrn Diess zu sagen:
„Was uns fehlt, das sind vor allem Schnelligkeit und der Mut zu kraftvollem, wenn es sein muss radikalem Umsteuern“

Ich bin sehr gespannt ob sich die Deutsche Autoindustrie auf der Vergangenheit ausruht, oder sich Strukturell so aufstellt, so ein Thema wie EEBUS in einem sinvollen Zeitrahmen abfahren zu können und nicht auf Zulieferer verweisen zu müssen. Und auch Zulieferer kann man anders Managen.

PS:
Ich leite auch eine SW Abteilung :-)

[andig]

Ich fände es Klasse, wenn die Offenheit und Lösungsorientierung soweit gehen würde, dass z.B. VW oder Elli Mitarbeiter hier in ihrer Rolle präsent wären. Schöne Beispiele dafür gibts z.B. bei Go wo Intel oder auch Mitarbeiter anderer Firmen in loser Zusammenarbeit Themen voran bringen. Uns treibt ja der gemeinsame Anspruch, die Energiewende zum Erfolg zu machen!

[DerAndereAndi]

Update: ich habe es nun zum Laufen gebracht, es gab noch einen Fehler bei den Heartbeats hier im Stack. Ein Feld ist mandatory und wird benötigt, die Porsche Wallbox hatte das aber nicht interessiert, daher ist das bis jetzt durchgerutscht.

Der Zertifikatsproblem ist noch offen, da bin ich noch mit Elli dran. Und auch an den Workarounds die ich einbauen musste aufgrund von Fehlern auf deren Seite.

[Gregor-de]

Danke…..
Bin schon ganz aufgeregt 😉

[andig]

Ein Feld ist mandatory und wird benötigt, die Porsche Wallbox hatte das aber nicht interessiert, daher ist das bis jetzt durchgerutscht.

Klasse! Bei fehlenden Pflichtfeldern würde man ja eine Fehlermeldung erwarten; beim Heartbeat lässt sich aber sicher nachvollziehen, dass das dann als Verbindungsabbruch gewertet wird...

[ginsolvibile]

Update: ich habe es nun zum Laufen gebracht, es gab noch einen Fehler bei den Heartbeats hier im Stack. Ein Feld ist mandatory und wird benötigt, die Porsche Wallbox hatte das aber nicht interessiert, daher ist das bis jetzt durchgerutscht.

Der Zertifikatsproblem ist noch offen, da bin ich noch mit Elli dran. Und auch an den Workarounds die ich einbauen musste aufgrund von Fehlern auf deren Seite.

Vielen Dank Andi, can't wait to see it finished!

[andig]

@elli.eco: könnten wir bitte eine grobe Abschätzung bekommen wie lange eine Korrektur des Zertifikats etwa dauern sollte bzw. wann das nächste Release geplant ist?

[DerAndereAndi]

Eventuell. Ist noch nichts sicher. Es gibt von Elli keine öffentlichen Release Planungen.

[DerAndereAndi]

Es ist leider weiterhin unklar wann das Zertifikat gefixt wird. Wäre es evtl. denkbar dass man bei den automatisierten Builds oder im Makefile einen patch der asn1.go Datei durchführt?

Z.b. mit patch -N -t < asn1.patch

-N  --forward  Ignore patches that appear to be reversed or already applied.
-t  --batch  Ask no questions; skip bad-Prereq patches; assume reversed.

Die Optionen stellen sicher dass der Patch nur durchgeführt wird, wenn er noch nicht vorhanden ist. Es ist aber nicht 100% sichergestellt dass der Patch auch nicht zu Compiler Fehlern führt, falls sich die Datei geändert hat.

--- asn1.go	2022-09-15 13:21:17.000000000 +0200
+++ asn1_new.go	2022-09-15 13:22:12.000000000 +0200
@@ -255,7 +255,7 @@
 	switch bytes[0] {
 	case 0:
 		*out = false
-	case 0xff:
+	case 1, 0xff:
 		*out = true
 	default:
 		return false

Auf dem Mac liegt die Datei in /usr/local/go/src/vendor/golang.org/x/crypto/cryptobyte und benötigt sudo zu patchen. Evtl. wäre das Makefile kein guter Ort dafür, sondern ein extra Kommando? Man müsste auch noch schauen ob das bei den automatisierten Builds überhaupt durchführbar wäre und wo dort die Datei liegt.

[andig]

Das wäre:

go env GOROOT
/opt/homebrew/Cellar/go/1.19.1/libexec

ich wage aber zu bezweifeln, ob uns die CI da ran lassen würde, sudo gibts m.W. nicht.

[StefanSchoof]

Ich glaube das geht:

The Linux and macOS virtual machines both run using passwordless sudo. When you need to execute commands or install tools that require more privileges than the current user, you can use sudo without needing to provide a password.

https://docs.github.com/en/actions/using-github-hosted-runners/about-github-hosted-runners#administrative-privileges

[DerAndereAndi]

@andig was wäre dein präferierter Ort wo das patchen gemacht werden sollte/könnte ?

[andig]

Makefile? Dann könnte man das sowohl im Dockerfile als auch in release.yaml aufrufen.

[DerAndereAndi]

Im Makefile wird ja sudo schon verwendet:

image:
	gokr-packer -overwrite=$(IMAGE_FILE) -target_storage_bytes=1258299392 $(IMAGE_OPTIONS)
	loop=$$(sudo losetup --find --show -P $(IMAGE_FILE)); sudo mkfs.ext4 $${loop}p4
	gzip -f $(IMAGE_FILE)

Ich mach das mal in den PR im evcc repo rein

[DerAndereAndi]

Das Repository hier wird archiviert, da die EEBUS Implementierung ersetzt wurde.

Elli ist meines Wissens an dem Zertifikatsproblem weiter dran und es soll ein Bugfix kommen. Wann ist bisher leider unbekannt. Der momentane Workaround funktioniert und hoffentlich kann er baldigst gestrichen werden.

Falls es weiteren Gesprächsbedarf zu dem Thema gibt, macht bitte eine Diskussion bei evcc auf: https://github.com/evcc-io/evcc/discussions