[Problem] vsftpd funktioniert nicht mehr - mehr Verbose

CaptainMorgan

Neuer User
Mitglied seit
28 Nov 2015
Beiträge
166
Punkte für Reaktionen
3
Punkte
18
Woah!
Darf ich dich fragen wie man sowas findet?

So wie ich das sehe wird nur das Objekt kVSFSysUtilMapProtNone gegen **ReadOnly ausgetauscht, bei gleichen source Dateien sollte es also eigentlich sicher sein.
Mein Bauchgefühl sagt mir ja nicht einfach Code von chinesischen Websites einzuspielen, aber langsam steigt die Verzweiflung...
 

Shirocco88

Aktives Mitglied
Mitglied seit
4 Jan 2016
Beiträge
870
Punkte für Reaktionen
67
Punkte
28
wenn dieser Patch 901-ignore_munmap_error.patch nicht hilft, dann bin ich raus;
da dieses Problem auch bei Ubuntu-14.04 in virtualisierten Umgebungen mit gewissen Kernelversionen (3.13.0-24 und in Kernel 3.13.0-30.54 gefixt ist) auftritt;
siehe https://bugs.launchpad.net/ubuntu/+source/vsftpd/+bug/1313450

ist die FB75xx-Serie nicht auch als VM konzipiert ?
hat sich die Kernelversion von FW 6.83 nach 7.01 geändert ?
 
Zuletzt bearbeitet:

CaptainMorgan

Neuer User
Mitglied seit
28 Nov 2015
Beiträge
166
Punkte für Reaktionen
3
Punkte
18
Update: Kurioses trägt sich zu. Habe im Moment Peters zweiten Patch geladen. Schon vor Stunden. Jetzt auf einmal scheint es zu gehen. Ich will nichts versprechen, ich schaue es mir an.
Ich habe es damals doppelt überprüft, mit extra Reboot und von zwei Maschinen.
Update2: Habe noch einen Benutzer hinzugefügt. Der erste geht weiterhin, der zweite produziert jetzt munmap, und alle 5-10 Versuche LogIn Incorrect
Update3: Habe jetzt die Nutzer "tim" und "tom" hinzugefügt, beide mit Passwort "123", ohne md5.
Manchmal geht der eine, manchmal geht der andere, manchmal keiner, manchmal beide.
"Gefühlt" sind es desto weniger Fehler desto kleiner die LogIn Informationen sind, doch im Großen und Ganzen lässt es einen doch verzweifeln.
Sollte in der Informatik nicht Reproduzierbarkeit gegeben sein?
Wenn das ganze nicht auf einer zweiten Box genauso wäre, würde ich auch defekten Ram/Cache tippen.
Andererseits müssten dann noch mehr Sachen unrund laufen, bzw das ganze instabil, wenn die Box so regelmäßig "Bithüpfer" produzieren würde.
 
Zuletzt bearbeitet:

CaptainMorgan

Neuer User
Mitglied seit
28 Nov 2015
Beiträge
166
Punkte für Reaktionen
3
Punkte
18
Nein, aber 0-Byte Dateien hochzuladen habe ich vorher nicht probiert, also bin ich davon ausgegangen dass es dabei helfen soll interne Probleme, bezüglich des Buffers und des Reservierens des Speicherplatzes zu lösen, als um den UpLoad von 0-Bytes Dateien.
 
Zuletzt bearbeitet:

PeterPawn

IPPF-Urgestein
Mitglied seit
10 Mai 2006
Beiträge
12,313
Punkte für Reaktionen
802
Punkte
113
Der ältere Ubuntu-Bug wurde - soweit ich es gelesen habe - durch ein Kernel-Update behoben (irgendwo in 3.13+) und verhinderte, daß der "vsftpd" überhaupt gestartet werden konnte. Wenn ich das hier richtig verstanden habe, tritt die "500 OOPS"-Message erst beim Login-Versuch für Benutzer auf, bei denen auf Dateien im OS zurückgegriffen werden soll.

