DSM 4.0 Beta - Erfahrungen, Probleme, Bugs

Status
Für weitere Antworten geschlossen.

Trolli

Benutzer
Mitglied seit
12. Jul 2007
Beiträge
9.848
Punkte für Reaktionen
1
Punkte
0
Ich denke, das sollte nach wie vor funktionieren. Zumindest hab ich noch nichts gegenteiliges gehört...
 

joku

Benutzer
Mitglied seit
06. Mrz 2011
Beiträge
6.664
Punkte für Reaktionen
2
Punkte
164
Da mir halt leider der Vergleich zum Betrieb mit DSM 3.2 fehlt, würde ich jetzt mal ein Downgrade auf DSM 3.2 machen
schau die mal die Datei in
/etc/VERSION
und
/etc.defaults/VERSION
an, die /etc.defaults/VERSION wird geladen nach dem 2x reset
*ohne Gewehr*
Gruß Jo
 

oetzi

Benutzer
Mitglied seit
20. Dez 2011
Beiträge
8
Punkte für Reaktionen
0
Punkte
1
Moin moin,

nachdem das mein erster Post hier im Forum ist (bisher war ich nur sehr interessierter Leser) zunächst mal ein herzliches Grüß Gott und jetzt schon mal vielen Dank für die zahlreichen nützlichen Tipps, die ich hier bis jetzt finden konnte.

Sollte das Problem hier schon mal irgendwo diskutiert worden sein muss ich zu meiner Verteidigung sagen: ich habe ca. 1,5 Stunden lang die Suche bemüht und nix passendes gefunden. Zwar diesen Thread, aber da steht auch keine Lösung. :S

Als altes Spielkind musste ich natürlich auch die 4.0 Beta ausprobieren. Draufspielen war kein Problem. Scheint alles funktioniert zu haben. Dann fing allerdings die Thumbnail-Erzeugung neu an. Bei 40.000 Bilder wollte ich das meiner 210j (und meinen Nerven) nicht antun. Also photo-Ordner erst mal umbenannt und einen neuen angelegt.

Dann wollte ich die Fotos mit dem Foto Uploader aus dem DSAssistant neu hochladen. Das funktionierte eine Weile auch recht gut. Mittlerweile ist es aber regelmäßig so, dass die Verbindung zur DiskStation beim Upload abbricht. Mit dem DSM 3.2 hatte ich das Problem nie.

Anhang anzeigen 7521

Die Weboberfläche der PhotoStation und des DSM kann ich nach einer solchen Meldung ohne Probleme erreichen. Abhilfe für den Foto Uploader schafft dann nur, wenn ich den Client-Rechner und die DiskStation neu starten. Kann dann aber durchaus sein, dass das Problem sofort (oder nach einigen Hundert Bildern) erneut auftritt. :(

Nen Bug bei Synology habe ich schon aufgemacht (Bug-ID #4059). Mal sehen, was die dazu sagen.

Hier noch ein paar technische Details:
- DiskStation 210j mit DSM 4.0 Beta
- Aktueller DSAssistant (kann grad net die genaue Version sagen, da ich nicht daheim bin. Ist aber vor ca. 1 Woche runtergeladen worden)
- Gigabit-Netzwerk (JUMBO-Frame ist sowohl auf der DS, als auch auf dem Client deaktiviert)
- Client-Rechner: Windows 7 64Bit mit 12GB Ram
- Rechner ist mit der DS über eine FritzBox 6360 verbunden

Zu dem Thema /var/log/messages:
Mir ist auch aufgefallen, dass da jetzt wesentlich mehr drin steht als noch mit der 3.2er-DSM-Version. Ich war davon ausgegangen, dass sie vielleicht einfach das Log-Level in der Beta etwas hochgedreht haben. Na ja, da will ich ihnen mal net den Kopf abreißen. Immerhin ist es im Moment noch offiziell ne Beta. Da erwarte ich noch nicht, dass alles funktioniert. ;)

So,
ich antworte mir dann mal selbst. ;)
Problem bei mir war anscheinend, dass meine Systempartition voll war (es ist einfach keine gute Idee seinen User-Apache loggen zu lassen ;)). Habs festgestellt, als ich frustriert wieder nen downgrade auf die 3.2 machen wollte. Systempartition freigeräumt, alles funzt. ;)
 

