JUUHUUU!! der hostmgr rennt, und die ds pennt...
hallo jungs,
sin,
zuerst mal vielen dank für deine rückmeldung.
wir haben ein working system, und ich muß dich jetzt leider mit einer großen bitte echt nerven. es geht nämlich um folgendes:
1.
im ruhezustand muß die ds noch immer arp reqs beantworten, weil sie sonst nach ablauf des arp cache timeouts eines rechners von demselben nicht mehr geweckt werden könnte [1] (außer man setzt am rechner statische arp einträge, was aber nicht praktikabel ist. stell dir vor du hast 100 rechner im lan, da wirst narrisch).
2.
trotz beantwortung der arp reqs darf sie jedoch nicht aufwachen. das dürfte das prob vom wo67 sein.
soweit die graue theorie, mit einem praktischen beispiel täte sich der wo67 aber leichter, wenn er einen case bei synology eröffnen will.
das ganze könnte ca. so aussehen:
- du hängst einen kontrollrechner mit installiertem
wireshark an den eth1 des tg.
- die ds hängt z.b. am eth4 des tg.
- du spiegelst den eth4 auf den eth1 mit:
=>eth switch mirror capture port 1
=>eth switch mirror ingress port 4
=>eth switch mirror egress port 4
- danach startest du den shark mit einem ansichtsfilter, sodaß du nicht durch irgendwelche nebengeräusche gestört wirst. angenommen das tg hat die (default) ip 10.0.0.138 und die ds hat die ip 10.0.0.129, dann schaut dieser filter so aus:
- Code: Alles auswählen
(arp.opcode==0x0001&&arp.src.proto_ipv4==10.0.0.138&&arp.dst.proto_ipv4==10.0.0.129)||(arp.opcode==0x0002&&arp.src.proto_ipv4== 10.0.0.129&&arp.dst.proto_ipv4==10.0.0.138)
falls du andre ips verwendest, mußt du halt den filter sinngemäß anpassen. und der code-abschnitt ist natürlich ein einzeiler.
- danach siehst du nur den traffic hostmgr <-> ds. alle 30s (scantime=30) geht eine arp req vom hostmgr raus und wird von der ds beantwortet (in dem bunti unten kommen die reps nicht von einer ds, sondern von einem mikrotik. hab leider keine ds, sonst hätt ich mir eh schon alles angeschaut).
- tg585v7_hostmgr_arp_traffic.png (36.34 KiB) 24075-mal betrachtet
- danach die trace als pcap sichern (und zwar nur die *displayed* packets!), und die pcap dem wo67 schicken.
bei unklarheiten fragen und vielen dank!
wolfgang,
wenn du schwein hast, dann zieht der sin unsren test von oben durch, und du schuldest ihm einen weißen spritzer + ein packerl tschicks...
insgesamt sollte der fahrplan klar sein:
- du prüfst die ganze gschicht noch mit arping
sry, hab vergessen, daß du win verwendest. arping muß da nachinstalliert werden:
http://www.heise.de/download/arping-1137383.html- und wenn deine ds tatsächlich mit arp reqs geweckt werden kann, eröffnest du bei synology einen case, in dem du eben diesen sachverhalt darlegst. als vergleich verwendest du die ds212+ mit der gefilteten trace vom sin. dort funkt das zeugs ja offensichtlich.
diese problembeschreibung ist durch den vergleich ds213+ vs. ds212+ schon sehr aussagekräftig, sodaß eine begründete hoffnung besteht, daß dieser bug relativ rasch behoben wird.
solltest du wider erwarten deine ds mit arping nicht wecken können, dann liegt das prob woanders, und wir müssen weitersuchen.
>"...Hat Deine DS 212+ denn schon den DeepSleep-Modus ?..."
ich denke schon. der sin redet ja in seinem ersten post explizit davon:
"...ich kann dir aufjedenfall sagen, das meine synology brav im deepsleep geht..."lg
zid
[1] //edit:
ich rede jetzt natürlich von ucasts, eh klar, oder?