Der Patch in #40 greift dann aber deutlich in die Logik des Ablaufs ein ... bei einem Pointer-Underrun (also einer Operation, wo ein wilder Zugriff in die Page VOR der eigentlichen Page (bzw. vor dem eigentlichen Buffer) erfolgt - diese "protection" klappt aber ohnehin nur für Buffer, die als Vielfaches der Seitengröße angefordert wurden, denn ansonsten wird als Pointer die Adresse "Ende - Größe" zurückgegeben:
Code:
  /* Before we make the "before" page inaccessible, store the size in it.
   * A little hack so that we don't need to explicitly be passed the size
   * when freeing an existing secure buffer
   */
  *((unsigned int*)p_mmap) = round_up;
  p_no_access_page = p_mmap;
  vsf_sysutil_memprotect(p_no_access_page, page_size, kVSFSysUtilMapProtNone);

  p_mmap += page_size;
  if (page_offset)    <<< Hier ist "page_offset" nicht 0, wenn die angeforderte Größe kein Vielfaches der Page-Size ist.
  {
    p_mmap += (page_size - page_offset);
  }
  *p_ptr = p_mmap;
) wird der Zugriff mit diesem Patch trotzdem funktionieren (solange er keinen Schreibversuch beinhaltet), denn die Seite ist jetzt erreichbar.

Das schwächt dann die Sicherheit (und damit die Idee) dieses "secure buffer" deutlich - gerade solche "Spezialitäten" sind es ja, die den "very secure FTP daemon" eigentlich ausmachen - denn ein normales Programm würde sich den Teufel darum scheren, die Pages rund um einen Buffer so zu manipulieren, daß Zugriffe dort unmittelbar zum Abbruch führen.

Notfalls kann man das aber sicherlich wirklich machen (so es denn hilft, denn immerhin wird ja trotzdem statt read/write (wie es von "map_anon_pages()" kommt) auf read/only gesetzt), denn auch Buffer in "nicht-Page-Größe" sind ja (prinzipbedingt) gegen solchen "Pointer-Underrun" nicht gefeit.

Ich weiß allerdings nicht, welche Puffergrößen im "vsftpd" normalerweise angefordert werden ... jedoch zeigt schon der Blick in die "filestr.c" weiter vorne, daß da eben der "secure buffer" auch nur in der Dateigröße angefordert wird. Damit greift der Schnipsel oben in diesem Beitrag mit einer Wahrscheinlichkeit von 1/4096 (denn die Page-Size müßte 4 KB betragen, iirc) ohnehin und ein Pointer-Underrun würde gar nicht festgestellt, solange er "im Rahmen" (einer Seite) bleibt und die Dateilänge nicht zufällig gerade ein Vielfaches von 4 KB ist.

Allerdings würde ich ohnehin nicht verstehen, warum es für ein "munmap()" einen Unterschied machen sollte, ob eine Page nun "read/only" oder "none" gemappt ist - zumindest in der Theorie (wenn man mal Kernel-Bugs beim syscall() außer Acht läßt) dürfte das keinen Unterschied ergeben. Wenn es bei einem Zugriff auf die Seite Probleme geben sollte (da wäre das Ergebnis dann aber eben ein SIGSEGV und kein "rc <> 0" vom "munmap()") durch irgendwelche nicht aktualisierten Cache-Pages, dann verstehe ich das noch - in die Richtung geht m.E. auch der Patch von den Chinesen.

Ich wäre ja schon begeistert, wenn tatsächlich klar ist, welcher "munmap()"-Call denn hier in die Hose geht - ich weiß allerdings nicht, ob ein "back trace" beim Abbruch (so man einen passenden Fehler provoziert, der nicht abgefangen wird, wie beim "500 OOPS") auch im "vsftpd" etwas bringen würde an Erkenntnis, wo nun dieses Problem eigentlich wirklich seine Wurzeln hat.

Ich bin ja nach wie vor der Ansicht, daß es nur zwei potentielle Stellen mit "munmap()" (in der Folge eines anderen Funktionsaufrufs) gibt ... bei der ersten (also dem ersten Patchversuch) hätte es gar keine "500 OOPS: munmap" mehr geben dürften und wenn die bei "str_fileread()" unter den Bedingungen des zweiten Patches jetzt trotzdem noch auftreten (ich dachte da eigentlich auch weniger an das Handling von 0-Byte-Files im Up- oder Download, sondern eher an diverse, im FRITZ!OS nicht vorhandene Dateien, wie "/etc/services" oder ähnliches), dann wäre wieder unerklärlich, warum es irgendeinen Fall gibt, bei dem es dann nicht zum Fehler kommt, wenn man es nur oft genug wiederholt.