BigBlue007

Benutzer
Mitglied seit
01. Feb 2012
Beiträge
34
Punkte für Reaktionen
0
Punkte
0
So, ich bin inzw. auch weitergekommen. :) Downgrade auf 3.2 hat problemlos funktioniert. Und jetzt ist alles, was im Log bei einem Wakeup zu sehen ist, dieses:

Code:
Feb  6 19:40:59 scemd: SCEMD: disk 1 wake up from hibernation
Feb  6 19:41:17 scemd: SCEMD: disk 2 wake up from hibernation

Also eindeutig ein DSM 4 Beta - Problem. Nachtrag zum Ticket ist raus.
 

BrokenPipe

Benutzer
Mitglied seit
07. Feb 2012
Beiträge
1
Punkte für Reaktionen
0
Punkte
0
Hi,
ich habe auch das write-cache Problem. Im DSM werden die Haken immer wieder entfernt, also hab ich das ganze per ssh ausprobiert:

Rich (BBCode):
DiskStation> hdparm -W 1 /dev/sda

/dev/sda:
 setting drive write-caching to 1 (on)
 write-caching =  1 (on)
DiskStation> hdparm -W 1 /dev/sdb

/dev/sdb:
 setting drive write-caching to 1 (on)
 write-caching =  0 (off)
DiskStation> hdparm -W /dev/sda  

/dev/sda:
 write-caching =  1 (on)
DiskStation> hdparm -W /dev/sdb

/dev/sdb:
 write-caching =  0 (off)

Also bei sda konnte ich den write-cache einschalten aber bei sdb nicht und das DSM zeigt immer noch keine Haken an.

Wurde das Problem schon an Synology gemeldet?

DS211j
2x WD20EARS
 

Matthieu

Benutzer
Mitglied seit
03. Nov 2008
Beiträge
13.222
Punkte für Reaktionen
88
Punkte
344
Wurde das Problem schon an Synology gemeldet?
Jeder sollte sein Problem selbst an Synology melden, denn es können unterschiedliche Ursachen sein und mit etwas Glück kann man auch schon einen Patch testen.

MfG Matthieu
 

Mikel

Benutzer
Mitglied seit
03. Okt 2008
Beiträge
11
Punkte für Reaktionen
0
Punkte
0
Im Standby (nur Status-LED ist an und blinkt) meiner DS212+ läuft der Lüfter jetzt immer noch, unter Einstellungen in "Energie" hab ich "stiller Modus" und auch "niedriger Energiestatus" ausporbiert, keine Änderung. Könnte schwören, dass das unter 3.2 nicht so war, oder vertue ich mich da?

Der läuft grundsätzlich immer !

Ich habe erst jetzt im Forum danach gesucht, weils mir erst gestern aufgefallen ist.

Bei meiner 211+ war es definitiv unter der 3.2 so, dass der Lüfter nach kurzer Zeit auch ausgegangen ist, wenn die DS im Standby (incl. HDs) war.
Dies war auch im Sommer so, wenn die Raumtemperatur höher war und sollte demnach jetzt erst recht so sein.
Die Einstellung im Reiter Energie ist/war auf "niedriger Energiestatus".

Jetzt, unter der 4.0 Beta, dreht der Lüfter immer, egal welche Einstellung.
Schade, denn er ist zwar recht leise, aber vorher war es eben noch besser.
 

Puppetmaster

Benutzer
Sehr erfahren
Mitglied seit
03. Feb 2012
Beiträge
18.991
Punkte für Reaktionen
629
Punkte
484
Ich habe erst jetzt im Forum danach gesucht, weils mir erst gestern aufgefallen ist.

