Call for testers: fxp(4) WOL - FreeBSD

This is a discussion on Call for testers: fxp(4) WOL - FreeBSD ; I've implemented WOL for fxp(4) and it works ok to me. Because there too many variants of fxp(4) hardwares I'd like to hear success/failure report before committing attached patch to tree. It seems that the following Intel 8255x supports WOL. ...

+ Reply to Thread
Results 1 to 7 of 7

Thread: Call for testers: fxp(4) WOL

  1. Call for testers: fxp(4) WOL

    I've implemented WOL for fxp(4) and it works ok to me. Because
    there too many variants of fxp(4) hardwares I'd like to hear
    success/failure report before committing attached patch to tree.
    It seems that the following Intel 8255x supports WOL. Apparently
    82557 lacks WOL capabillity.

    82558
    82559
    82550
    82551

    If your suspend/resume works on your system you can also wake up
    your system in suspend by WOL.

    Thanks.
    --
    Regards,
    Pyun YongHyeon

    _______________________________________________
    freebsd-current@freebsd.org mailing list
    http://lists.freebsd.org/mailman/lis...reebsd-current
    To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"

  2. Re: Call for testers: fxp(4) WOL

    On Wed, Oct 15, 2008 at 09:37:45AM +0900, Pyun YongHyeon wrote:
    > I've implemented WOL for fxp(4) and it works ok to me. Because
    > there too many variants of fxp(4) hardwares I'd like to hear
    > success/failure report before committing attached patch to tree.
    > It seems that the following Intel 8255x supports WOL. Apparently
    > 82557 lacks WOL capabillity.
    >
    > 82558
    > 82559
    > 82550
    > 82551
    >

    How can one figure out which chip he has?
    I have relative old Toshiba notebook with integrated intel network card.
    The system is:

    FreeBSD localhost.my.domain 8.0-CURRENT FreeBSD 8.0-CURRENT #0: Mon Oct 27 01:25:54 CET 2008 root@localhost.my.domain:/usr/obj/usr/src/sys/GENERIC i386

    Here are relevant messages from the verbose boot:

    fxp0: port 0xdf40-0xdf7f mem 0xfceff000-0xfcefffff irq 11 at device 8.0 on pci2
    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: on fxp0
    fxp0: XXX: driver didn't set ifq_maxlen
    ^^^
    Is this something to fix?

    fxp0: bpf attached
    fxp0: Ethernet address: xx:xx:xx:xx:xx:xx
    fxp0: [MPSAFE]
    fxp0: [ITHREAD]

    and this is the output from pciconv -lvc:

    fxp0@pci0:2:8:0: class=0x020000 card=0x00011179 chip=0x10318086 rev=0x42 hdr=0x00
    vendor = 'Intel Corporation'
    device = '82801CAM (ICH3) PRO/100 VE (LOM) Network Connection'
    class = network
    subclass = ethernet
    cap 01[dc] = powerspec 2 supports D0 D1 D2 D3 current D0

    It seems that driver changes something, after boot or 'ifconfig fxp0 wol':

    fxp0: flags=8843 metric 0 mtu 1500
    options=2008

    and after 'ifconfig fxp0 -wol':

    fxp0: flags=8843 metric 0 mtu 1500
    options=8

    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.

    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.

    > If your suspend/resume works on your system you can also wake up
    > your system in suspend by WOL.
    >

    Actually, the system does not wake up from suspended mode properly, either
    by power button or by WOL packet, but it tries.

    > Thanks.

    Thank you, if you need something more (debugging output,
    testing new patches, digging deeper...) just let me know.

    Alexey.
    _______________________________________________
    freebsd-current@freebsd.org mailing list
    http://lists.freebsd.org/mailman/lis...reebsd-current
    To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"


  3. Re: Call for testers: fxp(4) WOL

    On Mon, Nov 03, 2008 at 07:35:56PM +0100, Alexey Shuvaev wrote:
    > On Wed, Oct 15, 2008 at 09:37:45AM +0900, Pyun YongHyeon wrote:
    > > I've implemented WOL for fxp(4) and it works ok to me. Because
    > > there too many variants of fxp(4) hardwares I'd like to hear
    > > success/failure report before committing attached patch to tree.
    > > It seems that the following Intel 8255x supports WOL. Apparently
    > > 82557 lacks WOL capabillity.
    > >
    > > 82558
    > > 82559
    > > 82550
    > > 82551
    > >

    > How can one figure out which chip he has?
    > I have relative old Toshiba notebook with integrated intel network card.
    > The system is:
    >
    > FreeBSD localhost.my.domain 8.0-CURRENT FreeBSD 8.0-CURRENT #0: Mon Oct 27 01:25:54 CET 2008 root@localhost.my.domain:/usr/obj/usr/src/sys/GENERIC i386
    >
    > Here are relevant messages from the verbose boot:
    >
    > fxp0: 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: 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.

    > fxp0: bpf attached
    > fxp0: Ethernet address: xx:xx:xx:xx:xx:xx
    > fxp0: [MPSAFE]
    > fxp0: [ITHREAD]
    >
    > and this is the output from pciconv -lvc:
    >
    > fxp0@pci0:2:8:0: class=0x020000 card=0x00011179 chip=0x10318086 rev=0x42 hdr=0x00
    > vendor = 'Intel Corporation'
    > device = '82801CAM (ICH3) PRO/100 VE (LOM) Network Connection'
    > class = network
    > subclass = ethernet
    > cap 01[dc] = powerspec 2 supports D0 D1 D2 D3 current D0
    >
    > It seems that driver changes something, after boot or 'ifconfig fxp0 wol':
    >
    > fxp0: flags=8843 metric 0 mtu 1500
    > options=2008
    >


    It indicates your controller supports WOL with magic packet.

    > and after 'ifconfig fxp0 -wol':
    >
    > fxp0: flags=8843 metric 0 mtu 1500
    > options=8
    >
    > 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. :-(

    >
    > > If your suspend/resume works on your system you can also wake up
    > > your system in suspend by WOL.
    > >

    > Actually, the system does not wake up from suspended mode properly, either
    > by power button or by WOL packet, but it tries.
    >


    The system I tried didn't resume properly (blank screen) but I
    could login via network after sending WOL magic packets so I
    thought resume also works.

    > > Thanks.

    > Thank you, if you need something more (debugging output,
    > testing new patches, digging deeper...) just let me know.


    Thanks for testing. I'll think again.
    By chance can you try Linux on your system and check whether it
    works?
    --
    Regards,
    Pyun YongHyeon
    _______________________________________________
    freebsd-current@freebsd.org mailing list
    http://lists.freebsd.org/mailman/lis...reebsd-current
    To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"


  4. Re: Call for testers: fxp(4) WOL

    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: 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: 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'?):
    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].
    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.
    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 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!

    Alexey.
    _______________________________________________
    freebsd-current@freebsd.org mailing list
    http://lists.freebsd.org/mailman/lis...reebsd-current
    To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"


  5. 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: 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: 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

    _______________________________________________
    freebsd-current@freebsd.org mailing list
    http://lists.freebsd.org/mailman/lis...reebsd-current
    To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"

  6. Re: Call for testers: fxp(4) WOL

    On Sat, Nov 08, 2008 at 04:59:29PM +0900, Pyun YongHyeon wrote:
    > On Fri, Nov 07, 2008 at 08:48:44PM +0100, Alexey Shuvaev wrote:
    > > 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.
    >

    Yop. I was badly surprised by the dead system after I ocasionally sent
    WOL packet to the running system.

    > > 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.
    >

    Ha! Bingo! See below.

    > > 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!
    >
    > > 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?
    >

    Much, much better! Almost all issues are gone \O/.
    So, if I do ifconfig fxp0 up then the system does not react to WOL packets.
    And this is even if I do ifconfig fxp0 down afterwards.
    (With previous patch system always hangs in interface down state.)
    And if I shutdown system with ifconfig fxp0 -wol then it will not wake! Great!

    The only remaining thing is system vulnerability right after the boot
    before interface configuration. Receiving WOL packet in this interval
    hangs the system as before. Could this be fixed near attach routine
    or something similar? And also if I do ifconfig fxp0 -wol in this period
    and shutdown the system it will then wake on WOL packet.
    It is ifcongig fxp0 up that forces all things to work properly.

    > --
    > Regards,
    > Pyun YongHyeon
    >

    Thanks a lot,
    Alexey.
    _______________________________________________
    freebsd-current@freebsd.org mailing list
    http://lists.freebsd.org/mailman/lis...reebsd-current
    To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"


  7. Re: Call for testers: fxp(4) WOL

    On Sat, Nov 08, 2008 at 09:56:49PM +0100, Alexey Shuvaev wrote:

    [...]

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

    > Much, much better! Almost all issues are gone \O/.


    Glad to hear that. :-)

    > So, if I do ifconfig fxp0 up then the system does not react to WOL packets.
    > And this is even if I do ifconfig fxp0 down afterwards.
    > (With previous patch system always hangs in interface down state.)
    > And if I shutdown system with ifconfig fxp0 -wol then it will not wake! Great!
    >
    > The only remaining thing is system vulnerability right after the boot
    > before interface configuration. Receiving WOL packet in this interval
    > hangs the system as before. Could this be fixed near attach routine
    > or something similar? And also if I do ifconfig fxp0 -wol in this period
    > and shutdown the system it will then wake on WOL packet.
    > It is ifcongig fxp0 up that forces all things to work properly.
    >


    I've added hardware initialization routine in device attach.
    In theory it may have hardware reject magic frames, would you try
    attached one again after backing out previous one?

    Thanks.
    --
    Regards,
    Pyun YongHyeon

    _______________________________________________
    freebsd-current@freebsd.org mailing list
    http://lists.freebsd.org/mailman/lis...reebsd-current
    To unsubscribe, send any mail to "freebsd-current-unsubscribe@freebsd.org"

+ Reply to Thread