Als Notnagel bliebe nur noch die Vermutung, daß das Ermitteln der Page-Size hin und wieder nicht klappt ... denn dieser Wert wird natürlich bei den ganzen Kunststückchen zum Memory-Mapping auch jedesmal abgefragt und alle Berechnungen für die Pointer verlassen sich darauf, daß der jedesmal dasselbe Ergebnis liefert. Ermittelt wird diese Größe aber auch nur einmalig und anschließend wird sie in einer statischen Variablen gespeichert:
Code:
unsigned int
vsf_sysutil_getpagesize(void)
{
  static unsigned int s_page_size;
  if (s_page_size == 0)
  {
    s_page_size = getpagesize();
    if (s_page_size == 0)
    {
      die("getpagesize");
    }
  }
  return s_page_size;
}
Wenn jetzt aus irgendeinem kruden Grund an die Adresse von "s_page_size" geschrieben werden sollte (das muß hier ja auch beim Start noch auf 0 initialisiert werden, damit das klappt - aber das macht der Compiler eigentlich für statische Variablen automatisch so) und das ist am Ende nicht mehr die tatsächliche Seitengröße, dann käme die gesamte Pointerberechnung beim "munmap()" auch wieder durcheinander.

Das wäre dann ebenso ein Ansatz für weitere Tests, wie die zusätzliche Ausgabe des tatsächlichen Fehlercodes, der vom "munmap()" zurückgeliefert wird und der beim Aufruf verwendeten Parameter - im Moment ist ja nur klar, daß das Ergebnis nicht die erwartete "0" ist ... hinsichtlich des Fehlers herrscht aber weitgehende Unklarheit.

Ich bin mal gespannt, wie sich das hier entwickelt ... etwas komisch ist das schon. Da kommt dann noch die neue uClibc-ng hinzu, die ja auch aus dem "getpagesize()" erst mal den passenden Syscall machen müßte oder gleich selbst beim Build der Library wieder das Symbol PAGE_SIZE des Kernels als statische Variable speichern könnte. Mal schauen, was uClibc-ng da tatsächlich macht und ob/wie sich das von der älteren uClibc unterscheiden mag, die vor 07.0x verwendet wurde.
 

CaptainMorgan

Neuer User
Mitglied seit
28 Nov 2015
Beiträge
166
Punkte für Reaktionen
3
Punkte
18
Ich habe ja berichtet dass das selbe Verhalten auch auf der 7362SL, dem Router auftritt.
Und dem war auch so. Der Benutzer den ich dort Anfang der Woche angelegt habe wurde jetzt bis auf einen Stromausfall nicht mehr modifiziert. Und jetzt läuft das ganze tadellos.
TLSv1 an oder aus, md5 passwort, chroot, 5 Verbindungen, manuelle Ports.
Es könnte nicht schöner sein. Fast traue ich mich nicht es wieder anzufassen. Werde aber gleich versuchen Benutzer hinzuzufügen.
Macht das irgendeinen Sinn? Das die Konfiguration erst mehrere Tage stehen muss bevor es wirklich funktioniert?
 

PeterPawn

IPPF-Urgestein
Mitglied seit
10 Mai 2006
Beiträge
12,313
Punkte für Reaktionen
802
Punkte
113
Mit/ohne Patches? Wenn mit, mit welchen?

Wie geschrieben ... man muß erst mal die Ursache für die munmap()-Fehler kennen, bevor man "zielgerichtet raten" kann. Da die 7362SL auch noch einen anderen (älteren) Prozessor verwendet, kann man das u.U. nicht mal direkt miteinander vergleichen. Am Ende könnte es tatsächlich auch noch mit einem "memory mapping"-Problem bei der Virtualisierung des GRX5 zusammenhängen (dann aber eigentlich auf VR9-Chips nicht auftreten), denn da wird offenbar erst mal ein "bootcore kernel" geladen (der hat kein eigenes Dateisystem, da ist alles direkt im Kernel enthalten), der dann die Ressourcen an mehrere VM verteilen könnte - auch wenn AVM wohl nur eine VM benutzt bisher.
 

CaptainMorgan

