I developed a network init script to allow a gentoo system to establish a CLIP connection at startup. I'm using it on a 2.6.13-gentoo kernel with linux-atm-2.4.1-r1 and iproute2- 2.6.11.20050330 and it works pretty well to me, so I would like to contribute it to the gentoo community. I'm attaching it inline. The script should be named /lib/rcscripts/net.modules.d/clip . Regards, Giampaolo --BEGIN #!/bin/bash # Copyright (c) 2005 Gentoo Foundation # Distributed under the terms of the GNU General Public License v2 # Contributed by Giampaolo Tomassoni <g.tomassoni@libero.it> # # This is a Classical IP over ATM network init script for Gentoo. # # Requirements # - CONFIG_ATM_CLIP must be enabled before building the linux kernel. # - The net-dialup/linux-atm package must be emerged # - If a modular built of the clip kernel module was choosen, it is suggested # to pre-load it at boot time by adding the line: # # clip # # to the /etc/modules.autoload.d/kernel-2.x file. # # Usage # Build your linux kernel with ATM CLIP support and emerge the # net-dialup/linux-atm package. Then chdir to /etc/init.d and make a symlink to # net.lo naming it net.atmX, where X is 0 to 9. You may setup more CLIP inter- # faces if you have more than a single connection. Anyway, please note that it # is better to have the first interface name start by 0. So, your first CLIP # conn will be named atm0, the second atm1 and so on. # # Now have a look at "man atmsigd.conf" and edit the file /etc/atmsigd.conf # according to your preferences. My own /etc/atmsigd.conf looks this: # # # atmsigd.conf - configuration data for atmsigd # # # # See the atmsigd.conf man page for configuration details. # # # # debug { # level warn # dump /var/tmp # log syslog # trace 100 # } # # sig { # uni30 # uni31 # } # # but you may prefer a different setup, expecially for the "sig {}" section. # # Now edit the file /etc/conf.d/net, adding entries like config_atmX= and # routes_atmX= as for every standard tcp/ip device. Then, you have to add one # or more clip_atmX= entries to the file. Their syntax is: # # clip_atmX=( "peer_ip [if.]vpi.vci [opts]" ... ) # # where "peer_ip" is the IP address of a PVC peer (in case of an ATM connection # with your ISP, your only peer is usually the ISP gateway closest to you), # "if" is the number of the ATM interface which will carry the PVC, "vpi.vci" # is the ATM VC address, and "opts" may optionally specify VC parameters like # qos, pcr, and the like (see "atmarp -s" for further reference). # # By default, the PVC will use the LLC/SNAP encapsulation. If you need a null # encapsulation (aka "VC mode"), please add the keyword "null" to opts. # # An example of /etc/conf.d/net setup for an LLC/SNAP-encapsulated CLIP con- # nection having ip address 1.1.1.1, netmask 255.255.255.0 and remote gateway # 1.1.1.254 would be: # # clip_atm0=( "1.1.1.254 8.35" ) # config_atm0=( "1.1.1.1/24" ) # routes_atm0=( "default via 1.1.1.254" ) <- iproute2 # or # routes_atm0=( "0.0.0.0/0 gw 1.1.1.254" ) <- ifconfig # # Now save the file and execute the command: # # /etc/init.d/net.atm0 start # # you should see an output similar to the following: # #* Starting atm0 #* First CLIP instance: starting ATM CLIP daemons #* Starting Signaling Daemon (atmsigd) ... [ ok ] #* Starting Integrated Local Management Interface Daemon (ilmid) ...[ ok ] #* Starting Address Resolution Protocol Daemon (atmarpd) ... [ ok ] #* Creating CLIP interface atm0 ... [ ok ] #* Bringing up atm0 #* 1.1.1.1/24 [ ok ] #* Creating PVC 8.35 for peer 1.1.1.254 ... [ ok ] # # The link is now up. Please note that, as opposed to other protocols like the # PPP-over-ATM one, the CLIP protocol has no provision for automatic system # configuration: you have to manually add your ISP's DNS servers to the # /etc/resolv.conf file in order to successfully start surfing. When you've # done with the CLIP link, issue a: # # /etc/init.d/net.atm0 stop # # which should produce an output like: # #* Stopping atm0 #* Removing PVCs on this interface #* Removing PVC to 81.75.231.254 ... [ ok ] #* Bringing down atm0 #* Shutting down atm0 ... [ ok ] #* Last CLIP instance: stopping ATM CLIP daemons #* Stopping Address Resolution Protocol Daemon (atmarpd) ... [ ok ] #* Stopping Integrated Local Management Interface Daemon (ilmid) ...[ ok ] #* Stopping Signaling Daemon (atmsigd) ... [ ok ] # # Of course, you can start your CLIP connection(s) automatically at system # startup by issuing a: # # rc-update add net.atmX default # # but please read first the "Known bugs and limitations" section. # # # Known bugs and limitations # - It should be possible to specify an ATM SVC address instead of the PVC one, # but this is actually not yet tested. # - It seems that the actual CLIP kernel module doesn't support an IPv6 link # yet, but I didn't try it at all. # - There are tons of problems with CLIP under at least Linux 2.6.13. It seems # to me that the porting of the ATM stack into 2.6 is buggy at least. I # expect that the kind of problem I'm experiencing will disappear as more # people will start using Linux with the CLIP connection to its ISP. The # problems I found are the following: # - This script attempts loading the CLIP module into the kernel if it is not # already loaded, but this may lead to very weird behaviours on a linux # 2.6.x kernel: sometimes the kernel may freeze or oops. This script attempts # it with great care, but it is probably better to preload the module at boot # time instead (edit /etc/modules.autoload.d/kernel-2.6 accordingly). # - Under linux 2.6.x and during heavy load (like at system startup) I experi- # enced some kernel freeze. This script implements a nondeterministic work- # around (yeah, aka a "sleep"), which lets the CLIP kernel and daemon code to # stabilize a bit before going further. It seem to work to me, but since it # is a nonderterministic workaround, I wouldn't bet it works in other setups # as well. Also, in order for the workaround to have any effect, that's much # better not to setup a CLIP connection through a parallel startup! This # means that RC_PARALLEL_STARTUP must be "no" in your /etc/conf.d/rc. # - Setting up a PVC on an interface previously setupped with "ip link up" as # opposed to "ifconfig", the "atmarp -s" commands fails with a "No route # to host". However, this script implements a workaround to this. # # Hints for Telecom Italia's Smart ADSL users # You should have received a piece of paper full with a lot of numbers, IPs and # the like. The numbers you need in order to setup your CLIP connection to # internet are in the "IP ADDESS BASE PUBBLICO" field, which is the address to # assign to your local ATM interface, and in the "IP REMOTO" field, which is # the ip address of the Telecom's router closest to you. # In every and each Telecom Italia's Smart ADSL installation I saw, the subnet # mask was 255.255.255.0, which means a cidr of "/24", the gateway was always # at x.x.x.254 and the CLIP conn adopted the LLC/SNAP encapsulation. Also, in # Italy the vpi.vci pair is always 8.35. A reasonable setup would then be close # to the example shown above, apart the trivial differences in IP addresses. # # Further references # - the man pages o atmsigd, ilmid, atmarpd, and atmarp # - /usr/share/doc/linux-atm-*/atm-linux-howto.txt.gz # - the http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?part=4 # (Gentoo Linux x86 Handbook, Network Configuration section) # # Support # Actually, I'm not supporting this script in any way. If you have troubles or # question, it is better to ask to the knowledgefull Gentoo staff. If you send # me an e-mail, I'm easily going to discard it without notice. ATMPATH=/usr/sbin ATMARP=atmarp ARPFILE=/proc/net/atm/arp ARPWKSLEEP=3 ATMCLIP_SVC_NAME=( atmsigd ilmid atmarpd ) ATMCLIP_SVC_DESC=( \ "Signaling" \ "Integrated Local Management Interface" \ "Address Resolution Protocol" \ ) typeset -ar ATMCLIP_SVC_NAME ATMCLIP_SVC_DESC atmclip_svc_start() { local name="${ATMCLIP_SVC_NAME[$1]}" ebegin "Starting ${ATMCLIP_SVC_DESC[$1]} Daemon (${name})" start-stop-daemon --start --quiet --name "${name}" --exec "${ATMPATH}/ ${name}" -- -b -l syslog eend ${?} } atmclip_svcs_start() { einfo "First CLIP instance: starting ATM CLIP daemons" eindent atmclip_svc_start 0 && atmclip_svc_start 1 && atmclip_svc_start 2 || return 1 eoutdent } atmclip_svc_stop() { local name="${ATMCLIP_SVC_NAME[$1]}" ebegin "Stopping ${ATMCLIP_SVC_DESC[$1]} Daemon (${name})" start-stop-daemon --stop --quiet --name "${name}" --retry=-TERM/1/- TERM/2/-KILL/2 eend ${?} } atmclip_svcs_stop() { einfo "Last CLIP instance: stopping ATM CLIP daemons" eindent atmclip_svc_stop 2 && atmclip_svc_stop 1 && atmclip_svc_stop 0 || return 1 eoutdent } are_atmclip_svcs_running() { is_daemon_running "${ATMCLIP_SVC_NAME[0]}" || \ is_daemon_running "${ATMCLIP_SVC_NAME[1]}" || \ is_daemon_running "${ATMCLIP_SVC_NAME[2]}" } atmarp() { "${ATMPATH}/${ATMARP}" "$@" } # char* clip_provides(void) # # Returns a string to change module definition for starting up clip_provides() { echo 'clip' } # void clip_depend(void) # # Sets up the dependancies for the module clip_depend() { before interface } # bool clip_check_depends(void) # # Checks to see if we have the needed functions clip_check_depends() { local f for f in interface_post_start interface_down interface_up start-stop- daemon is_daemon_running; do if [[ ! $( type -t "${f}" ) == "function" ]]; then eerror "clip: missing required function ${f}\n" return 1 fi done return 0 } # bool clip_check_installed(void) # # Returns 1 if clip and linux-atm tools are installed, otherwise 0 clip_check_installed() { if [[ ! -r "${ARPFILE}" ]]; then /sbin/modprobe clip && sleep 2 if [[ ! -r "${ARPFILE}" ]]; then eerror "You need first to enable the kernel support for ATM CLIP" return 1 fi fi local x; for x in "${ATMCLIP_SVC_NAME[@]}" ${ATMARP}; do if [[ ! -x "${ATMPATH}/$x" ]]; then eerror 'You need first to "emerge net-dialup/linux- atm"' return 1 fi done return 0 } clip_get_vars() { echo "clip_$1" } # bool clip_pre_start(char *iface) # # Create the interface by calling atmarp -c # # Returns 0 (true) when successful, non-zero otherwise clip_pre_start() { local iface="$1" ifvar=$( bash_variable "$1" ) msg local -a opts eval opts=\"\$\{clip_${ifvar}\[@\]\}\" [[ -z "${opts}" ]] && return 0 clip_check_installed || return 1 if ! are_atmclip_svcs_running; then atmclip_svcs_start && sleep 1 || return 1 fi ebegin "Creating CLIP interface ${iface}" msg="`atmarp -c \"${iface}\" 2>&1`" if [[ $? -ne 0 ]]; then case "${msg}" in 'atmarp: Operation not permitted') # Interface already created # We don't need to create it anymore eend 0 'already present' ;; *) # Other error eend 1 "${msg}" ;; esac else eend 0 fi } clip_post_start() { local iface="$1" ifvar=$( bash_variable "$1" ) i local -a opts eval opts=\"\$\{clip_${ifvar}\[@\]\}\" [[ -z "${opts}" ]] && return 0 clip_check_installed || return 1 are_atmclip_svcs_running || return 1 # We need to have the interface fully set up. interface_post_start "${iface}" || return 1 # The atm tools (atmarpd?) are silly enough that they woun't work with # iproute2 interface setup as opposed to the ifconfig one. This is due # to the fact that iproute2 "ip link set up" command brings the inter- # face status to 'up', but doesn't yet assign an address to it. Some # buggy interface setup trapping code in the clip daemons do assume # this. It it probably due to the fact that atm tools were designed # when only the ifconfig way was available. # The workaround is to temporarily toggle the interface state from up # to down and then up again, without touching its address. This (should) # work with both iproute2 and ifconfig. interface_down "${iface}" interface_up "${iface}" # Now the real thing: create a PVC with our peer(s) for (( i=0; i<${#opts[@]}; i++ )); do set -- ${opts[$i]} local peerip="$1"; shift local ifvpivci="$1"; shift ebegin "Creating PVC ${ifvpivci} for peer ${peerip}" atmarp -s $peerip $ifvpivci $* eend ${?} done # When I'm telling CLIP is buggy in 2.6, I'm not joking: the system # sometimes locks on heavy load (ie: during startup). As a workaroung, # I'm going to let this script sleep for a while. This also mean you # can't use CLIP on a parallel startup! if [[ "${ARPWKSLEEP}" -gt 0 && "`/usr/bin/uname -r`" > 2.6.0 ]]; then ebegin "[WORKAROUND] Please allow ${ARPWKSLEEP} seconds for the CLIP code to stabilize" sync; sleep "${ARPWKSLEEP}"; sync eend 0 fi } # bool clip_pre_stop(char *iface) # # Here we basicly undo the PVC creation previously created through the # clip_post_start function. When we establish a new PVC, a corresponding line # is added to the /proc/net/atm/arp file, so we inspect it to extract all the # outstanding PVCs of this interface. clip_pre_stop() { local iface="$1" ifvar=$( bash_variable "$1" ) i local -a opts eval opts=\"\$\{clip_${ifvar}\[@\]\}\" [[ -z "${opts}" ]] && return 0 if are_atmclip_svcs_running; then # We remove all the PVCs which may have been created by # clip_post_start for this interface. This shouldn't be # needed by the ATM stack, but sometimes I got a panic # killing CLIP daemons without previously vacuuming # every active CLIP PVCs. # The linux 2.6's ATM stack is really a mess... local itf t encp idle ipaddr left einfo "Removing PVCs on this interface" eindent { read left && while read itf t encp idle ipaddr left do if [[ "${itf}" == "${iface}" ]]; then ebegin "Removing PVC to ${ipaddr}" atmarp -d "${ipaddr}" eend ${?} fi done } < "${ARPFILE}" eoutdent fi } # bool clip_post_stop(char *iface) # # Here we should teorically delete the interface previously created in the # clip_pre_start function, but there is no way to "undo" an interface creation. # We can just leave the interface down, but "ifconfig -a" will still list it... # What we can do here is to stop the ATM CLIP daemons if there is no other CLIP # PVC outstanding. We check this condition by inspecting the /proc/net/atm/arp # file. clip_post_stop() { local iface="$1" ifvar=$( bash_variable "$1" ) i local -a opts eval opts=\"\$\{clip_${ifvar}\[@\]\}\" [[ -z "${opts}" ]] && return 0 are_atmclip_svcs_running || return 0 local itf t encp idle ipaddr left hasothers { read left && while read itf t encp idle ipaddr left do if [[ "${itf}" != "${iface}" ]]; then hasothers=1 break fi done } < "${ARPFILE}" if [[ -z "${hasothers}" ]]; then atmclip_svcs_stop || return 1 fi } # vim:ts=8 --END
Created attachment 69899 [details] The /lib/rcscripts/net.modules.d/clip script Well, I didn't know I could attach a file here...
I'm not sure that we can include this in baselayout until it works with RC_PARALLEL_STARTUP="yes" Errors / possible problems (note, I've not run this code at all, just browsed it) ..... * Don't call interface_post_start - instead depend on interface like so clip_depend() { after interface } * May be more reliable to use interface_exists "${iface}" instead of parsing the output from atmarp when creating the CLIP interface as you're not overriding it with LC_ALL=C and other locales may get translated text... I have some pedantic/cosmetic comments also * I dislike the use of global variables. I see why you use them, but other scripts could overwrite them quite easily which will cause errors. * Use the $( ... ) notation instead of `...` * Always use ${FOO} for every variable except for bash internal ones ($1, $?, etc) * Using [[ ... ]] always quote the RHS variable and only quote the LHS variable if it's part of something more ie [[ ${foo} == "${bar} ]] && [[ "${foo}/bar" == ${bar}/var" ]] Marking as LATER until it works 100% with RC_PARALLEL_STARTUP="yes".
> I'm not sure that we can include this in baselayout until it works with > RC_PARALLEL_STARTUP="yes" Now it works to me also that way: there was a different problem (due to atm daemons being sensible to SIGHUP) which I fixed by daemonizing them through start-stop-daemon instead of letting them demonize by itself. > Errors / possible problems (note, I've not run this code at all, > just browsed > it) ..... Is there any way to have it tested by a wider base of users? I tried some gentoo forums, but no reply (yet). > * Don't call interface_post_start - instead depend on interface like so > clip_depend() { > after interface > } You've got a good sigth! :) No more need for this, either: I was misinterpreting the problems due to the SIGHUP matter... > * May be more reliable to use interface_exists "${iface}" instead > of parsing the > output from atmarp when creating the CLIP interface as you're not > overriding it > with LC_ALL=C and other locales may get translated text... Ok, I'm now using interface_exists(). > I have some pedantic/cosmetic comments also > > * I dislike the use of global variables. I see why you use them, but other > scripts could overwrite them quite easily which will cause errors. Well, I applied a "typedef -r" to them and changed their names to be a bit more difficult to override. If you think it is not enough, let me now: I'll try to remove them. > * Use the $( ... ) notation instead of `...` How many things changed by my early sh scripts... :) > * Always use ${FOO} for every variable except for bash internal > ones ($1, $?, etc) Should be done. Have a check. > * Using [[ ... ]] always quote the RHS variable and only quote > the LHS variable > if it's part of something more ie [[ ${foo} == "${bar} ]] && [[ > "${foo}/bar" == > ${bar}/var" ]] Ok. I think it's this way now. Have a check. I'm attaching a new version of the /lib/rcscript/net.modules.d/clip script to reflect my latest changes. Regards, g
Created attachment 69986 [details] The /lib/rcscripts/net.modules.d/clip script v.0.2
Don't test for the function start-stop-daemon - it's just a wrapper to the start-stop-daemon binary and should work fine without the wrapper No need to invoke --name as well as --exec when starting daemons (use --exec by choice) Avoid use of --quiet with start-stop-daemon unless it pumps too much to stdout when starting. This is to make debugging easier. When stopping with start-stop-daemon the --retry option is ignored (when using the wrapper in baselayout-1.12.0 which you are using) Use the --exec /path/to/bin instead of --name as it's much more reliable when stopping. If pidfiles are created (hopefully!) specify them here. Try and make then name them with the interface if you can --pidfile "/var/run/atmarpd.${iface}.pid" for example. Use them with starting as well and it's a more robust system No need to capture creating CLIP atmarp call in a subshell - this should suffice ebegin "Creating CLIP interface ${iface}" atmarp -c "${iface}" local r=$? eend ${r} After reading up on typeset -r, I still don't like global vars, but I also have no immediate issue with them at this time. baselayout prefers returning things like this via a function, but that's just us ;) That's about it - keep up the good work :)
Created attachment 70001 [details] The /lib/rcscripts/net.modules.d/clip script v.0.3 > Don't test for the function start-stop-daemon - it's just a wrapper to the > start-stop-daemon binary and should work fine without the wrapper Oh, I see. Ok. > No need to invoke --name as well as --exec when starting daemons > (use --exec by > choice) > > Avoid use of --quiet with start-stop-daemon unless it pumps too > much to stdout > when starting. This is to make debugging easier. > > When stopping with start-stop-daemon the --retry option is > ignored (when using > the wrapper in baselayout-1.12.0 which you are using) The above are done. > Use the --exec /path/to/bin instead of --name as it's much more > reliable when > stopping. If pidfiles are created (hopefully!) specify them here. > Try and make > then name them with the interface if you can > --pidfile "/var/run/atmarpd.${iface}.pid" > for example. Use them with starting as well and it's a more robust system Pidfile done. But these processes are supposed to be driver-wide, so I'm using a pidfile name like "/var/run/atmarpd.pid", without reference to any interface. It makes more sense to me... > No need to capture creating CLIP atmarp call in a subshell - this > should suffice > ebegin "Creating CLIP interface ${iface}" > atmarp -c "${iface}" > local r=$? > eend ${r} Fixed. > After reading up on typeset -r, I still don't like global vars, > but I also have > no immediate issue with them at this time. baselayout prefers > returning things > like this via a function, but that's just us ;) Ok, no more globals (apart clip_full). Is it more sweety now? :)
Created attachment 70003 [details] The /lib/rcscripts/net.modules.d/clip script v.0.3 Of course, a gave you a wrong version... This is the correct one.
Created attachment 70346 [details] The /lib/rcscripts/net.modules.d/clip script v.0.4 The previous script version was causing sometimes a kernel freeze during shutdown. It is not clear to me the why, but using the start-stop-daemon (function?) with --retry in version 0.2 was yielding more stable shutdown results. Now, I understand that the --retry option is silently discarded by the s-s-d function. Anyway, I modified the clip script by applying a sync before shutting daemons down (you never know) and a sleep after each daemon stops. My guess is that, when a daemon dies (possibly atmarpd), the others have to "do somthing" with the clip driver which can't be stopped by a kill. I'm still testing this script version, but it didn't yet missed a shutdown in my machine. Also, I have a question regarding the s-s-d function. In the rc_try_kill_pid function, I see that the script divides the timeout value by ten. Now, in my system RC_RETRY_TIMEOUT is 1. I tried to do a (( s=1/10 )) on my bash shell and it turned out to yield s=0, not s=0.1 as I would expect. Since this should result in RC_RETRY_COUNT x "sleep 0", may this mean that the rc_try_kill_pid doesn't give any chance to the clip script to wait for the termination of the atmclip daemons? This would mean that atmarpd may not yet be terminated before ilmid gets signaled, which is probably harmless with well-behaving daemons, but not with the atmclip ones... Also, please note that, whenever my the system got frozen at shutdown, I'm pretty shure the atmarpd stop operation returned an error ([!!] instead of [OK] in non-parallel shutdown). I feel this like a proof of my concerns regarding the rc_try_kill_pid operations. Regards, Giampaolo
See bug #107492 about the RC_RETRY_TIMEOUT bug (there's a patch there) The -R|--retry switch will also be supported in the next version
Created attachment 70404 [details] The /lib/rcscripts/net.modules.d/clip script v.0.5 Ok, this is my best effort in the clip script. This new version assumes the presence of a post-bug#107492 /lib/rcscripts/sh/rc-daemon.sh. However, the script can only be a best effort in supporting clip connection: the more I work around it, the stronger gets my belief that the 2.6 ATM stack is actually a mess... Thank you for your assistance, Roy.
baselayout-1.12.0_pre10 just got released with all your issues mentioned here resvoled. Is your kernel still unstable for atm? Have you fixed a bug upstream where we can link to?
I downloaded the post-bug#107492 /lib/rcscripts/sh/rc-daemon.sh in order to run my latest tests. So, if this is the same version of the rc-daemon.sh shipped with baselayout-1.12.0_pre10, I guess that nothing is changed by then: the clip script sometimes freezes the system during shutdown. The problem seems to be related to atmarpd termination: if I issue by hand a: # ifconfig atm0 down # kill -15 {pid of atmarpd} before starting a shutdown, the latter completes fine in every and each case. Otherwise it may freeze the kernel. I found it is because sometimes atmarpd termination is not yet completed when atmsigd is signaled to TERM. And this happens after the s-s-d function pedantically attempted a lot in killing atmarpd and then failed. In one of my previous posts, I said that the atmsigd, ilmid and atmarpd daemons are quite susceptible to signals. This may probably be the cause: with my rcscript configuration, the s-s-d function 'kills' atmarpd once every second and there are chanches that this somehow slows down (or maybe even prevents) the atmarpd cleanup operations, resulting in s-s- d to report a failure in atmarpd shutdown. Also, in rc_try_kill_pid, if I apply a change like the following: for (( i=0; i<RC_RETRY_COUNT*10; i++ )); do + ps ax | grep atm >/dev/console if ${session} ; then such that the function now reports the status of the atm processes, I can see that 'ps ax' reports the atmarpd process in the 'D' state (ie: uninterruptible sleep or I/O) soon after the first kill. Sometimes the atmarpd doesn't leave this state. When this happens, the s-s-d function will fail and the system will freeze soon after the atmsigd process gets killed too. Note that this happens to me when the atm clip daemons were up for few hours. If you boot the OS and then bring it down, everything works fine. This slows down my shutdown testing a lot... I don't really see a way to circumvent it, Maybe using /sbin/start-stop- daemon -signal {KILL/secs}* we could avoid yellowing atmarpd with too many "leave the bathroom, please!" every second, which may be the cause of atmarpd shutdown failures. But I still have to test it. In summary: I wouldn't release such a beast right now... I'm instead going to get the linux-atm community informed of my troubles with atmarpd, in order to hear for comments and clues by them. Regards,
Dears, it is months now that the clip script is working on a small server of mines. I discovered that most of the freeze problems actually happen when the kernel CLIP driver and the related clip daemons never see a live connection, IE: during my off-line tests. I never got problems restarting a clip-connected system. But now I have to face another problem: the is_daemon_running() function suddenly disappeared upgrading to a recent baselayout (1.11.14-r3). How I am expected to inspect a daemon state? Through start-stop-daemon --stop --kill 0 ? Regards
is_daemon_running() is only in baselayout-1.12 branch
Aaah, that's why: I had to downgrade to some 'stable' modules because of a problem with udev (somehow, the firmware wasn't uploaded to my speedtouch usb device at startup). Question: the clip script will eventually be delivered with baselayout-1.12.x? If this is the case, when do the baselayout people plan to ship a 'stable' version?
(In reply to comment #15) > Question: the clip script will eventually be delivered with baselayout-1.12.x? > If this is the case, when do the baselayout people plan to ship a 'stable' > version? I'm tempted to ship this with the net-dialup/linux-atm package once baselayout-1.12 becomes stable instead. BTW, we changed the API slightly in 1.12_pre13 and better. Checkout the new depend function as it now handles a bit more so you can drop custom functions such as _provides, _check_depends and _get_vars. See our modules for details :)
Created attachment 78300 [details] The /lib/rcscripts/net.modules.d/clip script v.0.6 net-dialup/linux-atm is fine to me, but what if baselayout gets shaked again? It is probably better to have this script well bound to its runtime environment. Am I wrong? Anyway, your reply sounds like you guys are going to ship it within few months, so I'm attaching a new version of the clip script endorsing your brand-new net.modules interfacing as well as fixing and enhancing its own embedded documentation. Regards
(In reply to comment #17) > Created an attachment (id=78300) [edit] > The /lib/rcscripts/net.modules.d/clip script v.0.6 > > net-dialup/linux-atm is fine to me, but what if baselayout gets shaked again? > It is probably better to have this script well bound to its runtime > environment. Am I wrong? Well, it won't after we split. If it does then it will require so sync between maintainer and baselayout, but baselayout devs also maintain most of the related packages, so it should be a non issue.
I see. Well, whatever you choose is fine to me. By the way, Roy, take a rest: it is sunday... :)
sys-apps/baselayout-1.12.4 breaks the API for which this script was developed (sys-apps/baselayout-1.12.0). Would you give me some hints about the changes needed to adjust it to its new home? Thanks.
(In reply to comment #20) > sys-apps/baselayout-1.12.4 breaks the API for which this script was developed > (sys-apps/baselayout-1.12.0). Shouldn't - the API is the same. What's the error?
* Service net.atm0 starting /lib/rcscripts/net/clip.sh: line 363: interface_variable: command not found network interface atm0 does not exist Please verify hardware or kernel module (driver) [ !! ] * ERROR: net.atm0 failed to start
Oh, by the way: atm0 is to be created by the clip module itself.
(In reply to comment #22) > * Service net.atm0 starting > /lib/rcscripts/net/clip.sh: line 363: interface_variable: command not found > network interface atm0 does not exist > Please verify hardware or kernel module (driver) > [ !! ] > * ERROR: net.atm0 failed to start > interface_variable was 1.11 bash_variable is 1.12 The latest script you have here uses bash_variable .....
> (In reply to comment #22) > interface_variable was 1.11 > bash_variable is 1.12 > The latest script you have here uses bash_variable ..... ... and it works, indeed. Sorry for wasting your time, Roy: I probably changed it to had it work on previous baselayout versions, then forgot that. Any news on distributing this script?
net-dialup - you think this should be in baselayout or the linux-atm ebuild?
pppd, adsl and many other 'dialup' scripts are borrowed by baselayout. So I would think clip.sh should be there. But it is not a big issue.
I think this net module should be installed by baselayout because: - other net modules such as ppp.sh are also installed by baselayout and not by net-dialup/ppp. - users may have other baselayouts, like baselayout-lite, prolly not compatible with this net module. As a side note, this is the first time I hear about IP over ATM. :P
Here in Italy we enjoy rare things... :) There are other countries in which CLIP is used to connect ISPs as well, however. Some ADSL routers name it as RFC1483, but that is the "bridged" version, not the "routed" one. CLIP is actually defined by RFC2225 (see ftp://ftp.rfc-editor.org/in-notes/rfc2225.txt )
Created attachment 94699 [details] The /lib/rcscripts/net.modules.d/clip script v.0.7 Since we are going to ship, I'm attaching a new 0.7 version of the clip.sh script. This new version offer: - 10 retries every 2 secs when creating a VC. This change is needed by some atm interfaces (notably, ADSL modems) which may report a failure if a VC creation is attempted before they reach showtime; - improved error handling. Daemons startup is now rolled back when a failure occurs in creating a PVC; - corrected a problem when multi-VCs on the same atmX interfaces are defined (which is probably a seldom used feature); - enhanced and fixed documentation. I successfully tested the new 0.7 script with a 2.6.17-gentoo-r4 kernel which, by the way, seems much more stable with respect to the clip issues I experienced in earlier releases. The tests were performed starting and stopping the system either in parallel and non-parallel rc mode, and with and without errors during the PVC setup. Also, manual startup and shutdown of CLIP interfaces was tested. Regards.
Created attachment 94701 [details, diff] Unified diff of the clip.sh script from v.0.6 o v.0.7 And this is a patch from the version. Roy, this is meant to help you look at changes, in order to better identify syntactical or api problems which I may have introduced. Oh, by the way: the pathname of the script is, of course, /lib/rcscripts/net/clip.sh, not the one reported in the attachment name.
OK, I've added it to baselayout-1.12 and trunk branches with a few style modifications. Documentation has been added too. http://sources.gentoo.org/viewcvs.py/baselayout/branches/baselayout-1_12/net-scripts/net/clip.sh?view=markup May want to test that to ensure I've not broken anything ;) Will be in baselayout-1.12.5
Created attachment 94772 [details] The /lib/rcscripts/net/clip.sh script (In reply to comment #32) > OK, I've added it to baselayout-1.12 and trunk branches with a few style > modifications. Documentation has been added too. Great. A lot of doc had been trashed, I you mean /etc/conf.d/net.example. :) > May want to test that to ensure I've not broken anything ;) Actually, it happened: you ripped a couple of lines just at the beginning of the true script, after docs: # Current default for the clip_full setting clip_full="${clip_full:-yes}" That's nothing crucial: the script works like in "clip_full=no" case, but to be conformant with the ATM specs, it would be better to have a compliant default. I'm attaching a corrected copy of the script in the gentoo branch. > Will be in baselayout-1.12.5 Great. Thanks.
(In reply to comment #33) > Great. A lot of doc had been trashed, I you mean /etc/conf.d/net.example. :) Yeah. I also trimmed down what went in to try and keep it as concise as possible. > Actually, it happened: you ripped a couple of lines just at the beginning of > the true script, after docs: > > # Current default for the clip_full setting > clip_full="${clip_full:-yes}" Good thing as setting variables like that in global scope is a no-no. I've fixed the svn copy to default it to yes inside the functions instead.
(In reply to comment #34) > Good thing as setting variables like that in global scope is a no-no. I've > fixed the svn copy to default it to yes inside the functions instead. Rules were a bit less strict some time ago... :) Revision #2201 works fine to me.
(In reply to comment #35) > (In reply to comment #34) > > Good thing as setting variables like that in global scope is a no-no. I've > > fixed the svn copy to default it to yes inside the functions instead. > > Rules were a bit less strict some time ago... :) Oh, I'm not saying it didn't work - it does. It just goes against our current design :)
(In reply to comment #36) > Oh, I'm not saying it didn't work - it does. It just goes against our current > design :) Well, I'm not arguing that: revision #2201 (in the baselayout trunk) is the script with inherent "clip_full=yes". The one carring your last changes. I downloaded and tested it, and it passed the tests (ok/non-parallel, fail/non-parallel, ok/parallel, and fail/parallel). Take it easy... :)
Roy, what was the matter with clip_check_installed?
(In reply to comment #38) > Roy, what was the matter with clip_check_installed? > check_installed is to detect if the userland software is available or not. We only check for kernel modules at the point we wish to use it.
Created attachment 95004 [details] The /lib/rcscripts/net/clip.sh script The attached file is a reformatted version of the clip script, accounting for a 4 chars wide tabstop: the one in the baselayout trunk is sometimes a bit ugly...
baselayout-1.12.5 has the clip script, so marking this as fixed
