Beiträge von bax

Hallo!

Habe das Problem dass der Bildschirm keine Sonderzeichen anzeigt wenn ich Firefox verwende.

Folgendes Problem:

• öffne Bildschirm mit Firefox
• gebe Zeichen ein
• a-z, A-Z, 0-9, ,./;'[]\`-= funktionieren (US ANSI Tastatur)
• andere Sonderzeichen funktionieren nicht (Shift + [a-z], Shift + [0-9], alle anderen Sonderzeichen für die ein Modifier benötigt wird)
• über die Bildschirmtastatur funktionieren alle Zeichen

Ausgaben in der Konsole (vermutlich nicht relevant):

Diese Seite verwendet die nicht standardisierte Eigenschaft "zoom". Stattdessen sollte calc() in den entsprechenden Eigenschaftswerten oder "transform" zusammen mit "transform-origin: 0 0" verwendet werden. 
VNCPopUp

XML Parsing Error: syntax error
Location: https://www.servercontrolpanel.de/SCP/VNCProxy?connect
Line Number 1, Column 1: 
VNCProxy:1:1

Das Problem have ich in andere Browsern nicht, daher gehe ich von einem Kompatibilitätsproblem / Problem des SCP Bildschirms aus.

Konfiguration:

mac OS 11.1

Tastatus US ANSI

Firefox 85.0

SCP-Tastaturlayout: US

System: FreeBSD 12.2 (es wird kein Tastaturlayout per `/etc/rc.conf` zum Systemstart geladen)

Hallo!

Auch ich habe wie bereits hier und hier beschrieben habe ich seit einiger Zeit ein Problem mit der Erreichbarkeit meines FreeBSD 11.0 Servers über IPv6.

Bis vor einigen Wochen lief über ein Jahr alles wunderbar, seit einem nicht genau bekannten Zeitraum hält die IPv6 Verbindung immer nur für ca. 40-80 Minuten nach einem Neustart.

Es gab kein mir bekanntes Softwareupdate oder eine Änderung der Konfiguration die das auslösen hätte können.

Meine Konfiguration:

/etc/rc.conf

#IPv4

ifconfig_vtnet0_name="em0"
ifconfig_em0="inet YY.YY.YY.YY netmask 255.255.252.0"
defaultrouter="188.TT.TT.TT"

# IPv6

ifconfig_em0_ipv6="inet6 accept_rtadv"
rtsold_enable="YES"
ifconfig_em0_alias0="inet6 2aXX:XXXX:XXXX:XXXX::1 prefixlen 64"
ipv6_defaultrouter="fe80::1%em0"

gateway_enable="YES"
ipv6_gateway_enable="YES"

ifconfig

em0: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
    options=6c07bb<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,JUMBO_MTU,VLAN_HWCSUM,TSO4,TSO6,LRO,VLAN_HWTSO,LINKSTATE,RXCSUM_IPV6,TXCSUM_IPV6>
    ether ZZ:ZZ:ZZ:ZZ:ZZ:ZZ
    inet YY.YY.YY.YY netmask 0xfffffc00 broadcast 188.DD.DD.DD
    inet6 fe80::KKKK:KKKK:KKKK:1822%em0 prefixlen 64 scopeid 0x1
    inet6 2aXX:XXXX:XXXX:XXXX::1 prefixlen 64
    inet6 2aXX:XXXX:XXXX:XXXX::103 prefixlen 128
    nd6 options=23<PERFORMNUD,ACCEPT_RTADV,AUTO_LINKLOCAL>
    media: Ethernet 10Gbase-T <full-duplex>
    status: active
lo0: flags=8049<UP,LOOPBACK,RUNNING,MULTICAST> metric 0 mtu 16384
    options=600003<RXCSUM,TXCSUM,RXCSUM_IPV6,TXCSUM_IPV6>
    inet6 ::1 prefixlen 128
    inet6 fe80::1%lo0 prefixlen 64 scopeid 0x2
    inet 127.0.0.1 netmask 0xff000000
    inet 10.0.0.1 netmask 0xffffffff
    inet 10.0.0.4 netmask 0xffffffff
    inet 10.0.0.3 netmask 0xffffffff
    nd6 options=21<PERFORMNUD,AUTO_LINKLOCAL>
    groups: lo