Neuer User
Mitglied seit
28 Nov 2015
Beiträge
166
Punkte für Reaktionen
3
Punkte
18
Auf der 7362SL, dem Router, läuft gar kein Patch. Alles "Serie" aus dem Trunk. Stand 09.01, also noch bevor ich den Thread hier aufgemacht habe.
Da auf beiden identische Probleme auftraten habe ich angenommen dass es auch eine identische Lösung geben muss. Da es sich angenehmer arbeitet wenn das Internet nicht ständig ausfällt, habe ich mich entschieden alle Experimente an der 7560 durchzuführen. Dabei war alles was die 7362SL gebraucht hat ein paar Tage Ruhe... Und ja, ich weiß dass es dafür so keine logische Erklärung gibt.

Dann hier nochmal der letzte Aufruf, hat denn niemand eine 7560/7580/7590 der eventuell aus Neugier mal versuchen würde vsftpd zu installieren?
Mit einer Stichprobe von 1 ist einem "chaotischen" Fehler schwer auf die Schliche zu kommen.

der dann die Ressourcen an mehrere VM verteilen könnte - auch wenn AVM wohl nur eine VM benutzt bisher.
Shirocco88 hat in #42 VM's erwähnt. Würde so ein Schuh daraus?
 

PeterPawn

IPPF-Urgestein
Mitglied seit
10 Mai 2006
Beiträge
12,313
Punkte für Reaktionen
802
Punkte
113
Shirocco88 hat in #42 VM's erwähnt. Würde so ein Schuh daraus?
Wenn die Probleme generell nur auf GRX5-Systemen auftreten, wäre das zumindest eine Möglichkeit - vielleicht klappt im virtualisierten Kernel der Zugriff auf die (bare-metal) TLBs nicht immer zuverlässig, denn irgendeine Erklärung für wechselnde Ergebnisse wird ja auch noch gebraucht, wenn das nicht 100% reproduzierbar ist und in seltenen Fällen weiterhin funktioniert.

Ich habe zwar auch eine 7580, aber dort keine modifizierte Firmware installiert, weil mir die nur zur Analyse der originalen AVM-Firmware dienen sollte. Ich überlege zur Zeit den Wechsel zu einer 7590 für diese Zwecke, denn offenbar will AVM die 7580 bei den Labor-Versionen ja eher nicht unterstützen. Wenn ich die Box irgendwann "frei" haben sollte, kann ich auch selbst dort einen "vsftpd" testen ... im Moment wäre mir das zuviel Aufwand, auch wenn ich natürlich Shell-Zugriff habe.

Ich widme mich dem ganzen Thema "vsftpd" auch nur deshalb, weil ein FTP-Server (und da gilt der vsftpd nun mal als eine sichere Wahl) zum Verteilen eigener Pakete in meinen Planungen eine gewisse Rolle spielt.
 

Shirocco88

Aktives Mitglied
Mitglied seit
4 Jan 2016
Beiträge
870
Punkte für Reaktionen
67
Punkte
28
was mich erstaunt ist, dass es bei der FB7362SL mit FW 06.83 alles funktionierte, und bei Kernel-/libc-Wechsel (ich setze mal voraus, dass wie berichtet keine Änderung im Freetz an vsftpd-3.0.3 stattgefunden hat) die Probleme aufgetreten sind;
@CaptainMorgan
nur um sicher zu sein, hat vsftpd mit einer FW 06.xx bei der FB7560 schon mal funktioniert ?
wie sieht es mit dem Patch in #40 aus, konntest Du den schon testen ?
 
Zuletzt bearbeitet:

CaptainMorgan

Neuer User
Mitglied seit
28 Nov 2015
Beiträge
166
Punkte für Reaktionen
3
Punkte
18
Beides werde ich nochmal testen.
Wie du vielleicht gelesen hast hat sich ja auch die Prämisse jetzt leicht geändert.
Die 7362Sl funktioniert nun tadellos, zumindest "konstant". Alles was nicht funktioniert kann ich auf eigenes Konfigurationsunvermögen schieben.
Die 7560 verhält sich irrsinnig, da bleibe ich noch etwas dran.
 

stulle

