letzte Linux Version ( cgm-rc-heli-simulator-linux-x86-64bit-1623.zip ) kaputt
#1
Hallo und guten Tag,
das Update mit o.g. Datei führte mal wieder zum Vergessen der Lizenz und einiger Einstellungen.
Weil das Programm zudem fälschlich und persistent behauptet keine Internetverbindung zu haben, ist diese Version für mich unbenutzbar.
Ich musste auf cgm-rc-heli-simulator-linux-x86-64bit-1619.zip zurück gehen und die Credentials für die Lizenz erneut eingeben.
PS
Irgendwie folgt die Benamung der Dateien nicht wirklich den propagierten Versionsnummern?
Gruß
Dieter
#2
Hallo Dieter,
im Namen der Download-Datei ist immer die Versionsnummer enthalten.
Zum Kompilieren des neXt v1.620 und höher habe ich die aktuellen Unity3D Libraries verwendet. Das war ein relativ großer Sprung, was intern auch sehr viel Programmierarbeit bedeutete. Weiters ist die 32bit Version leider nicht mehr enthalten, da Unity3D die 32bit Unterstützung komplett über Bord geschmissen hat. Das könnte in Deinem Fall die genannten Unterschiede verursacht haben.
Werden der Internetzugriff der neuen Version von Deinem System geblockt? Eventuell alle Dateizugriffe? So könnte ich mir das erklären.
Viele Grüße,
Klaus
#3
Hallo Klaus,
der Appclication stehen eine Namensauflösung und die Berechtigung einen beliebigen Port einer beliebigen IP-Adresse zu connecten zur Verfügung.
ein strace auf den Prozess mit grep 'open' gefiltert zeigt Folgendes:
2
3
4
5
6
7
[pid 5466] openat(AT_FDCWD, "/dev/nvidiactl", O_RDWR) = 37
[pid 5435] openat(AT_FDCWD, "/usr/share/fonts/truetype/ariali.ttf", O_RDONLY) = 37
[pid 5455] openat(AT_FDCWD, "/etc/ssl/certs/ca-certificates.crt", O_RDONLY <unfinished ...>
[pid 5455] <... openat resumed> ) = -1 ENOENT (No such file or directory)
[pid 5435] openat(AT_FDCWD, "/home/db/neXt/prefs.ini", O_WRONLY|O_CREAT|O_TRUNC, 0666) = 39
/etc/ssl/certs/ca-certificates.crt ist eine Datei die es auf einem Ubuntu System gibt bei OpenSuSE aber nicht.
Nur so eine Idee. Es gibt noch andere Linux Distributionen als Ubuntu ( an african word for Slackware is too hard for me )
Es gibt auch Standards und tools wie man auf jedem Linux System an die gewünschte Info kommt.
Gruß
Dieter
#4
#5
ca-certificates.crt wird auch in der alten Version versucht zu öffnen. Daran scheitert es nicht.
In beiden Versionen erscheint ein connect
connect(36, {sa_family=AF_INET, sin_port=htons(443), sin_addr=inet_addr("217.160.0.15")}, 16 <unfinished ...>
also wird 217.160.0.15 mit HTTPS angesprochen und das sollte erfolgreich sein.
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
Nicht OK:
[pid 7809] socket(AF_INET6, SOCK_DGRAM, IPPROTO_IP) = 16
[pid 7825] socket(AF_INET, SOCK_STREAM, IPPROTO_TCP) = 34
[pid 7825] connect(34, {sa_family=AF_INET, sin_port=htons(443), sin_addr=inet_addr("217.160.0.15")}, 16) = -1 EINPROGRESS (Operation now in progress)
[pid 7825] getpeername(34, {sa_family=AF_INET, sin_port=htons(443), sin_addr=inet_addr("217.160.0.15")}, [128->16]) = 0
[pid 7825] getsockname(34, {sa_family=AF_INET, sin_port=htons(58698), sin_addr=inet_addr("192.168.178.3")}, [128->16]) = 0
[pid 7830] socket(AF_INET, SOCK_STREAM, IPPROTO_TCP <unfinished ...>
[pid 7830] connect(39, {sa_family=AF_INET, sin_port=htons(443), sin_addr=inet_addr("217.160.0.15")}, 16 <unfinished ...>
[pid 7830] getpeername(39, {sa_family=AF_INET, sin_port=htons(443), sin_addr=inet_addr("217.160.0.15")}, [128->16]) = 0
[pid 7830] getsockname(39, {sa_family=AF_INET, sin_port=htons(58700), sin_addr=inet_addr("192.168.178.3")}, [128->16]) = 0
[pid 7835] socket(AF_INET, SOCK_STREAM, IPPROTO_TCP <unfinished ...>
[pid 7835] connect(39, {sa_family=AF_INET, sin_port=htons(443), sin_addr=inet_addr("217.160.0.15")}, 16 <unfinished ...>
[pid 7835] getpeername(39, {sa_family=AF_INET, sin_port=htons(443), sin_addr=inet_addr("217.160.0.15")}, [128->16]) = 0
[pid 7835] getsockname(39, {sa_family=AF_INET, sin_port=htons(58702), sin_addr=inet_addr("192.168.178.3")}, [128->16]) = 0
OK:
[pid 8464] socket(AF_INET6, SOCK_DGRAM, IPPROTO_IP) = 16
[pid 8519] socket(AF_INET, SOCK_STREAM, IPPROTO_TCP <unfinished ...>
[pid 8519] connect(35, {sa_family=AF_INET, sin_port=htons(443), sin_addr=inet_addr("217.160.0.15")}, 16 <unfinished ...>
[pid 8519] getpeername(35, {sa_family=AF_INET, sin_port=htons(443), sin_addr=inet_addr("217.160.0.15")}, [128->16]) = 0
[pid 8519] getsockname(35, {sa_family=AF_INET, sin_port=htons(58712), sin_addr=inet_addr("192.168.178.3")}, [128->16]) = 0
[pid 8521] socket(AF_INET, SOCK_STREAM, IPPROTO_TCP) = 38
[pid 8521] connect(38, {sa_family=AF_INET, sin_port=htons(443), sin_addr=inet_addr("217.160.0.15")}, 16) = -1 EINPROGRESS (Operation now in progress)
[pid 8521] getpeername(38, {sa_family=AF_INET, sin_port=htons(443), sin_addr=inet_addr("217.160.0.15")}, [128->16]) = 0
[pid 8521] getsockname(38, {sa_family=AF_INET, sin_port=htons(58714), sin_addr=inet_addr("192.168.178.3")}, [128->16]) = 0
[pid 8533] socket(AF_INET, SOCK_STREAM, IPPROTO_TCP <unfinished ...>
[pid 8533] connect(36, {sa_family=AF_INET, sin_port=htons(443), sin_addr=inet_addr("217.160.0.15")}, 16 <unfinished ...>
[pid 8533] <... getpeername resumed> {sa_family=AF_INET, sin_port=htons(443), sin_addr=inet_addr("217.160.0.15")}, [128->16]) = 0
[pid 8533] <... getsockname resumed> {sa_family=AF_INET, sin_port=htons(58716), sin_addr=inet_addr("192.168.178.3")}, [128->16]) = 0
Wie man sieht returned in beiden Fällen getpeername() erfolgreich.
(DESCRIPTION getpeername() returns the address of the peer connected to the socket sockfd, in the buffer pointed to by addr. )
Andernfalls würde ein Fehlercode wie ENOTCONN (The socket is not connected) statt 0 returned werden.
Die Application behauptet also trotz erfolgreich hergestellter Verbindung keinen Internetzugang zu haben.
Gruß
Dieter
#6
#7
#8
Hallo Klaus,
es lag doch wie zuerst vermutet an der fehlenden Datei /etc/ssl/certs/ca-certificates.crt
Möglicherweise haben die älteren neXt Versionen Dein Serverzertifikat ja einfach akzeptiert,
wenn die Gültigkeit nicht überprüft werden konnte.
Auf einem SuSE System und vermutlich auch bei Red Hat, CentOS usw. liegen die
CA Zertifikate in einzelnen Dateien im PEM Format im Verzeichnis /etc/ssl/certs/.
Außerdem liegen dort mit c_rehash erzeugte symlinks zu den *.pem files.
Die Datei ca-certificates.crt existiert nicht. Trotzdem funktionieren natürlich
Programme wie Browser usw. und können vertrauenswürdige SSL Verbindungen aufbauen.
Dafür gibt es ja den code in der libssl.
Ich habe nochmal ein strace mit mehr Ausgabe laufen lassen:
2
3
4
5
6
7
8
9
10
11
12
[pid 7645] getpeername(39, {sa_family=AF_INET, sin_port=htons(443), sin_addr=inet_addr("217.160.0.15")}, [128->16]) = 0
[pid 7645] getsockname(39, {sa_family=AF_INET, sin_port=htons(53620), sin_addr=inet_addr("192.168.178.3")}, [128->16]) = 0
[pid 7645] openat(AT_FDCWD, "/etc/ssl/certs/ca-certificates.crt", O_RDONLY) = -1 ENOENT (No such file or directory)
[pid 7645] close(39) = 0
[pid 7645] write(1, "Curl error 77: Error reading ca cert file from /etc/ssl/certs/ca-certificates.crt\n\n \n(Filename: ./Modules/UnityWebRequest/Implementations/TransportCurl.cpp Line: 734)\n\n", 168Curl error 77: Error reading ca cert file from /etc/ssl/certs/ca-certificates.crt
(Filename: ./Modules/UnityWebRequest/Implementations/TransportCurl.cpp Line: 734)
) = 168
Ich habe nun einfach sämtliche *.pem files aneinandergehängt als ca-certificates.crt
hin gelegt und es funktioniert nun mit V1.623 V1.625 und V1.627
Entweder hast Du UnityWebRequest falsch konfiguriert/bedient oder die Implementation ist an der Stelle bei Unity völlig naiv/fehlerhaft.
Das Kommandozeilenprogramm curl versteht diese Options:
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
--cacert <file>
(TLS) Tells curl to use the specified certificate file to verify the peer. The file may contain multiple CA certificates. The certificate(s) must be in PEM format. Nor-
mally curl is built to use a default file for this, so this option is typically used to alter that default file.
curl recognizes the environment variable named 'CURL_CA_BUNDLE' if it is set, and uses the given path as a path to a CA cert bundle. This option overrides that variable.
The windows version of curl will automatically look for a CA certs file named ´curl-ca-bundle.crt´, either in the same directory as curl.exe, or in the Current Working
Directory, or in any folder along your PATH.
If curl is built against the NSS SSL library, the NSS PEM PKCS#11 module (libnsspem.so) needs to be available for this option to work properly.
(iOS and macOS only) If curl is built against Secure Transport, then this option is supported for backward compatibility with other SSL engines, but it should not be set.
If the option is not set, then curl will use the certificates in the system and user Keychain to verify the peer, which is the preferred method of verifying the peer's
certificate chain.
(Schannel/WinSSL only) This option is supported for WinSSL in Windows 7 or later with libcurl 7.60 or later. This option is supported for backward compatibility with
other SSL engines; instead it is recommended to use Windows' store of root certificates (the default for WinSSL).
If this option is used several times, the last one will be used.
--capath <dir>
(TLS) Tells curl to use the specified certificate directory to verify the peer. Multiple paths can be provided by separating them with ":" (e.g. "path1:path2:path3").
The certificates must be in PEM format, and if curl is built against OpenSSL, the directory must have been processed using the c_rehash utility supplied with OpenSSL.
Using --capath can allow OpenSSL-powered curl to make SSL-connections much more efficiently than using --cacert if the --cacert file contains many CA certificates.
If this option is set, the default capath value will be ignored, and if it is used several times, the last one will be used.
Vielleicht kannst Du dich ja mal dazu äußern und das Problem nicht einfach ignorieren.
Gruß
Dieter
#9
Hallo Dieter,
wenn ich alle Einzelheiten selbst programmieren wollte, dann könnte ich mir die Game Engine ja sparen. Die Unity3D Mannschaft soll ein funktionierendes Frontend für verschiedene Plattformen liefern. An den betreffenden Internet-Aufrufen habe ich nichts geändert. Auf Windows und OSX funktioniert es ja. Und warum es auf Deinem Linux nicht funktioniert hast Du ja jetzt herausgefunden.
Unity3D gibt an, dass die Builds für Ubuntu Linux 16.4 und jünger kompatibel sind. Offensichtlich ist bei dieser Distribution das nötige Zertifikat eingebunden. Dann wäre ja soweit alles in Ordnung. Nur mit der Erkenntnis, dass es mit den alten Unity3D Libraries kompatibler war.
Hast Du einen Vorschlag, was ich hier ändern soll?
Viele Grüße,
Klaus
#10
Hallo Klaus,
magst Du nicht das DigiCert Global Root CA in der Application vorhalten und einen eigenen certificateHandler implementieren?
Die Beispiele dafür sind doch schnell angepasst.
Außerdem liegt doch offensichtlich ein schwerwiegender Bug in Unity vor.
Bei der Hälfte aller Linux-Installationen dürfte die App keine ssl Verbindung zum Server herstellen können.
Da solltest Du einen Report einkippen, oder?
Ich kann die selbst erstellte Datei mit den Root-CA auch nicht ohne Weiteres permanent dahin legen.
Der Inhalt von /etc/ssl/certs/ ist dynamisch. Ist ja auch sicherheitsrelevant.
Gruß
Dieter
#11
Hallo Klaus,
ich habe jetzt doch eine befriedigende Lösung gefunden.
Es gibt ein Package names ca-certificates-steamtricks als rpm
Das legt in /usr/lib/ca-certificates/update.d/ die Datei 81etc_ssl_crt_steamtricks.run hin.
Der mehr als höfliche Kommentar darin:
# compatability fix for proprietary software
Dieses Script ist so in den Update-Hook eingeklinkt und erzeugt in /etc/ssl/certs/ einen symlink:
ca-certificates.crt -> /var/lib/ca-certificates/ca-bundle.pem.
ca-bundle.pem enthält alle Root-CAs im PEM-Format wie ich das
auch erzeugt hatte.
Gruß
Dieter
#12
Hallo Dieter,
bisher hab ich keinen Bugreport von anderen Entwicklern auf Unity3D gesehen. Das liegt daran, dass es wohl auf dem von Unity3D empfohlenen System funktioniert. Leider ist es bei Unity3D so, dass die sich um Bugreports nicht so sehr kümmern. Da kann es schonmal ein paar Jahre dauern bis irgendwas behoben wird.
Ich halte mich hier aber auch nicht für zuständig. Und ein Fallback auf http wäre auch nicht angebracht... vielleicht war das bisher ja so. Zutrauen würd ich denen alles.
Viele Grüße,
Klaus
#13
Hallo Klaus,
bei Steam scheinen sie ja auch der Ansicht zu sein, dass eine legacy Lösung, die bei Ubuntu funktioniert,
ausreichend ist um Linuxkompatibilität zu behaupten. Darum gibt es ja diesen und andere Workarrounds.
Man stelle sich mal vor, der Firefox Browser würde nur auf Debian/Ubuntu Installationen mit HTTPS funktioneren.
Irgendwo habe ich gelesen, dass frühere Versionen von Unity einfach jedes Serverzertifikat akzeptiert haben.
Das ist ja was Anderes als auf HTTP zurück zu fallen. Der Datenstrom kann trotzdem nur auf den Endpunkten
mitgelesen werden. Allerdings ist dann nicht sicher, dass der Server der ist, der er zu sein behauptet. Das könnte
dann z.B. durch DNS Spoofing angegriffen werden.
Gruß
Dieter
#14
Hallo Dieter,
also wurde das Zertifikatsproblem (auf anderen Linux Distributionen) durch die Erhöhung der Unity3D Sicherheitsrichtlinien hervorgerufen.
Dass Unity3D mehr nur eine Linux Distribution unterstützen sollte, wünsche ich mir auch. Aber wie schon geschrieben, interessieren die sich nicht dafür. Hauptsache Linux kompatibel.
Viele Grüße,
Klaus
- neXt - CGM RC Flight Simulator - English
- News: neXt - CGM RC Flight Simulator
- FAQ
- Feature Suggestions
- Model Setups
- neXt - CGM RC Flight Simulator - Deutsch
- Neuigkeiten: neXt - CGM RC Flight Simulator
- Fragen und Antworten zum neXt
- Gewünschte Funktionen
- Modell Setups
- Verschiedenes
- Marktplatz: Kaufen und Verkaufen
- Align
- FBL-Systeme
- Blade
- Advertising
Related topics
Register now!
Sign up now!