Spontán(?) felébredő gép - wake on LAN probléma

 ( locsemege | 2018. július 8., vasárnap - 11:37 )

Picit távolról futok neki a történetnek, hogy minden részletében világossá tudjam ezt tenni.

Van egy MSI alaplap, rajta valami ilyennel:

Ethernet controller: Realtek Semiconductor Co., Ltd. RTL8111/8168/8411 PCI Express Gigabit Ethernet Controller (rev 01)

A hozzá tartozó modul az r8169. A drót másik végén van egy TP-Link TL-WR842N v3 router, melyre OpenWrt/LEDE snapshot image-et teszek, saját igény szerint rakom össze az image-et a mindenkori legfrissebb, jelenleg 4.9.111-es kernellel.

A desktop gép interface-e az alábbi wake on LAN lehetőségeket támogatja:

Supports Wake-on: pumbg

Ez a dokumentáció szerint az alábbi:

p Wake on PHY activity
u Wake on unicast messages
m Wake on multicast messages
b Wake on broadcast messages
g Wake on MagicPacket™

Egy darabig remekül be tudtam kapcsolni a gépemet távolról, egy ideje viszont nem. Ez úgy történt, hogy ssh-ztam a router-re, majd onnan etherwake-kel MagicPacket-et küldtem a gépnek, amire ő bekapcsolt. Néztem, most miért nem megy. Azért, mert a státusz 'd' volt, azaz disabled. A NetworkManager GUI felületén szépen lehet ezeket állítani, mondtam neki, hogy legyen 'bg'. Azaz broadcast és MagicPacket. Amúgy valószínű, hogy az első felesleges, sőt, lehet, hogy épp ez okozza a bajomat, de mintha arra emlékeztem volna, hogy így volt, amikor régen működött.

Kipróbáltam, működött, örültem. Aztán gépet leállítottam, elmentem aludni. Éjjel fél 3 körül arra ébredtem, hogy bekapcsolt a számítógép. Annyira álmos voltam, hogy szerintem beléptem, s úgy állítottam le (a log szerint viszont nem). Aztán másodjára is bekapcsolt a gép hajnal 4 körül, ekkor viszont belépés nélkül állítottam le. Viszont ekkor a WOL disabled-re lett inicializálva, vélhetően azért, mert nem léptem be. Ezt onnan tudom, mert utána hagyott aludni, továbbá délelőtt a router-re ssh-zva notebook-ról nem tudtam bekapcsolni a desktop gépet.

Amúgy cseppet hülyének érzem most magam, lehet, hogy a 4 óra körüli bekapcsolást csak álmodtam. Pedig tényleg úgy emlékszem, mintha megtörtént volna. Ezért mondom mindezt:

locsemege    tty1         :0               Sun Jul  8 10:28   still logged in
locsemege    :0                            Sun Jul  8 10:28   still logged in
reboot       system boot  4.17.4-200.fc28. Sun Jul  8 10:27   still running
reboot       system boot  4.17.4-200.fc28. Sun Jul  8 02:27 - 02:28  (00:01)
locsemege    tty1         :0               Sat Jul  7 21:02 - 00:45  (03:42)
locsemege    :0                            Sat Jul  7 21:02 - down   (03:42)
reboot       system boot  4.17.4-200.fc28. Sat Jul  7 21:02 - 00:45  (03:43)

Azt simán elhinném, hogy ilyen-olyan kernel bug miatt bekapcsol a gép. Egyetlen bökkenő, hogy kikapcsolt állapotban nem fut rajta operációs rendszer. Egyedül a hálózati interface figyel. Vagy MagicPacket-et kapott, de akkor baj van, mert valaki be tudott lépni a router-emre, vagy broadcast message-et. Ehhez viszont nem értek, nem tudom, ennek mi lehet a forrása. Lehet, hogy egy sima arp kérésre ébredt fel?

Hozzászólás megjelenítési lehetőségek

A választott hozzászólás megjelenítési mód a „Beállítás” gombbal rögzíthető.

BIOS/Kernel/LAN kártya frissítés? Router firmware frissítés? Router log? Milyen router és milyen firmware?

De hiszen írtam, te ember! :)

A drót másik végén van egy TP-Link TL-WR842N v3 router, melyre OpenWrt/LEDE snapshot image-et teszek, saját igény szerint rakom össze az image-et a mindenkori legfrissebb, jelenleg 4.9.111-es kernellel.

Ez egy 10 éves alaplap, a legfrissebb BIOS van rajta, de az már van kb. 7-8 éves. A firmware-t a hálózati interface-hez a Linux tölti le. Ez az általam használt - legfrissebb - verzió:

rpm -q linux-firmware
linux-firmware-20180525-85.git7518922b.fc28.noarch


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Látom, bocsi, benéztem!

