Namensauflösung auf Clients gestört

pummi · 25. April 2026 um 13:36

Liebe Linuxmuster-Gemeinde,

-Base…: 7.2.21-0
-Linbo…: 4.2.16-0
-WebUI…: 7.2.86
-Sophomorix…: 3.92.1-3
-Client Ubuntu 24.04

seit dem Austausch von Switchen in unserem Netzwerk am 17.4. ca 11.00 Uhr ist der Samba-dns Dienst zwischen unseren Clients und dem Server massiv gestört. Unsere Prüfung ergab, dass alle Serverdienste unverändert in den gewünschten Parametern laufen, wir haben keine auffälligen log-Dateien, weder auf dem Server noch auf den Clients. Es gab auch keine Systemveränderungen (Updates o.ä.) in den letzten drei Monaten.
Die Clients können wie gewohnt am Server mit einem gültigen Account authentifiziert werden, finden dann aber beim Booten die shares nicht und das Internet ist nur über IPs erreichbar. Wenn wir jedoch auf diesem Client die Netzwerkverbindung kurz trennen, läuft danach alles für ca. 30 Sekunden normal, bricht dann aber wieder ab. Auch der Versuch, mit einem alten Image zeigte das gleiche Verhalten.

Auf dem Server läuft übrigens alles normal, die Namensauflösung funktioniert einwandfrei.
Könnte das Problem von einem aktiven DNS oder DHCP - Dienst auf einem Gerät im Netz - vorrangig auf den neu eingebauten - u.U. das unkonventionelle Verhalten unserer Clients erklären?
Ansonsten sind wir nun ziemlich ratlos.

Vielen Dank für Euer Mitdenken

markus

pummi · 28. April 2026 um 07:42

Zu unserem DNS-Desaster hier noch weitere Erkenntnisse: wir haben jetzt ein ganz altes Image (ubuntu 22.04) eingespielt, und hier funktionieren die Web-Browser wieder normal. Nur die Shares bleiben verschwunden. Am Verhalten der 24er Images hat sich nichts geändert.

Weiterhin frustriert

markus

tjordan · 29. April 2026 um 04:54

Hallo Markus,

schau mal nach, wie die Clients DNS auflösen. Achte hier insbesondere auch mal auf DNSv6. Möglich das du einen aktiven DHCPv6-Server bei dir im Netz hast. Evtl. auch auf einem Client einen tcpdump machen und mit Wireshark analysieren.

Gruß

Thomas

baumhof · 29. April 2026 um 08:26

Hallo Markus,

.. ich hatte deine Nachfrage auch gesehen, aber leider keine Idee gehabt, außer dem, was du sowiso ins Augegefaßt hast (fremde DNS/DHCP im Netz).

Ist euer Netz den segmentiert? Oder ist es flach?

Wenn Clients, vor allem „vorübergehend“ (was bei dir ja der Fall ist wegen der 30 Sekunden, wo es geht, und dann nicht mehr) seltsame Probleme zeigen, dann kann das durchaus an Schutzvorrichtungen der Switches liegen. Ich hatte es schon, dass das STP Protokoll an den Swithces (Spanning Tree) falsch eingestellt war und die Switches regelmäßig dachten, da läge ein Problem an einem Port vor: den haben sie dann geblockt. Je nach dem welcher Port das war, waren einzelne Cleints betroffen oder ganze Netzsegmente.

Dass es mit dem alten Image nicht auftritt ist eher ein Hinweis, dass es nicht an STP liegt.

In jedem Fall würde ich mal auf den Switches nachschauen, ob es solche Blockevents den gab.

.. sorry: nur Gedanken, keine Lösungen

LG
Holger

Buster · 30. April 2026 um 15:08

Hi,

ja, das mit den 30 Sekunden liefert einen Anfangsverdacht sich mal die Spanning-Tree-Konfiguration der Switche anzusehen. Alle Ports für Endgeräte (aus Sicht des Switches sind das alle Clients und Server) sollten im (R)STP als Edge-Ports konfiguriert sein. Zu den Switchen können aber auch physischen Ports der virtuellen Switche für Produktivnetze deiner Virtualisierungshosts gehören, wenn die virtuellen Switche (R)STP unterstützen. Die Ports der Management-Interfaces der Server sind wiederum normale Edge-Ports.

Viele Grüße
Buster

tjordan · 4. Mai 2026 um 05:34

