Protokoll Opennet Montagstreffen (26.08.2024)

Heute war ein sehr produktives Treffen und wir konnten mehrere Probleme lösen bzw. Ursachen ermitteln.

Problem 1: Rene bekommt keine Mailinglisten Emails seit einigen Wochen

Rene hat eine gmail Adresse. Er vermisst Emails von den Opennet Mailinglisten, welche andere problemlos empfangen. Es ist jedoch möglich Rene direkt (ohne ML) eine Email über den ONI Emailserver zu schicken.

Die Untersuchung fing auf kazam (Mailman3) an. Dieser leitet an den lokalen Postfix und weiter an crimson Postfix. Dort fanden wir die entscheidende Fehlermeldung im log.

Aug 25 07:38:32 crimson postfix/smtp[24163]: 315C33896BE: to=<xxx@xxx.xxx>, relay=gmail-smtp-in.l.google.com[66.102.1.26]:25, delay=1.2, delays=0.04/0.04/0.54/0.6, dsn=5.7.26, status=bounced (host gmail-smtp-in.l.google.com[66.102.1.26] said: 550-5.7.26 Your email has been blocked because the sender is unauthenticated. 550-5.7.26 Gmail requires all senders to authenticate with either SPF or DKIM. 550-5.7.26  550-5.7.26  Authentication results: 550-5.7.26  DKIM = did not pass 550-5.7.26  SPF [list.opennet-initiative.de] with ip: [46.4.100.244] = did not 550-5.7.26 pass 550-5.7.26  550-5.7.26  For instructions on setting up authentication, go to 550 5.7.26  https://support.google.com/mail/answer/81126#authentication ffacd0b85a97d-37308269811si2896947f8f.662 - gsmtp (in reply to end of DATA command))

Dieses Problem ist einigen bekannt. Unserer Emailinfrastruktur fehlen einige "Sicherheitsfeatures". Es ist jedoch verwunderlich, dass direkte Emails zustellbar sind, Emails per ML von Google jedoch anders gehandhabt werden.
Die Lösung besteht in der Aktualisierung der Emailinfrastruktur, welches bereits begonnen wurde. Die Bedeutsamkeit dieses Projekt wurde vielen nun nochmals ins Gedächtnis gerufen.

Problem 2: Torstens AP2.227 tauchte nicht im Monitoring auf.

Torsten hat einen virtuellen AP mit 0.5.9 Firmware. Dieser ist nicht im Monitoring zu sehen. Das on-monitoring Paket ist installiert.

Letztendlich gab es hier 2 Teilprobleme (fetch olsr und fetch olsr2). Im Log des munin Servers war bei fetch olsr eine Fehlermeldung zu sehen. Dies führte zum Abbruch des Monitoring-Versuchs.
Bei fetch olsr ist mind. in der 0.5.9 ein Bug, welchen Tobias bereits für die unstable gelöst hat.

Nachdem wir dies fixen konnten, gab es Fehlermeldungen zu fetch olsr2. Dies wurde bereits auf der dev ML diskutiert. Es können keine Daten vom API Server abgerufen werden. Bei der konkreten Fehlersuche sind wir jedoch weiter gekommen. Tests mit Micropython zeigten 3 unterschiedliche Verhalten beim Aufbau eines TLS Sockets:

Test 1

Server direkt im Internet mit LE Zertifikat: ai = _socket.getaddrinfo("www.opennet-initiative.de", 443)

Hiermit hatte Micropython kein Problem:

root@AP-2-209:/tmp# micropython program.py 
Address infos: [(2, 1, 6, 'crimson.opennet-initiative.de', bytearray(b'\x02\x00\x01\xbb
......
Connect address: bytearray(b'\x02\x00\x01\xbb.\x04d\xf4\x00\x00\x00\x00\x00\x00\x00\x00')
<_SSLSocket b7d328a0>
b'HTTP/1.1 301 Moved Permanently\r\nDate: Mon, 26 Aug 2024 18:50:50 GMT\r\nServer: Apache\r\nStrict-Transport-Security: max-age=15768000\r\nX-Content-Type-Options: nosniff\r\nVary: Accept-Encoding,Cookie\r\nExpires: Thu, 01 Jan 1970 00:00:00 GMT\r\nCache-Control: private, must-revalidate, max-age=0\r\nLast-Modified: Mon, 26 Aug 2024 18:50:50 GMT\r\nLocation: https://wiki.opennet-initiative.de/wiki/Hauptseite\r\nContent-Length: 0\r\nContent-Type: text/html; charset=utf-8\r\n\r\n'

Test 2

Zugriff über TLS proxy (slt): ai = _socket.getaddrinfo("api.on-i.de", 444)

Dies endet im einem SSL Fehler:

root@AP-2-209:/tmp# micropython program.py 
Address infos: [(2, 1, 6, 'domain-proxy.opennet-initiative.de', bytearray(b'\x02\x00\x01\xbb
...
Traceback (most recent call last):
  File "program.py", line 38, in <module>
  File "program.py", line 21, in main
OSError: (-29312, 'SSL - The connection indicated an EOF')

Test 3

Zugriff direkt auf Backendserver (ohne TLS Proxy): ai = _socket.getaddrinfo("192.168.10.14", 444)

Die funktioniert problemlos:

root@AP-2-209:/tmp# micropython program.py 
Address infos: [(2, 1, 6, '192.168.10.14', bytearray(b'\x02\x00\x01\xbc\xc0\xa8
...
<_SSLSocket b7dc2890>
b'HTTP/1.1 403 Forbidden\r\nDate: Mon, 26 Aug 2024 18:53:33 GMT\r\nServer: Apache\r\nContent-Length: 337\r\nConnection: close\r\nContent-Type: text/html; charset=iso-8859-1\r\n\r\n<!DOCTYPE HTML PUBLIC "-//IETF//DTD HTML 2.0//EN">\n<html><head>\n<title>403 Forbidden</title>\n</head><body>\n<h1>Forbidden</h1>\n<p>You don\'t have permission to access this resource.Reason: The client software did not provide a hostname using Server Name Indication (SNI), which is required to access this server.<br />\n</p>\n</body></html>\n'

Der veraltete slt Proxy scheint hier ein Problem zu sein. Mögliche Lösungsansätze sind:
a) haproxy statt slt nutzen
b) auf TLS verzichten und unverschlüsseltes HTTP nutzen (beim Zugriff auf nicht-sensitive öffentliche Daten)
c) diese Anfrage an den API Server herausdesignen

Problem 3: Wiki mit ungültigen Node Daten

Dieses Problem konnten wir noch nicht untersuchen. Im Wiki (https://wiki.opennet-initiative.de/wiki/Opennet_Nodes) wird der Knoten AP2.227 als offline seit 2022 angezeigt. Dies ist aber falsch.

Problem 4: Auf der Karte fehlen Kanten für AP1.198

In unserer Karte (https://wiki.opennet-initiative.de/wiki/Karte/City) fehlen die Kanten für AP1.198 (Kringelgraben). Dies konnten wir noch nicht untersuchen.