Bei meiner 211+ war es definitiv unter der 3.2 so, dass der Lüfter nach kurzer Zeit auch ausgegangen ist, wenn die DS im Standby (incl. HDs) war.
Dies war auch im Sommer so, wenn die Raumtemperatur höher war und sollte demnach jetzt erst recht so sein.
Die Einstellung im Reiter Energie ist/war auf "niedriger Energiestatus".

Jetzt, unter der 4.0 Beta, dreht der Lüfter immer, egal welche Einstellung.
Schade, denn er ist zwar recht leise, aber vorher war es eben noch besser.


Danke für diesen Hinweis!
Irgendwer hatte hier bereits geschrieben, daß der Lüfter der DS212+ auch im StandBy dreht. Das kann ich nicht bestätigen! Mir war es von Anfang an wichtig, daß bei meiner DS212+ der Lüfter im Standby eben NICHT läuft (wozu auch? CPU-Last gleich null, Systemtemperatur laut Sensor um die 50°C - also völlig ok). Ich habe allerdings 2 2,5 Zoll Platten verbaut, die erzeugen auch wenig Abwärme.
Es ist mir im Übrigen auch noch kein Unterschied bei den 3 Energiemodi aufgefallen. Damals (DSM 3.0 ??) als es nur 2 Einstellungen '3,5 Zoll' und '2,5 Zoll' gab, da merkte man einen Unterschied. Seit es diese drei Optionen gibt, nicht mehr.

Wenn also tatsächlich auch in der Final der Lüfter ständig laufenn würde, fände ich das sehr bedauerlich. Gut, er ist nicht laut, aber man hört ihn doch. Und notwendig wird es auch nicht sein... Da ärgere ich mich bei meinem *ähem* QNAP NAS schon drüber, daß der Lüfter niemals ausgeht!

Bei meiner DS110j, bei der ich die Beta seit Erscheinen ausprobiere, geht der Lüfter übrigens auch mit Beta 4.0 aus!

Ich habe da auch noch ein nervendes Winterproblem entdeckt - allerdings noch bei DSM3.2, wird aber bei der 4.0 sicher nicht ander sein:
Wenn die DS212+ läuft, also nicht im StandBy ist, und ich mal für ein paar Minuten die Türe zum Lüften öffne, wird der Guten offenbar so kalt, daß der Lüfter ausgeht. Zumindest bekomme ich die Warntöne und je nach dem 2-8 Mails mit Lüfter angehalten/Lüfter wieder gestartet.
Da sollte vielleicht auch nochmal ein Tempeprturabgleich auf Softwareebene erfolgen, sprich: wenn Lüfter anhält, Raum-/Systemtemperatur aber < 20°C, dann ist das kein Grund zur Besorgnis!
 

itari

Benutzer
Mitglied seit
15. Mai 2008
Beiträge
21.900
Punkte für Reaktionen
14
Punkte
0
die Geschichte mit der intelligenten Temperatursteuerung solltest den Synology-Entwicklern vorschlagen, das ist ganz sicherlich ein Wunsch, den viele hier haben.

Itari
 

Trolli