Hi,

also STP…weiß ich nicht…glaub ich nicht so wirklich dran. Grundsätzlich kann das schon Thema sein, aber nachdem wie die Symptome beschrieben worden sind tippe ich eher darauf, dass jetzt irgendwo ein Gerät im paednetz hängt, welches vorher in einem anderen VLAN war.

Was mich an der STP Theorie stört: Image Rollout z.B. scheint ja zu funktionieren. Wären das eine STP-Geschichte, wären die Auswirkungen im Netz viel massiver. Die Symptome wären auch anderes…es gäbe ständig irgendwelche reconnects.

Grundsätzlich kann man auch auf den Switches schauen, ob es auf den Ports im Log irgendwelche „Blocked by STP“ Messages gibt. Ansonsten könnte man zunächst mit statischer IPv4 und DNSv4 (IPv6 abschalten) schauen, ob es zu keinerlei Einschränkungen im Betrieb kommt.

So könnte man das Problem zumindest mal eingrenzen.

Viele Grüße

Thomas

pummi · 9. Juni 2026 um 17:14

Liebe Linuxmuster-Nette,

unser DNS-Problem hat sich nur teilweise gelöst. Noch immer fehlen bei der Anmeldung alle Shares, Internet geht nur mit IPs, kein dns. Wenn man die Netzverbindung trennt und sie dann wieder aktiviert, funktioniert das Internet einwandfrei.

Als Workaround habe wir im Moment: Anmelden mit einem lokalen User, Netzverbindung trennen und wieder aktivieren, abmelden, Anmeldung mit dem eigene Account, Shares sind da, Netz funktioniert.

Inzwischen haben wir entdeckt, dass in der /etc/resolve.conf Merkwürdiges geschieht: Bei der ersten Anmeldung sieht die Datei so aus:


/etc/resolv.conf                            911/920                99%

# Do not edit.
#
# This file might be symlinked as /etc/resolv.conf. If you're looking at
# /etc/resolv.conf and seeing this text, you have followed the symlink.
#
# This is a dynamic resolv.conf file for connecting local clients to the
# internal DNS stub resolver of systemd-resolved. This file lists all
# configured search domains.
#
# Run "resolvectl status" to see details about the uplink DNS servers
# currently in use.
#
# Third party programs should typically not access this file directly, but only
# through the symlink at /etc/resolv.conf. To manage man:resolv.conf(5) in a
# different way, replace this symlink by a static file or a different symlink.
#
# See man:systemd-resolved.service(8) for details about the supported modes of
# operation for /etc/resolv.conf.

nameserver 127.0.0.53
options edns0 trust-ad
search .

In der letzten Zeile bei search steht nur ein Punkt, der Domänenname fehlt. Nach der Netztrennung und Wiederaktivierung sieht die /etc/resolve.conf dann so aus:

# Do not edit.
#
# This file might be symlinked as /etc/resolv.conf. If you're looking at
# /etc/resolv.conf and seeing this text, you have followed the symlink.
#
# This is a dynamic resolv.conf file for connecting local clients to the
# internal DNS stub resolver of systemd-resolved. This file lists all
# configured search domains.
#
# Run "resolvectl status" to see details about the uplink DNS servers
# currently in use.
#
# Third party programs should typically not access this file directly, but only
# through the symlink at /etc/resolv.conf. To manage man:resolv.conf(5) in a
# different way, replace this symlink by a static file or a different symlink.
#
# See man:systemd-resolved.service(8) for details about the supported modes of
# operation for /etc/resolv.conf.

nameserver 127.0.0.53
options edns0 trust-ad
search linuxmuster.lan

Domäne ist nun da, alles funktioniert bis zum nächsten Sync. Dann alles wieder von vorne. Hat jemand verhalten schon mal erlebt und weiß woran es liegt?

Ergänzende noch die Datei etc/unbound/unbound.conf/resolvconf_resolvers.conf

etc/unbound/unbound.co~olvconf_resolvers.conf        140/140               100%
# Generated by resolvconf

forward-zone:
        name: "linuxmuster.lan"
        forward-addr: 10.0.0.1

forward-zone:
        name: "."
        forward-addr: 10.0.0.

