| Summary: | net-misc/br2684ctl is too fast | ||
|---|---|---|---|
| Product: | Gentoo Linux | Reporter: | Helmut Jarausch <jarausch> |
| Component: | Current packages | Assignee: | Gentoo Dialup Developers <net-dialup> |
| Status: | RESOLVED WONTFIX | ||
| Severity: | normal | CC: | axiator, base-system, marat.buharov, pacho, roy |
| Priority: | High | ||
| Version: | unspecified | ||
| Hardware: | All | ||
| OS: | Linux | ||
| Whiteboard: | |||
| Package list: | Runtime testing required: | --- | |
| Attachments: | patch for openrc's /lib64/rc/net/br2684ctl.sh | ||
|
Description
Helmut Jarausch
2009-04-20 18:31:13 UTC
Created attachment 188972 [details, diff]
patch for openrc's /lib64/rc/net/br2684ctl.sh
assigning to maintainers (In reply to comment #1) > Created an attachment (id=188972) [edit] > patch for openrc's /lib64/rc/net/br2684ctl.sh > Further tests have shown that a 'sleep 1' instead of 'sleep 30' (as proposed in my previous patch) suffices. I think, this addition to /lib/rc/net/br2684ctl.sh is more reasonable than patch (it checks the interface creation every second)
Instead of "sleep 30" I suggest that:
local endval="$?" timeout=30 i=0
while true; do
if [ -e /dev/${IFACE} ]; then
eend ${endval}
fi
sleep 1
[ ${timeout} -eq 0 ] && continue
i=$((${i} + 1))
[ ${i} -ge ${timeout} ] && break
done
eend ${endval}
Roy, is this still an issue with the current openrc? I looked at the code in git and do not see where a sleep has been inserted. If it is still an issue, could this be fixed before the next release? imo the br2684 program should do this before the parent process returns. Sorry, I can not test it anymore because my old AccessRunner-based ADSL-modem has been died. So I switched to ADSL-router and currently that problem is not for me. Net-dialup team, can someone look into fixing this? It has been determined that fixing br2684ctl would be a better option than delaying in openrc. Also, this is a blocker for openrc going stable. Thanks, William (In reply to comment #8) > Net-dialup team, > can someone look into fixing this? It has been determined that fixing > br2684ctl would be a better option than delaying in openrc. What is the status of this bug? Should we leave this as a blocker? Thanks, > William William, I don't know if this helps you, but... there is linux-atm package which also provides br2684ctl, and since there is no bug opened against it probably it's good idea to suggest use that. At least debian uses br2684ctl from linux-atm in the recent distributions. But well, Alin knows this things better... BTW, have anybody tried linux-atm with openrc? There is need to change file /usr/share/doc/openrc-0.6.0-r1/net.example
>>>>>>
#-----------------------------------------------------------------------------
# RFC 2684 Bridge Support
# For RFC 2684 bridge support emerge net-misc/br2684ctl
<<<<<<
(In reply to comment #10) > BTW, have anybody tried linux-atm with openrc? > After diffing /var/tmp/portage/net-misc/br2684ctl-20040226/work/br2684ctl-20040226.orig/br2684ctl.c against /var/tmp/portage/net-dialup/linux-atm-2.5.0/work/linux-atm-2.5.0/src/br2684/br2684ctl.c it seems that problem remains. In source from linux-atm there is no checks for real interface creation (I'm not accounting asynchronous call for ioctl which is the same as in net-misc/br2684ctl) (In reply to comment #10) > William, I don't know if this helps you, but... there is linux-atm package > which also provides br2684ctl, and since there is no bug opened against it > probably it's good idea to suggest use that. At least debian uses br2684ctl > from linux-atm in the recent distributions. But well, Alin knows this things > better... > BTW, have anybody tried linux-atm with openrc? I would say that we need to know for sure whether the separate package br2684ctl is deprecated, and if it is, remove it from the tree. Also, there is a bug requesting aversion bump for linux-atm. We need to do that and figure out whether that fixes this issue. Thanks, William (In reply to comment #12) > (In reply to comment #10) > > BTW, have anybody tried linux-atm with openrc? > > > After diffing > /var/tmp/portage/net-misc/br2684ctl-20040226/work/br2684ctl-20040226.orig/br2684ctl.c > against > /var/tmp/portage/net-dialup/linux-atm-2.5.0/work/linux-atm-2.5.0/src/br2684/br2684ctl.c > it seems that problem remains. In source from linux-atm there is no checks for > real interface creation (I'm not accounting asynchronous call for ioctl which > is the same as in net-misc/br2684ctl) Have you actually tested linux-atm with openrc to see if the issue happens? I'm not on dialup, so there is no way for me to do that. Thanks, William (In reply to comment #14) > Have you actually tested linux-atm with openrc to see if the issue happens? > I'm not on dialup, so there is no way for me to do that. > No. In comment #7 I wrote that my ADSL-modem has been died. So, I can not check it now. You're going to find it harder and harder to find testers. Most DSL providers are moving to the newer DSL technologies as they can transition their customers off to PPPoE (I believe all US providers have moved to PPPoE by now). The configuration used by people in this situation is PPPoA, which I believe you'll have a hard time finding. I say we remove this as a blocker and fix it when we get a bug report. (In reply to comment #16) > You're going to find it harder and harder to find testers. Most DSL providers > are moving to the newer DSL technologies as they can transition their customers > off to PPPoE (I believe all US providers have moved to PPPoE by now). The > configuration used by people in this situation is PPPoA, which I believe you'll > have a hard time finding. br2684 is used in PPPoE configuration for some USB-modems (Alcatel Speedtouch or Connexant Accessrunner for example) in bridged mode (for establishing ethernet channel over ADSL and then pppd creates PPPoE link on top of that channel). But I think that there are too few people who use that modems, most of them switched to ADSL-routers. dropped |
