Hide Forgot
Created attachment 527887 [details] Prevent endless discovery loop Description of problem: Timeout is ignored for broadcast type packets and some other type packets. Package rp-pppoe-3.5-32.1 and previous and newer versions. File discovery.c Function waitForPADS(PPPoEConnection *conn, int timeout) Hope the issue is seen in patch file (attached). Version-Release number of selected component (if applicable): Package rp-pppoe-3.5-32.1 think all newer had not fixed the bug too. How reproducible: Put client machine in the environment where there are PADI broadcast packets send by other machines. So usual discovery request like "pppoe -A -d" will loop endless (at list much more then timeout). Steps to Reproduce: For example: 1. On machine "B-client": while true; do pppoe -I eth1 -A -d -T2; done; 2. On machine "A-client": pppoe -A -d -I eth1 -T2 will loop much much more then 2 seconds... Actual results: Loop forever in discovery cycle. Expected results: Return access concentrators on timeout measures. Additional info: First I put this bug description at http://bugs.centos.org/view.php?id=5043
Why there is no activity with this bug? Does anything unclear? Should I give more info? Is patch understandable?
This request was evaluated by Red Hat Product Management for inclusion in the current release of Red Hat Enterprise Linux. Because the affected component is not scheduled to be updated in the current release, Red Hat is unable to address this request at this time. Red Hat invites you to ask your support representative to propose this request, if appropriate, in the next release of Red Hat Enterprise Linux.
This bug/component is not included in scope for RHEL-5.11.0 which is the last RHEL5 minor release. This Bugzilla will soon be CLOSED as WONTFIX (at the end of RHEL5.11 development phase (Apr 22, 2014)). Please contact your account manager or support representative in case you need to escalate this bug.
Thank you for submitting this request for inclusion in Red Hat Enterprise Linux 5. We've carefully evaluated the request, but are unable to include it in RHEL5 stream. If the issue is critical for your business, please provide additional business justification through the appropriate support channels (https://access.redhat.com/site/support).