Re: [patch] WOL support for nfe(4)
On Tue, 9 Nov 2010, Pyun YongHyeon wrote: > On Tue, Nov 09, 2010 at 10:01:36PM +0100, Yamagi Burmeister wrote: > > On Tue, 9 Nov 2010, Pyun YongHyeon wrote: [..] > > >You can switch to suspend mode with "acpiconf -s1". If all goes > > >well, driver would put the controller into suspend mode after > > >reprogramming controller to accept WOL frames. After that, you can > > >wakeup the box by sending a WOL magic packet. > > > > Okay, It thought that S3 is required. Put the box into S1, waited some > > minutes and send the magic packet. The video didn't resume but I was > > able to login via SSH. So waking up by sending the WOL magic packet > > works. > > > > Thanks for testing. Probably you want to poke jkim@ to address > video resume issue. It _may_ be just a matter of toggling the value of hw.acpi.reset_video ? cheers, Ian ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: [patch] WOL support for nfe(4)
On Tue, Nov 09, 2010 at 10:01:36PM +0100, Yamagi Burmeister wrote: > On Tue, 9 Nov 2010, Pyun YongHyeon wrote: > > >>No, the link stays at 1000Mbps so the driver must manually switch back > >>to 10/100Mbps. > >> > > > >Hmm, this is real problem for WOL. Establishing 1000Mbps link to > >accept WOL frames is really bad idea since it can draw more power > >than 375mA. Consuming more power than 375mA is violation of > >PCI specification and some system may completely shutdown the power > >to protect hardware against over-current damage which in turn means > >WOL wouldn't work anymore. Even if WOL work with 1000Mbps link for > >all nfe(4) controllers, it would dissipate much more power. > > > >Because nfe(4) controllers are notorious for using various PHYs, > >it's hard to write a code to reliably establish 10/100Mbps link in > >driver. In addition, nfe(4) is known to be buggy in link state > >handling such that forced media selection didn't work well. I'll > >see what could be done in this week if I find spare time. > > Hmm... Maybe just add a hint to the manpage that WOL is possible broken? I think this may not be enough. Because it can damage your hardware under certain conditions if protection circuit was not there. > Nevertheless thanks for your work it's much appreciated :) > > >>>o When you put your box into suspend mode, can you wake up your box > >>>with WOL magic packet? > >> > >>I'm sorry but I can't test that since none of those boxes supports > >>suspend: > >> > >> % sysctl hw.acpi.suspend_state > >>hw.acpi.suspend_state: NONE > >> > > > >You can switch to suspend mode with "acpiconf -s1". If all goes > >well, driver would put the controller into suspend mode after > >reprogramming controller to accept WOL frames. After that, you can > >wakeup the box by sending a WOL magic packet. > > Okay, It thought that S3 is required. Put the box into S1, waited some > minutes and send the magic packet. The video didn't resume but I was > able to login via SSH. So waking up by sending the WOL magic packet > works. > Thanks for testing. Probably you want to poke jkim@ to address video resume issue. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: [patch] WOL support for nfe(4)
On Tue, 9 Nov 2010, Pyun YongHyeon wrote: No, the link stays at 1000Mbps so the driver must manually switch back to 10/100Mbps. Hmm, this is real problem for WOL. Establishing 1000Mbps link to accept WOL frames is really bad idea since it can draw more power than 375mA. Consuming more power than 375mA is violation of PCI specification and some system may completely shutdown the power to protect hardware against over-current damage which in turn means WOL wouldn't work anymore. Even if WOL work with 1000Mbps link for all nfe(4) controllers, it would dissipate much more power. Because nfe(4) controllers are notorious for using various PHYs, it's hard to write a code to reliably establish 10/100Mbps link in driver. In addition, nfe(4) is known to be buggy in link state handling such that forced media selection didn't work well. I'll see what could be done in this week if I find spare time. Hmm... Maybe just add a hint to the manpage that WOL is possible broken? Nevertheless thanks for your work it's much appreciated :) o When you put your box into suspend mode, can you wake up your box with WOL magic packet? I'm sorry but I can't test that since none of those boxes supports suspend: % sysctl hw.acpi.suspend_state hw.acpi.suspend_state: NONE You can switch to suspend mode with "acpiconf -s1". If all goes well, driver would put the controller into suspend mode after reprogramming controller to accept WOL frames. After that, you can wakeup the box by sending a WOL magic packet. Okay, It thought that S3 is required. Put the box into S1, waited some minutes and send the magic packet. The video didn't resume but I was able to login via SSH. So waking up by sending the WOL magic packet works. -- Homepage: www.yamagi.org Jabber: yam...@yamagi.org GnuPG/GPG:0xEFBCCBCB ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Problems with 8.1, PPPoE server, and Cisco client
On 11/9/10 12:18 PM, Paul Thornton wrote: Hi folks, Keeping the list archives updated for any poor soul that has a similar problem in future... On 26/10/2010 18:55, Paul Thornton wrote: I'm also going to give mpd a go and see if that works - but if it tries the same config options as pppoed then I may be straight back to where I am now. The verdict with mpd is exactly the same - the Cisco takes exception to the IPCP request immediately following the successful auth, and tears down the connection. I'm going to take this to the Cisco TAC and see if they can suggest anything that may be causing this as it makes no sense at all when all other clients I try work. take especial care with netmasks and network definitions if you have any Paul. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org" ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Problems with 8.1, PPPoE server, and Cisco client
On 09/11/2010 20:16, Paul Thornton wrote: > Sorry for that unedited copy of the last mail to the list. Finger trouble in mail client. Must try harder! Paul. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Problems with 8.1, PPPoE server, and Cisco client
Hi folks, Keeping the list archives updated for any poor soul that has a similar problem in future... On 26/10/2010 18:55, Paul Thornton wrote: > I'm also going to give mpd a go and see if that works - but if it tries > the same config options as pppoed then I may be straight back to where I > am now. The verdict with mpd is exactly the same - the Cisco takes exception to the IPCP request immediately following the successful auth, and tears down the connection. I'm going to take this to the Cisco TAC and see if they can suggest anything that may be causing this as it makes no sense at all when all other clients I try work. Paul. ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: Problems with 8.1, PPPoE server, and Cisco client
On 26/10/2010 18:55, Paul Thornton wrote: > I've been taking another look at this after being dragged off onto other > things for a few days, and hopefully have some more information that > might help point in the right direction for a fix / where to debug next. > > On 20/10/2010 17:16, Julian Elischer wrote: >> have you tried to connect this cisco router to anything else pppoe? >> (take it home and make it connect to your ISP for example?) > The Cisco client does work to a Cisco router acting as a PPPoE server - > I used a 891 (client) to a 3945 (server) and using an established setup > that is known to work, I collected a happy tcpdump. Of course that > doesn't tell us why there was such an issue with the FreeBSD ppp server > and it looks very similar to me. > > I'm also going to give mpd a go and see if that works - but if it tries > the same config options as pppoed then I may be straight back to where I > am now. > > Thanks to everyone for their help with this. > > So here is the dump from a known good setup, IOS at both ends - starting > from the CHAP success point again. This time, both ends play the game > and agree amongst themselves what they will and won't do as expected > (many thanks to Ian here for the commentary as to what was going on in > the exchanges I have): > >> 20:29:10.200860 PPPoE [ses 0x13] CHAP, Response (0x02), id 1, Value >> 8f917e3cd84fd4b3a5e8b705655bf16772d0cd1462392eed8bb4ab0ccb7f75bb2d01695ac26cdc07127b4fb3435a279a01, >> Name vt123456...@vdsl01.v >> 20:29:14.501312 PPPoE [ses 0x13] CHAP, Success (0x03), id 1, Msg >> 20:29:14.501702 PPPoE [ses 0x13] IPCP, Conf-Request (0x01), id 1, length 12 >> encoded length 10 (=Option(s) length 6) >> 0x: 8021 0101 000a >>IP-Addr Option (0x03), length 6: 109.71.168.123 >> 0x: 6d47 a87b >> 20:29:14.504344 PPPoE [ses 0x13] IPCP, Conf-Request (0x01), id 1, length 12 >> encoded length 10 (=Option(s) length 6) >> 0x: 8021 0101 000a >>IP-Addr Option (0x03), length 6: 0.0.0.0 >> 0x: >> 20:29:14.504497 PPPoE [ses 0x13] unknown PPP protocol (0x8207) >> 0x: 0101 0004 >> 20:29:14.504669 PPPoE [ses 0x13] IPCP, Conf-Ack (0x02), id 1, length 12 >> encoded length 10 (=Option(s) length 6) >> 0x: 8021 0201 000a >>IP-Addr Option (0x03), length 6: 109.71.168.123 >> 0x: 6d47 a87b >> 20:29:14.505200 PPPoE [ses 0x13] IPCP, Conf-Nack (0x03), id 1, length 12 >> encoded length 10 (=Option(s) length 6) >> 0x: 8021 0301 000a >>IP-Addr Option (0x03), length 6: 109.71.174.50 >> 0x: 6d47 ae32 >> 20:29:14.505290 PPPoE [ses 0x13] LCP, Prot-Reject (0x08), id 2, length 12 >> encoded length 10 (=Option(s) length 6) >> 0x: c021 0802 000a >>Rejected unknown Protocol (0x8207) >>Rejected Packet >> 0x: 0101 0006 >> 20:29:14.505800 PPPoE [ses 0x13] IPCP, Conf-Request (0x01), id 2, length 12 >> encoded length 10 (=Option(s) length 6) >> 0x: 8021 0102 000a >>IP-Addr Option (0x03), length 6: 109.71.174.50 >> 0x: 6d47 ae32 >> 20:29:14.506753 PPPoE [ses 0x13] IPCP, Conf-Ack (0x02), id 2, length 12 >> encoded length 10 (=Option(s) length 6) >> 0x: 8021 0202 000a >>IP-Addr Option (0x03), length 6: 109.71.174.50 >> 0x: 6d47 ae32 >> 20:29:23.247975 PPPoE [ses 0x13] IP (tos 0x0, ttl 255, id 35, offset 0, >> flags [none], proto ICMP (1), length 100) >> 109.71.174.50 > 217.65.161.4: ICMP echo request, id 10, seq 0, length 80 >> 20:29:23.257872 PPPoE [ses 0x13] IP (tos 0x0, ttl 61, id 51771, offset 0, >> flags [none], proto ICMP (1), length 100) >> 217.65.161.4 > 109.71.174.50: ICMP echo reply, id 10, seq 0, length 80 > The ping here is the start of real data flowing - I used this setup for > about 30 minutes of web browsing with no problems. > > Paul. > > ___ > freebsd-net@freebsd.org mailing list > http://lists.freebsd.org/mailman/listinfo/freebsd-net > To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org" ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: [patch] WOL support for nfe(4)
On Tue, Nov 09, 2010 at 09:49:14AM +0100, Yamagi Burmeister wrote: > > Thanks for your reply. > > On Mon, 8 Nov 2010, Pyun YongHyeon wrote: > > >Thanks for the patch. I attached slightly modified the code to > >better match other WOL capable drivers in tree. Because data sheet > >is not available I blindly made a patch based on your code. I have > >a couple of questions which I can't verify it on real hardware(I > >have no more access to the hardware). > > > >o If you established a gigabit link with link partner and shutdown > > your box, does the established link automatically change to 10 or > > 100Mbps? You can check it on your link partner. If your link > > partner still reports it established 1000Mbps link, we have to > > do other necessary work in driver(i.e. manually switching to > > 10/100Mbps). > > No, the link stays at 1000Mbps so the driver must manually switch back > to 10/100Mbps. > Hmm, this is real problem for WOL. Establishing 1000Mbps link to accept WOL frames is really bad idea since it can draw more power than 375mA. Consuming more power than 375mA is violation of PCI specification and some system may completely shutdown the power to protect hardware against over-current damage which in turn means WOL wouldn't work anymore. Even if WOL work with 1000Mbps link for all nfe(4) controllers, it would dissipate much more power. Because nfe(4) controllers are notorious for using various PHYs, it's hard to write a code to reliably establish 10/100Mbps link in driver. In addition, nfe(4) is known to be buggy in link state handling such that forced media selection didn't work well. I'll see what could be done in this week if I find spare time. > >o When you put your box into suspend mode, can you wake up your box > > with WOL magic packet? > > I'm sorry but I can't test that since none of those boxes supports > suspend: > > % sysctl hw.acpi.suspend_state > hw.acpi.suspend_state: NONE > You can switch to suspend mode with "acpiconf -s1". If all goes well, driver would put the controller into suspend mode after reprogramming controller to accept WOL frames. After that, you can wakeup the box by sending a WOL magic packet. > >o When your system boots up with/without WOL magic packet, sending > > WOL magic packets from other hosts can hang your box? > > No they don't. No matter if the box was started by sending the WOL magic > packet or by hand it survives all WOL packets I send to it. > Ok, some controllers are known to hang the box if it receive WOL frames before initializing controller. > >o If you disabled WOL with ifconfig before system shutdown, can you > > still wakeup your box with WOL magic packet? > > No, I can't. WOL is disabled and the box must be started manually. > > >o If you reprogram your station address with ifconfig(i.e. ifconfig > > nfe0 ether xx:xx:xx:xx:xx:xx), can you still wakeup your box with > > WOL magic packet? > > Yes, with sending the WOL magic packet to the new station adress. > Sending it to the original adress doesn't work. > > >The patch I made didn't take into account management firmware so > >if you use the patch with IMPI, IMPI wouldn't work. But I think > >that's not an issue since all other parts of nfe(4) also ignores > >management firmware at this moment. > > I can't test that, because none of these machines has the IPMI option > installed. Sorry. > Ok, all other features except wakeup from suspend seem to work. Thanks for testing! ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Re: [patch] WOL support for nfe(4)
Thanks for your reply. On Mon, 8 Nov 2010, Pyun YongHyeon wrote: Thanks for the patch. I attached slightly modified the code to better match other WOL capable drivers in tree. Because data sheet is not available I blindly made a patch based on your code. I have a couple of questions which I can't verify it on real hardware(I have no more access to the hardware). o If you established a gigabit link with link partner and shutdown your box, does the established link automatically change to 10 or 100Mbps? You can check it on your link partner. If your link partner still reports it established 1000Mbps link, we have to do other necessary work in driver(i.e. manually switching to 10/100Mbps). No, the link stays at 1000Mbps so the driver must manually switch back to 10/100Mbps. o When you put your box into suspend mode, can you wake up your box with WOL magic packet? I'm sorry but I can't test that since none of those boxes supports suspend: % sysctl hw.acpi.suspend_state hw.acpi.suspend_state: NONE o When your system boots up with/without WOL magic packet, sending WOL magic packets from other hosts can hang your box? No they don't. No matter if the box was started by sending the WOL magic packet or by hand it survives all WOL packets I send to it. o If you disabled WOL with ifconfig before system shutdown, can you still wakeup your box with WOL magic packet? No, I can't. WOL is disabled and the box must be started manually. o If you reprogram your station address with ifconfig(i.e. ifconfig nfe0 ether xx:xx:xx:xx:xx:xx), can you still wakeup your box with WOL magic packet? Yes, with sending the WOL magic packet to the new station adress. Sending it to the original adress doesn't work. The patch I made didn't take into account management firmware so if you use the patch with IMPI, IMPI wouldn't work. But I think that's not an issue since all other parts of nfe(4) also ignores management firmware at this moment. I can't test that, because none of these machines has the IPMI option installed. Sorry. Ciao, Yamagi -- Homepage: www.yamagi.org Jabber: yam...@yamagi.org GnuPG/GPG:0xEFBCCBCB ___ freebsd-net@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-net To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