Nekem amúgy a broadcast a gyanús, most kikapcsoltam, hogy broadcast message-re feltápászkodjon. Az a szörnyű gyanúm, hogy az arp broadcast-on megy, de amúgy nem tudom, nincsenek mélyebb hálózati ismereteim.


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Szia!

Egy halozaton *rengeteg* broadcast megy, pl DHCP keres, (igen az ARP is bizonyos esetekben) (ipv6 neighbour discovery?), mindenfele nyitott es zart kereso es hirdetesi protokollok, pl UPnP, CDP rengeteg kulombozo eszkozrol pl. SAMBA server / windows file megosztas kereses, wifis mobiltelefon, router, halozati nyomtato, halozatos TV, mediabox / chromecast, jatekkonzol stb.

A kerdes hogy mit ert a halozati ic "broadcast" -on, mert ha mindezekre ugrik akkor egy atlag modern halozaton par masodperc alatt be kellene kapcsolnia...

Köszönöm a megerősítést, gyakorlatilag biztos, hogy ez volt a baj. Kikapcsoltam, hogy broadcast üzenetre is felkeljen, azóta béke van, s csak akkor ébred, ha valóban szeretném.

Azért nem éledt sokkal hamarabb, gyakrabban, mert ez nem egy nagy forgalmú céges hálózat, egyedül a router-en futott OpenWrt/LEDE, volt egy kikapcsolt gép az egyik LAN portján, van még egy notebook, de az wifi-n, s szintén épp kikapcsolva. Szóval nem volt túl eseménydús az élet. El tudom képzelni, hogy lejárt a dhcp lease time, s ekkor eresztett meg broadcast üzenetet a router, de amúgy nem tudom. Mindegy is, már jó. :)


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Használtam sokáig wol-t és msi cuccokat, leírom amit tapasztalataim után gondolok, de ha nem értünk egyet, nyugodtan írhatod, hogy "te, ember", nem sértődök meg :)
A fejlett energiagazdálkodási motyók önmagukban is tartogatnak meglepetéseket, msi-vel fűszerezve szerintem borotvaél..
Írtad, hogy régi az alaplap, de típust elsőre nem látok. Volt egykor az a váltás, hogy már nem kell az a 3 eres kábel a wol-hoz, PCI2.2 megoldja. Látom, hogy egy integrált kártya, de nem dugtál azóta (mármint egyéb kártyát) valamely pci-ba? És akkor inkompatibilitás esetleg átrakni másik pci-ba vagy az új kártya hibás esetleg..
Vagy próbálkozhatnál egy másik gépből kiszerelt pci hálókártyával az alaplapit letiltva.
Aztán ott az alaplap. Nemrég egy másik szálon világosítottak fel, hogy pici kondikon nem látszik a púposság, márpedig egyrészt a rossz kondik meg tudják viccelni a Power Management szütyiket, másrészt az _összes_ msi eszközünk a vacak kondik miatt elavulásuk előtt ment tönkre.
Még ott a táp is. Legelső körben egy másik _biztosan_jó_ táppal csinálj végig egy éjszakát.
Utolsó próbálkozásom egy msi-nél a firmware downgrade lenne, aztán ha nem megy, e-hulladékba vele :)

Ennyire nem rossz, sőt kifejezetten jó ezzel az alaplappal a tapasztalatom, ezért is nyúzom hajlott kora ellenére. 10 éves; Micro-Star International Co., Ltd. [MSI] Device 7388, ezt mondja az lspci. Épp azokban az időkben mentek tönkre nagy mennyiségben elkók miatt alaplapok, így piaci tényezővé vált, ha jó elkókat raktak a lapba. Ezt is úgy reklámozták, hogy magas élettartamú, fene tudja, hány órát bíró elkók vannak benne. Nyilván azon túlvagyok, hiszen a HDD-mben például 27 934 üzemóra van.

A gép stabil, nem produkál megmagyarázhatatlan jelenségeket, fagyásokat.

Egyelőre hiszek abban, hogy félrekonfiguráltam, a broadcast üzenetre ébresztés nem kellett volna. Megnézem, hogy a jelenlegi beállítással nyugodt lesz-e az éjszakám. :)


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE

Teljesen véletlenül a WOL-al nem kapcsoltad be az USB-s ébresztést is? Nekem is MSI lapom van, igaz csak 2 és fél éves, de nálam az egér volt az, ami rendszeresen ébresztette a gépet, pedig első körben én is a WOL-ra gyanakodtam, mivel csak a bekapcsolása után jelentkezett a probléma.


Vizsgára felkészülés végett keresek "kidobásra" szánt menedzselhető Cisco switch-eket és routereket, leginkább Pest és Bács-Kiskun megye területén.

Nem. Most már lényegében biztos vagyok abban, hogy hálózati broadcast csomag élesztette fel, mert amióta kikapcsoltam az erre történő élesztést, békésen pihen a gépem. Viszont MagicPacket-tel fel tudom kelteni.


tr '[:lower:]' '[:upper:]' <<<locsemege
LOCSEMEGE