Debian wil niet Wake-on-LANnen

[Robin F.]

Ik heb laatst een oud thin-clientje op de kop getikt (Neoware CA2), een leuk klein PC'tje met een passief gekoelde VIA CPU en fanloze voeding. Ik heb hem uitgebreid met veel RAM en een CompactFlash-kaartje als harde schijf, met als doel om hem als remote Linux-bak te gebruiken. De netwerkinterface is een on-board Realtek 8139C.

Nou wil ik hem alleen wel via Wake-on-LAN aanzetten, omdat hij van mij niet continu aan hoeft. Het moederbordje en het BIOS ondersteunen dit, ik kan hem zonder problemen aanzetten door een Magic Packet te versturen. Mijn probleem is alleen dat dit niet meer lukt nu ik Debian heb geïnstalleerd. Na een shutdown reageert de PC niet meer op een Wake-on-LAN-commando. Als ik de PC echter opnieuw start en weer uitzet voordat Debian geladen is, dan werkt het weer wel, dus Debian zet op één of andere manier de Wake-on-LAN-functionaliteit uit.

Enig zoeken levert op dat ik niet de enige ben, en dat het schijnbaar simpel op te lossen is via ethtool. Ik heb dat inmiddels geprobeerd, en na "ethtool -s eth0 wol g" wordt keurig vermeld dat Wake-on-LAN is geactiveerd. Maar het werkt nog steeds niet. Ik heb deze opdracht in /etc/network/interfaces gezet bij post-down (en nog andere plaatsen geprobeerd), ik heb het in /etc/init.d/halt gezet als laatste opdracht voor de echte "halt", ik heb daar ook gezegd dat "halt" niet de network interfaces uit moet zetten (dwz halt zonder -i), maar nog steeds werkt het niet.

Ook als ik met acpitool zeg dat de computer moet waken op het betreffende PCI-event, doet hij het nog steeds niet. Ik weet het nou niet meer, is er ergens nog een instelling om ervoor te zorgen dat de netwerkkaart in Wake-on-LAN-modus komt?

[lamko]

In n gewone pc had ik ook problemen met deze chipset Realtek 8139C op een kaartje en ik kon het ook niet werkend krijgen. Heb voor 30 piek ofzo een Intel kaart gekocht dat werkt tenminste.

[gertvdijk]

De Realtek 8139 chip heeft de meest ranzige driver ooit voor een netwerkkaart in de Linux kernel... Er is ooit eens een mooi stukje over geschreven waarbij een developer erachter kwam dat de chip elke X aantal seconden een volledige rotschop moet krijgen om te laten werken.
Hoewel dus mainstream budget: crappy ondersteuning.

[Robin F.]

Tsja, ranzig ok, maar hij zit nou eenmaal on-board, dus het zal wel moeten

Volgens mij ben ik er inmiddels achter wat er mis is, na drie dagen zoeken. De chip geeft standaard een active-high signaal op pin 83 als hij een Wake-on-LAN event signaleert. Mijn moederbord verwacht echter een positieve puls, geen continu hoog signaal. Dat kan de chip ook geven (dat doet hij immers als ik Linux niet heb gestart), maar daarvoor moet je een bepaalde bit in een register van de chip op "1" zetten. Lang verhaal, het komt erop neer dat de 8139too-driver deze bit niet zet.

Nou heb ik een klein stukje in de source erbij gezet om die bit goed te zetten, dus nu zou ik het voor elkaar moeten kunnen krijgen. Probleem is alleen dat ik niet erg veel ervaring heb met kernels compileren, dus kan iemand me even op weg helpen hoe ik alleen even /usr/src/linux/drivers/net/8139too.c hercompileer, zonder gelijk honderd config-scripts te moeten doorlopen en megabytes source te moeten compileren?

[lamko]

Zou je die patch vrij willen geven want zelf kan ik niet programmeren !
En een google search met deze keyworden zou wel moeten lukken :
linux kernel only compile a single module

[ Voor 43% gewijzigd door lamko op 11-07-2009 21:31 ]

[Robin F.]

Sorry, het wordt nu meer een Debian-specifieke vraag, maar wat doe ik nu nog fout?

make drivers/net/8139too.ko

Werkt netjes, en er verschijnt een 8139too.ko. Maar als ik die probeer te modproben, dan lukt dat niet wegens "Invalid module format" en "no symbol version for struct_module". Ik heb de source binnengehaald via apt-get linux-source-2.6.26, moet ik hier nog eerst patches aan toevoegen voordat ik precies dezelfde kernel heb als waar ik nu op draai? Of doe ik nou iets anders fout?