Benutzer
Mitglied seit
12. Jul 2007
Beiträge
9.848
Punkte für Reaktionen
1
Punkte
0
Mir ist gerade ein Problem mit Time Backup aufgefallen. Hat jemand schonmal etwas ähnliches beobachtet?
Aus der /var/log/messages:
Feb 8 12:05:02 kernel: [324992.326368] EXT4-fs: can't allocate buddy meta groupFeb 8 12:05:02 kernel: [324992.331553] EXT4-fs (dm-1): failed to initalize mballoc (-12)
Feb 8 12:05:02 kernel: [324992.338100] EXT4-fs (dm-1): mount failed
Feb 8 12:05:02 kernel: [324992.409453] BUG: unable to handle kernel NULL pointer dereference at 00000000000001e0
Feb 8 12:05:02 kernel: [324992.409827] IP: [<ffffffff8112ea87>] ext4_clear_inode+0x17/0x40
Feb 8 12:05:02 kernel: [324992.409827] PGD 684c067 PUD 17988067 PMD 0
Feb 8 12:05:02 kernel: [324992.409827] Oops: 0000 [#1] SMP
Feb 8 12:05:02 kernel: [324992.409827] last sysfs file: /sys/block/md2/md/dev-sdc3/slot
Feb 8 12:05:02 kernel: [324992.409827] CPU 0
Feb 8 12:05:02 kernel: [324992.409827] Modules linked in: snd_pcm_oss snd_mixer_oss snd_usb_audio snd_pcm snd_timer snd_hwdep snd_usbmidi_lib snd_rawmidi snd_seq_device snd snd_page_alloc soundcore cifs udf isofs loop usbhid hid usblp usb_storage uhc
Feb 8 12:05:02 kernel: [324992.409827] Process mount (pid: 7702, threadinfo ffff880022104000, task ffff88003df26870)
Feb 8 12:05:02 kernel: [324992.409827] Stack:
Feb 8 12:05:02 kernel: [324992.409827] ffff88001252a0c0 ffffffff810b3f7f ffff88001252a0c0 ffffffff810b419c
Feb 8 12:05:02 kernel: [324992.409827] <0> ffff880019fa0ec0 ffffffff810b177d 0000000000008001 00000000ffffffff
Feb 8 12:05:02 kernel: [324992.409827] <0> ffff880022388000 ffffffff81436ca0 ffffffff813386e0 0000000000000001
Feb 8 12:05:02 kernel: [324992.409827] Call Trace:
Feb 8 12:05:02 kernel: [324992.409827] [<ffffffff810b3f7f>] ? clear_inode+0x5f/0xe0
Feb 8 12:05:02 kernel: [324992.409827] [<ffffffff810b419c>] ? generic_drop_inode+0x2c/0x60
Feb 8 12:05:02 kernel: [324992.409827] [<ffffffff810b177d>] ? shrink_dcache_for_umount_subtree+0x18d/0x260
Feb 8 12:05:02 kernel: [324992.409827] [<ffffffff810b1879>] ? shrink_dcache_for_umount+0x29/0x50
Feb 8 12:05:02 kernel: [324992.409827] [<ffffffff8109eaa5>] ? generic_shutdown_super+0x25/0x100
Feb 8 12:05:02 kernel: [324992.409827] [<ffffffff8109eba9>] ? kill_block_super+0x29/0x50
Feb 8 12:05:02 kernel: [324992.409827] [<ffffffff8112cf29>] ? ext4_kill_sb+0x9/0x30
Feb 8 12:05:02 kernel: [324992.409827] [<ffffffff8109f028>] ? deactivate_locked_super+0x58/0x80
Feb 8 12:05:02 kernel: [324992.409827] [<ffffffff8109fde1>] ? get_sb_bdev+0x191/0x1a0
Feb 8 12:05:02 kernel: [324992.409827] [<ffffffff81130b30>] ? ext4_fill_super+0x0/0x2520
Feb 8 12:05:02 kernel: [324992.409827] [<ffffffff8109f0a6>] ? vfs_kern_mount+0x56/0xf0
Feb 8 12:05:02 kernel: [324992.409827] [<ffffffff8109f1a3>] ? do_kern_mount+0x53/0x120
Feb 8 12:05:02 kernel: [324992.409827] [<ffffffff810b976f>] ? do_mount+0x4ff/0x810
Feb 8 12:05:02 kernel: [324992.409827] [<ffffffff810d9d19>] ? compat_sys_mount+0xa9/0x290
Feb 8 12:05:02 kernel: [324992.409827] [<ffffffff8102a052>] ? ia32_sysret+0x0/0x5
Feb 8 12:05:02 kernel: [324992.409827] Code: db 3b 81 48 89 ef e8 79 b2 f8 ff e9 db fb ff ff 66 66 66 90 53 48 89 fb e8 e7 12 01 00 48 8b 83 40 01 00 00 48 8b 80 88 02 00 00 <48> 8b b8 e0 01 00 00 48 85 ff 74 0d 48 8d b3 78 02 00 00 5b e9
Feb 8 12:05:02 kernel: [324992.409827] RIP [<ffffffff8112ea87>] ext4_clear_inode+0x17/0x40
Feb 8 12:05:02 kernel: [324992.409827] RSP <ffff880022105cb8>
Feb 8 12:05:02 kernel: [324992.409827] CR2: 00000000000001e0
Feb 8 12:05:02 kernel: [324992.775209] ---[ end trace b404809f1be7bc3a ]---
Feb 8 12:05:02 timebkp: [7684]BK_ERR:mount snapshot [/dev/mapper/vol1-snap0] on mount_point [/tmp/timebkp_7684/volume1] failed
Feb 8 12:05:02 kernel: [324992.910581] device-mapper: ioctl: unable to remove open device vol1-snap0
Feb 8 12:05:02 timebkp: [7684]BK_ERR:delete snapshot device vol1-snap0 failed
Feb 8 12:05:02 timebkp: [7684]BK_ERR:remove loop device /dev/loop0 fail: Device or resource busy(16) : 16(Device or resource busy)
Feb 8 12:05:02 timebkp: [7684]BK_WARN:creating snapshot of volume1 failed
Feb 8 12:05:02 timebkp: [7684]BK_WARN:no snapshot has been created
 

itari

Benutzer
Mitglied seit
15. Mai 2008
Beiträge
21.900
Punkte für Reaktionen
14
Punkte
0
@trolli,

kannst du den Fehler reproduzieren? und tritt er auch nach einem Neustart noch auf?

Itari
 

Trolli

Benutzer
Mitglied seit
12. Jul 2007
Beiträge
9.848
Punkte für Reaktionen
1
Punkte
0
Ist jetzt zum ersten Mal aufgetreten. Ich werde das weiter beobachten und berichten...
 

rauppe31

Benutzer
Mitglied seit
06. Jun 2011
Beiträge
2.734
Punkte für Reaktionen
0
Punkte
82
Hab jetzt auch mal in meine Log-Datei geschaut.
Ich habe dort auch komische Einträge von Time Backup entdeckt:

Feb 8 12:00:27 timebkp: [15614]BK_ERR:div trap
Feb 8 12:00:32 timebkp: [15614]BK_ERR:div trap
Feb 8 12:00:33 timebkp: [15614]BK_ERR:div trap
Feb 8 12:00:44 timebkp: [15614]BK_ERR:div trap
Feb 8 12:00:45 timebkp: [15614]BK_ERR:div trap
Feb 8 12:00:46 timebkp: [15614]BK_ERR:div trap
Feb 8 12:00:47 timebkp: [15614]BK_ERR:div trap
Feb 8 12:00:48 timebkp: [15614]BK_ERR:div trap
Feb 8 12:00:49 timebkp: [15614]BK_ERR:div trap
Feb 8 12:00:50 timebkp: [15614]BK_ERR:div trap
Feb 8 12:00:53 timebkp: [15614]BK_ERR:div trap
Feb 8 12:00:54 timebkp: [15614]BK_ERR:div trap
Feb 8 12:00:55 timebkp: [15614]BK_ERR:div trap
Feb 8 12:00:56 timebkp: [15614]BK_ERR:div trap
Feb 8 12:00:57 timebkp: [15614]BK_ERR:div trap
Feb 8 12:01:04 timebkp: [15614]BK_ERR:div trap
Feb 8 12:01:05 timebkp: [15614]BK_ERR:div trap
Feb 8 12:01:08 timebkp: [15614]BK_ERR:div trap
Feb 8 12:01:09 timebkp: [15614]BK_ERR:div trap
Feb 8 12:01:10 timebkp: [15614]BK_ERR:div trap
Feb 8 12:01:14 timebkp: [15614]BK_ERR:div trap
Feb 8 12:01:15 timebkp: [15614]BK_ERR:div trap
Feb 8 12:01:16 timebkp: [15614]BK_ERR:div trap
Feb 8 12:01:18 timebkp: [15614]BK_ERR:div trap
Feb 8 12:01:20 timebkp: [15614]BK_ERR:div trap
Feb 8 12:01:21 timebkp: [15614]BK_ERR:div trap
Feb 8 12:01:22 timebkp: [15614]BK_ERR:div trap
Das passiert jedes mal, wenn Time Backup sich startet.
Jemand eine Idee, was das sein könnte?
 

Trolli

Benutzer
Mitglied seit
12. Jul 2007
Beiträge
9.848
Punkte für Reaktionen
1
Punkte
0
Die Einträge hab ich auch - ich hab das mal als 'normal' angesehen. Aber was damit gemeint ist, weiß ich nicht wirklich...
 

trox

Benutzer
Mitglied seit
20. Jul 2009
Beiträge
18
Punkte für Reaktionen
0
Punkte
0
Hallo, habe eben dieses Mail von meiner DS erhalten...

The hard disk 4 on DiskStation had an I/O error, but it is working properly now after several retries. It might have been caused by bad sectors. If this error occurs again, please back up your data and run the S.M.A.R.T. test on your hard drive to examine the hard drive status.

Im Dmesg-Log steht folgendes:

[19441.017284] ata4.00: exception Emask 0x0 SAct 0x1 SErr 0x0 action 0x6 frozen
[19441.024346] ata4.00: failed command: READ FPDMA QUEUED
[19441.029497] ata4.00: cmd 60/48:00:00:b3:ba/00:00:85:00:00/40 tag 0 ncq 36864 in
[19441.029502] res 40/00:00:00:fb:00/00:00:00:00:00/a0 Emask 0x4 (timeout)
[19441.044197] ata4.00: status: { DRDY }
[19441.047865] ata4: hard resetting link
[19441.507325] ata4: SATA link up 3.0 Gbps (SStatus 123 SControl 300)
[19441.557376] ata4.00: configured for UDMA/133
[19441.561653] ata4.00: device reported invalid CHS sector 0
[19441.567064] sd 3:0:0:0: [sdd] Result: hostbyte=0x00 driverbyte=0x08
[19441.573338] sd 3:0:0:0: [sdd] Sense Key : 0xb [current] [descriptor]
[19441.579711] Descriptor sense data with sense descriptors (in hex):
[19441.585891] 72 0b 00 00 00 00 00 0c 00 0a 80 00 00 00 00 00
[19441.592317] 00 00 00 00
[19441.595562] sd 3:0:0:0: [sdd] ASC=0x0 ASCQ=0x0
[19441.600012] sd 3:0:0:0: [sdd] CDB: cdb[0]=0x28: 28 00 85 ba b3 00 00 00 48 00
[19441.607203] end_request: I/O error, dev sdd, sector 2243605248
[19441.613044] read error, md2, sdd3 index [3], sector 6702498048 [raid5_align_endio]
[19441.620619] read error, md2, sdd3 index [3], sector 6702498056 [raid5_align_endio]
[19441.628191] read error, md2, sdd3 index [3], sector 6702498064 [raid5_align_endio]
[19441.635776] ata4: EH complete
[19441.775250] read error corrected, md2, sdd3 index [3], sector 2243605256 [raid5_end_read_request]
[19441.784151] raid5:md2: read error corrected (8 sectors at 2234168064 on sdd3)
[19441.791298] read error corrected, md2, sdd3 index [3], sector 2243605264 [raid5_end_read_request]
[19441.800169] raid5:md2: read error corrected (8 sectors at 2234168072 on sdd3)
[19441.807306] read error corrected, md2, sdd3 index [3], sector 2243605272 [raid5_end_read_request]
[19441.816177] raid5:md2: read error corrected (8 sectors at 2234168080 on sdd3)

Ein kurzer SMART Test zeigt den Status normal an. Current-Pending-Sector-Count und Reallocated-Sector-Count zeigen beide 0 an.
Werde morgen ein Downgrade auf DSM 3.2 durchführen, keine Lust irgendwelche Dateien zu vom Backup restoren zu müssen.
Habe eigentlich nur wegen dem ungelösten Kopierfehler "First copy stops" * von DSM 3.2 auf 4 updated.
* http://forum.synology.com/enu/viewtopic.php?f=187&t=41044
 

BigBlue007

Benutzer
Mitglied seit
01. Feb 2012
Beiträge
34
Punkte für Reaktionen
0
Punkte
0
Wie weiter oben schon mehrfach berichtet und IMHO inzw. auch mit einiger Sicherheit bestätigt, handelt es sich hierbei um einen Bug in DSM 4.0. Der Fehler ist nach einem Downgrade auf 3.2 weg. Ich habe das Problem bereits gemeldet, andere sicher auch schon, aber es sollte eigentlich JEDER sein Problem individuell melden, schon allein, damit die sehen, dass es wirklich ein Problem in der Fläche und nicht nur bei 2 Leuten ist.
 

trox

Benutzer
Mitglied seit
20. Jul 2009
Beiträge
18
Punkte für Reaktionen
0
Punkte
0
Hi, habe meins auch schon gemeldet. Gruss

#3954
Since the DSM 4.0 update, I have kernel-errormessages like this:
"ata3.00: device reported invalid CHS sector 0"
"ata3.00: failed command: READ FPDMA QUEUED"
This seems to be kernel related, not hardware-fault.
 

goetz

Super-Moderator
Teammitglied
Sehr erfahren
Mitglied seit
18. Mrz 2009
Beiträge
14.164
Punkte für Reaktionen
412
Punkte
393
Hallo,
BUG!
Wenn im VPN Center OpenVPN und/oder PPTP aktiviert ist/sind und man den HotSpot einschaltet verschwinden die NAT Regeln für VPN, somit ist nur noch die DS per VPN erreichbar, das restliche lokale Netz nicht.
Vorher, nur VPN
Rich (BBCode):
DS411plusII> iptables -t nat -L
Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination

Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination
MASQUERADE  all  --  10.8.0.0/24          anywhere
MASQUERADE  all  --  10.0.0.0/24          anywhere

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination
nach Aktivierung des HotSpot
Rich (BBCode):
DS411plusII> iptables -t nat -L
Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination

Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination
MASQUERADE  all  --  10.1.14.0/23         anywhere
MASQUERADE  all  --  10.1.14.0/23         anywhere

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination
Andersherum funktioniert es, also HotSpot ein und dann VPN einschalten.
Report ist raus.

Gruß Götz
 

Trolli

Benutzer
Mitglied seit
12. Jul 2007
Beiträge
9.848
Punkte für Reaktionen
1
Punkte
0
@trolli,

kannst du den Fehler reproduzieren? und tritt er auch nach einem Neustart noch auf?

Itari
Gestern Abend ist Time Backup dann ohne Fehler durchgelaufen - heute morgen wieder das gleiche Problem. Auch nach einem Neustart konnte ich keine manuelle Time Backup Sicherung durchführen...
 
Status
Für weitere Antworten geschlossen.
 

Kaffeautomat

Wenn du das Forum hilfreich findest oder uns unterstützen möchtest, dann gib uns doch einfach einen Kaffee aus.

Als Dankeschön schalten wir deinen Account werbefrei.

:coffee:

Hier gehts zum Kaffeeautomat