Neuer User
Mitglied seit
8 Jan 2006
Beiträge
11
Punkte für Reaktionen
1
Punkte
3
Ich melde mich mal wieder, habe im Moment sehr wenig Zeit.
Ich hatte in meinen Beiträgen weiter oben vergessen zu schreiben, dass ich die Probleme mit dem Standard-FTP Client auf SuseLinux 13.4 nicht habe (eben nochmal getestet). Auf Win 10 benutze ich WinSCP und den Speedcommander mit den genannten Problemen. Wie gesagt, früher hatte ich eine FritzBox 7390, die liegt hier rum, hat die letzte Labor mit freetz drauf und die hatte kein "..OOPS: munmap". Habe erst wieder am WE etwas Zeit, könnte die dann mal als W-LanRepeater anschließen und testen.
Ich kann mich jetzt nicht erinnern, dass meine jetzige 7590 schon mal ohne die vsftpd Problematik lief, weder die 06.83 und jetzt die 154.07.08 rev64611 BETA.
Welchen Patch aus welchen Beitrag kann ich denn mal testen und muss ich vorher ein vsftpd dirclean durchführen?
 

CaptainMorgan

Neuer User
Mitglied seit
28 Nov 2015
Beiträge
166
Punkte für Reaktionen
3
Punkte
18
Ich hatte in meinen Beiträgen weiter oben vergessen zu schreiben, dass ich die Probleme mit dem Standard-FTP Client auf SuseLinux 13.4 nicht habe (eben nochmal getestet). Auf Win 10 benutze ich WinSCP und den Speedcommander mit den genannten Problemen.
Das ist allerdings erwähnenswert... Ich habe kein natives Linux installiert, aber ich versuche es demnächst mal mit einer Ubuntu VM. Firefox W10 lieferte mir aber auch munmaps, und Android macht eh was es will.

Ich kann mich jetzt nicht erinnern, dass meine jetzige 7590 schon mal ohne die vsftpd Problematik lief, weder die 06.83 und jetzt die 154.07.08 rev64611 BETA.
Welchen Patch aus welchen Beitrag kann ich denn mal testen und muss ich vorher ein vsftpd dirclean durchführen?
Die 7560 bei mir auch nicht, die wurde mir mit 7.01 liefert. Und wie sich gezeigt hat läuft meine 7362SL ja doch. Sowohl mit 7.01 und 6.83, 6.54...
Wenn sich bei dir ähnliches zeigt, liegt es vielleicht wirklich an den GRX5 Systemen. Ein veränderter Kernel oder Befehlssatz.
Bezüglich der Patches: Testen würde ich alle. Wie erwähnt, bei sample-size 1 ist es schwer definitive Aussagen zu treffen, besonders bei einem "randomisierten" Problem.
Ich selbst will auch die Tage noch den China Patch einspielen.
Meine Boxen sind alle im aktiven Dienst, und alle Experimente müssen am offenen Herzen erfolgen, deswegen kann ich im Moment leider nicht so viel testen, da ich nicht vor Ort bin.
Das ganze über die Fernwartung zu machen ist mir zu heikel. Wenn dann was schiefgeht ist niemand da zum Recovern.
Ich weiß nicht wie sehr du auf die Mehrfunktionen der 7590 angewiesen bist, aber eventuell kannst ja die Boxen am Wochenende tauschen, um dir und deinen Angehörigen das Internet zu erhalten. Dann hätten wir eine komplett befreite GRX5 Box in willigen und fähigen Händen um mal richtig durchzutesten. Wenn irgendetwas eine zweiter Test gebraucht wird, kann normalerweise auch ein bis zwei Images am Tag unauffällig durchbringen....
 

Shirocco88

Aktives Mitglied
Mitglied seit
4 Jan 2016
Beiträge
870
Punkte für Reaktionen
67
Punkte
28
nur mal ne Frage, um das zu verstehen:
Welcher Mehrwert bietet "vsftpd" gegegenüber dem "AVM ftpd" allgemein, bzw. im konkreten Use-Case ?
https://github.com/Freetz/freetz/blob/master/make/mod/files/root/etc/init.d/rc.ftpd
Wäre die Nutzung von "AVM FTPd" über Freetz als Workaround für FB75xx denkbar ?

Freue mich natürlich, wenn die Probleme mit FB75xx HW und vsftpd behoben sind; Testergebnisse gerne einstellen; Hilfestellung soweit mir möglich, werde ich liefern.
 

CaptainMorgan

Neuer User
Mitglied seit
28 Nov 2015
Beiträge
166
Punkte für Reaktionen
3
Punkte
18
Wäre die Nutzung von "AVM FTPd" über Freetz als Workaround für FB75xx denkbar ?
In meinem Konkreten Fall ja. Und nein.
Aktiviert man AVM ftpd bleibt Port 21 immer aktiv, und auf dem wird auch FTP ohne TLS akzeptiert, eignet sich bei einem Klienten also nicht zum durchstellen.
Und der Port der "gehärtet" ist, den die Box für Zugriff aus dem WAN verwendet, spricht aus dem LAN nicht an.
Mit vsftpd kann man einen gehärteten Port durchstellen.