Auch hier gibt es neben dem korrekten Eintrag mit Domain einen nur mit Punkt, also ohne Domainname. Diese Datei bleibt auch nach Netztrennung unverändert.
Ich betone nochmal, dass wir weder auf dem Server noch auf den Clients ein Update o.ä. gemacht hatten, erst als unser Schulträger Netzwerkkomponenten ausgetauscht hatte, begann das Problem; aber vielleicht eher eine Korrelation als ein kausaler Zusammenhang?

Für Ideen, die zur Lösung des Problems führen, wird eine Belohnung von 100 netten Gedanken ausgelobt.

Danke und viele Grüße

markus

foer · 9. Juni 2026 um 18:41

Hallo,

nur einfach mal laut gedacht. Beim Start eines Clients ist der systemd-Service systemd-resolved.service dafür zuständig, dass eine passende resolv.conf erzeugt wird. Habt ihr schon mal den Status direkt nach dem booten angesehen mit systemctl status systemd-resolved.service? Vielleicht steht da ja irgendwas erhellendes. Bei meinen 24.04er Clients sieht das nach dem Booten so aus:

● systemd-resolved.service - Network Name Resolution
     Loaded: loaded (/usr/lib/systemd/system/systemd-resolved.service; enabled; preset: enabled)
     Active: active (running) since Tue 2026-06-09 20:12:40 CEST; 5min ago
       Docs: man:systemd-resolved.service(8)
             man:org.freedesktop.resolve1(5)
             https://www.freedesktop.org/wiki/Software/systemd/writing-network-configuration-managers
             https://www.freedesktop.org/wiki/Software/systemd/writing-resolver-clients
   Main PID: 580 (systemd-resolve)
     Status: "Processing requests..."
      Tasks: 1 (limit: 8961)
     Memory: 6.5M (peak: 7.0M)
        CPU: 134ms
     CGroup: /system.slice/systemd-resolved.service
             └─580 /usr/lib/systemd/systemd-resolved

Jun 09 20:12:40 hp-client-test systemd[1]: Starting systemd-resolved.service - Network Name Resolution...
Jun 09 20:12:40 hp-client-test systemd-resolved[580]: Positive Trust Anchors:
Jun 09 20:12:40 hp-client-test systemd-resolved[580]: . IN DS 20326 8 2 e06d44b80b8f1d39a95c0b0d7c65d08458e880409bbc683457104237c7f8ec8d
Jun 09 20:12:40 hp-client-test systemd-resolved[580]: Negative trust anchors: home.arpa 10.in-addr.arpa 16.172.in-addr.arpa 17.172.in-addr.arpa 1>
Jun 09 20:12:40 hp-client-test systemd-resolved[580]: Using system hostname 'hp-client-test'.
Jun 09 20:12:40 hp-client-test systemd[1]: Started systemd-resolved.service - Network Name Resolution.
Jun 09 20:12:45 hp-client-test systemd-resolved[580]: enp1s0: Bus client set search domain list to: linuxmuster.windeck-gymnasium.de
Jun 09 20:12:45 hp-client-test systemd-resolved[580]: enp1s0: Bus client set default route setting: yes
Jun 09 20:12:45 hp-client-test systemd-resolved[580]: enp1s0: Bus client set DNS server list to: 10.16.1.1
Jun 09 20:12:46 hp-client-test systemd-resolved[580]: Using degraded feature set UDP instead of UDP+EDNS0 for DNS server 10.16.1.1.

Wie sieht das bei euch aus? Vielleicht gibt es bei euch irgendeine race-condition und der Service wird zu früh gestartet?
Wie ist es denn, wenn ihr euch nach dem Booten euch anmeldet und ein systemctl restart systemd-resolved.service absetzt? Passt dann die resolv.conf. Das würde dann darauf hin deuten, dass der Service zu früh gestartet wird.
Das könntet ihr dann genauer analysieren oder einfach etwas murksen und den Service beim laden der Session neu starten lassen…dazu könntet ihr die linuxmuster-linuxclient7-Skripte benutzen.
Ein noch blöderer Murks wäre es ggf. mit Hilfe der o.g. Skripte einfach die funktionierende resolv.conf zum passenden Zeitpunkt hin zu kopieren.

Noch eine Idee wäre es, mit Hilfe der Skripte einfach vor der Anmeldung den Networkmanager neu zu starten, was euer Anmeldeverfahren mit lokalem user, wieder abmelden, usw. in Software abbilden würde. Der Befehl dazu ist systemctl restart NetworManager.service.