pflog0: flags=141<UP,RUNNING,PROMISC> metric 0 mtu 33160
    groups: pflog

Die Routingtabellen bleiben nach dem Ausfall die gleichen:

netstat -rn

Routing tables

Internet:
Destination        Gateway            Flags     Netif Expire
default            188.TT.TT.TT        UGS         em0
10.0.0.1           link#2             UH          lo0
10.0.0.2           link#2             UH          lo0
10.0.0.3           link#2             UH          lo0
10.0.0.4           link#2             UH          lo0
10.0.0.10          link#2             UH          lo0
10.0.0.11          link#2             UH          lo0
10.0.0.12          link#2             UH          lo0
10.0.0.13          link#2             UH          lo0
127.0.0.1          link#2             UH          lo0
188.TT.TT.0/22     link#1             U           em0
YY.YY.YY.YY       link#1             UHS         lo0

Internet6:
Destination                       Gateway                       Flags     Netif Expire
::/96                             ::1                           UGRS        lo0
default                           fe80::1%em0                   UGS         em0
::1                               link#2                        UH          lo0
::ffff:0.0.0.0/96                 ::1                           UGRS        lo0
2aXX:XXXX:XXXX:XXXX::/64             link#1                        U           em0
2aXX:XXXX:XXXX:XXXX::1               link#1                        UHS         lo0
2aXX:XXXX:XXXX:XXXX::102             link#1                        UHS         lo0
2aXX:XXXX:XXXX:XXXX::103             link#1                        UHS         lo0
fe80::/10                         ::1                           UGRS        lo0
fe80::%em0/64                     link#1                        U           em0
fe80::KKKK:KKKK:KKKK:1822%em0     link#1                        UHS         lo0
fe80::%lo0/64                     link#2                        U           lo0
fe80::1%lo0                       link#2                        UHS         lo0
ff02::/16                         ::1                           UGRS        lo0

In einem kurzen Kontakt mit dem Kundenservice von Netcup wurde nur abgewiegelt und gesagt dass das Problem an der Serverkonfiguration liegen muss da keine Probleme bekannt seien.

Meine Konfiguration hat über ein Jahr (erst 10.0 und neuere Versionen, seit einigen Monaten 11.0) tadellos funktioniert:

#IPv4

ifconfig_vtnet0_name="em0"
ifconfig_em0="inet XX.XX.XX.XX netmask 255.255.252.0"
defaultrouter="XX.XX.XX.XX"

# IPv6


ifconfig_em0_ipv6="inet6 accept_rtadv"
ifconfig_em0_alias0="inet6 2a03:4000:Y:Y::1 prefixlen 64"
rtsold_enable="YES"
ipv6_defaultrouter="fe80::1%em0"

gateway_enable="YES"
ipv6_gateway_enable="YES"

aber seit einiger Zeit scheint es da wie geschrieben ein Problem zu geben…

Bei mir (FreeBSD 11.0) scheint es das Problem nicht zu beheben. Nach einem Neustart bin ich über IPv6 erreichbar, nach einiger Zeit nicht mehr – da hilft dann wieder nur der Reboot.

Da das Problem erst seit einiger Zeit zu bestehen scheint und sich an der Netzwerkkonfiguration nichts geändert hat glaube ich eher dass es (bei mir) an Netcup liegt (?).

+1

(FreeBAS 11)

bin von aussen auch nicht über IPv6 erreichbar

Zitat von [netcup] Oli

Nach einem Logout/Login funktioniert diese wieder. Der Fehler ist ab Version 6.0.4. behoben (steht im Footer).

Danke!
Korrekt, jetzt geht es.

Leider reagiert die Konsole / der Monitor nicht wenn ich das neue SCP verwende. Über die "alte" Schnittstelle geht es noch.
Ich werde regelmäßig "disconnected" und die Konsole reagiert nicht auf Eingaben.

Das Problem scheint noch zu bestehen… Gibt es hier Entwicklungen?

Das klingt super, danke!

Gibt es hierzu eine Aussage?

Zitat von [netcup] Felix

