Beiträge von holzhammer

Vielen Dank für euer Feedback, hier noch zum Abschluss meine finale Lösung:

Da der Druck des Reset-Tasters einen anderen Code auslöst als der Code, der den Reboot auslöst (siehe Beitrag #1), habe ich davon abgesehen, den Taster zu entfernen. Der Fehler liegt offenbar irgendwo danach.

Da der Reboot so schnell erfolgt, kann der Reset-Button auch nicht am NAS selbst erfolgen, da man sich so schnell nicht anmelden kann.

Ich habe also an einem anderen QNAP das QTS installiert und dort den Reset-Button deaktiviert. Diese Platte dann in das TS-451 eingebaut, und seither läuft es stabil. Ich darf nur keinen Factory Reset machen - brauche ich aber eh nicht.

Danke

Andreas

UpSpin:

Genau, den Firmware Recovery habe ich probiert.

Eine Reparatur bei QNAP für ein Gerät ausserhalb der Garantie ist leider regelmässig wirtschaftlicher Unsinn

Ich denke auch nicht, dass es der Button selber ist. Da es das Problem schon öfter gegeben hat, hatte ich gehofft jemand kennt den vermutlichen Übeltäter.

Habe ich ausprobiert, dadurch wird ein anderer Tastencode generiert. Auch danach versucht das NAS aber den Reset.

Der Versuch kommt alle 15 Sekunden

Hi,

mein TS-451 hängt in einer Reboot Schleife fest. Offenbar meint das Teil, dass der Reset-Knopf dauernd betätigt wird.

Ich habe es neu installiert und schaffe es gerade, mich am Webinterface anzumelden, bevor es heruntergefahren wird. Ich sehe dann dort noch die Meldung, dass die Dienste gestoppt werden, und dann kommt auch schon der Reboot.

Keine Chance, so den Reset zu deaktivieren.

Was ich bisher probiert habe:

- anderer RAM -> selbes Verhalten

- Neuinstallation auf neue Platten -> selbes Verhalten

- Firmware Recovery -> mit der Recovery Firmware bootet es nicht automatisch neu, sobald ich auf die aktuelle Firmware aktualisiere hängt es in der Schleife.

- Migration von einer TS-259Pro+ mit deaktiviertem Reset Button -> damit läuft es seit einigen Stunden stabil

Ursache ist also definitiv der Reset-Button. Ich kann das auch im Log nachvollziehen (/var/log/hal_daemon.log):

Tue Nov 27 17:34:48 2018
do_restore_config(1903):Reset system configuration to default settings.
Tue Nov 27 17:35:03 2018
do_restore_config(1903):Reset system configuration to default settings.
Tue Nov 27 17:35:18 2018
do_restore_config(1903):Reset system configuration to default settings.
Tue Nov 27 17:35:33 2018
do_restore_config(1903):Reset system configuration to default settings.
Tue Nov 27 17:35:48 2018
do_restore_config(1903):Reset system configuration to default settings.
Tue Nov 27 17:36:03 2018
do_restore_config(1903):Reset system configuration to default settings.
Tue Nov 27 17:36:18 2018
do_restore_config(1903):Reset system configuration to default settings.
Tue Nov 27 17:36:33 2018
do_restore_config(1903):Reset system configuration to default settings.
Tue Nov 27 17:36:48 2018
do_restore_config(1903):Reset system configuration to default settings.
Tue Nov 27 17:37:03 2018
do_restore_config(1903):Reset system configuration to default settings.
Tue Nov 27 17:37:18 2018
do_restore_config(1903):Reset system configuration to default settings.

Der Knopf selber lässt sich drücken, ist also zumindest kein mechanischer Fehler.

Das scheint ja gelegentlich vorzukommen. Kann man das irgendwie reparieren? Ich habe zwar einen Workaround, aber lieber wäre mir ein NAS ohne den Fehler.

Danke

Andreas

QRACKZ :

Das Firmwareupdate per QFinder hat man in der Anleitung im englischen Wiki leider vergessen: https://wiki.qnap.com/wiki/Fir…napurna_Labs.29_based_NAS

11. Once the firmware recovery process is done, the NAS will shutdown automatically. (PS: TS-531P is the exception that the NAS will reboot instead of shutdown.)

12. Remove the jumper from pin J2 (for TS-431XU/TS-831XU/TS-1231XU only).

13. Done.

Aber Hauptsache das Ding läuft wieder!

dr_mike: Läuft wieder, siehe Beitrag vorher

Den hatte ich grad noch weiter bearbeitet!

Danke an alle Beteiligten für geistige und moralische Unterstützung!

dr_mike: Nach längerem Zögern habe ich mich entschieden, das NAND einfach mal komplett zu löschen. Kaputt ist das TS-231+ eh schon.

WARNUNG: Do not try this at home! Nicht nachmachen, vermutlich ist euer QNAP danach ein Türstopper!

Ergebnis: Bootet weiterhin in U-Boot, ergo liegt das tatsächlich woanders

Nettes Detail: Das Recovery schreibt auch in das Flash, wenn keine Daten per TFTP empfangen wurden! Habe ich erst später bemerkt, weil kein LAN-Kabel angeschlossen war.

Ergebnis:

Keine Bad Blocks mehr, das Recovery läuft scheinbar korrekt durch, das NAS bootet aber weiterhin in denselben Zombiestatus

Edit:

Heureka! Mit dem neuen Recovery bootet das Gerät jetzt zumindest soweit, dass es im Finder angezeigt wird!

Ich hatte erst das alte Recovery getestet, da das vorher bessere Ergebnisse gezeigt hat.

An sich müssten beide funktionieren. Das NAND war komplett leer, Platte keine installiert. Das U-Boot wird vermutlich nicht angefasst, also sollte es keinerlei Abhängigkeiten geben.

Edit2:

Leider kann ich es immer noch nicht installieren. Beim Doppelklick auf das System bekomme ich einen blauen leeren Bildschirm im Browser.

Seltsam: Als Version wird eine 1.3.x.x angezeigt?

Edit3:

Heureka! Firmware über QFinder aktualisieren hat das Problem final behoben! Die TS-231+ läuft wieder.

Wieso der Flash soviele bad blocks hatte, ist mir nicht klar. Ein seltsames Problem, aber wenigstens ein gelöstes Problem.

Dann ist vollständiges Löschen des NAND vielleicht nicht so gut...

Bisher habe ich in der Console nichts verändert.

Das Recovery mit deinem Image liefert dasselbe Ergebnis wie das Recovery mit TS-X31P+_434:

NAND read: device 0 offset 0xf800000, size 0x2000000
 33554432 bytes read: OK
SERDES 2, p0123, pma, reg[201][7:0] <= 0xfc
SERDES 2, p0123, pma, reg[202][7:0] <= 0xff
SERDES 2, p0123, pma, reg[203][7:0] <= 0xff
SERDES 2, p0123, pma, reg[204][7:0] <= 0xff
SERDES 2, p0123, pma, reg[205][7:0] <= 0x7f
SERDES 2, p0123, pma, reg[205][7:0] <= 0xff
SERDES 2, p4, pma, reg[13][4:4] <= 0x01
SERDES 2, p4, pma, reg[15][4:3] <= 0x03
## Booting kernel from Legacy Image at 08000000 ...
   Image Name:   Linux-4.2.8
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    23270864 Bytes = 22.2 MiB
   Load Address: 00008000
   Entry Point:  00008000
   Verifying Checksum ... Bad Data CRC
ERROR: can't get kernel image!
PCI Cleanup: FLR 1.0.0
Unknown command 'p-▒p-▒' - try 'help'
ALPINE_DB>

Bist du sicher, dass das uboot im NAND liegt? Es gibt scheinbar noch einen weiteren Flash:

ALPINE_DB> flash_contents_toc_print
SF: Detected MX25U1635E with page size 256 Bytes, erase size 64 KiB, total 2 MiB
#  | OBJ ID                    | Instance | Name     | Device  | Offset   | Max Size
------------------------------------------------------------------------------------
 0 | 000000 (       BOOT_MODE) |        0 | boot-mod | Current | 00010000 | 00010000
 1 | 00000c (        PRE_BOOT) |        0 |  preboot | Current | 00020000 | 00050000
 2 | 000006 (    UBOOT_SCRIPT) |        0 | u-boot-s | Current | 00070000 | 00010000
 3 | 000005 (           UBOOT) |        0 |    uboot | Current | 00080000 | 00080000
 4 | 000002 (              DT) |        0 |       dt | Current | 00100000 | 00010000
 5 | 000007 (       UBOOT_ENV) |        0 | uboot-en | Current | 00110000 | 00020000
 6 | 00000c (        PRE_BOOT) |        0 |   config | Current | 00130000 | 000d0000
ALPINE_DB>
ALPINE_DB> nand info

Device 0: nand0, sector size 128 KiB
  Page size       2048 b
  OOB size          64 b
  Erase size    131072 b
  subpagesize     2048 b
  options     0x40000200
  bbt options 0x    8000
ALPINE_DB>

Der MX25U1635E von "flash_contents_toc_print" ist laut Datenblatt ein NOR-Flash.

Leider finde ich nichts um uboot, mit dem ich die Partitionen des NAND anzeigen könnte.

Sinnvoll ist die Fehlermeldung nicht:

NAND erase: device 0 offset 0x1f000000, size 0x1000000
Erasing at 0x1ffe0000 -- 100% complete.
OK
NAND write: device 0 offset 0x1f000000, size 0x1e0000
Attempt to write outside the flash area
 0 bytes written: ERROR.

Erst löscht er erfolgreich size 0x1000000, dann soll der kleinere Schreibvorgang ausserhalb liegen.

dr_mike: Das weiß ich leider nicht mehr. Die Festplatten sind auch schon im neuen System, so dass ich von dort auch keine Infos ermitteln kann.

Ich habe die Recovery mit beiden Images aus dem QNAP Wiki getestet:

Mit dem TS-X31P+_434 bootet das NAS überhaupt nicht mehr.

Mit dem TS-X31P+_fw bootet es zumindest irgendwohin auf der Konsole

Bei beiden endet das Recovery mit einem "Attempt to write outside the flash area"

Wieso gibt es denn unterschiedliche Recovery Images? Wird da nicht einfach das DOM vollständig neu geschrieben? Da ich keine alten Platten wieder an den Start bringen muss, sollte das ja egal sein.

Kann das NAND zu viele Fehler haben? An sich ist das ja 512MB groß, und die Firmware nur 180MB. Da müsste ja mehr als die Hälfte kaputt sein.

Ich könnte über die Konsole das NAND vollständig löschen, denke ich. Die Frage ist, ob da der UBoot ebenfalls drauf liegt. Das wäre dann schlecht.

Mit dem TS-X31P+_FW scheint es sogar korrekt zu booten:

[~] # ps
 194 admin       420 S < udevd --daemon
  206 admin       572 S   /sbin/hal_app --se_scan
  214 admin      1260 S   /sbin/daemon_mgr
  224 admin      1696 S   /sbin/hal_daemon -t
  327 admin           SW< [kworker/0:1H]
  536 admin      1772 S   /usr/local/sbin/_thttpd_ -p 8080 -nor -nos -u admin -
  639 admin       472 S   /bin/utelnetd -d -p 13131
  640 admin      1908 S   /sbin/bcclient
  670 admin           SW< [kworker/1:1H]
 1117 admin      1144 S   /usr/sbin/sshd -f /etc/ssh/sshd_config -p 22
 1174 admin       888 S   /bin/sh /etc/init.d/klogd.sh start
 1188 admin      1184 S   -sh
 1192 admin       284 S   /bin/dd if=/proc/kmsg of=/mnt/HDA_ROOT/.logs/kmsg bs=
 1228 admin       724 R   ps -axf

Blöderweise hat es kein Netzwerk-Interface, auf dem die Dienste lauschen könnten. ifconfig eth0 liefert nur einen Fehler

Ticket hatte ich offen, das NAS ist gerade aus der Garantie raus... Und mit serieller Console brauche ich dem Support eh nicht zu kommen. Recovery hat nicht funktioniert? -> Dann ist es kaputt.

Irgendwie ist es zu schade zum wegwerfen, so prinzipiell tickt es ja noch.

Ich glaub ich brauch mal ein x31+ zum gegenüberstellen.

QRACKZ: Vielen Dank, die neuen Recovery Images habe ich noch nicht gesehen. Gleich mal getestet und an der seriellen Console verfolgt, leider ohne Erfolg. Der Schreibvorgang endet mit:

TFTP from server 169.254.100.177; our IP address is 169.254.100.100
Filename 'nasconfig.ubi'.
Load address: 0x8000000
Loading: #################################################################
         #################################################################
         ####
         1.9 MiB/s
done
Bytes transferred = 1966080 (1e0000 hex)
[eth rx] warn: dma state didn't change to Disable
[eth rx] warn: failed to change state, error -110

NAND erase: device 0 offset 0x1f000000, size 0x1000000
Erasing at 0x1ffe0000 -- 100% complete.
OK

NAND write: device 0 offset 0x1f000000, size 0x1e0000
Attempt to write outside the flash area
 0 bytes written: ERROR

Woher weiss ich denn, welches Recovery-Image das richtige ist?

Mit dem TS-X31P+_434 bootet das NAS überhaupt nicht mehr.

Mit dem TS-X31P+_fw bootet es zumindest irgendwohin:

[   16.829527] UBIFS: un-mount UBI device 0, volume 0
[   16.840417] UBI: detaching mtd3 from ubi0
[   16.844983] UBI: mtd3 is detached from ubi0
[   16.853699] ufsd: module license 'Commercial product' taints kernel.
[   16.860039] Disabling lock debugging due to kernel taint
[   16.866301] ufsd: Unknown symbol jnl_op (err 0)
[   16.986140] udevd (194): /proc/194/oom_adj is deprecated, please use /proc/194/oom_score_adj instead.
[   16.995376] udev: starting version 140
[   30.134847] IPv6: Loaded, but administratively disabled, reboot required to enable
[   30.473606] Bridge firewalling registered

daemon_mgr PID 1183/1

Welcome to use the QNAP's products.

TEST login: admin

Da kann ich mich zwar anmelden, es ist aber kein Netzwerk verfügbar. lsmod zeigt ein geladenes e1000e Modul, ifconfig findet aber kein eth0

RedDiabolo: Das habe ich von hier: QNAP Consolen Port - Zugang und Belegung

Man braucht tatsächlich nur einen Klinkenstecker und einen passenden seriellen Port. Ich habe dazu ein altes Audio-Cinchkabel geopfert und einen DB9 Stecker drangelötet.

dr_mike: Danke! Das sieht exakt nach meinem Problem aus!

Mittlerweile Zugang via seriellem Wartungsport. Offenbar ist das Flash beschädigt:

stage2_eth3_ram_loader v1.73
Executing next!
stage2.5_loader v1.73
SPD I2C Address: 50
Executing next!

-----------------------------------------------------
Stage 3 version: 1.73.0
Commit ID: 8a64313
CVOS commit ID: abad961
HAL commit ID: 5396ac1
Build date: Feb 12 2017 21:53:45
-----------------------------------------------------

EEPROM Revision ID = 39
Device ID = a212
Device Info: AL21200-1400
Loading DT to 00100000 (18765 bytes)...
Board config ID: alpine_db_qnap
Loading application to 00100000 (483948 bytes)...
Executing application...


U-Boot 2015.07-alpine_db-1.73.4-00001-g2c66ee7-dirty-HAL (Sep 25 2017 - 16:25:51 +0800)

I2C:   ready
DRAM:  1 GiB
Trace early: 00ff0000, 10000

   _
  /_\  _ __  _ __   __ _ _ __  _   _ _ __ _ __   __ _
 //_\\| '_ \| '_ \ / _` | '_ \| | | | '__| '_ \ / _` |
/  _  \ | | | | | | (_| | |_) | |_| | |  | | | | (_| |
\_/ \_/_| |_|_| |_|\__,_| .__/ \__,_|_|  |_| |_|\__,_|
   __       _           |_|
  / /  __ _| |__  ___
 / /  / _` | '_ \/ __|
/ /__| (_| | |_) \__ \
\____/\__,_|_.__/|___/
               ___             _
 /\ /\        / __\ ___   ___ | |_
/ / \ \_____ /__\/// _ \ / _ \| __|
\ \_/ /_____/ \/  \ (_) | (_) | |_
 \___/      \_____/\___/ \___/ \__|

eeprom_per_device_init: no valid information found!
power_init_board: EEPROM per device information is not valid - using defaults!
SF: Detected MX25U1635E with page size 256 Bytes, erase size 64 KiB, total 2 MiB
U-Boot redundant environment not found in TOC!
Board config ID: alpine_db_qnap
Trace disabled
NAND:  512 MiB
SF: Detected MX25U1635E with page size 256 Bytes, erase size 64 KiB, total 2 MiB
PCI:
  00:01.0     - 1c36:0001 - Network controller
  00:03.0     - 1c36:0001 - Network controller
  00:04.0     - 1c36:0011 - Cryptographic device
  00:05.0     - 1c36:0021 - Base system peripheral
  00:09.0     - 1c36:0031 - Mass storage controller
PCIE_0: Link up. Speed 5GT/s Width x1
PCI:
  01:00.0     - 1b6f:7052 - Serial bus controller
handle_link: PCIE_1 no link found
In:    serial
Out:   serial
Err:   serial
Net:   , al_eth1 [PRIME]
Warning: al_eth1 using MAC address from net device
, al_eth3
Warning: al_eth3 using MAC address from net device

Hit any key to stop autoboot:  0
gpio: pin 0 (gpio 0) value is 1
Error: Power Mode 0xff no support!

NAND read: device 0 offset 0x0, size 0x2000000
Skipping bad block 0x00000000
Skipping bad block 0x00020000
Skipping bad block 0x00040000
Skipping bad block 0x00060000
Skipping bad block 0x00080000
Skipping bad block 0x000a0000
Skipping bad block 0x000c0000
Skipping bad block 0x000e0000
[…]
Skipping bad block 0x005c0000
Skipping bad block 0x005e0000
Skipping bad block 0x00600000
Skipping bad block 0x00620000
Skipping bad block 0x00640000
Skipping bad block 0x00660000
Skipping bad block 0x00680000
Skipping bad block 0x006a0000
Skipping bad block 0x006c0000
Skipping bad block 0x006e0000
Skipping bad block 0x00700000
Skipping bad block 0x00720000
Skipping bad block 0x00740000
Skipping bad block 0x00760000
Skipping bad block 0x00780000
Skipping bad block 0x007a0000
Skipping bad block 0x007c0000
Skipping bad block 0x007e0000
Skipping bad block 0x00800000
Skipping bad block 0x00820000
Skipping bad block 0x00840000
Skipping bad block 0x00860000
Skipping bad block 0x00880000
Skipping bad block 0x008a0000
Skipping bad block 0x008c0000
Skipping bad block 0x008e0000
Skipping bad block 0x00900000
Skipping bad block 0x00920000
Skipping bad block 0x00940000
Skipping bad block 0x00960000
Skipping bad block 0x00980000
Skipping bad block 0x009a0000
Skipping bad block 0x009c0000
Skipping bad block 0x009e0000
Skipping bad block 0x00a00000
Skipping bad block 0x00a20000
Skipping bad block 0x00a40000
Skipping bad block 0x00a60000
Skipping bad block 0x00a80000
Skipping bad block 0x00aa0000
Skipping bad block 0x00ac0000
Skipping bad block 0x00ae0000
Skipping bad block 0x00b00000
Skipping bad block 0x00b20000
Skipping bad block 0x00b40000
Skipping bad block 0x00b60000
Skipping bad block 0x00b80000
Skipping bad block 0x00ba0000
Skipping bad block 0x00bc0000
Skipping bad block 0x00be0000
Skipping bad block 0x00c00000
Skipping bad block 0x00c20000
Skipping bad block 0x00c40000
Skipping bad block 0x00c80000
Skipping bad block 0x00ca0000
Skipping bad block 0x00cc0000
Skipping bad block 0x00ce0000
Skipping bad block 0x00d00000
Skipping bad block 0x00d20000
Skipping bad block 0x00d40000
Skipping bad block 0x00d60000
Skipping bad block 0x00d80000
Skipping bad block 0x00da0000
Skipping bad block 0x00dc0000
Skipping bad block 0x00de0000
Skipping bad block 0x00e00000
Skipping bad block 0x00e20000
Skipping bad block 0x00e40000
Skipping bad block 0x00e60000
Skipping bad block 0x00e80000
 33554432 bytes read: OK
SERDES 2, p0123, pma, reg[201][7:0] <= 0xfc
SERDES 2, p0123, pma, reg[202][7:0] <= 0xff
SERDES 2, p0123, pma, reg[203][7:0] <= 0xff
SERDES 2, p0123, pma, reg[204][7:0] <= 0xff
SERDES 2, p0123, pma, reg[205][7:0] <= 0x7f
SERDES 2, p0123, pma, reg[205][7:0] <= 0xff
SERDES 2, p4, pma, reg[13][4:4] <= 0x01
SERDES 2, p4, pma, reg[15][4:3] <= 0x03
## Booting kernel from Legacy Image at 08000000 ...
   Image Name:   Linux-3.10.20-al-2.5.3_sa
   Image Type:   ARM Linux Kernel Image (uncompressed)
   Data Size:    17107072 Bytes = 16.3 MiB
   Load Address: 00008000
   Entry Point:  00008000
   Verifying Checksum ... OK
## Flattened Device Tree blob at 03b4f008
   Booting using the fdt blob at 0x3b4f008
   Loading Kernel Image ... OK
PCI Cleanup: FLR 1.0.0
   reserving fdt memory region: addr=0 size=100000
   Loading Device Tree to 03b35000, end 03b3c94c ... OK
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!
I/O CC forced to 1!
!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!!

Starting kernel ...

Uncompressing Linux... done, booting the kernel.
[    0.000000] Booting Linux on physical CPU 0x0
[    0.000000] Initializing cgroup subsys cpuset
[    0.000000] Initializing cgroup subsys cpu
[    0.000000] Initializing cgroup subsys cpuacct
…..

Update: der Wartungsport mit Klinkenstecker an der TS-231+ ist ein einfacher serieller Port, der direkt am seriellen Port meines Laptops funktioniert. An einem 3.3V Seriell <-> USB Wandler klappte es nicht.

Hat das mal jemand weiterverfolgt? Mein USB->Seriell Wandler, der bei den internen Konsolenports schön funktioniert, spuckt hier nur Unsinn aus.

RedDiabolo: Verkabeln im Altbau/Miete ist keine Option. PowerLAN leider auch nicht, da geht nichts drüber. Die WLAN-Verbindung ist ja stabil, die QNAP baut sie nur aktiv ab. Das würde ich ihr gerne abgewöhnen.

L0gD4ta: das sind nur 8 Watt. Das ist mehr ein Hobby auf der Suche nach dem sparsamsten Server.

1. habe ich gemacht -> Tee trinke ich seit Tagen

2. habe ich auch gemacht. Selbes Verhalten. Nach dem 10 Sekunden Reset Status und Disk LEDs auf rot.

L0gD4ta: genau so ist es.

Der Router steht im Wohnzimmer, das NAS im Arbeitszimmer. Dort stehen auch die beiden PCs.

Momentan steht dort auch ein ddwrt-Router, der das NAS und die PCs an den Router im Wohnzimmer anbindet (Netgear WNDR4500).

Und diesen Router (und seinen Stromverbrauch) würde ich gerne einsparen.

Prinzipiell kann die QNAP das auch ganz gut, nur bekomme ich es nicht stabil.

Hallo,

ich wollte mit einer TS-431+ meine in die Jahre gekommene Infrastruktur (WLAN-Router, ESX mit 2 VMs, Synology DS) ablösen.

Dazu sollte die TS-431+ folgendes tun:

- Fileserver via CIFS - funktioniert

- Windows VM zum testen - funktioniert

- Univention VM als Mailserver -funktioniert

- DDNS Client, weil das meine Vodafone Box nicht kann - mit Gebastel via cron - das konnte die Synology schöner

- interner DNS Server für Split-DNS - geht nicht, macht jetzt die Univention VM

- WLAN und Ethernet-Bridge - hier wird's schräg!

Ich möchte die beiden LAN-Ports und einen WLAN USB-Stick als Bridge einrichten. Der Plan war, dass das QNAP sich mit dem WLAN verbindet, an den Ethernet-Ports hängen zwei PCS, die darüber ins Internet gehen.

Leider ist QNAP der Meinung, dass WLAN Ports nichts in vSwitches zu suchen haben...

Dabei funktioniert es im Prinzip ganz prächtig:

- WLAN Verbindung aufbauen

- auf der Console die IP vom WLAN entfernen (ifconfig wlan0 0.0.0.0) und das WLAN Interface an den vSwitch anhängen (brcrl addif qvs0 wlan0)

=> schon kommen die VMs und die PCs über das WLAN ins Netz

Probleme dabei:

- das QNAP prüft regelmässig irgendwas, und baut die WLAN Verbindung ab. Beim Neuaufbau funktioniert die Bridge nicht mehr (dazu muss das Interface _vor_ dem Aufbau aus der Bridge herausgenommen und danach wieder neu aufgenommen werden).

- das QNAP protokolliert nicht, _was_ es denn prüft

- ich kann die Startscripten nicht reboot-fest verändern, um das irgendwie zu umgehen.

Wie kommt QNAP denn auf die Idee, dass man WLAN und LAN nicht bridgen darf?

Ich könnte jetzt versuchen, den WLAN-Stick an eine virtuelle pfsense Firewall durchzureichen und die auf Bridge-Mode zu schalten, aber das ist doch etwas weit hergeholt. Da die Stabilität mit USB3.0 Platten auch berühmt schlecht ist, habe ich da auch wenig Hoffnung.

Seltsamerweise ist die Verbindung an den Vodafone Kabelrouter stabiler als an eine Fritzbox am selben Standort. Die Verbindung wird aber scheinbar von der QNAP aktiv abgeschalten.

Hat jemand eine Idee, wie ich das WLAN und LAN stabil in eine Bridge geschaltet bekomme?

Danke

Andreas

Hallo,

nach einem Firmware-Update ist mein TS-231+ nicht mehr erreichbar.

Beim Booten piept es einmal, dann nach mehreren Sekunden noch einmal, und schließlich dreimal (wirklich dreimal, angeblich USB Copy, da ist aber nichts).

Danach ist die Status-LED grün, LAN blinkt, und die HDD ist ebenfalls grün.

Nur leider im QFinder nicht mehr zu ermitteln.

Ich habe ein Firmware-Recovery versucht. Dabei ruft das NAS auch die Dateien ab, nach einem Reboot ist es aber weiterhin nicht sichtbar.

Ein Factory Reset über den Reset-Taster hat auch nichts gebracht. Danach leuchtet Status Rot, und beide HDDs ebenfalls rot.

Hat noch jemand eine Idee, wie ich das Gerät wiederbeleben kann? Gibt es für diese komische Maintenance-Klinkenbuchse eine Belegung, ist das ein serieller Diagnoseport?

Danke

Andreas