Natürlich wäre es am besten, ihr würdet das Problem verstehen, ich denke aber der Leidensdruck bei euch ist so hoch, dass ihr ggf. mit einem Hack leben könntet.

Vielleicht ist ja was für euch dabei?

VG
Dominik

P.S.: Mir fällt gerade noch was ein…was sagt den ein systemctl status sssd.service nach dem Booten eines Clients, was ein systemctl status nmbd.service?

Buster · 10. Juni 2026 um 07:07

Hi,

die Unbound-Konfigurationsdatei sieht auch merkwürdig aus. In der Zeile forward-addr: 10.0.0. fehlt ein Oktett für eine vollständige gültige IP-Adresse.

VG
Buster

foer · 10. Juni 2026 um 07:52

Hi,
mir fällt gerade auf, dass ich diese unbound Konfiguration gar nicht habe! Wieso läuft auf euern Clients überhaupt ein Unbound?

VG

Dominik

pummi · 11. Juni 2026 um 16:54

Lieber Dominik, lieber Buster,

danke für Eure Hinweise. Zur Unbound-Datei kann ich nur sagen, dass wir unbound nicht installiert und am laufen haben.In der Datei /etc/resolvconf.conf steht diese Datei als Mirror für Debian:

/etc/resolvconf.conf                                                                                500/500               100%
# Configuration for resolvconf(8)
# See resolvconf.conf(5) for details

resolv_conf=/etc/resolv.conf
# If you run a local name server, you should uncomment the below line and
# configure your subscribers configuration files below.
#name_servers=127.0.0.1


# Mirror the Debian package defaults for the below resolvers
# so that resolvconf integrates seemlessly.
dnsmasq_resolv=/var/run/dnsmasq/resolv.conf
pdnsd_conf=/etc/pdnsd.conf
unbound_conf=/etc/unbound/unbound.conf.d/resolvconf_resolvers.conf

Wann und warum diese Datei angelegt wurde, ist uns rätselhaft.

Ein systemctl status systemd-resolved.service ergibt bei frisch gesynctem Client das folgende:

● systemd-resolved.service - Network Name Resolution
     Loaded: loaded (/usr/lib/systemd/system/systemd-resolved.service; enabled; preset: enabled)
     Active: active (running) since Wed 2026-06-10 13:09:21 CEST; 11min ago
       Docs: man:systemd-resolved.service(8)
             man:org.freedesktop.resolve1(5)
             https://www.freedesktop.org/wiki/Software/systemd/writing-network-configuration-managers
             https://www.freedesktop.org/wiki/Software/systemd/writing-resolver-clients
   Main PID: 496 (systemd-resolve)
     Status: "Processing requests..."
      Tasks: 1 (limit: 9431)
     Memory: 7.5M (peak: 8.0M)
        CPU: 280ms
     CGroup: /system.slice/systemd-resolved.service
             └─496 /usr/lib/systemd/systemd-resolved

Jun 10 13:09:21 bg2220 systemd[1]: Starting systemd-resolved.service - Network Name Resolution...
Jun 10 13:09:21 bg2220 systemd-resolved[496]: Positive Trust Anchors:
Jun 10 13:09:21 bg2220 systemd-resolved[496]: . IN DS 20326 8 2 e06d44b80b8f1d39a95c0b0d7c65d08458e880409bbc683457104237c7f8ec8d
Jun 10 13:09:21 bg2220 systemd-resolved[496]: Negative trust anchors: home.arpa 10.in-addr.arpa 16.172.in-addr.arpa 17.172.in-addr.arpa 18.172.in-addr.arpa 19.172.in-addr.arpa 20.172.in-addr.arpa 21.172.in-addr.arpa 22.172.in-addr.arpa 23.172.in-addr.arpa 24.172.in-addr.arpa 25.172.in-addr.arpa 26.172.in-addr.arpa 27.172.in-addr.arpa 28.172.in-addr.arpa 29.172.in-addr.arpa 30.172.in-addr.arpa 31.172.in-addr.arpa 170.0.0.192.in-addr.arpa 171.0.0.192.in-addr.arpa 168.192.in-addr.arpa d.f.ip6.arpa ipv4only.arpa corp home internal intranet lan local private test
Jun 10 13:09:21 bg2220 systemd-resolved[496]: Using system hostname 'bg2220'.
Jun 10 13:09:21 bg2220 systemd[1]: Started systemd-resolved.service - Network Name Resolution.
Jun 10 13:10:52 bg2220 systemd-resolved[496]: ens18: Bus client set search domain list to: linuxmuster.lan
Jun 10 13:10:52 bg2220 systemd-resolved[496]: ens18: Bus client set default route setting: yes
Jun 10 13:10:52 bg2220 systemd-resolved[496]: ens18: Bus client set DNS server list to: 10.0.0.1
Jun 10 13:10:52 bg2220 systemd-resolved[496]: Using degraded feature set UDP instead of UDP+EDNS0 for DNS server 10.0.0.1.

