Buster: Automatisch IP via DHCP fehlerhaft?

[McBane87]

Hallo Zusammen,

Ich haben eben ein Update von Stretch auf Buster gemacht und habe nun das Problem, dass es sich scheinbar keine IP mehr via DHCP zieht.
Das einzige was instant hilft, ist, wenn ich folgendes eingebe. Danach habe ich sofort eine IP, ohne auch nur eine Sekunde warten zu müssen:

Code: Alles auswählen

dhclient ens32

Hier ein paar Infos bevor ich den obigen Befehl eingebe:

Code: Alles auswählen

cat /etc/network/interfaces

# This file describes the network interfaces available on your system
# and how to activate them. For more information, see interfaces(5).

source /etc/network/interfaces.d/*

# The loopback network interface
auto lo
iface lo inet loopback

# The primary network interface
allow-hotplug ens32
iface ens32 inet dhcp

Code: Alles auswählen

ifconfig 

ens32: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet6 fe80::211:22ff:fe33:4455  prefixlen 64  scopeid 0x20<link>
        ether 00:11:22:33:44:55  txqueuelen 1000  (Ethernet)
        RX packets 53  bytes 3180 (3.1 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 11  bytes 1682 (1.6 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 1000  (Local Loopback)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

Code: Alles auswählen

# /var/log/syslog

Jul  9 09:01:24 SomeHost dhclient[482]: DHCPDISCOVER on ens32 to 255.255.255.255 port 67 interval 20
Jul  9 09:01:24 SomeHost sh[459]: DHCPDISCOVER on ens32 to 255.255.255.255 port 67 interval 20
Jul  9 09:01:44 SomeHost dhclient[482]: DHCPDISCOVER on ens32 to 255.255.255.255 port 67 interval 11
Jul  9 09:01:44 SomeHost sh[459]: DHCPDISCOVER on ens32 to 255.255.255.255 port 67 interval 11
Jul  9 09:01:55 SomeHost dhclient[482]: DHCPDISCOVER on ens32 to 255.255.255.255 port 67 interval 11
Jul  9 09:01:55 SomeHost sh[459]: DHCPDISCOVER on ens32 to 255.255.255.255 port 67 interval 11
Jul  9 09:02:06 SomeHost dhclient[482]: No DHCPOFFERS received.
Jul  9 09:02:06 SomeHost sh[459]: No DHCPOFFERS received.
Jul  9 09:02:06 SomeHost sh[459]: No working leases in persistent database - sleeping.
Jul  9 09:02:06 SomeHost dhclient[482]: No working leases in persistent database - sleeping.
Jul  9 09:02:06 SomeHost sh[459]: ens32=ens32

Hier ist merkwürdig, dass das System plötzlich der Meinung ist, ich hätte eine IP gehabt eim DHCPRELEASE:

Code: Alles auswählen

ifdown ens32 && ifup ens32

Killed old client process
Internet Systems Consortium DHCP Client 4.4.1
Copyright 2004-2018 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/

Listening on LPF/ens32/00:11:22:33:44:55
Sending on   LPF/ens32/00:11:22:33:44:55
Sending on   Socket/fallback
DHCPRELEASE of 192.168.1.60 on ens32 to 192.168.1.1 port 67
send_packet: Network is unreachable
send_packet: please consult README file regarding broadcast address.
dhclient.c:2878: Failed to send 300 byte long packet over fallback interface.
Internet Systems Consortium DHCP Client 4.4.1
Copyright 2004-2018 Internet Systems Consortium.
All rights reserved.
For info, please visit https://www.isc.org/software/dhcp/

Listening on LPF/ens32/00:11:22:33:44:55
Sending on   LPF/ens32/00:11:22:33:44:55
Sending on   Socket/fallback
DHCPDISCOVER on ens32 to 255.255.255.255 port 67 interval 6
DHCPDISCOVER on ens32 to 255.255.255.255 port 67 interval 10
DHCPDISCOVER on ens32 to 255.255.255.255 port 67 interval 15
DHCPDISCOVER on ens32 to 255.255.255.255 port 67 interval 17
DHCPDISCOVER on ens32 to 255.255.255.255 port 67 interval 12
No DHCPOFFERS received.
No working leases in persistent database - sleeping.

Ist das ein Bug? Oder hat jemand eine Idee woran das liegen könnte?
Ich könnte natürlich einfach versuchen in der "/etc/network/interfaces" ein "post-up dhclient ens32" hinzufügen. Das hilft vielleicht, aber das wäre ja nur ein Workaround.

EDIT:

Nur mal noch so als Info nebenbei.
Ich habe jetzt ein komplett frisches Debian Buster mithilfe der Netinst-ISO installiert.
Das installieren hat wunderbar funktioniert. Es gab eine Adresse via DHCP und alles lief.
Sobald die Installation fertig war und das System durchgebootet hatte, habe ich nun aber das gleiche Problem wie oben beschrieben. Irghendwas ist an Buster kaputt....

Ich möchte der Vollständigkeithalber noch erwähnen dass wir uns in deiner VSphere VM-Umgebung befinden. Das erschien mir Anfangs noch nicht wichtig. Aber vielleicht ist die Info ja doch relevant.

Weitere Erkenntnisse:

Wenn ich mir die Binary /sbin/ifup vom alten Debian Stretch zum neuen Debian Buster kopiere bzw. die vorhandene ersetze und dann noch ein "auto ens32" ins /etc/network/interfaces schreibe. Dann klappt auch wieder alles problemlos mit DHCP. (Ohne das "auto ens32" würde die alte ifup Version das interface nicht starten im Gegensatz zur neueren Version.)

Ich konnte die Kollegen vom DHCP befragen. In den Logs ist zu sehen, dass das ifup von Buster eine andere CID zum DHCP übermittelt. Erwarten würde der DHCP soetwas:
"01:00:11:22:33:44:55:" als CID. Bekommen tut er aber das hier mit der neueren Version von ifup: "ff:22:33:44:55:00:01:00:01:24:b7:2f:8e:00:11:22:33:44:55:". Und aus diesem Grund bekommt der Client dann auch keine IP. Er wird nicht als authorisiertes System erkannt! => "could not offer an address: no permitted ranges available"

(Da ich die MAC Adressen abgeändert habe und die Logik hinter der langen CID nicht ganz verstehe, kann es sein, dass sie für Wissende jetzt keinen Sinn mehr ergibt nachdem ich sie abgeändert habe, aber das Prinzip sollte trotzdem klar sein. Es wird eine viel längere CID übermittelt)

Fragt sich natürlich, wie kann ich Buster abgewöhnen die CID so zu "verschlimmbessern" ?

Das Ursache des Problems habe ich mittlerweile gefunden. Das ifupdown Paket setzt seit Version 0.8.35 auf DUID beim dhclient. Es ruft den dhclient also mit der Option "-i" auf. Damit kann unser Netzwerk bzw. DHCP Umgebung aber nicht umgehen. Und wenn ich die Source richtig deute, dann ist die Option "-i" auch noch hardcoded, sodass man keine Wahl mehr hat. Außer man deinstalliert den dhclient und nutz einen anderen Client wie zum Beispiel pump.

Mein aktueller Workaround bleibt einfach das Paket in dem dhclient vorkommt zu deinstallieren und dafür einen anderen DHCP-Client zu installieren. Denn ifupdown prüft nach einer festen Reihenfolge verschiedenen DHCP-Clients auf existenz und nutzt den erstbesten. Wenn dhclient also nciht da ist, dann wird ein anderer, der vorhande ist, genommen. Somit sollte ich auch bei zukünftigen Updates der Pakete relativ sicher fahren.

[jessie]

Code: Alles auswählen

Jul  9 09:01:55 SomeHost sh[459]: DHCPDISCOVER on ens32 to 255.255.255.255 port 67 interval 11
Jul  9 09:02:06 SomeHost dhclient[482]: No DHCPOFFERS received.
Jul  9 09:02:06 SomeHost sh[459]: No DHCPOFFERS received.
Jul  9 09:02:06 SomeHost sh[459]: No working leases in persistent database - sleeping.
Jul  9 09:02:06 SomeHost dhclient[482]: No working leases in persistent database - sleeping.

Irgendein Problem mit dem DHCP-Server (respektive Router, Fritzbox).
Ich würde mal den Protokollablauf
https://en.wikipedia.org/wiki/Dynamic_H ... n_Protocol
mit wireshark untersuchen. Eventuell Probleme mit Netzwerkkonfiguration/Verzögerungen - irgendwann klappt es ja. Dein

Code: Alles auswählen

dhclient ens32

führt ja zum Restart des DHCP-Clients, des lokalen Dienstes. Vielleicht wäre auch nur ein Neustart des systemD-Dienstes ohne genau dieses Kommando erfolgreich. Kannst auch mal deinen DHCP-Server/Router neu starten, vielleicht hilft das schon.

Code: Alles auswählen

DHCPRELEASE of 192.168.1.60 on ens32 to 192.168.1.1 port 67
send_packet: Network is unreachable

Port 67 deines DHCP-Servers hat wohl ein Problem mit der Erreichbarkeit.

[McBane87]

Hi Jessie, danke für deine Antwort.

Irgendein Problem mit dem DHCP-Server

Das würde ich mal entschieden ausschließen. Ich bin in einem großen Firmennetzwerk unterwegs, habe nur die IPs abgeändert im obigen Beispiel
Wenn der DHCP generell Probleme hätte dann wäre das bekannt. Denn dann hätten wir ein riesen Problem.
Der DHCP-Server kann hier also eigentlich nciht das Problem sein. Es muss an etwas leiegn, was Debian Buster anders macht als vorher. Wenn ich mir ein ähnliches System mit Debian Stretch im gleichen Netz schnappe und es 10 mal boote, dann bekomme ich 10 mal problemlos eine IP. Nur das Buster System stellt sich irgendwie quer.

[jessie]

Der DHCP-Server kann hier also eigentlich nciht das Problem sein.

Lösche mal alte, unbenutzte Leases raus oder starte neu. Ansonsten halt wireshark zum Festestellen der Unterschiede im Protokollablauf Stretch versus Buster. Der "unproblematische" DHCP-Server in einem "großen" Netzwerk dürfte wohl ein Windows-Server sein - und der hat doch sicher auch DHCP- und Ereignis-Logs.

Gerade wieder eingefallen: Per Avahi/Zeroconf (avahid in Debian-Standardinstallation/systemD enthalten) wurden früher IPv4-Adressen (APIPA) bei Nichterreichbarkeit des DHCP-Servers automatisch vom Client konfiguriert. Nun IPv6-Adressen. Inwiefern dir diese Info bei deinem Problem helfen könnte, weiß ich aber nicht.
https://en.wikipedia.org/wiki/Zero-conf ... networking
https://wiki.wireshark.org/APIPA

[McBane87]

Lösche mal die alten Leases raus oder starte neu

Das ändert leider nichts. Habe ich ja auch schon mehrfach getan. Zum Beispiel mit obigen Beispiel "ifdown ens32 && ifup ens32"

Der unproblematische DHCP-Server [...] hat doch sicher auch DHCP- und Ereignis-Logs

Da komme ich nicht dran. Muss ich bei Gelegenheit mal jemanden fragen.

Ansonsten halt Wireshark zum Festestellen der Unterschiede im Protokollablauf Stretch versus Buster

Solche spielerein wollte ich auf den Systemen eigentlich vermeiden, aber mal schauen was sich da machen lässt.

[jessie]

Solche spielerein wollte ich auf den Systemen eigentlich vermeiden, aber mal schauen was sich da machen lässt.

Das kannst du auf einem extra dafür benutzten Rechner machen. Rechner mit NW-IF promiskutitiv in gleicher Broadcast-Domain, auf dem Sorgenkind mit Buster wäre am einfachsten oder ein NW-Analyzer-Rechner (NW-Probe) an Mirror-/SPAN-Port am Switch. Manche Dinge benötigt man immer wieder mal.

Meine Frage wurde nicht beantwortet: Welchen konkreten DHCP-Server benutzt ihr nun?

Das ändert leider nichts. Habe ich ja auch schon mehrfach getan. Zum Beispiel mit obigen Beispiel "ifdown ens32 && ifup ens32"

Den DHCP-Server meinte ich.

Und dann noch was: Wenn dir Berechtigungen für den Zugriff auf den zentrale Netzwerkkomponenten wie DHCP-Server fehlen - es könnte durchaus sein, dass Oberguru-Admins noch einige (DHCP-/Cisco-) Tricks angewendet haben, um den Neuanschluss unbekannter/unerwünschter Hosts zu unterbinden. Könnte man per fixer IP-MAC-Konfiguration (Spoofing am richtigen Switch-Port bzw. VLAN) vielleicht aushebeln - und den Arbeitsplatz aufs Spiel setzen. Ich finde jedenfalls bedenkenswert, dass du offenbar nicht selbständig an zentrale Netwerkkomponenten wie euren DHCP-Server ran darfst.

Da komme ich nicht dran. Muss ich bei Gelegenheit mal jemanden fragen.

Tue das besser - vor leicht missverständlicher Eigeninitiative und Arbeitsplatzverlust.

Versuche es doch mal zuhause - an deinem eigenen DHCP-Server/Router - und schon weißt du, ob es am (Debian/Buster) DHCP-Client oder am DHCP-Server (einschließlich trickreichem Netzwerk) der Firma liegt.

Edit: Letzten Absatz hinzugefügt.

[McBane87]

Welchen konkreten DHCP-Server benutzt ihr nun?

Keine Ahnung. Ist aber auch irrelevant. Zu viele Informationen muss ich dem gesamten Internet auch nicht geben

Wenn dir Berechtigungen für den Zugriff auf den zentrale Netzwerkkomponenten wie DHCP-Server fehlen [...] Ich finde jedenfalls bedenkenswert, dass du offenbar nicht selbständig an zentrale Netwerkkomponenten wie euren DHCP-Server ran darfst.

Da mache dir mal keine Sorgen. Das ist in großen Firmen nun mal so. Da gibt es Teams die sind für Bereich A zuständig und andere eben für Bereich B. Der Server ist offiziell in den Systemen hinterlegt und darf ganz normal im Netz arbeiten. Das tat er ja auch schon vor dem Update auf Buster

[jessie]

Welchen konkreten DHCP-Server benutzt ihr nun?

Keine Ahnung. Ist aber auch irrelevant. Zu viele Informationen muss ich dem gesamten Internet auch nicht geben

Wenn du meinst - ich habe den letzten Beitrag um einen Tipp erweitert und noch mehr zu tun. Jedenfalls würde ich bei offenbar (evtl. nur kurzfristig) nicht erreichbarem DHCP-Server nicht nur Client-Logs untersuchen und DHCP-Client neu oder anders restarten.

Edit: Überschneidung mit Folgebeitrag.

[McBane87]

Wenn du meinst - ich habe den letzten Beitrag um einen Tipp erweitert und noch mehr zu tun.

Bitte verstehe das nicht falsch. Ich weiß deine Hilfe durchaus zu schätzen, aber ich kann und will nicht zu viele Informationen über Interna preisgeben. Sowas ist nun mal Sicherheitsrelevant und hat im Internet nichts zu suchen. Selbst wenn nicht mal bekannt ist um welche Firma es sich handelt....

Danke dir auf jedenfall für deinen Einsatz.

[jessie]

Plastikrouter oder PC mit VM / DHCP-Server (xWRT, pfSense, (*)), Router oder L3-Switch aus Ersatzteillager. Direktanschluss DHCP-Client ohne das geheimnisumwitterte Fimengerät mit evtl. trickreichem Netzwerk davor. Was meint der Buster-DHCP-Client dazu? Die somit leicht erreichbaren Server-Logs sagen was? Dafür braucht man keine Firmen-Berechtigungen, geht sogar im Biergarten mit den (Staubsauger-) Verlängerungskabeln von Lady Dreckfort.

(*) verbreitete Linux-DHCP-Server:
dnsmasq u. isc-dhcp-server

[Tintom]

Sind in /etc/network/interfaces.d/ Dateien enthalten?

[McBane87]

Sind in /etc/network/interfaces.d/ Dateien enthalten?

Nein ist leer

[McBane87]

Nur mal noch so als Info nebenbei.
Ich habe jetzt ein komplett frisches Debian Buster mithilfe der Netinst-ISO installiert.
Das installieren hat wunderbar funktioniert. Es gab eine Adresse via DHCP und alles lief.
Sobald die Installation fertig war und das System durchgebootet hatte, habe ich nun aber das gleiche Problem wie oben beschrieben. Irghendwas ist an Buster kaputt....

Ich möchte der Vollständigkeithalber noch erwähnen dass wir uns in deiner VSphere VM-Umgebung befinden. Das erschien mir Anfangs noch nicht wichtig. Aber vielleicht ist die Info ja doch relevant.

[McBane87]

Weitere Erkenntnisse:

Wenn ich mir die Binary /sbin/ifup vom alten Debian Stretch zum neuen Debian Buster kopiere bzw. die vorhandene ersetze und dann noch ein "auto ens32" ins /etc/network/interfaces schreibe. Dann klappt auch wieder alles problemlos mit DHCP. (Ohne das "auto ens32" würde die alte ifup Version das interface nicht starten im Gegensatz zur neueren Version.)

Ich konnte die Kollegen vom DHCP befragen. In den Logs ist zu sehen, dass das ifup von Buster eine andere CID zum DHCP übermittelt. Erwarten würde der DHCP soetwas:
"01:00:11:22:33:44:55:" als CID. Bekommen tut er aber das hier mit der neueren Version von ifup: "ff:22:33:44:55:00:01:00:01:24:b7:2f:8e:00:11:22:33:44:55:". Und aus diesem Grund bekommt der Client dann auch keine IP. Er wird nicht als authorisiertes System erkannt! => "could not offer an address: no permitted ranges available"

(Da ich die MAC Adressen abgeändert habe und die Logik hinter der langen CID nicht ganz verstehe, kann es sein, dass sie für Wissende jetzt keinen Sinn mehr ergibt nachdem ich sie abgeändert habe, aber das Prinzip sollte trotzdem klar sein. Es wird eine viel längere CID übermittelt)

Fragt sich natürlich, wie kann ich Buster abgewöhnen die CID so zu "verschlimmbessern" ?

[novalix]

Man kann über die Konfiguration dem dhcp-client die Kennung der Netzwerkkarte händisch mitgeben.
Allerdings scheint ja dhclient selber nicht das Problem zu sein, da der manuelle Aufruf ja erfolgreich verläuft.
Derzeit ist das Debugging solcher Probleme ja durchaus auch dadurch erschwert, dass man immer erst mal herausfinden muss, wer im Hintergrund bezüglich Konfiguration und start up eigentlich den Hut auf hat.

Der Tipp von @jessie den network stack mal per systemd neu zu starten, könnte weitere Erkenntnisse bringen.

Code: Alles auswählen

systemctl restart networking

Falls der restart nicht gelingt sollte ein Hinweis auf relevante Logmeldungen erscheinen.

Es ist auch wenig wahrscheinlich, dass /sbin/ifup in buster allgemein kaputt ist. Dann hätten viel mehr Leute Probleme (ich auch).

[McBane87]

Das Ursache des Problems habe ich mittlerweile gefunden. Das ifupdown Paket setzt seit Version 0.8.35 auf DUID beim dhclient. Es ruft den dhclient also mit der Option "-i" auf. Damit kann unser Netzwerk bzw. DHCP Umgebung aber nicht umgehen. Und wenn ich die Source richtig deute, dann ist die Option "-i" auch noch hardcoded, sodass man keine Wahl mehr hat. Außer man deinstalliert den dhclient und nutz einen anderen Client wie zum Beispiel pump.

[Tintom]

Das Ursache des Problems habe ich mittlerweile gefunden. Das ifupdown Paket setzt seit Version 0.8.35 auf DUID beim dhclient. Es ruft den dhclient also mit der Option "-i" auf. Damit kann unser Netzwerk bzw. DHCP Umgebung aber nicht umgehen. Und wenn ich die Source richtig deute, dann ist die Option "-i" auch noch hardcoded, sodass man keine Wahl mehr hat. Außer man deinstalliert den dhclient und nutz einen anderen Client wie zum Beispiel pump.

Es gibt hierzu einen Bugreport: 923640. Vielleicht doch eher ein dhclient xxx in einem Skript verpacken und nach jedem Aktivieren der Schnittstelle das Skript laufen lassen?
Ich sehe hier aber den Ball beim DHCP-Server, es geht hier soweit ich das beurteilen kann um einen Standard für IPv4/IPv6-Netze von 2006 (RFC 4361), der vom Server anscheinend nicht verarbeitet werden kann.

[jessie]

Das Ursache des Problems habe ich mittlerweile gefunden. Das ifupdown Paket setzt seit Version 0.8.35 auf DUID beim dhclient. Es ruft den dhclient also mit der Option "-i" auf. Damit kann unser ... DHCP [Server] ... nicht umgehen.

Workaround testen, DHCP-Client „native“ per systemD:
/etc/systemd/network/20-wired.network

Code: Alles auswählen

[Match]
Name=<IF-Name>

[Network]
DHCP=ipv4 (yes für IPv4 u. IPv6)

Oder/und doch mal den (Windows-) Server updaten (lassen).

Da die DUID mit DHCPv6 somit IPv6 genutzt wird, dürfte bei Nutzung von dhclient auch helfen, IPv6 zu deaktivieren, zumal wesentliche Netzwerkkomponenten mit IPv6 offensichtlich nicht klar kommen.
https://goneuland.de/debian-9-stretch-i ... ktivieren/
(Per Bootloader geht das auch.)

Edit: Link korrigiert.

[McBane87]

Es gibt hierzu einen Bugreport: 923640. Vielleicht doch eher ein dhclient xxx in einem Skript verpacken und nach jedem Aktivieren der Schnittstelle das Skript laufen lassen?
Ich sehe hier aber den Ball beim DHCP-Server, es geht hier soweit ich das beurteilen kann um einen Standard für IPv4/IPv6-Netze von 2006 (RFC 4361), der vom Server anscheinend nicht verarbeitet werden kann.

Dem kann ich nicht wiedersprechen. Aber es ist sehr unwahrscheinlich, dass nur wegen Debian Buster Änderungen am Server vorgenommen werden. Denn dem Gegnüber stehen nun mal tausende Netzwerkgeräte die null Probleme damit haben. Noch dazu kommt, dass ich überhaupt nicht weiß ob der Server ein Update nötig hat. Womöglich bietet die betriebene Lösung das auch in der neuesten Version gar nicht an oder es ist einfach unpraktikabel bei uns und wurde mit Absicht nicht so gemacht. Bin halt für den Bereich nicht zuständig.

Da die DUID mit DHCPv6 somit IPv6 genutzt wird, dürfte bei Nutzung von dhclient auch helfen, IPv6 zu deaktivieren, zumal wesentliche Netzwerkkomponenten mit IPv6 offensichtlich nicht klar kommen. http://www.thomas-krenn.com/de/wiki/IPv6_deaktivieren

Das Paket ifupdown bzw. dessen Binary ifup macht meiner Auffassung nach keinen Unterschied zwischen IPv4 und IPv6 beim Aufruf von dhclient.
Es wird grundsätzlich immer die Option "-i" gesetzt.


Mein aktueller Workaround bleibt einfach das Paket in dem dhclient vorkommt zu deinstallieren und dafür einen anderen DHCP-Client zu installieren. Denn ifupdown prüft nach einer festen Reihenfolge verschiedenen DHCP-Clients auf existenz und nutzt den erstbesten. Wenn dhclient also nciht da ist, dann wird ein anderer, der vorhande ist, genommen. Somit sollte ich auch bei zukünftigen Updates der Pakete relativ sicher fahren.

[DirkB]

Man kann in der dhclient.conf auch die DUID durch "send dhcp-client-identifier 1:0:a0:24fb:9c;" überschreiben. Man beachte die 1: vor der eigentlichen MAC Adresse, ansonsten wird vorne die 00: abgeschnitten und beim DHCP kommt nur die a0:24fb:9c an.

interface "ep0" {
hardware ethernet 00:a0:24fb:9c;
send dhcp-client-identifier 1:0:a0:24fb:9c;
}

Viel Erfolg.

Grüße, Dirk