Welcher Mehrwert bietet "vsftpd" gegegenüber dem "AVM ftpd" allgemein, bzw. im konkreten Use-Case ?
Das man die Benutzerkonten unabhängig von den FritzBox Logins einstellen kann.
Da hat AVM viel getan, der Anreiz ist wirklich gering geworden. Das ist auch der Grund warum ich den alten Samba-HowTo Thread ausgegraben habe, es funktioniert halt nur mehr solala...

@stulle: Wie sieht es aus, denkst du du kannst am WE ein paar Images durchschleusen?

Frage an alle:
Da bei mir immer die Sorge mitspielt das meine VM einen Knacks hat, macht es Sinn bei Images mit dem gleichen Trunk und der gleichen .config die Checksummen zu vergleichen, vorrausgesetzt gleiche oder keine Signatur?
 

stulle

Neuer User
Mitglied seit
8 Jan 2006
Beiträge
11
Punkte für Reaktionen
1
Punkte
3
Ich habe nur den Sonntag, mal schauen ob meine Fam mich lässt.
@Shirocco88, #55, war es nicht mal so, dass AVM gar kein ftp auf den Boxen hatte. Bei meiner ersten gefreetzten 7170, ewig her, war das glaube ich so. Seit dem nutze ich den vsftpd und das hat sich nun aus Gewohnheit bis zu den aktuellen Boxen bei mir durchgezogen.
 

stulle

Neuer User
Mitglied seit
8 Jan 2006
Beiträge
11
Punkte für Reaktionen
1
Punkte
3
So, ich konnte heute schon testen. Habe mir die alte gefreetzte 7390 gegriffen (mit letzten Softwarestand AVM 84.06.85 rev62149, Freetz: devel-14946M) und als WLAN-, Dect-Repeater eingerichtet. Zusätzlich zu vsftpd ist noch samba, nfs und oscam installiert. vstpd und samba sind "external" auf dem internen Speicher wegen "Image to big". Zusätzlich hängt noch eine 700 Gbyte Festplatte (ext3) am USB.
Wie erwartet und wie schon geschrieben gibt es keinerlei Probleme auf den Zugriff, ganz egal löschen, schreiben, kopieren auf intern oder FP, ein "..OOPS: munmap" trat nicht einmal auf.
 

Genesis100

Neuer User
Mitglied seit
6 Mrz 2011
Beiträge
67
Punkte für Reaktionen
1
Punkte
8
Ich weiß es nicht wie aktuell ist das Thema mit vsftpd und der Fritzbox 7590 mit freetz 7.01

Ich hatte die gleiche probleme wie @CaptainMorgan. Mein Problem hat sich gelöst als de Patch 901-ignore_munmap_error.patch in die Freetz-Trunk aufgenommen hatte.

Mein Freetz Image Freetz_7590_oscam_1.4.9_vsftp_SSL_ignore_munmap_7590_07.01-freetz-devel-15014.de_20190206-170307, mein vsftpd.conf

background=yes
check_shell=no
listen=yes
anonymous_enable=yes
local_enable=yes
local_umask=022
chroot_local_user=no
passwd_chroot_enable=no
write_enable=yes
nopriv_user=root
secure_chroot_dir=/var/run/vsftpd
listen_port=21
userlist_enable=yes
anon_root=/mod/home/ftp
xferlog_std_format=no
xferlog_enable=no
vsftpd_log_file=/var/log/vsftpd.log
log_ftp_protocol=no
syslog_enable=yes
max_clients=25
max_per_ip=5
pasv_min_port=0
pasv_max_port=0
pasv_promiscuous=yes
delay_failed_login=15
chroot_list_enable=yes
ssl_enable=yes
ssl_sslv2=yes
ssl_sslv3=yes
ssl_tlsv1=yes
force_local_data_ssl=no
force_local_logins_ssl=no

Gruß
 
  • Like
Reaktionen: gismotro

3CX PBX - GRATIS
Linux / Win / Cloud

Statistik des Forums

Themen
233,286
Beiträge
2,032,407
Mitglieder
351,810
Neuestes Mitglied
cyb7