Date: Wed, 28 May 2014 06:55:44 -0700 (PDT) From: =?iso-8859-1?Q?Yves_Gu=E9rin?= <yvesguerin@yahoo.ca> To: "rc@freebsd.org" <rc@freebsd.org>, David Wolfskill <david@catwhisker.org> Subject: Re: An attempt to decrease time taken to bring up NICs Message-ID: <1401285344.56835.YahooMailNeo@web122405.mail.ne1.yahoo.com> In-Reply-To: <20140527225721.GA64440@albert.catwhisker.org> References: <20140527225721.GA64440@albert.catwhisker.org>
next in thread | previous in thread | raw e-mail | index | archive | help
Dear, I have the same problem, but I resolved it by modifying the boot screen (/boot/loader.4th) and (to include my network setup as a menu, replacing the FreeBSD one) I transfert my choice via the kernel arguments and I had an rc script to setup my rc.conf dynamically. Regards, Yves Guerin Le Mardi 27 mai 2014 18h57, David Wolfskill <david@catwhisker.org> a écrit : This may well be something that is generally applicable only to a subset of machines, but here goes.... My laptop has both wired (em(4)) and wireless (iwn(4)) NICs. During normal operation, I would prefer to have one NIC used; which one depends on circumstances that are rather location-dependent -- but the machine is intended to have the role of "DHCP client" (again, in "normal operation"). As a consequence, /etc/rc.conf includes: wlans_iwn0=wlan0 ifconfig_wlan0="WPA DHCP" ifconfig_em0="DHCP" And as a consequence of *that*, FreeBSD (via rc.d/netif, if I understand correctly) attempts to bring up em0, then wlan0... serially, and on every boot (well, transition from single-user to multi-user mode). Now, I can control the behavior a bit: * I can choose whether or not to plug a wire into em0. (In some cases, I can even control whether or not the other end of the wire is connected to anything useful. :-}) * I can disable the iwn0 NIC (by sliding the hardware switch). (Sometimes I can even do that intentionally. :-}) But whether or not either (or both) of the above have been done, we first try to bring up em0, then try to bring up wlan0. One plausible approach might be to fork off separate subprocesses, and try to bring up the NICs in parallel. However, I'm not that ambitious. :-} I did think of a couple of things that might help somewhat, though, and even tried coding one of them up: * Create an rc.conf knob to control allow the specification of the number of NICs I would like to have brought up. In my case, I might set that at 1 -- so if I'm in an environment where I know I only want to use thw wired NIC, I connect em0, it's brought up, and then rc.d/netif stops trying to bring up NICs (because I've reached the target number). * Create an rc.conf knob to make the sequence in which the NICs are brought up explicit. For the first one (specifying a target number of active NICs), I cobbled up a bit of code (only changing rc.d/netif); the changed version even seems to do the right thing if I invoke: service netif start However, in "real life" (i.e., during a real transition from single- to multi-user mode), the behavior seems to be unchanged. Is there something ... different ... about how rc.d/netif is invoked during boot time, perhaps? For the second... it seems that the sequence is effectively dictated by the sequence in which "ifconfig -l" outputs the list of NICs (though rc.d/netif has a bit of code to move lo0 to the front of the list). I suppose one possible approach would be: * If a certain rc variable has a non-empty value, treat it as a space-separated list of NICs (same format as output of "ifconfig -l"), and use that value in place of the currently-used "ifconfig -l" output. (This implies that the current behavior of ensuring that lo0 is first would remain.) * If that rc variable is undefined or has an empty value, fall back to the current use of the output of "ifconfog -l". Might want to set an emtpy value for the rc variable in /etc/defaults/rc.conf. The reason the second one is an issue is that it seems to me that the behavior I'm seeing (where rc.d/netif tries the wired NIC first, then the wireless) is essentially an accident of the names chosen for the NICs, rather than something that an administrator can choose. Finally, I note that even in cases where I've disabled the wireless NIC, I see (e.g.): ... May 27 14:08:45 d130 wpa_supplicant[374]: Failed to initiate AP scan. May 27 14:09:16 d130 last message repeated 31 times May 27 14:11:17 d130 last message repeated 121 times May 27 14:21:18 d130 last message repeated 600 times May 27 14:31:19 d130 last message repeated 600 times May 27 14:41:20 d130 last message repeated 600 times May 27 14:51:21 d130 last message repeated 600 times May 27 15:01:22 d130 last message repeated 600 times May 27 15:11:23 d130 last message repeated 600 times May 27 15:21:24 d130 last message repeated 601 times May 27 15:31:25 d130 last message repeated 600 times May 27 15:41:26 d130 last message repeated 600 times .... which seems... well, not very clever. If I've disabled the wireless NIC, I'd rather not have wpa_supplicant trying to do anything (at least, with the wireless NIC). So -- am I exhibiting my tendency toward "tunnel vision" again, or do parts of the above seem to make some sense? Suggestions? Thanks! Peace, david -- David H. Wolfskill david@catwhisker.org Taliban: Evil cowards with guns afraid of truth from a 14-year old girl. See http://www.catwhisker.org/~david/publickey.gpg for my public key. From owner-freebsd-rc@FreeBSD.ORG Thu May 29 16:16:17 2014 Return-Path: <owner-freebsd-rc@FreeBSD.ORG> Delivered-To: freebsd-rc@freebsd.org Received: from mx1.freebsd.org (mx1.freebsd.org [IPv6:2001:1900:2254:206a::19:1]) (using TLSv1 with cipher ADH-AES256-SHA (256/256 bits)) (No client certificate requested) by hub.freebsd.org (Postfix) with ESMTPS id 3B6C3FD for <freebsd-rc@freebsd.org>; Thu, 29 May 2014 16:16:17 +0000 (UTC) Received: from mail-qg0-x243.google.com (mail-qg0-x243.google.com [IPv6:2607:f8b0:400d:c04::243]) (using TLSv1 with cipher ECDHE-RSA-RC4-SHA (128/128 bits)) (Client CN "smtp.gmail.com", Issuer "Google Internet Authority G2" (verified OK)) by mx1.freebsd.org (Postfix) with ESMTPS id 0019A2A64 for <freebsd-rc@freebsd.org>; Thu, 29 May 2014 16:16:16 +0000 (UTC) Received: by mail-qg0-f67.google.com with SMTP id a108so509686qge.2 for <freebsd-rc@freebsd.org>; Thu, 29 May 2014 09:16:16 -0700 (PDT) DKIM-Signature: v=1; a=rsa-sha256; c=relaxed/relaxed; d=gmail.com; s 120113; h=mime-version:date:message-id:subject:from:to:content-type; bh=lYyZIoRfrGnfdSDXSuj/UKOZhACn9ctjQr+2qZl3+eY=; b=xYPXrcp7TRTcuFiWdeqhGvDonDvNzEr5EYt89Hnx/3vvY/hKhSsk0NRXf1TFJgLUVR ZrSBFbL7pyVWBzCJUTA7ZNsFB+PjypWMSTw/aSz/1u27kKLfuAauhXXdN/FUf+mt9cVa eFApG4JxtCFimuFJDH6lB+4Dqlbc5R+UETYl0vAutTQjffckJWMAe2enoVQZVNcn+Xk4 IW1L3bm8ztYR4IhJ2flsrPZPjGKMoAN+ZeTxuXI44AjEXmwGOdmmr5Np+xb8xxjFyVCa QZkfxCh3+K/GtOGtaM9R7vKlnu1UoeaUoPWIuVawp1KxGvXWMRRDeU3NCHZolRYOyqsu gTvQ=MIME-Version: 1.0 X-Received: by 10.224.16.199 with SMTP id p7mr11931385qaa.76.1401380175960; Thu, 29 May 2014 09:16:15 -0700 (PDT) Received: by 10.229.14.196 with HTTP; Thu, 29 May 2014 09:16:15 -0700 (PDT) Date: Thu, 29 May 2014 11:16:15 -0500 Message-ID: <CA+7eH3XGh5yfr8eFL3oDMM4cZRVvNJF48K89p-ek5co22VF0ig@mail.gmail.com> Subject: Help needed to add scheduling to a small rc.d script From: Pietro Sammarco <pietro.bsdml@gmail.com> To: freebsd-rc@freebsd.org Content-Type: text/plain; charset=UTF-8 X-Content-Filtered-By: Mailman/MimeDel 2.1.18 X-BeenThere: freebsd-rc@freebsd.org X-Mailman-Version: 2.1.18 Precedence: list List-Id: "Discussion related to /etc/rc.d design and implementation." <freebsd-rc.freebsd.org> List-Unsubscribe: <http://lists.freebsd.org/mailman/options/freebsd-rc>, <mailto:freebsd-rc-request@freebsd.org?subject=unsubscribe> List-Archive: <http://lists.freebsd.org/pipermail/freebsd-rc/>; List-Post: <mailto:freebsd-rc@freebsd.org> List-Help: <mailto:freebsd-rc-request@freebsd.org?subject=help> List-Subscribe: <http://lists.freebsd.org/mailman/listinfo/freebsd-rc>, <mailto:freebsd-rc-request@freebsd.org?subject=subscribe> X-List-Received-Date: Thu, 29 May 2014 16:16:17 -0000 Hello everyone, let me begin saying I know very little about sh scripting and shell scripting in general, so by reading here and there I have managed to create a small sh scrip that ping google.com and if the ping timed out it will take wlan0 down, take it back up and run dhclient on it. Essentially what I need to do is to add a 30 seconds scheduling time to this script, so that each and every 30 seconds it will check if google.comis pingable, and if not it will do what the script it supposed to do, and at the same time I want to keep the start and stop feature. Lastly, the main reason why I need to make this script is because when my laptop resumes from suspending ( hw.acpi.lid_switch_state ) the wireless goes numb, and those steps are required for the OS to associate with the AP again, and becase this laptop is not always connected through wireless and sometimes it act as gateway sharing the connection from the ethernet card to the wireless card, I would rather avoid to make this script a cronjob. Here's the mini script itself Thanks #!/bin/sh . /etc/rc.subr name="resumewlan" start_cmd="resumewlan_start" stop_cmd="resumewlan_stop" if ! [ "`ping -c 1 google.com`" ]; then ifconfig wlan0 down & ifconfig wlan0 up & dhclient wlan0 #if ping timed out, takes down the wireless, takes it back up and executes dhlient on it fi
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?1401285344.56835.YahooMailNeo>