Author:
Mike Ireton (The insane laughing clown of wireless broadband)
|
[
Next Thread |
Previous Thread |
Next Message |
Previous Message
]
Date Posted: 22:15:57 2006-07-29 Sat
Author Host/IP: 65.127.35.1 In reply to:
David F. Skoll
's message, "Re: Bug report: discovery fails if non-expected packets hit interface" on 12:51:41 2006-07-29 Sat
>I have committed code into CVS to fix this, but
>further analysis reveals that in the real world, it
>should not be a problem. rp-pppoe is designed to be
>used with Linux's pppd, and that has its own timeout
>which will kill the pppoe process if it becomes
>unresponsive. (The default rp-pppoe setup includes
>LCP-Echo timeouts, which should kill the unresponsive
>pppoe process and start over again.)
>
I am not aware of linux pppd having a timer for this situation, by the way. I do know it has some timeouts if used with the pty option in order kill that process if necessary, and this certainly does work in conjunction with lcp-echo and such. But with pppoe as a plugin, I am not so sure. When debugging this problem and with liberal syslog()'s sprinked about, I never saw pppd interrupting anything; control stayed within waitForPADO() the entire time, and I never saw it re-entered. And this was over the course of hours while caught in waitForPADO(), I would have saw something if it had left that loop.
>(If you want to test the latest CVS version, please
>e-mail me: dfs@roaringpenguin.com and I'll make a
>tarball for you.)
I'll take you up on that.
Mike-
[
Next Thread |
Previous Thread |
Next Message |
Previous Message
]
|