Domain und Server-IP sind da, werden ber nicht oin die /etc/resolv.conf geschrieben

Nach der Netztrennung und Reaktivierunmg ändert sich das Ergebnis allerdings:

● systemd-resolved.service - Network Name Resolution
     Loaded: loaded (/usr/lib/systemd/system/systemd-resolved.service; enabled; preset: enabled)
     Active: active (running) since Wed 2026-06-10 13:09:21 CEST; 12min ago
       Docs: man:systemd-resolved.service(8)
             man:org.freedesktop.resolve1(5)
             https://www.freedesktop.org/wiki/Software/systemd/writing-network-configuration-managers
             https://www.freedesktop.org/wiki/Software/systemd/writing-resolver-clients
   Main PID: 496 (systemd-resolve)
     Status: "Processing requests..."
      Tasks: 1 (limit: 9431)
     Memory: 7.5M (peak: 8.0M)
        CPU: 301ms
     CGroup: /system.slice/systemd-resolved.service
             └─496 /usr/lib/systemd/systemd-resolved

Jun 10 13:09:21 bg2220 systemd-resolved[496]: Using system hostname 'bg2220'.
Jun 10 13:09:21 bg2220 systemd[1]: Started systemd-resolved.service - Network Name Resolution.
Jun 10 13:10:52 bg2220 systemd-resolved[496]: ens18: Bus client set search domain list to: linuxmuster.lan
Jun 10 13:10:52 bg2220 systemd-resolved[496]: ens18: Bus client set default route setting: yes
Jun 10 13:10:52 bg2220 systemd-resolved[496]: ens18: Bus client set DNS server list to: 10.0.0.1
Jun 10 13:10:52 bg2220 systemd-resolved[496]: Using degraded feature set UDP instead of UDP+EDNS0 for DNS server 10.0.0.1.
Jun 10 13:21:31 bg2220 systemd-resolved[496]: ens18: Bus client set default route setting: no
Jun 10 13:21:36 bg2220 systemd-resolved[496]: ens18: Bus client set DNS server list to: 10.0.0.1
Jun 10 13:21:36 bg2220 systemd-resolved[496]: ens18: Bus client set search domain list to: linuxmuster.lan, linuxmuster.lan
Jun 10 13:21:38 bg2220 systemd-resolved[496]: Using degraded feature set UDP instead of UDP+EDNS0 for DNS server 10.0.0.1.

Domain und Server IP sind da und stehen jetzt auch in der /etc/resolv.conf. Etwas irritiert bin ich von der Tatsache, das es einmal

ens18: Bus client set default route setting: yes

und kurz danach

ens18: Bus client set default route setting: no

heißt. Aber Domian und Server-Ip sind korrekt .

Verstehen kann ich auch die Angaben in der von systemctl status nmbd.service nicht vollständig:

● nmbd.service - Samba NMB Daemon
     Loaded: loaded (/usr/lib/systemd/system/nmbd.service; enabled; preset: enabled)
     Active: active (running) since Wed 2026-06-10 13:10:52 CEST; 10min ago
       Docs: man:nmbd(8)
             man:samba(7)
             man:smb.conf(5)
   Main PID: 1223 (nmbd)
     Status: "nmbd: ready to serve connections..."
      Tasks: 1 (limit: 9431)
     Memory: 10.9M (peak: 11.4M)
        CPU: 91ms
     CGroup: /system.slice/nmbd.service
             └─1223 /usr/sbin/nmbd --foreground --no-process-group

