Re: Call for testers: fxp(4) WOL

On Fri, Nov 07, 2008 at 08:48:44PM +0100, Alexey Shuvaev wrote:
 > On Tue, Nov 04, 2008 at 10:42:46AM +0900, Pyun YongHyeon wrote:
 > > On Mon, Nov 03, 2008 at 07:35:56PM +0100, Alexey Shuvaev wrote:
 > >  > Here are relevant messages from the verbose boot:
 > >  > 
 > >  > fxp0: <Intel 82801CAM (ICH3) Pro/100 VE Ethernet> port 0xdf40-0xdf7f mem 0xfceff000-0xfcefffff irq 11 at device 8.0 on pci2
 > > 
 > > If it's based on ICH controller it would be 82559.
 > > 
 > >  > fxp0: Reserved 0x1000 bytes for rid 0x10 type 3 at 0xfceff000
 > >  > fxp0: using memory space register mapping
 > >  > fxp0: PCI IDs: 8086 1031 1179 0001 0042
 > >  > fxp0: Dynamic Standby mode is disabled
 > >  > miibus0: <MII bus> on fxp0
 > >  > fxp0: XXX: driver didn't set ifq_maxlen
 > >  >       ^^^
 > >  > Is this something to fix?
 > >  > 
 > > 
 > > fxp(4) didn't set ifq_maxlen and if_attach corrected this with
 > > its default value. Normally network device drivers set this queue
 > > length to number of Tx descriptors but it's completely up to
 > > driver writers and I don't see compeling reason to change that.
 > > 
 > Ok, I just was attracted by something with 'XXX'.
 > 
 > >  > However the system seems to honors only the BIOS settings, if I enable WOL in
 > >  > the BIOS the system wakes up from power-down or suspend (to ram) states
 > >  > regardless of fxp settings and with disabled WOL in BIOS it never 
 > >  > wakes up.
 > >  > 
 > > 
 > > Yes that's an expected behaviour. BIOS option should be changed to
 > > enable WOL if you want to wake up your box from power down. If
 > > you don't want to wake up your box regardless of BIOS configuration
 > > you have to disable WOL with ifconfig before shutting down your
 > > box. Likewise even if you enable WOL with ifconfig(8) to wake up
 > > your system, BIOS WOL option also should be enabled to make it 
 > > work.
 > > 
 > >  > The worse thing I have noticed is if I send WOL packet while the system is
 > >  > running it reliably hangs. It does not panic and switching virtual
 > >  > consoles works (and typing/deleting something in the shell prompt too),
 > >  > but the cooler runs at full power and you can't do anything else.
 > >  > This is both with patched fxp and that from -CURRENT.
 > > 
 > > Hmm, I think that was old bebahviour of stock fxp(4). Previously
 > > fxp(4) was programmed to accept WOL packets regardless of running
 > > state of hardware. With my patch the WOL should be disabled for
 > > normal operation and WOL is enabled again when you shutdown your
 > > box. If sotck fxp(4) also show the same behaviour it's big security
 > > hole.
 > > ATM I have no idea how WOL packets can affect running box. :-(
 > > 
 > I have tested more thoroughly and here are the results.
 > 
 > FreeBSD-CURRENT (late oktober) without your patch
 > (is it what you call 'stock'?):

Yes.

 > 	interface up or down, WOL disabled or enabled in the BIOS -
 > 	system hangs when receiving WOL packet.
 > 	Breaking to debugger shows kernel running, namely 3 acpi threads,
 > 	acpi_task_[0-2].

This is critical issue, your box is vulnerable to WOL attack.

 > FreeBSD-CURRENT from 4 Nov 2008 with your patch:
 > 	again, with WOL enabled in BIOS or not, system hangs with WOL packet,
 > 	but only if interface is down.
 > 	With interface (fxp0) up and running, nothing happens.
 > 	However, I failed to disable WOL with ifconfig, notebook boots
 > 	always when WOL enabled in the BIOS.

Maybe BIOS doesn't honor preprogrammed PCI configuration data?
Or the reset command in fxp_stop() might cleared some important
configuration data.

 > Linux-Ubuntu uname: Linux ubuntu 2.6.22-14-generic #1 SMP
 > Sun Oct 14 23:05:12 GMT 2007 i686 GNU/Linux (booted live from CD)
 > 	The same results as with FreeBSD-CURRENT with your patch.
 > 	Disabling wol with ethtool does not produce the desired results.
 > 	Receiving WOL packet when interface is down does not hang the system,
 > 	but it (according to top) consumes 70% in system with
 > 	kacpid process consuming 98.5% of cpu.
 > 

Thanks a lot for your testing!

 > > Thanks for testing. I'll think again.
 > > By chance can you try Linux on your system and check whether it
 > > works?
 > >
 > So, it seems your patch is making FreeBSD on par with Linux.
 > If you need something more, you are welcome!

I still have no clue yet but would you try attached one after
backing out previous patch?

-- 
Regards,
Pyun YongHyeon