FreeNAS via Subnet erreichen für CIFS Freigabe



  • Guten Tag,

    ich stehe am Abgrund zur Weißglut.

    Ich habe einen FreeNAS aufgesetzt um  diesen in einem Netzwerk was mit einer pfSense 2.1.5 betrieben wird einzubinden.

    Das Netzwerk hat mehrere Subnets. Der NAS hat sein eigenes bekommen.
    Beim eintichten habe ich mich eher auf die Benutzerechte konzentreirt und nicht an die Broadcast Probleme mit Windows Freigaben geadcht.

    Jetzt habe ich den NAS ins Netzwerk eingebunden und hatte vorher schon die Regeln konfiguriert und war schon erfreut, dass ich von einem PC, der seine Backups auf dem NAS ablegen sollte, diesen auch anpingen kann. Aber das war es dann auch ;(
    Nach etwas Suche im Netz wurde mit klar, dass es für Windowsfreigaben nicht einfach ist, diese über verschiedene Subnets zu erreichen.
    Nachdem was ich hier im Forum gefunden habe, gibt die zwei Fälle, dass der NAS entweder nicht anzupingen ist, oder/und mit Namen nicht erreichbar ist und oft ein DNS Problem vorliegt.

    Um einen Fehler bei den Rules auszuschließen, habe ich auf dem NAS Subnet und einem LAN Netz testweise any-to-any auf beiden Seiten erstellt und alle anderen deaktiviert - nur um es wirklich auszuschliessen!
    Aber schon vorher konnte ich sowohl pingen, als auch einen erfolgreichen nslookup machen.
    Das einzige was nicht klappt, ist auf die Freigaben zu kommen.

    Weder via IP noch über den Namen. Mein Ziel ist es ja nicht mal, dass ich per Windows Explorer das Netz durchsuchen kann. Es würde mir vollkommen reichen, wenn ich die für den PC bestimmte Freigabe als Laufwerk einbinden kann.

    Wenn ich den NAS an ein Switch im selben Subnet stecke, klappt natürlich alles auf Anhieb. Darum suche ich in der pfSense den Fehler.

    Sowohl PC als auch der NAS haben eine feste IP.
    Ich kann vom NAS den PC im anderen Subnet anpingen, nslookup im Lan wie auch ins I-Net klappen von beiden Seiten aus.

    Wenn ich über CMD: "dir \ip_des_NAS" ausführe kommt:
    Der Netzwerkpfad wurde nicht gefunden

    Via Explorer und Diagnose kommt: Die Verbindung wird vom Remotegerät nicht akzeptiert

    Jemand einen Ansatz für mich, was ich übersehe oder wie ich testen könnte, woran ich scheiter?

    Gruß…



  • Hi flachfalke,

    ich stehe am Abgrund zur Weißglut.

    …und das bringt Dich auch nicht weiter.... ;)
    Du bist wohl nicht der einzige der an Layer3 und Broadcasts scheitert.
    Ich betreibe so in etwa ein ähnliches Szenario und muss mich bis Dato auch damit zufrieden geben, das es nichts mit Samba wird.
    Kleines Trostpflaster für mich, nur ganz selten ein Windows-PC im Netzwerk.
    Alle Versuche, das mit einem Regelwerk zurecht zu biegen, waren nicht von Erfolg gekrönt, obwohl ab und an im Netz zu lesen ist, das es funktionieren soll.

    und war schon erfreut, dass ich von einem PC, der seine Backups auf dem NAS ablegen sollte, diesen auch anpingen kann.

    ICMP hat eben nichts mit TCP/IP zu tun. :)
    Ich habe mich für den Zugriff bis jetzt mit FTP beholfen, ist zwar nicht so kompfortabel, funktioniert aber.
    Schau mal hier…
    http://www.unixboard.de/vb3/showthread.php?52131-Samba-subnetz%FCbergreifend
    Scheitert bei mir am Verständnis….

    wirst du ein echtes Routing zwischen den Subnets ermöglichen müssen, das auch Broadcasts durchlässt (indem du z.B. direkte Neighbors mittels iproute2 definierst).

    Wenn Du da was nachvollziehen kannst wäre ich über eine Rückmeldung ganz dankbar.
    Gruß orcape



  • Mal Windowsfirewall ausschalten und falls das was ändert in der Windowsfirewall andere Subnets durchlassen?



  • Mal Windowsfirewall ausschalten und falls das was ändert in der Windowsfirewall andere Subnets durchlassen?

    Sorry, aber was hat ein blocken von Broadcasts auf Layer3 in der pfSense mit einer Windows Firewall zu tun ?



  • @orcape:

    Mal Windowsfirewall ausschalten und falls das was ändert in der Windowsfirewall andere Subnets durchlassen?

    Sorry, aber was hat ein blocken von Broadcasts auf Layer3 in der pfSense mit einer Windows Firewall zu tun ?

    So wie ich es verstanden habe sind im konkreten Fall die Broadcasts ja nur für die Namensauflösung notwendig. Er hat aber schon das Problem dass er mit \ <ip>nicht auf die Freigabe kommt. Das gleiche hatte ich auch schon - und da hat die Windowsfirewall den Zugriff auf das andere Subnet blockiert.

    Um einen Fehler bei den Rules auszuschließen, habe ich auf dem NAS Subnet und einem LAN Netz testweise any-to-any auf beiden Seiten erstellt und alle anderen deaktiviert - nur um es wirklich auszuschliessen!

    Wenn er damit sagen will dass es mit any-to-any klappt, dann ist mein Hinweis natürlich fehl am Platz.</ip>



  • @fbd:

    Um einen Fehler bei den Rules auszuschließen, habe ich auf dem NAS Subnet und einem LAN Netz testweise any-to-any auf beiden Seiten erstellt und alle anderen deaktiviert - nur um es wirklich auszuschliessen!

    Wenn er damit sagen will dass es mit any-to-any klappt, dann ist mein Hinweis natürlich fehl am Platz.

    Nein, mit any-to-any klappt genau so nichts, wie mit den Rules, die ich mir vorher aus dem Netz abgeschaut habe, um nicht das Scheunentor öffnen zu müssen. Aber bevor ich mich todsuche an dem Problem und es nachher, bedingt durch eine falsche Regel nicht klappt, teste ich lieber so.
    Nach meinem pfSense Verständnis, ist doch mit einer solchen any-to-any Rule theoretisch keine Regelwerk im Weg, oder doch?!

    Ich habe mich für den Zugriff bis jetzt mit FTP beholfen, ist zwar nicht so kompfortabel, funktioniert aber.
    Schau mal hier…
    http://www.unixboard.de/vb3/showthread.php?52131-Samba-subnetz%FCbergreifend
    Scheitert bei mir am Verständnis….

    Korrekt, wenn ich per ftp:\ anfrage, kommt die Benutzkennungsabfrage als "Antwort"….grrrr

    Der Threadersteller aus deinem Link, hat im ServerSubNetz einen WINS Server aufgeführt....der sorgt glaub ich in dem Fall dafür, dass er zumindest die Freigaben aufgelistet bekommt mit einem "dir \...." Das würde mir ja VOLLKOMMEN reichen! Ob die Netzwerkumgebung unter Windows was ausgibt oder ich den NAS per IP und nicht per Namen ansprechen muss, wäre mir herzlich egal. Ich kanns irgendwie nicht glauben, dass das ein Problem ist und hoffte an meiner laienhaftigkeit zu scheitern.

    Aber nachdem ich das DNS Problem gemeistert habe und sowohl per Namen als auch per IP Rückmeldung bekam, dachte ich es muss doch langsam funzen...

    Mein Big Prob ist, dass ich nicht weiß, ob ich im NAS das Problem lösen KÖNNTE, oder in der Sense, oder oder. Der Netzwerk Guru bin ich nicht;(

    Im FreeNAS Forum hab ich das gefunden:
    http://forums.freenas.org/index.php?threads/pfsense-two-lan-subnets-freenas-shares.26913/

    Den Lösungsversuch des TE hätte ich nichtmals versucht, aber vl kann jemand anders aus den Antworten etwas nützliches ableiten?

    Ich gehe weiter kämpfen….gegen Windmühlen



  • Korrekt, wenn ich per ftp:\ anfrage, kommt die Benutzkennungsabfrage als "Antwort"….grrrr

    ..logisch, da sind keine Broadcasts gefragt.

    Ich gehe weiter kämpfen….gegen Windmühlen

    …lass den Quatsch, das hat schon der Don Quijote mit seiner Dulcinea von Toboso nicht hinbekommen.
    Versuchs mal mit IPV6, da ist Broadcast Geschichte.
    Ich schreib dann mal ab...;-)
    Gruß orcape



  • ok…

    Würdest Du mir das kurz näher erklären? Reicht es die Subnets, die auf den NAS sollen auf IPV6 umzustellen, oder wie darf ich das verstehen?

    Eine andere Alternative wäre dann nur, alles was mit dem NAS kommunizieren soll, in ein Subnet zu packen?

    oh man... :-[



  • Reicht es die Subnets, die auf den NAS sollen auf IPV6 umzustellen, oder wie darf ich das verstehen?

    Die ausgehenden Rules noch IPV6 aktivieren, natürlich muss IPV6 auch auf NAS und PC aktiviert sein bzw. das unterstützen.
    Bei IPV 6 ist Multicast aktuell, nicht mehr Broadcast.
    Wissen tu ich 's auch nicht, aber vermuten….;-)



  • Das mit IPV6 scheint aber auch nicht wirklich die Lösung unseres Problems zu sein.
    Samba4 soll wohl auch noch nicht wirklich mit IPV6 umgehen können.
    Als nächstes Problem habe ich mit OpenMediaVault und damit Debian-Wheezy nur ein Samba3.6 an Board.
    Also weiter mit FTP oder NFS…..:(
    Gruß orcape



  • Hi,
    habe das ganze nun nach Änderung der Samba-Version auf dem NAS in den Griff bekommen.
    Weiterhin nur mit IPV4.
    Allerdings ein reines Linux-Netz, zumindest meistens.;)
    Auf den betreffenden Interfaces die Freigabe der Ports 137-139 oder eine any-to-any Rule.
    Folgendes Tutorial….
    http://web.mit.edu/rhel-doc/4/RH-DOCS/rhel-rg-de-4/s1-samba-network-browsing.html
    Hier mal die Samba.conf des NAS….

    ======================= Global Settings =======================
    [global]
    workgroup = orca.net
    server string = NAS
    netbios name = skyflight
    interfaces = 127.0.0.0/8 172.16.7.0/24 192.168.33.0/24 192.168.89.0/24 192.168.155.0/24
    security = user
    domain master = yes
    local master = yes
    wins server = yes
    remote announce = 192.168.89.255 192.168.155.255 192.168.33.255 192.168.55.255
    dns proxy = no
    log level = 0
    syslog = 0
    log file = /var/log/samba/log.%m
    max log size = 1000
    syslog only = yes
    panic action = /usr/share/samba/panic-action %d
    encrypt passwords = true
    passdb backend = tdbsam
    obey pam restrictions = yes
    unix password sync = no
    passwd program = /usr/bin/passwd %u
    passwd chat = *Enter\snew\s*\spassword:* %n\n *Retype\snew\s*\spassword:* %n\n *password\$
    pam password change = yes
    socket options = TCP_NODELAY IPTOS_LOWDELAY
    guest account = nobody
    load printers = no
    disable spoolss = yes
    printing = bsd
    printcap name = /dev/null
    unix extensions = yes
    wide links = no
    create mask = 0777
    directory mask = 0777
    use sendfile = yes
    aio read size = 16384
    aio write size = 16384
    null passwords = no
    time server = no
    wins support = yes
    
    #======================= Share Definitions =======================
    [orca]
    path = /media/0dfd442f-28c4-421b-9b37-32570c3828e8/orca
    guest ok = no
    read only = no
    browseable = yes
    inherit acls = yes
    inherit permissions = no[global]
            workgroup = orca.net
            server string = server orca
            netbios name = orca
            interfaces = 127.0.0.0/8 192.168.33.0/24 192.168.89.0/24 192.168.155.0/24
            security = user
            encrypt passwords = true
            passwd program = /usr/bin/passwd %u
            passwd chat = *Enter\snew\s*\spassword:* %n\n *Retype\snew\s*\spassword:* %n\n *p$
            syslog = 0
            log file = /var/log/samba/log.%m
            max log size = 1000
            os level = 64
            local master = yes
            wins support = No
            wins server = 172.16.7.10
            remote announce = 172.16.7.10 192.168.89.255 192.168.155.255 192.168.33.255
            domain master = No
            dns proxy = No
            usershare allow guests = Yes
            panic action = /usr/share/samba/panic-action %d
            idmap config * : backend = tdb
    
    [orca]
            comment = Home Directories
            path = /home/orca/
            valid users = %S
            admin users = root
            read only = No
            create mask = 0700
            directory mask = 0700
            guest ok = Yes
            public = Yes
            browseable = Yes
    
    ea support = no
    store dos attributes = no
    printable = no
    create mask = 0755
    force create mode = 0644
    directory mask = 0755
    force directory mode = 0755
    hide dot files = yes
    valid users = "orcape","Tino","orca","Kerstin"
    invalid users =
    read list = "Tino","Kerstin"
    write list = "orcape","orca"
    
    

    Hier die Samba.conf eines Linux-Client….

    [global]
            workgroup = orca.net
            server string = server orca
            netbios name = orca
            interfaces = 127.0.0.0/8 192.168.33.0/24 192.168.89.0/24 192.168.155.0/24
            security = user
            encrypt passwords = true
            passwd program = /usr/bin/passwd %u
            passwd chat = *Enter\snew\s*\spassword:* %n\n *Retype\snew\s*\spassword:* %n\n *p$
            syslog = 0
            log file = /var/log/samba/log.%m
            max log size = 1000
            os level = 64
            local master = yes
            wins support = No
            wins server = 172.16.7.10
            remote announce = 172.16.7.10 192.168.89.255 192.168.155.255 192.168.33.255
            domain master = No
            dns proxy = No
            usershare allow guests = Yes
            panic action = /usr/share/samba/panic-action %d
            idmap config * : backend = tdb
    
    [orca]
            comment = Home Directories
            path = /home/orca/
            valid users = %S
            admin users = root
            read only = No
            create mask = 0700
            directory mask = 0700
            guest ok = Yes
            public = Yes
            browseable = Yes
    
    

    Dabei befindet sich das NAS in einer DMZ an OPT1,      Netzwerk    172.16.7.0/24.
    Der Client im LAN,                                                          Netzwerk    192.168.155.0/24
    Die Daten einfach entsprechend anpassen, sollte funktionieren.
    Kleine Fehler in der Config sind mir zu verzeihen…..;)
    Gruß orcape


  • Moderator

    Ich weiß zwar nicht wie ihr von SMB/CIFS auf IPv6 kommt, aber die pfSense war bei solchen Problemen seltenst die Ursache. Meist ließ es sich runterbrechen auf:

    • SAMBA war falsch konfiguriert (bspw. nur das Netz erlaubt, wo er drin steht und das andere Netz nicht)
    • SMB Browsing hat nicht gepasst
    • Freigaben falsch konfiguriert
    • etc etc

    Die pfSense an der Stelle ist höchst dumm zu betrachten und da Falke ja schon sagt, dass ihm Netzbrowsing wurscht ist, sollte dem auch nichts entgegen stehen. Ich hab hier ein NAS (Synology was ja Samba ist) im Netz stehen und keinerlei Problem von verschiedenen Netzen aus drauf zu browsen, selbst per Einwahl und OpenVPN ist das drin - und da wird auch nur geroutet und kein Broadcast oder sonstige dark magic (TM) vollzogen.

    Insofern würde ich wie Rudi im anderen Thread raten, dir mal den FreeNAS genau anzusehen oder/und testweise einfach mal ne dumme Windows Kiste im gleichen Netz freizugeben und mit der mal zu testen (Vorsicht da die Firewall der Kiste). Am Ende ist es gar nicht die pfs (wie so oft) sondern ne ganz andere Stellschraube.

    Grüße



  • Hi JeGr,

    Ich weiß zwar nicht wie ihr von SMB/CIFS auf IPv6 kommt,

    Zitat @flachfalke

    Beim eintichten habe ich mich eher auf die Benutzerechte konzentreirt und nicht an die Broadcast Probleme mit Windows Freigaben geadcht.

    Da es Problem mit den Broadcasts bei IPV6 nicht mehr gibt, hatte ich das als Möglichkeit angesehen.
    Leider habe ich dann hinterher gelesen, das Samba4 da auch noch Schwierigkeiten macht.

    …aber die pfSense war bei solchen Problemen seltenst die Ursache. Meist ließ es sich runterbrechen auf:

    • SAMBA war falsch konfiguriert (bspw. nur das Netz erlaubt, wo er drin steht und das andere Netz nicht)
    • SMB Browsing hat nicht gepasst
    • Freigaben falsch konfiguriert
    • etc etc

    Das habe ich mittlerweile auch herausgefunden.
    Bei mir lag nur das Problem vor, das ich auf dem OMV-NAS noch eine Samba3 Version laufen hatte.
    Diese war nicht dazu zu überreden, mit meinen anderen Debian-Jessie PC ´s zusammen zu arbeiten, da hier schon Samba4 zum Einsatz kommt.
    Jetzt habe ich das OMV (Wheezy) "gezwungen" Samba4 zu akzeptieren, was es mit einigem "murren" auch tut und schon funktioniert das NAS als domain master und die anderen PC ´s spielen mit.
    Danke an @flachfalke, ich hätte ohne seinen Thread das Problem (welches eigentlich keines ist..;-)) wohl weiter vor mir hergeschoben.
    Gruß orcape


  • Moderator

    Diese war nicht dazu zu überreden, mit meinen anderen Debian-Jessie PC ´s zusammen zu arbeiten, da hier schon Samba4 zum Einsatz kommt.

    Ja, 2x Samba unterschiedlicher Versionen… Unschön.

    @flachfalke: aber auch in deinem Fall denke ich, dass es eben eher auf Samba Seite zu suchen ist, nicht an der pfSense. Hoffe du bleibst am Ball.



  • @orcape:

    Danke an @flachfalke,…

    Nicht dafür :)  Aber freut mich, wenn man als Noob auch irgendwie etwas beitragen kann.

    Ich bin absolut kein Crack und auf Linux basierten Dingen noch weniger. Darum zweifel ich grundlegend immer an meinem KnowHow und tue mich schwer ein Thread aufzumachen für Dinge, dir nach meiner Ansicht eigentlich funktionieren müssten.

    Denn eigentlich will ich es nicht verstehen müssen, dass ein NAS keine CIFS über ein Subnet sichtbar bekommt für Windows…, aber nachdem orcape hier schrieb, dass ich besser meine Energie in ein Workaround stecke, hatte ich das vor. Aber bis heute bin ich zeitlich noch nicht dazu gekommen und freue mich grad auch darüber, denn JeGr macht mir doch wieder Hoffnung.

    Den FreeNAS habe ich nämlich nur installiert in Sicht auf HDD und Dateisystem inkl. CIFS Freigaben und Benutzerrechten. SAMBA hab ich nicht konfiguriert/geändert. Hatte ich auch nie Bedarf dran, denn in meinem Netzwerk wo ich es eingerichtet habe bzw die Benutzerrechte und Co. getestet habe, steckte er immer im selben Netz mit allen Clients.

    Aber wenn ich jetzt JeGr

    • SAMBA war falsch konfiguriert (bspw. nur das Netz erlaubt, wo er drin steht und das andere Netz nicht)

    lese und die ersten Zeilen von orcape Samba Config Datei, denke (und HOFFE) ich, dass dort mein Problem liegt. Denn da habe ich nie Hand dran angelegt.
    Für mich allein war ich froh genug, dass ich von den Subnetzen pingen, nslookup und Co erfolgreich ausführen konnte und dachte damit ist die Sache geritzt?
    Aber aus der Zeile hier:

    interfaces = 127.0.0.0/8 172.16.7.0/24 192.168.33.0/24 192.168.89.0/24 192.168.155.0/24

    von orcape entnehme ich peinlichst, dass man im SAMBA die Subnetze eintragen muss!? Zugegeben…sollte es daran liegen freu ich mir ja n Loch wohin, aber da wären wir auch wieder beim newbie meinerseits.

    Hoffe du bleibst am Ball.

    Wie du merkst, habt ihr mir Hoffnung gemacht. Ich bin gespannt…
    Könnt ihr mir noch was mit auf den Weg für morgen geben? Also ich muss im NAS in der Samba Config die nötigen Subnetze hinzufügen und dann könnte es schon klappen?

    Greets!!


  • Moderator

    @flachfalke: ja man kann Samba durchaus beschränken, dass Anfragen nur aus bestimmten Netzen angenommen werden. Ob das bei dir der Fall ist kann ich nicht sagen, aber da wäre zumindest ein Ansatzpunkt :)



  • Gute Nachricht: Problem besteht nicht mehr!
    Schlechte Nachricht: Keine Ahnung warum…

    Hab gestern Abend kreuz und quer gelesen und mir einige Dinge notiert, die ich ändern wollte:

    • NETBIOS Namen müssen kleingeschrieben sein
    • Allowed Hosts hinzufügen im NAS
    • und noch mehr...

    Aber als ich heute auf die "Baustelle" kam, hab ich mit dem NetBios Namen des NAS angefangen und nach dem Speichern, konnte ich ihn über den Windows Explorer erreichen :o
    Zum gegencheck nochmal umgeändert, aber daran lag es wohl nicht. Also: Im Grunde habe ich nichts geändert, aber es klappt nun. Weiß der Geier warum.

    Am Wochenende hatte sich die pfSense zum zweiten mal in 9 Monaten verabschiedet und es fand ein Reboot statt. Aber wenn es daran liegen sollte...kann ich leider auch keine Erklärung dafür finden.
    Natürlich freue ich mich, dass es klappt, aber es kommen die nächsten Probleme.

    Was nicht sein sollte, ist, dass wenn ich von verschiedenen PC's aus auf den NAS pinge, die Latenz stark schwankt. Von realen 1-3ms bis hin zu 150ms und mehr ist alles dabei.

    Auffällig ist der Load average mit circa immer den Werten: 2.69, 2.38, 2.33, die auch mal über 3 klettern.

    Die SystemActivity zeigt das dazu:

    last pid: 69124;  load averages:  2.48,  2.46,  2.37  up 0+03:56:43    19:10:06
    185 processes: 9 running, 161 sleeping, 15 waiting
    
    Mem: 219M Active, 684M Inact, 548M Wired, 272K Cache, 414M Buf, 2461M Free
    Swap: 8192M Total, 8192M Free
    
      PID USERNAME   PRI NICE   SIZE    RES STATE   C   TIME   WCPU COMMAND
      256 root       138   20  6908K  1404K CPU1    1 185:57 96.00% /usr/local/sbin/check_reload_status
       10 root       171 ki31     0K    32K RUN     0  71:11 48.00% [idle{idle: cpu0}]
       10 root       171 ki31     0K    32K RUN     1 131:15 19.97% [idle{idle: cpu1}]
    67561 root        55    0   150M 38068K RUN     0   0:00  1.95% /usr/local/bin/php
        0 root       -16    0     0K   192K sched   0   0:57  0.00% [kernel{swapper}]
       11 root       -32    -     0K   272K RUN     0   0:52  0.00% [intr{swi4: clock}]
       11 root       -68    -     0K   272K RUN     0   0:31  0.00% [intr{irq257: re1}]
    61062 root        76    0   157M 49568K accept  0   0:19  0.00% /usr/local/bin/php{php}
        0 root       -68    0     0K   192K -       0   0:13  0.00% [kernel{dummynet}]
        3 root        -8    -     0K    16K -       0   0:07  0.00% [g_up]
       11 root       -68    -     0K   272K WAIT    0   0:06  0.00% [intr{irq19: ath0 atap}]
    29496 root        76   20  8296K  1888K wait    0   0:06  0.00% /bin/sh /var/db/rrd/updaterrd.sh
        4 root        -8    -     0K    16K -       0   0:04  0.00% [g_down]
       13 root       -16    -     0K    16K -       0   0:03  0.00% [yarrow]
       11 root       -32    -     0K   272K WAIT    0   0:02  0.00% [intr{swi4: clock}]
    84962 root        64   20 12160K  7120K select  0   0:02  0.00% /usr/local/sbin/ntpd -g -c /var/etc/ntpd.
    42964 root        64   20  5784K  1484K select  0   0:02  0.00% /usr/local/sbin/apinger -c /var/etc/aping
    55780 root        44    0 24232K  4600K kqread  0   0:02  0.00% /usr/local/sbin/lighttpd -f /var/etc/ligh
    

    alle paar Sekunden kommen die "savevoucher" und "filter_sync" PIDs dazu

      PID USERNAME   PRI NICE   SIZE    RES STATE   C   TIME   WCPU COMMAND
      256 root       134   20  6908K  1404K RUN     1 186:31 77.98% /usr/local/sbin/check_reload_status
    79333 root       128   20   152M 33476K CPU0    0   0:00 53.96% /usr/local/bin/php -f /etc/rc.filter_sync
       10 root       171 ki31     0K    32K RUN     1 131:41 43.99% [idle{idle: cpu1}]
    68114 root       126   20   162M 50864K RUN     0   0:03 41.99% /usr/local/bin/php -f /etc/rc.savevoucher
    

    Über die Suche nach "/usr/local/sbin/check_reload_status" kommen zig Threads hier im Forum, auf die es keine mir Verständliche Lösung gibt. Manche haben aufgrund dies die pfSense neu aufgesetzt oder geupdatet.
    Einn Thread gibt es, wo alle 5 Minuten die Voucher und Firewall Regeln neu gesynct werden, was ihm auffällig vorkam. Bei mir, passiert das alle paar Sekunden!

    Feb 10 18:19:08 	check_reload_status: Synching vouchers
    Feb 10 18:19:07 	check_reload_status: Synching vouchers
    Feb 10 18:18:45 	check_reload_status: Syncing firewall
    Feb 10 18:18:42 	check_reload_status: Syncing firewall
    Feb 10 18:18:38 	check_reload_status: Synching vouchers
    Feb 10 18:18:38 	check_reload_status: Synching vouchers
    Feb 10 18:18:14 	check_reload_status: Syncing firewall
    Feb 10 18:18:11 	check_reload_status: Syncing firewall
    Feb 10 18:18:05 	check_reload_status: Synching vouchers
    Feb 10 18:18:05 	check_reload_status: Synching vouchers
    Feb 10 18:17:44 	check_reload_status: Syncing firewall
    Feb 10 18:17:41 	check_reload_status: Syncing firewall
    Feb 10 18:17:37 	check_reload_status: Synching vouchers
    Feb 10 18:17:37 	check_reload_status: Synching vouchers
    Feb 10 18:17:05 	check_reload_status: Synching vouchers
    Feb 10 18:17:05 	check_reload_status: Synching vouchers
    Feb 10 18:16:43 	check_reload_status: Syncing firewall
    Feb 10 18:16:40 	check_reload_status: Syncing firewall
    Feb 10 18:16:36 	check_reload_status: Synching vouchers
    Feb 10 18:16:36 	check_reload_status: Synching vouchers
    Feb 10 18:16:09 	check_reload_status: Syncing firewall
    Feb 10 18:16:08 	check_reload_status: Syncing firewall
    Feb 10 18:16:04 	check_reload_status: Synching vouchers
    Feb 10 18:16:04 	check_reload_status: Synching vouchers
    Feb 10 18:15:41 	check_reload_status: Syncing firewall
    Feb 10 18:15:39 	check_reload_status: Syncing firewall
    Feb 10 18:15:35 	check_reload_status: Synching vouchers
    Feb 10 18:15:35 	check_reload_status: Synching vouchers
    Feb 10 18:15:14 	check_reload_status: Syncing firewall
    Feb 10 18:15:12 	check_reload_status: Syncing firewall
    Feb 10 18:15:03 	check_reload_status: Synching vouchers
    Feb 10 18:15:03 	check_reload_status: Synching vouchers
    Feb 10 18:14:38 	check_reload_status: Syncing firewall
    Feb 10 18:14:35 	check_reload_status: Syncing firewall
    Feb 10 18:14:31 	check_reload_status: Synching vouchers
    Feb 10 18:14:31 	check_reload_status: Synching vouchers
    Feb 10 18:14:02 	check_reload_status: Synching vouchers
    Feb 10 18:14:02 	check_reload_status: Synching vouchers
    Feb 10 18:13:33 	check_reload_status: Syncing firewall
    Feb 10 18:13:32 	check_reload_status: Syncing firewall
    Feb 10 18:13:23 	check_reload_status: Synching vouchers
    Feb 10 18:13:23 	check_reload_status: Synching vouchers
    Feb 10 18:12:49 	check_reload_status: Synching vouchers
    Feb 10 18:12:49 	check_reload_status: Synching vouchers
    Feb 10 18:12:32 	check_reload_status: Syncing firewall
    Feb 10 18:12:26 	check_reload_status: Syncing firewall
    Feb 10 18:12:22 	check_reload_status: Synching vouchers
    Feb 10 18:12:22 	check_reload_status: Synching vouchers
    Feb 10 18:11:56 	check_reload_status: Syncing firewall
    Feb 10 18:11:55 	check_reload_status: Syncing firewall
    Feb 10 18:11:46 	check_reload_status: Synching vouchers
    Feb 10 18:11:46 	check_reload_status: Synching vouchers
    Feb 10 18:11:29 	check_reload_status: Syncing firewall
    Feb 10 18:11:25 	check_reload_status: Syncing firewall
    Feb 10 18:11:21 	check_reload_status: Synching vouchers
    Feb 10 18:11:21 	check_reload_status: Synching vouchers
    Feb 10 18:10:46 	check_reload_status: Synching vouchers
    Feb 10 18:10:46 	check_reload_status: Synching vouchers
    Feb 10 18:10:29 	check_reload_status: Syncing firewall
    Feb 10 18:10:24 	check_reload_status: Syncing firewall
    Feb 10 18:10:20 	check_reload_status: Synching vouchers
    Feb 10 18:10:20 	check_reload_status: Synching vouchers
    Feb 10 18:09:42 	check_reload_status: Synching vouchers
    Feb 10 18:09:42 	check_reload_status: Synching vouchers
    Feb 10 18:09:27 	check_reload_status: Syncing firewall
    Feb 10 18:09:24 	check_reload_status: Syncing firewall
    Feb 10 18:09:20 	check_reload_status: Synching vouchers
    Feb 10 18:09:20 	check_reload_status: Synching vouchers
    Feb 10 18:08:37 	check_reload_status: Synching vouchers
    Feb 10 18:08:36 	check_reload_status: Synching vouchers
    Feb 10 18:08:24 	check_reload_status: Syncing firewall
    Feb 10 18:08:20 	check_reload_status: Syncing firewall
    Feb 10 18:08:15 	check_reload_status: Synching vouchers
    Feb 10 18:08:14 	check_reload_status: Synching vouchers
    Feb 10 18:07:40 	check_reload_status: Syncing firewall
    Feb 10 18:07:39 	check_reload_status: Syncing firewall
    Feb 10 18:07:30 	check_reload_status: Synching vouchers
    Feb 10 18:07:30 	check_reload_status: Synching vouchers
    Feb 10 18:07:21 	check_reload_status: Syncing firewall
    Feb 10 18:07:18 	check_reload_status: Syncing firewall
    Feb 10 18:07:14 	check_reload_status: Synching vouchers
    Feb 10 18:07:14 	check_reload_status: Synching vouchers
    Feb 10 18:06:29 	check_reload_status: Synching vouchers
    Feb 10 18:06:29 	check_reload_status: Synching vouchers
    Feb 10 18:06:18 	check_reload_status: Syncing firewall
    Feb 10 18:06:17 	check_reload_status: Syncing firewall
    Feb 10 18:06:07 	check_reload_status: Synching vouchers
    Feb 10 18:06:07 	check_reload_status: Synching vouchers
    Feb 10 18:05:29 	check_reload_status: Synching vouchers
    Feb 10 18:05:28 	check_reload_status: Synching vouchers
    Feb 10 18:05:21 	check_reload_status: Syncing firewall
    Feb 10 18:05:17 	check_reload_status: Syncing firewall
    Feb 10 18:05:06 	check_reload_status: Synching vouchers
    Feb 10 18:05:06 	check_reload_status: Synching vouchers
    Feb 10 18:04:34 	check_reload_status: Syncing firewall
    Feb 10 18:04:28 	check_reload_status: Syncing firewall
    Feb 10 18:04:24 	check_reload_status: Synching vouchers
    Feb 10 18:04:24 	check_reload_status: Synching vouchers
    Feb 10 18:04:09 	check_reload_status: Syncing firewall
    Feb 10 18:04:04 	check_reload_status: Synching vouchers
    Feb 10 18:04:04 	check_reload_status: Synching vouchers
    Feb 10 18:03:59 	check_reload_status: Reloading filter
    Feb 10 18:03:59 	check_reload_status: Syncing firewall
    Feb 10 18:03:23 	check_reload_status: Synching vouchers
    Feb 10 18:03:23 	check_reload_status: Synching vouchers
    Feb 10 18:03:08 	check_reload_status: Syncing firewall
    Feb 10 18:03:06 	check_reload_status: Syncing firewall
    Feb 10 18:03:02 	check_reload_status: Synching vouchers
    Feb 10 18:03:02 	check_reload_status: Synching vouchers
    Feb 10 18:02:28 	check_reload_status: Syncing firewall
    Feb 10 18:02:26 	check_reload_status: Syncing firewall
    Feb 10 18:02:14 	check_reload_status: Synching vouchers
    Feb 10 18:02:14 	check_reload_status: Synching vouchers
    Feb 10 18:02:07 	check_reload_status: Syncing firewall
    Feb 10 18:02:04 	check_reload_status: Syncing firewall
    Feb 10 18:02:01 	check_reload_status: Synching vouchers
    Feb 10 18:02:00 	check_reload_status: Synching vouchers
    Feb 10 18:01:14 	check_reload_status: Syncing firewall
    Feb 10 18:01:12 	check_reload_status: Synching vouchers
    Feb 10 18:01:12 	check_reload_status: Synching vouchers
    Feb 10 18:01:12 	check_reload_status: Syncing firewall
    Feb 10 18:01:01 	check_reload_status: Syncing firewall
    Feb 10 18:00:36 	check_reload_status: Synching vouchers
    Feb 10 18:00:36 	check_reload_status: Synching vouchers
    Feb 10 18:00:16 	check_reload_status: Syncing firewall
    Feb 10 18:00:12 	check_reload_status: Syncing firewall
    

    An Services habe ich folgende:

    apinger 	
    captiveportal 	xx
    captiveportal 	xy
    cron 	
    dhcpd 	
    dnsmasq 	
    ntpd 
    radiusd 
    squid 	
    
    

    Und in einem Thread kam man darauf, dass es vielleicht daran liegen kann, dass sich ein regestrierter Voucher auf mehreren Netzen (versucht) einzuloggen, was zu einem Problem dieser Art führen kann? Das konnte ich so direkt nicht bestätigen.

    Im Grunde habe ich keinen Schimmer, wo ich anfangen muss. Das Problem wird die CPU Last sein? Aber die Ursache kann x-Möglicheiten sein, oder?

    Hier mal ein Ping von der pfSense aus zur Veranschaulichung

    PING 192.168.70.3 (192.168.70.3) from 192.168.60.1: 56 data bytes
    64 bytes from 192.168.70.3: icmp_seq=0 ttl=128 time=3.597 ms
    64 bytes from 192.168.70.3: icmp_seq=1 ttl=128 time=7.451 ms
    64 bytes from 192.168.70.3: icmp_seq=2 ttl=128 time=71.085 ms
    64 bytes from 192.168.70.3: icmp_seq=3 ttl=128 time=91.081 ms
    64 bytes from 192.168.70.3: icmp_seq=4 ttl=128 time=58.562 ms
    64 bytes from 192.168.70.3: icmp_seq=5 ttl=128 time=53.692 ms
    64 bytes from 192.168.70.3: icmp_seq=6 ttl=128 time=54.931 ms
    64 bytes from 192.168.70.3: icmp_seq=7 ttl=128 time=0.878 ms
    64 bytes from 192.168.70.3: icmp_seq=8 ttl=128 time=97.305 ms
    64 bytes from 192.168.70.3: icmp_seq=9 ttl=128 time=46.065 ms
    
    --- 192.168.70.3 ping statistics ---
    10 packets transmitted, 10 packets received, 0.0% packet loss
    round-trip min/avg/max/stddev = 0.878/48.465/97.305/32.939 ms
    

    Die Sense 2.1.5 läuft auf einer APU1C mit 4GB Ram. Angeschlossen ist sie an ein Cisco 10 Port managed Switch auf dem zwei WANs ankommen und in der pfSense zum MultiWan mutieren. Einmal aus einem DSL Modem im Bridgemode mit PPPOE und Nr.2 ist ein LTE Router per DHCP.
    Dazu läuft wie man bei Services sehen kann Squid und zwei CP. Ein Gästenetz und ein HeimWlan. Beide via Voucher Zugang.
    Alle "wichtigen" Clients sind verkabelt.

    Passt zwar nicht mehr in den Thread, aber möchte auch nicht einen aufmachen. Gibt zu der CPU Load Sache schon so viele. SChlau werd ich aus keinem.

    Zwar läuft das Netzwerk, mit den beschriebenen Einschränkungen, aber eine Endlösung stellt es so nicht dar. Die Übertragungsrate auf den NAS z.B. bleibt bei 6MB/Sekunde stehen, obwohl dazwischen nur ein (GB) Switch ist. Das kann es ja nicht sein ;(

    Aber aus Angst das Netz nun bei versuchen komplett zu killen, würde ich mit einer zweiten Apu anfangen es neu zu gestalten.
    Oder ihr habt den einen heissen Ansatz, was da bei mir falsch läuft.

    Greets,


  • Moderator

    Da sich mit der neuen Version so einiges geändert hat, würde ich eher sagen mit 2.2 neu aufsetzen, dann hast du hoffentlich auch keine Stör- oder Seiteneffekte mehr, die sich jetzt vielleicht erledigt haben. Wenn du eh noch relativ am Anfang bist, würde ich dann auch gleich auf der neuen Codebasis anfangen aufzusetzen und nicht mit dem alten Stand - gerade was CP etc. angeht, wurde da ja einiges gestrickt.



  • Hi flachfalke,
    nur mal noch so als Hinweis zu Samba und deren config…
    Wenn Du die smb.conf händisch bearbeitest, weil da z.B. im GUI des FreeNAS auf Grund von Versions-Unterschieden keine Einstellungsmöglichkeiten sind und anschließen den Samba-Server neu startest ist das kein Problem.
    Dann solltest Du aber nicht mehr über den GUI Änderungen vornehmen, der überschreibt sonst Deine händische Config.
    Gruß orcape