Jun 10 13:10:52 bg2220 systemd[1]: Started nmbd.service - Samba NMB Daemon.
Jun 10 13:10:52 bg2220 nmbd[1223]: [2026/06/10 13:10:52.299315,  0] source3/nmbd/nmbd_namequery.c:109(query_name_response)
Jun 10 13:10:52 bg2220 nmbd[1223]:   query_name_response: Multiple (2) responses received for a query on subnet 10.0.222.222 for name WORKGROUP<1d>.
Jun 10 13:10:52 bg2220 nmbd[1223]:   This response was from IP 10.0.233.4, reporting an IP address of 10.0.233.4.
Jun 10 13:16:09 bg2220 nmbd[1223]: [2026/06/10 13:16:09.281561,  0] source3/nmbd/nmbd_namequery.c:109(query_name_response)
Jun 10 13:16:09 bg2220 nmbd[1223]:   query_name_response: Multiple (2) responses received for a query on subnet 10.0.222.222 for name WORKGROUP<1d>.
Jun 10 13:16:09 bg2220 nmbd[1223]:   This response was from IP 10.0.233.4, reporting an IP address of 10.0.233.4.
Jun 10 13:21:12 bg2220 nmbd[1223]: [2026/06/10 13:21:12.570274,  0] source3/nmbd/nmbd_namequery.c:109(query_name_response)
Jun 10 13:21:12 bg2220 nmbd[1223]:   query_name_response: Multiple (2) responses received for a query on subnet 10.0.222.222 for name WORKGROUP<1d>.
Jun 10 13:21:12 bg2220 nmbd[1223]:   This response was from IP 10.0.233.4, reporting an IP address of 10.0.233.4.

Eine response von dem Rechner mit der IP 10.0.233.4 finde ich überraschend. Diese Meldung erscheint auch, wenn der entsprechende Rechner ausgeschaltet ist. Der Rechner steht in dem Gebäudeteil, in dem vor sechs Wochen einige neue Switche eingebaut wurden.

Ein Problem gibt es auch bei systemctl status sssd.service:

● sssd.service - System Security Services Daemon
     Loaded: loaded (/usr/lib/systemd/system/sssd.service; enabled; preset: enabled)
    Drop-In: /etc/systemd/system/sssd.service.d
             └─override.conf
     Active: active (running) since Wed 2026-06-10 14:20:26 CEST; 12min ago
   Main PID: 1414 (sssd)
      Tasks: 5 (limit: 9431)
     Memory: 98.7M (peak: 102.6M)
        CPU: 1.933s
     CGroup: /system.slice/sssd.service
             ├─1414 /usr/sbin/sssd -i --logger=files
             ├─1417 /usr/libexec/sssd/sssd_be --domain linuxmuster.lan --uid 0 --gid 0 --logger=files
             ├─1440 /usr/libexec/sssd/sssd_nss --uid 0 --gid 0 --logger=files
             ├─1442 /usr/libexec/sssd/sssd_pam --uid 0 --gid 0 --logger=files
             └─1443 /usr/libexec/sssd/sssd_pac --uid 0 --gid 0 --logger=files

Jun 10 14:20:25 bg2220 systemd[1]: Starting sssd.service - System Security Services Daemon...
Jun 10 14:20:25 bg2220 sssd[1414]: Starting up
Jun 10 14:20:25 bg2220 sssd_be[1417]: Starting up
Jun 10 14:20:25 bg2220 sssd_be[1417]: PAC check is requested but krb5_validate is set to false. PAC checks will be skipped.
Jun 10 14:20:26 bg2220 sssd_pac[1443]: Starting up
Jun 10 14:20:26 bg2220 sssd_pam[1442]: Starting up
Jun 10 14:20:26 bg2220 sssd_nss[1440]: Starting up
Jun 10 14:20:26 bg2220 systemd[1]: Started sssd.service - System Security Services Daemon.
Jun 10 14:20:52 bg2220 sssd_be[1417]: Warning: user would have been denied GPO-based logon access if the ad_gpo_access_control option were set to enforcing mode.
Jun 10 14:29:40 bg2220 sssd_be[1417]: Warning: user would have been denied GPO-based logon access if the ad_gpo_access_control option were set to enforcing mode.

Die warnings in den letzten Zeilen bleibt nach frischem Sync und nach der Netztrennung identisch.

Alles in allem sind wir zur Zeit hochmotiviert, nach dem mündlichen Abitur auf die 7.3 umzusteigen und einen neuen, aktuelleren Client anzulegen.

Man hätte halt gerne verstanden, was da so vorgeht.

Danke noch mal an alle Mitdenkenden

markus