Guten Tag,

an dem Feature wird gearbeitet. Allerdings erfährt DNSSEC zur Zeit auch vermehrt Ablehnung, weshalb eventuell die Arbeiten daran abgebrochen werden.

Details: Neuer Masterschlüssel für das Herz des Netzes | heise Netze

Kommende Woche können wir sagen, wann es planmäßig fertiggestellt ist oder ob wir eventuell die Arbeiten an DNSSEC abbrechen müssen, da das Risiko eines Totalausfalls durch DNSSEC zu groß wird und am Ende kaum ein Kunde noch DNSSEC einsetzen möchte.

Mit freundlichen Grüßen

Felix Preuß

Alles anzeigen

Gibt es hierzu schon Neuigkeiten?

Die aktuelle KVM Version von Netcup hat ein Problem mit FreeBSD – ACPI Reboot wird nicht erkannt wenn mehr al ein Prozessorkern verwendet wird.
Reboot von FreeBSD von der Konsole aus funktioniert nicht

EDIT: Hier wohl nicht relevant da SHUTDOWN und nicht REBOOT verwendet wird.

Zitat von [netcup] Felix

Guten Tag,

da Sie vom CCP ins VCP gelangen, können Sie im VCP ein entsprechend langes Passwort setzen und dieses anschließend nicht verwenden. So können Sie die 2FA vom CCP ans VCP vererben.

In der Software die demnächst das VCP ablösen wird, werden Sie den Login per Passwort komplett abschalten können.

Mit freundlichen Grüßen

Felix Preuß

Alles anzeigen

Das klingt super, danke!

Gibt es einen Plan wann auch von Netcup-DNS-Servern verwaltete .com und .de Domains DNSSEC unterstützen werden?

Es wäre toll wenn die 2FA auch für das vservercontrolpanel verfügbar wäre.

Da Let's Encrypt nun auch DNS zur Domain-Validierung unterstützt wäre es toll wenn die DNS-Einstellungen im CCP auch per API angepasst werden könnten.
Für vServer-Kunden die keinen eigenen DNS-Server betreiben würde das die Automatisierung erleichtern.

Habe das gleiche Problem.
Gibt es hierzu Neuigkeiten?

Ein kurzes Update hierzu.
Die angegebenen Einstellungen haben NICHT funktioniert (nach einem Neustart war keine IPv6 Verbindung vorhanden).
Des Weiteren habe ich nun die IPv4 Adresse statisch vergeben. Das DHCP von Netcup gibt keine IPv6 DNS server bekannt. Bei jedem Start wird die /etc/resolv.conf durch DHCP überschrieben. Es stehen also keine IPv6 DNS Router bereit wenn DHCP bei Netcup verwendet wird.

Meine neue /etc/rc.conf

### Netzwerk 




#IPv4 




ifconfig_em0="inet XXX.XXX.XXX.XXX netmask 255.255.252.0" 
defaultrouter="XXX.XXX.XXX.1" 




# IPv6 




ifconfig_em0_ipv6="inet6 accept_rtadv" 
ifconfig_em0_alias0="inet6 YYYY:YYYY:YYYY:YYYY::1 prefixlen 64" 
rtsold_enable="YES" 
ipv6_defaultrouter="fe80::1%em0"

meine /etc/resolf.conf (es werden nur drei IP-Adressen von FreeBSD verwendet, der letzte Eintrag wird also ignoriert):

search yourserver.net 




nameserver 46.38.225.230 
nameserver 46.38.252.230 
nameserver 2a03:4000:0:1::e1e6 
nameserver 2a03:4000:8000::fce6

Zitat von frostschutz

Nicht das was ich gemeint habe ... ich kenne FreeBSD nicht, Google meint was von /etc/wall_cmos_clock

Eine Stunde daneben klingt halt stark danach, daß die "Systemuhr" falsch interpretiert wird (local statt UTC oder andersrum).

Danke für den Tip! Ich habe "tzsetup" ausgeführt und die Systemuhr auf UTC gestellt. Jetzt passt es!

Zitat von frostschutz

Gibts da auch ne Einstellung der Systemuhr utc vs. local?

BSD Start - FreeBSD and time zones