[ThinkPad]

Sluit anders gewoon een andere netwerkkaart aan (desnoods zo'n USB netwerkkaartje, USB to Ethernet).

Dan ben je waarschijnlijk sneller klaar dan het eindeloze zoeken naar de oplossing.

[thegve]

http://www.debian.org/doc/FAQ/ch-kernel.en.html

Kernels bakken doe je onder Debian met het make-kpkg tooltje.
Losse modules heb ik nog niet echt vaak mee gespeeld eigenlijk. Maar waarschijnlijk als je de source ophaalt, patched, en dan make-kpkg draait, dan zou het goed moeten gaan.

editje:
Waarschijnlijk zal make-kpkg modules in jouw geval de truuk doen. Worden wel alle modules opnieuw gebouwd, maar das jammer dan...

[ Voor 19% gewijzigd door thegve op 12-07-2009 01:42 ]

[MrScratch]

He, da's grappig. Ik probeer ook Wake on Lan aan de praat te krijgen op een Neoware CA2. Ik heb er naast de standaard netwerkkaart ook een Intel 1Gbit kaart in zitten. Met beiden lukt het me niet om het ding wakker te krijgen. Ik heb ook met de ethtool zitten frutten, maar daar is het ook niet gelukt. Ik draai overigens gentoo op de neoware. Als ik vooruitgang boek, laat ik het zeker weten.

Update: Ik heb nu precies datgene getest wat TS ook aangaf. Bij een reboot en dan als grub opkomt weer uitzetten, zorgt ervoor dat er op de standaard netwerkkaart een wol mogelijk is.

Ik zat me te bedenken, dat het ook mogelijk is dit geautomatiseerd te doen. Ik heb ooit een server gehad, waarvan ik de boot wilde instellen met een timer. Dit ging door deze te laden, maar dan moest de machine rebooten voor het in het rom geladen was. Hiervoor heb ik toen een extra item in grub aangemaakt, die ipv weer opstarten de machine uitzette. Met grub kan je ook een eenmalige default boot optie aanzetten en die zet je dan op deze speciale item en daarna doe je een reboot. Gevolg is dat de machine reboot en dan de shutdown item in grub kiest en zichzelf uitschakelt.

Misschien dat deze techniek ook kan werken voor dit geval. Met ethtool -s eth0 wol g, zet je wol aan, je stelt grub eenmalig in op het speciale item en doet een reboot. Ik ga eens kijken of ik dat werkend krijg.

[ Voor 55% gewijzigd door MrScratch op 12-07-2009 14:04 ]

[Robin F.]

Dat gaat waarschijnlijk niet werken. Het probleem is namelijk niet dat Wake-on-LAN gedisabled is, het is de precieze vorm van het signaal die het probleem is. De RTL8139 kan vier verschillende signalen aan het moederbord geven wanneer hij een Wake-on-LAN detecteert: Active low, active high, positive pulse en negative pulse.

Ik heb met de scoop gemeten dat de betreffende pin inderdaad hoog wordt als ik een Magic Packet verstuur na een Linux-sessie. Dat is dus de standaardactie: active high.

Meet ik die pin nou nadat ik de boot heb onderbroken, dan komt er een korte puls voorbij fietsen, en start de computer op. Dat is dus een positive pulse. Dit kun je instellen door in het Config4-register van de 8139 bit nummer 2 (genaamd LWPTN) op "1" te zetten.

Dit heb ik inmiddels gedaan in 8139too.c, en het is inmiddels gelukt te compileren. De module 8139too.ko heb ik gekopieerd naar /lib/modules/2.6.26-2-486/kernel/drivers/net/ , maar bij het booten laadt hij op de één of andere manier toch nog de oude versie... Pas als ik eerst modprobe -r 8139too en daarna weer modprobe 8139too uitvoer, laadt hij de nieuwe versie Tenminste, ik heb een printk (KERN_INFO "Gepatcht!\n"); toegevoegd om dit te controleren, en dat zie ik pas in de dmesg verschijnen nadat ik de driver heb geünload en gereload.

Anyway, zelfs als ik dus de driver heb aangepast om dat bitje goed te zetten, en het eindelijk gelukt is om de aangepaste driver te laden, werkt het nog steeds niet Ik vermoed dat later op één of andere manier de bit weer wordt teruggezet, maar ik kan dit niet terugvinden in de source van de driver.

Punt is, het is heel simpel hardwarematig op te lossen door gewoon even dat signaal om te zetten van een stap naar een puls. Maar ik heb nou net een OS waar je zelf de drivers aan kunt passen, dus ik wil het gewoon goed doen in de drivers. Dat is de Goede Oplossing, en als dat lukt, dan heeft uiteindelijk iedereen er wat aan

Ik ga nog even verder prutsen, als iemand verder nog ideeën heeft hoor ik het graag!

[vanaalten]

Kan je misschien een klein programmaatje maken, puur om even dat registerbit uit te lezen zodat je kan controleren of dat bit inderdaad wordt teruggezet, of dat er misschien iets anders aan de hand is?

[MrScratch]

Ok, nou ik wacht in spanning af of het je lukt. De driver aanpassen is inderdaad de beste manier, maar dat gaat mij iets boven de pet.

Mocht je willen dat ik de patch ook bij mijn kernel probeer, laat het me weten. Een sourcefile in gentoo aanpassen en een nieuwe kernel + modules bakken, dat lukt me waarschijnlijk nog wel.

[lamko]

Dit heb ik inmiddels gedaan in 8139too.c, en het is inmiddels gelukt te compileren. De module 8139too.ko heb ik gekopieerd naar /lib/modules/2.6.26-2-486/kernel/drivers/net/ , maar bij het booten laadt hij op de één of andere manier toch nog de oude versie... Pas als ik eerst modprobe -r 8139too en daarna weer modprobe 8139too uitvoer, laadt hij de nieuwe versie Tenminste, ik heb een printk (KERN_INFO "Gepatcht!\n"); toegevoegd om dit te controleren, en dat zie ik pas in de dmesg verschijnen nadat ik de driver heb geünload en gereload.

Ga op je hdd kijken naar 8139too.ko kijk of je verschillende versie op je hdd ziet staan is dit niet het geval.
zou ik gewoon je kernel maar opnieuw compileren dan weet je zeker dat de kernel jouw versie gebruikt !

[autostatic]

Met ethtool moet het lukken. Heb 45 thin clients in beheer met Thinstation erop die hetzelfde probleem hadden, een 8139 kaart en geen reactie op WOL pakketjes. Oplossing staat in de installatiehandleiding die ik voor die dingen heb gemaakt. Misschien heb je er wat aan.

[MrScratch]

Ik ben toch stout geweest en heb gekeken of het met een grub-entry is te fixen. Door in grub de regels:

title Halt
halt

te zetten, voeg je een mogelijkheid toe om in grub weer direct een shutdown te doen. Dat gaat prima en daarna is wol beschikbaar.

Dus mocht het met de kernel-driver niet lukken, is deze weg altijd nog een mogelijkheid.

@Autostatic: Ik kan in jouw handleiding niet vinden hoe je het probleem met de 8139 kaart fixed, behalve dat je ethtool -s eth0 wol g toevoegt aan een bepaald script, maar zoals in de topicstart is te lezen, helpt dit helaas voor de neoware CA2 niet.

[Verwijderd]

gertvdijk schreef op zaterdag 11 juli 2009 @ 21:14:
Er is ooit eens een mooi stukje over geschreven waarbij een developer erachter kwam dat de chip elke X aantal seconden een volledige rotschop moet krijgen om te laten werken.
Hoewel dus mainstream budget: crappy ondersteuning.

Bedoel je dit:

code:

   70  * It's impossible given this rotten design to really achieve decent
   71  * performance at 100Mbps, unless you happen to have a 400Mhz PII or
   72  * some equally overmuscled CPU to drive it.

http://fxr.watson.org/fxr/source/pci/if_rl.c

[autostatic]

Check morgen wel wat voor nic er precies inzit, misschien is het net een andere. En ik voeg een regel toe in het network init script. Wat er gebeurt namelijk is dat na het laden van de 8139 kernel module wol uitgeschakeld wordt. Met het ethtool commando zet je het weer aan.

Edit:

code:

Identified 8139 chip type 'RTL-8100B/8139D'

Andere chipset dus

[ Voor 13% gewijzigd door autostatic op 13-07-2009 09:41 ]

[Robin F.]

@vanaalten: Goed idee, dat heb ik nu op een aantal plaatsen in de driver gezet. Bij het laden en unloaden van de module vertelt hij nu wat er in het register staat. En het klopt steeds, dus wat dat betreft gaat het goed

@lamko: Volgens mij zijn de drivers twee keer beschikbaar: in de kernel gecompileerd èn als module in /lib/modules. Ik wist niet dat dat kon (kan het eigenlijk wel?), maar er staan nergens op de harde schijf nog andere bestanden die 8139too.ko heten dan de goede. Zelfs als ik die even een andere naam geeft, laadt hij hem bij het booten nog steeds, dus ik moet haast wel concluderen dat hij ook vast in de kernel zit.

@AutoStatic: Dank, maar dat had ik dus al geprobeerd

@MrScratch: Gelukkig is er dus een workaround, maar je bent het vast met me eens dat het niet de schoonheidsprijs verdient Still, mocht het niet lukken, dan kan ik het dus altijd nog zo oplossen.

Anyway, met alle mogelijke trucs doet hij het nog steeds niet.... Ik weet nu 99% zeker dat ik het betreffende register goed heb ingesteld, maar nog steeds geeft hij een continu signaal en geen puls op een Magic Packet. Wie weet is de datasheet onvolledig (zou me niks verbazen gezien het commentaar in de source), dus mijn volgende plan is om te kijken wat er in de registers staat op het moment dat de computer opstart (en Wake-on-LAN dus nog wel werkt).

Probleem is alleen dat de driver dus al geladen wordt voordat ik de registers uit kan lezen. Is het mogelijk om de kernel te vertellen dat hij een driver niet mag laden? Het helpt niet om hem in de modprobe blacklist te zetten (al geprobeerd).

[MrScratch]

Robin F. schreef op maandag 13 juli 2009 @ 22:39:
@MrScratch: Gelukkig is er dus een workaround, maar je bent het vast met me eens dat het niet de schoonheidsprijs verdient Still, mocht het niet lukken, dan kan ik het dus altijd nog zo oplossen.

Volledig eens, maar ik doe het er voorlopig maar mee.

Ik heb nu een script shutdown_wol.sh, en als ik die run, dan gaat de Neoware perfect in de wol-wachtstand. Bij een wol-actie gaat hij aan en boot hij weer de default kernel. Mocht je de details willen van hoe dit in grub in te richten, just let me know.

[autostatic]

Robin F. schreef op maandag 13 juli 2009 @ 22:39:
Probleem is alleen dat de driver dus al geladen wordt voordat ik de registers uit kan lezen. Is het mogelijk om de kernel te vertellen dat hij een driver niet mag laden? Het helpt niet om hem in de modprobe blacklist te zetten (al geprobeerd).

Misschien dat de module nu 2 keer geladen wordt, eerst via het initrd bestand en daarna nog een keer via udev? Misschien helpt het om de r8139too module uit initrd te halen en een nieuwe initrd aan te maken.

[gertvdijk]

AutoStatic schreef op dinsdag 14 juli 2009 @ 09:43:
[...] het initrd bestand [...]

Tegenwoordig heet dat het initramfs.
Maar je hebt wel een goed punt. Dus

update-initramfs

[lamko]

Wist niet dat de modules ook al geladen werden in de initramfs ? Maar een kernel recompile had dit dus ook verholpen met de aangepaste module er van uitgaan met de nieuwe kernel dat er ook een nieuwe initramfs komt. En het moet trouwens update-initramfs -u zijn om de al bestaande initramfs bij te werken.

[ Voor 14% gewijzigd door lamko op 14-07-2009 22:56 ]

[Robin F.]

Er zitten inderdaad een heleboel modules in initramfs, en met een update kun je die er uit halen. Dat heb ik gedaan, en nu laadt hij netjes alleen de nieuw gecompileerde driver.

Tot zover het goede nieuws, want het werkt nog steeds niet. Erger nog, zelfs als ik de 8139-drivers helemaal weg laat, dus netwerkloos start en afsluit, werkt het niet Het ligt dus niet (alleen) aan de netwerkdriver... Wanneer ik start met acpi=off, werkt het weer, maar dan kan Debian de computer dus niet meer uit zetten.

Ik heb niet zo'n zin in dat duistere doolhof genaamd ACPI, maar het lijkt toch hiermee te maken te hebben. Ik ga nog even verder kijken.

[Matis]

Ik heb eenzelfde probleem,

ik heb zowel een als Intel NIC in mijn servertje zitten; Ik draai Ubuntu 8.04, maar dat ding reageert niet op WOL. Hij *vergeet* ook zijn ethtool instellingen.

Even m'n NIC info:

• RTL 8111C chip (10/100/1000 Mbit) Onboard van Realtek (eth0)
• Intel PRO/1000 GT Desktop Adapter PCI inteekkaart (eth1)

Ik gebruik mijn onboard NIC normaliter niet, maar hij geeft hetzelfde probleem

Even een voorbeeld:

hemy@hemy-server:~$ sudo ethtool eth1
Settings for eth1:
	Supported ports: [ TP ]
	Supported link modes:   10baseT/Half 10baseT/Full 
	                        100baseT/Half 100baseT/Full 
	                        1000baseT/Full 
	Supports auto-negotiation: Yes
	Advertised link modes:  10baseT/Half 10baseT/Full 
	                        100baseT/Half 100baseT/Full 
	                        1000baseT/Full 
	Advertised auto-negotiation: Yes
	Speed: 100Mb/s
	Duplex: Full
	Port: Twisted Pair
	PHYAD: 0
	Transceiver: internal
	Auto-negotiation: on
	Supports Wake-on: umbg
	Wake-on: g
	Current message level: 0x00000007 (7)
	Link detected: yes
hemy@hemy-server:~$ sudo ethtool -s eth1 wol umbg
hemy@hemy-server:~$ sudo ethtool eth1
Settings for eth1:
	Supported ports: [ TP ]
	Supported link modes:   10baseT/Half 10baseT/Full 
	                        100baseT/Half 100baseT/Full 
	                        1000baseT/Full 
	Supports auto-negotiation: Yes
	Advertised link modes:  10baseT/Half 10baseT/Full 
	                        100baseT/Half 100baseT/Full 
	                        1000baseT/Full 
	Advertised auto-negotiation: Yes
	Speed: 100Mb/s
	Duplex: Full
	Port: Twisted Pair
	PHYAD: 0
	Transceiver: internal
	Auto-negotiation: on
	Supports Wake-on: umbg
	Wake-on: umbg
	Current message level: 0x00000007 (7)
	Link detected: yes

All good zou je denken (ik heb heven umbg gebruikt om dat het kan ).

Maar wanneer ik de server uitzet (zowel via de terminal als via de GUI), dan wordt mijn server niet meer wakker. Ik zie (wanneer ik ping en WOL) de NIC-lampjes knipperen, echter komt mijn servertje niet meeer tot leven.

Wanneeer ik hem weer handmatig aanzet, krijg ik de volgende ethtool output:

sudo ethtool eth1
Settings for eth1:
	Supported ports: [ TP ]
	Supported link modes:   10baseT/Half 10baseT/Full 
	                        100baseT/Half 100baseT/Full 
	                        1000baseT/Full 
	Supports auto-negotiation: Yes
	Advertised link modes:  10baseT/Half 10baseT/Full 
	                        100baseT/Half 100baseT/Full 
	                        1000baseT/Full 
	Advertised auto-negotiation: Yes
	Speed: 100Mb/s
	Duplex: Full
	Port: Twisted Pair
	PHYAD: 0
	Transceiver: internal
	Auto-negotiation: on
	Supports Wake-on: umbg
	Wake-on: g
	Current message level: 0x00000007 (7)
	Link detected: yes

Alles *vergeten*. De wol g (magic packet) bestaat nog wel, maar ook daar deed hij niets mee
Ik hoop niet dat dit vloeken in de kerk is, maar Windows (en de drivers van Intel) gaven me een fantastisch overzicht met welke instellingen ik de NIC kon configureren. Ik kon toen mijn server zelfs wakker *pingen*.

Echter denkt Ubuntu daar anders over.

Ik heb hier de driver gevonden die erbij hoort, echter heb ik die nog niet durven installeren.

Tevens kun je bij ethtool met de optie -i of --driver zelf een driver meegeven. Wanneer je in de readme kijkt op de site staat daar ook bij hoe je de driver moet bouwen en invoegen.

[gertvdijk]

Matis schreef op woensdag 15 juli 2009 @ 08:40:
Ik heb hier de driver gevonden die erbij hoort, echter heb ik die nog niet durven installeren.

Dat hoeft ook niet, want dat is gewoon de e1000(e) driver die in de mainline kernel zit. Alleen als je echt een nieuwere versie moet hebben voor je oude kernel zou je dat eens kunnen proberen. Maar ik ben met dit soort dingen heel voorzichtig, gezien ook de fuckup in 2.6.27-rcX waarbij Intel NICs gewoon overleden waren door een corrupt EEPROM.

[lamko]

Ik heb niet zo'n zin in dat duistere doolhof genaamd ACPI, maar het lijkt toch hiermee te maken te hebben. Ik ga nog even verder kijken.

Zou je anders niet advies vragen van een kernelontwikkelaar die wat meer thuis is in acpi ?

[gertvdijk]

lamko schreef op woensdag 15 juli 2009 @ 12:14:
Zou je anders niet advies vragen van een kernelontwikkelaar die wat meer thuis is in acpi ?

Alvorens je dat doet zou ik de laatste RC installeren en testen. Het wordt doorgaans niet gewaardeerd als je vragen (upstream) gaat stellen of bugs gaat reporten in kernels van één of twee jaar geleden (Debian Lenny = 2.6.26 = 1 jaar oud).

[Matis]

Ik kwam net zelf deze tutorial tegen:
http://lojic.com/blog/200...tu-804-linux-wake-on-lan/
Misschien kun je er wat mee. Ik ben het nu aan het proberen, alleen kan ik het niet testen, ik zit op mijn werk en mn server staat thuis

[Robin F.]

Ik heb het inmiddels opgelost, maar tot mijn spijt niet via software. Het wordt me toch teveel werk om het hele acpi-systeem te gaan bestuderen, dus heb ik het maar hardwarematig opgelost Zie hieronder (klikbaar):



Uiteindelijk heeft dit toch mijn voorkeur, want nu werkt het in elk geval met ieder besturingssysteem dat ik erop zet (en overleeft het bijvoorbeeld een kernel-upgrade), en blijft het mogelijk om het systeem remote aan te zetten als je het niet correct afsluit (wat niet het geval is bij de grub-oplossing van MrScratch). Uiteraard dank aan allen voor de hulp, ik heb er in elk geval veel van geleerd

[MrScratch]

Heel knap, maar wat heb je nu precies gedaan? In ieder geval gaat dit mijn kunde ver te boven, dus dan moet ik het probleem van niet kunnen opstarten na een incorrecte afsluiter maar voor lief nemen.

[Robin F.]

Eigenlijk heel simpel: dat oranje-witte draadje komt van de power-knop, dus als je de twee pinnen die daaronder zitten met elkaar verbindt, dan gaat de computer aan. Ik heb een transistor over die pinnen gezet (aan het eind van het gele patchdraadje), die wordt aangestuurd door het Wake-on-LAN-signaal uit de netwerkchip. Zodra hij zijn pin hoog maakt (in plaats van een puls geeft), wordt de powerknop dus bediend. De andere transistor (op de voorgrond) zorgt ervoor dat dat niet kan gebeuren als de PC al aan staat.

Het is inmiddels dus een beetje offtopic geworden voor dit subforum (ik ben zelf eigenlijk ook meer van de hardware), maar ik wou jullie deze oplossing toch niet onthouden

[lamko]

Graag even een klein schemaatje posten voor de duidelijkheid met pinbenummering en type componenten !
Verder goed bedacht en nu ben je ook niet meer afhankelijk van je bios of je moederbord of die wel of niet wake on lan ondersteunt, am I'm right ?

[Robin F.]

Hmmm, van dat laatste ben ik niet zo zeker. Je moederbord moet natuurlijk wel de netwerkkaart standby-power geven, en je netwerkkaart moet geconfigureerd zijn om te reageren op een Magic Packet (of iets anders). Maar ik kan me voorstellen dat er situaties zijn waarin dit voorkomt, dat dus het moederbord wel standby-power aan de netwerkkaart geeft, maar niet reageert op Wake-on-LAN-pulsen (mijn geval is zo'n situatie , maar misschien zijn er meer).

Anyway, het schema:



Je hebt dus pin 83 van de RTL8139 nodig (links), en de power-switch op je mobo (rechts). Verder twee willekeurige NPN-transistoren (of NMOSFET's), en twee weerstanden van zeg 1 tot 10 kΩ. "Power on" is een punt dat 3.3 of 5 volt geeft wanneer de PC aan staat (en nul als hij op standby staat). Ik heb daarvoor de +5V van de IrDA-header gebruikt omdat die in de buurt was.

Oh ja, die onderste poot van de power switch is eigenlijk gewoon GND, dus je moet wel even checken welke van de twee pinnen je moet aansluiten