# Detecting Existance of Network Cable

## AdmiralNemo

On my laptop, I have a wired ethernet RJ-45 jack as well as a PCMCIA 802.11g Wi-Fi network card.  Sometimes, I use wireless, sometimes I use wired, but I never know when I am going to use what.  My problem is that I like to have my wired card try and obtain a DHCP address and if not, fallback to a static one, for use with configuring routers and such, but it takes a really long time to determine that no DHCP server is available.  I was wondering if there is some way to determine if a cable is plugged into the jack or not, like Windows can, before even attempting a DHCP query.  This way, when my computer boots, it doesn't hang on Bringing up eth0 for a long time and would reduce the boot time significantly.

If you have any suggestions or comments, I would be glad to hear.  Thanks

----------

## nielchiano

there is a tool called "mii-tool" and "mii-diag" that allow you to talk to the transmitter in some network-cards. You can tell him to autonegotiate it's speed, or to have a fixed setting; it also tells what the other side supports. It basicaly tells everything about layer 1:

```
eth0: negotiated 100baseTx-FD, link ok

  product info: vendor 00:40:63, model 52 rev 9

  basic mode:   autonegotiation enabled

  basic status: autonegotiation complete, link ok

  capabilities: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD

  advertising:  100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD

  link partner: 100baseTx-FD 100baseTx-HD 10baseT-FD 10baseT-HD flow-control
```

this way you can see if there is some device connected.

However, just plugging your computer into an empty switch will tell you that you have link. This will cause DHCP to run, and take a long time.

I think it would be better to shorten the dhcp timeout to, say 5 seconds?

if you're using dhcpcd (probabely), add the -t option:

```
-t <timeout>

              Specifies (in seconds ) for how long dhcpcd will try to  get  an

              IP  address.  The  default  is 60 seconds.  dhcpcd will not fork

              into background until it gets a valid IP address in  which  case

              dhcpcd  will  return  0 to the parent process.  In a case dhcpcd

              times out before receiving a valid IP address from  DHCP  server

              dhcpcd  will  return  exit code 1 to the parent process. Setting

              the timeout to zero disables it: dhcp will keep  trying  forever

              to get a lease, and if the lease is lost, it will try forever to

              get another.
```

you can add it in your /etc/conf.d/net:

```
iface_eth0="dhcp"

dhcpcd_eth0="-t 5"

iface_wlan0="dhcp"

dhcpcd_wlan0="-t 10"
```

you can also configure 1 default option. check out net.example!

----------

## UberLord

You can use netplug or ifplugd to manage your wired network connections for you.

baselayout-1.12 has integrated support for both which works really well.

baselayout-1.11 has no such support, but you can use ifplugd with some thought.

----------

## depontius

 *UberLord wrote:*   

> You can use netplug or ifplugd to manage your wired network connections for you.
> 
> baselayout-1.12 has integrated support for both which works really well.
> 
> baselayout-1.11 has no such support, but you can use ifplugd with some thought.

 

Is there any reason to prefer netplug or ifplugd?

Is there anything to watch out for since baselayout-1.12 is marked unstable?

I have a laptop, and want wired preferred over wireless, which is pretty basic.

What if I walk from access-capable to non-access-capable to access-capable, again?

Since I'm walking, it's most likely that I'm on battery. In that case, I'd like to think that when I lose signal, and fail to capture a new AP, that the wireless adapter is powered down. But then when I walk back to access-capable, if it's been powered down, it won't re-capture, which is understandable. In that case, there needs to be some way to give it a little kick, preferably as non-root.

Beyond that, it would be nice to have networked and non-networked runlevels, as discussed elsewhere in Gentoo documentation. Be nice for things like sshd and cups.

How much of this does/can baselayout-1.12 do?

----------

## UberLord

 *depontius wrote:*   

> Is there any reason to prefer netplug or ifplugd?

 

netplug is smaller and lighter but works equally well.

ifplugd has more features, but most people have no use for them.

 *Quote:*   

> Is there anything to watch out for since baselayout-1.12 is marked unstable?

 

Not really. I use 1.12 on all my boxes and servers.

 *Quote:*   

> I have a laptop, and want wired preferred over wireless, which is pretty basic.
> 
> What if I walk from access-capable to non-access-capable to access-capable, again?
> 
> Since I'm walking, it's most likely that I'm on battery. In that case, I'd like to think that when I lose signal, and fail to capture a new AP, that the wireless adapter is powered down. But then when I walk back to access-capable, if it's been powered down, it won't re-capture, which is understandable. In that case, there needs to be some way to give it a little kick, preferably as non-root.

 

Well, if you use wpa_supplicant then it always scans for an AP, thus the network card is never down and should never need to be restarted. If you want the adapter to power down when not associated then you're also responsible for powering it up again. How you do that is up to you,

 *Quote:*   

> Beyond that, it would be nice to have networked and non-networked runlevels, as discussed elsewhere in Gentoo documentation. Be nice for things like sshd and cups.
> 
> How much of this does/can baselayout-1.12 do?

 

baselayout-1.11 can do this also. Simply follow our documentation about creating and using other runlevels.

----------

## depontius

 *UberLord wrote:*   

>  *depontius wrote:*   Is there any reason to prefer netplug or ifplugd? 
> 
> netplug is smaller and lighter but works equally well.
> 
> ifplugd has more features, but most people have no use for them.

 

Done. emerge -C ifplugd, emerge netplug, I had to go to ~x86 to get it to install, as suggested on bugzilla.

According to the netplug homepage, there's a file /etc/netplug.conf, which isn't there in the ebuild, I presume because of the baselayout integration.

But how do I know what netplug is being told to do, how do I tweak the configuration. Maybe I'm looking in the wrong places for TRM to Read.

 *Quote:*   

>  *Quote:*   Is there anything to watch out for since baselayout-1.12 is marked unstable? 
> 
> Not really. I use 1.12 on all my boxes and servers.

 

Installed and booted, running, although things look a little weird. In the first place, ath0 is up, although no address has been assigned. I presume that's due to the way it's set up to work with netplug.

More disturbing, I want to tweak my dhcpcd in /etc/conf.d/net thus: dhcpcd_eth1="-d -D -H -h arnie -e /var/lib/dhcpc"

-d - I want more information

-D - I want the system to get its domain from the dhcp server

-H - I want the system to get its hostname from the server - I have "OVERRIDE=0" in /etc/conf.d/domainname, but I'm disturbed about two-place configuration

-h - I want to request the name "arnie" from our ddns server, if available, and if the stupid thing doesn't take too long to respond. I also want it to just be "localhost" when it's not connected to anything at all.

-e - I want it to put the fetched resolv.conf over in /var/lib/dhcpc, and I will point dnsmasq to look at that, once this whole mess runs. In the meantime, I'll manage /etc/resolv.conf.

I'm disturbed that dhcp options appear to be configurable through "dhcp_eth1" or "dhcpcd_eth1", though in this case my use of the latter hasn't worked, at all. There is no evidence that any of these settings had any effect. At the moment I also don't know where to find TFM for "dhcp_eth1" other than a sketchy /etc/conf.d/net.example, and various things I've seen at various times, and partly forgotten up on the web site. There's a real problem on the web site with too much documentation, parts of it overlapping, parts of it obsolete, and knowing what to find, where. I usually end up using google, and even then get too many hits.

Here's part of /var/log/messages:

```
Mar  7 10:39:22 localhost e1000: eth1: e1000_watchdog_task: NIC Link is Up 100 Mbps Full Duplex

Mar  7 10:39:22 localhost netplugd[7656]: /etc/netplug.d/netplug eth1 in -> pid 7656

Mar  7 10:39:22 localhost rc-scripts: WARNING:  netmount is scheduled to start when net.eth1 has started.

Mar  7 10:39:23 localhost rc-scripts: wpa_supplicant_eth1 does not define a driver

Mar  7 10:39:23 localhost rc-scripts: WARNING:  sshd is scheduled to start when net.eth1 has started.

Mar  7 10:39:23 localhost dhcpcd[8217]: broadcasting DHCP_REQUEST for x.xx.xxx.xx

Mar  7 10:39:23 localhost cron[8263]: (CRON) STARTUP (V5.0)

Mar  7 10:39:27 localhost dhcpcd[8217]: broadcastAddr option is missing in DHCP server response. Assuming 9.61.130.255

Mar  7 10:39:27 localhost dhcpcd[8217]: dhcpIPaddrLeaseTime=43200 in DHCP server response.

Mar  7 10:39:27 localhost dhcpcd[8217]: dhcpT1value is missing in DHCP server response. Assuming 21600 sec

Mar  7 10:39:27 localhost dhcpcd[8217]: dhcpT2value is missing in DHCP server response. Assuming 37800 sec

Mar  7 10:39:27 localhost dhcpcd[8217]: DHCP_ACK received from  (x.xx.x.xxx)

Mar  7 10:39:28 localhost sshd[8584]: Server listening on 0.0.0.0 port 22.

Mar  7 10:39:28 localhost netplugd[7655]: eth1: state INNING pid 7656 exited status 0

Mar  7 10:39:48 localhost netplugd[7655]: No interface name

Mar  7 10:39:48 localhost netplugd[7655]: Callback failed
```

Incidentally, those last 2 lines repeat every 30 seconds.

 *Quote:*   

>  *Quote:*   I have a laptop, and want wired preferred over wireless, which is pretty basic.
> 
> What if I walk from access-capable to non-access-capable to access-capable, again?
> 
> Since I'm walking, it's most likely that I'm on battery. In that case, I'd like to think that when I lose signal, and fail to capture a new AP, that the wireless adapter is powered down. But then when I walk back to access-capable, if it's been powered down, it won't re-capture, which is understandable. In that case, there needs to be some way to give it a little kick, preferably as non-root. 
> ...

 

Can you point me to documentation as a starting point? I'm really a newbie with respect to wireless.

 *Quote:*   

>  *Quote:*   Beyond that, it would be nice to have networked and non-networked runlevels, as discussed elsewhere in Gentoo documentation. Be nice for things like sshd and cups.
> 
> How much of this does/can baselayout-1.12 do? 
> 
> baselayout-1.11 can do this also. Simply follow our documentation about creating and using other runlevels.

 

I've read this before, I just have to reread it, and do it. With some time for it to digest, I have a little better understand that the only runlevel hierarchy is from boot->default, or alternative boot->alternative default. Beyond that, any alternative default runlevels are "flat" with respect to each other. That's my starting point, so I think I can get this one.

----------

## UberLord

 *depontius wrote:*   

> Done. emerge -C ifplugd, emerge netplug, I had to go to ~x86 to get it to install, as suggested on bugzilla.

 

You only need baselayout-1.12 which is ~x86 - so you would add

=sys-apps/baselayout-1.12.0* ~x86

to /etc/portage/package.keywords (ditto for any deps baselayout bitches about, like bash)

 *Quote:*   

> According to the netplug homepage, there's a file /etc/netplug.conf, which isn't there in the ebuild, I presume because of the baselayout integration.

 

Correct

 *Quote:*   

> But how do I know what netplug is being told to do, how do I tweak the configuration. Maybe I'm looking in the wrong places for TRM to Read.

 

That's the point of netplug. As it's smaller and lighter you don't tweak the configuration as the only configuration it currently has is what interfaces to monitor, which baselayout takes care of.

 *Quote:*   

>  *Quote:*   Is there anything to watch out for since baselayout-1.12 is marked unstable? 
> 
> Not really. I use 1.12 on all my boxes and servers.

 

Installed and booted, running, although things look a little weird. In the first place, ath0 is up, although no address has been assigned. I presume that's due to the way it's set up to work with netplug.[/quote]

ath0 is a wireless interface, thus it should be controlled by wpa_supplicant.

netplug and ifplugd are for wired interfaces only.

 *Quote:*   

> 
> 
> More disturbing, I want to tweak my dhcpcd in /etc/conf.d/net thus: dhcpcd_eth1="-d -D -H -h arnie -e /var/lib/dhcpc"

 

Don't bother with -e - we force resolv.conf location

We'll probably drop the domainname script at some point, as I think it's pointless. Remove it from your runlevel.

 *Quote:*   

> I'm disturbed that dhcp options appear to be configurable through "dhcp_eth1" or "dhcpcd_eth1"

 

I'm disturbed by your lack of ability to read the documentation.

dhcp_eth1 has generic dhcp configuration options applicable to all dhcp clients

dhcpcd_eth1 has dhcpcd specific configuration options

```
dhcp_eth1="nodns nontp"

dhcpcd_eth1="-R -N"
```

The above do the same thing. The first like works across all dhcp clients (dhcpcp, dhclient, pump, udhcpc) whereas the second only works for dhcpcd.

 *Quote:*   

> There's a real problem on the web site with too much documentation, parts of it overlapping, parts of it obsolete, and knowing what to find, where. I usually end up using google, and even then get too many hits.

 

I did my best. Dont like it? Re-write it then   :Twisted Evil: 

 *Quote:*   

> Can you point me to documentation as a starting point? I'm really a newbie with respect to wireless

 

http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?part=4&chap=4

----------

## depontius

 *UberLord wrote:*   

>  *Quote:*   But how do I know what netplug is being told to do, how do I tweak the configuration. Maybe I'm looking in the wrong places for TRM to Read. 
> 
> That's the point of netplug. As it's smaller and lighter you don't tweak the configuration as the only configuration it currently has is what interfaces to monitor, which baselayout takes care of.

 

But for instance, what if I want to save battery power by shutting down the wireless adapter when I know an access point won't be available or needed? If all of the details are hidden behind the scenes, then my only way to do this is to reverse engineer the scripts. Then I've no guarantee what I do will work across updates. I last ran into this back when I had tweaks for RedHat to adapt to afs at work, non-afs at home, based on granted IP. Every update broke my stuff and forced me to re-integrate it.

 *Quote:*   

>  *Quote:*   
> 
> Installed and booted, running, although things look a little weird. In the first place, ath0 is up, although no address has been assigned. I presume that's due to the way it's set up to work with netplug. 
> 
> ath0 is a wireless interface, thus it should be controlled by wpa_supplicant.
> ...

 

So I've got:

```
modules=( "iproute2" "wpa_supplicant" )

config_eth1=( "dhcp" )

wpa_supplicant_ath0="-dd -Dmadwifi"

dhcpcd_eth1="-d -D -H -h arnie -e /var/lib/dhcpc"
```

The first 3 are from net.examples and TFM, which I did Read, by the way. The latter is assembled from TFM and man dhcpcd.

 *Quote:*   

>  *Quote:*   
> 
> More disturbing, I want to tweak my dhcpcd in /etc/conf.d/net thus: dhcpcd_eth1="-d -D -H -h arnie -e /var/lib/dhcpc" 
> 
> Don't bother with -e - we force resolv.conf location

 

When my laptop is at home, I'd normally want it to get resolv.conf from my home lan - the standard configuration. Sometimes I'm on my home LAN, connected to work via VPN. Today that overwrites resolv.conf, meaning that when I'm on the VPN, I lose my LAN. I've been looking at dnsmasq to get around this. With dnsmasq, I'd set /etc/resolv.conf to 127.0.0.1, I'd add the company nameserver in the dnsmasq.conf file, and I need to stuff the dhcp-granted resolv.conf somewhere else, and tell dnsmasq about it. That way, company packets and names would get routed to the company nameserver, yet my LAN continues to work, including the printer. If it's hardcoded for dhcp to drop /etc/resolv.conf then this solution doesn't work. I suppose I run "nodns", then have a script look at /var/lib/dhcpc/dhcpcd_eth1.info and build a resolv.conf for dnsmasq, but this is more work, more roundabout, and more likely to break on an update.

 *Quote:*   

>  *Quote:*   I'm disturbed that dhcp options appear to be configurable through "dhcp_eth1" or "dhcpcd_eth1" 
> 
> I'm disturbed by your lack of ability to read the documentation.
> 
> dhcp_eth1 has generic dhcp configuration options applicable to all dhcp clients
> ...

 

Again, I read the documentation. What I'm disturbed by is the fact that there are 2 ways to do something. If by some accident I were to happen to do both, which would take precedence? For that matter, if dhcp_eth1 has an option, will that same option coded in dhcpcd_eth1 even work? I tried to set everything with the way I'm used to using "raw", dhcpcd_eth1, and nothing worked.

 *Quote:*   

> 
> 
> ```
> dhcp_eth1="nodns nontp"
> 
> ...

 

The up-to-date Gentoo handbook is just fine. But the documentation listing is 7 pages long, and it's actually been cleaned up quite a bit since I did anything but search from google. But a few of the titles further down refer to "the new Linux 2.4 kernel".

 *Quote:*   

>  *Quote:*   Can you point me to documentation as a starting point? I'm really a newbie with respect to wireless 
> 
> http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?part=4&chap=4

 

As I said, read that. Doesn't really tell what's going on inside baselayout-1.12/netplug, but I guess that stuff's not marked stable, yet.

----------

## UberLord

 *depontius wrote:*   

> But for instance, what if I want to save battery power by shutting down the wireless adapter when I know an access point won't be available or needed? If all of the details are hidden behind the scenes, then my only way to do this is to reverse engineer the scripts. Then I've no guarantee what I do will work across updates. I last ran into this back when I had tweaks for RedHat to adapt to afs at work, non-afs at home, based on granted IP. Every update broke my stuff and forced me to re-integrate it.

 

Hogwash. You can do this

```
preup() {

   if [[ ${IFACE} == "eth1" ]] ; then

      interface_exists "${IFACE}" || modprobe yourmodule

   fi

}

postdown() {

   if [[ ${IFACE} == "eth1" ]] ; then

      interface_exists "${IFACE}" && rmmod yourmodule

   fi

}
```

 *Quote:*   

> 
> 
> So I've got:
> 
> ```
> ...

 

iproute2 is default for 1.12

The first 3 are from net.examples and TFM, which I did Read, by the way. The latter is assembled from TFM and man dhcpcd.

 *Quote:*   

>  *Quote:*   
> 
> More disturbing, I want to tweak my dhcpcd in /etc/conf.d/net thus: dhcpcd_eth1="-d -D -H -h arnie -e /var/lib/dhcpc" 
> 
> Don't bother with -e - we force resolv.conf location

 

When my laptop is at home, I'd normally want it to get resolv.conf from my home lan - the standard configuration. Sometimes I'm on my home LAN, connected to work via VPN.[/quote]

Stop right there. The issue is that many things want to control one file - which is bad. baselayout solves this slightly when RC_AUTO_INTERFACE in /etc/conf.d/rc is enabled as everything under baselayout control. Well that's mainly dhcp clients and static config, but it's a start - we merge resolv.conf files from different interfaces. This is why we force programs that alter resolv.conf like dhcpcd to store their own in their own location. Hence it is inadvisable to use the -e flag.

For baselayout-1,13 (or 1.12 of we don't get it stable for a while yet) we (or someone else - maybe you?) will write a patch to openvpn so it stores it's resolv.conf in ${svcdir}/net-scripts/state/${iface} so that it can be merged. Maybe we won't have to write an openvpn net module, maybe we will.

Your dnsmasq idea sounds plausible though.

 *Quote:*   

>  *Quote:*   I'm disturbed that dhcp options appear to be configurable through "dhcp_eth1" or "dhcpcd_eth1" 
> 
> I'm disturbed by your lack of ability to read the documentation.
> 
> dhcp_eth1 has generic dhcp configuration options applicable to all dhcp clients
> ...

 

Again, I read the documentation. What I'm disturbed by is the fact that there are 2 ways to do something. If by some accident I were to happen to do both, which would take precedence?[/quote]

dhcpcd_eth1="-R" has been around in Gentoo for years - before I joined.

dhcp_eth1="nodns" has been around since baselayout-1.11 and is the preferred way. Infact the documentation merely references dhcpcd_eth1 as a way of passing specific options but desribes the former a lot more.

However dhcpcd takes precedence as it's specific config. That's a general rule of thumb we try to adhere to.

Would it supprise you that we also support

iface_eth0="192.168.0.1 netmask 255.255.255.0 broadcast 192.168.0.255"

ifconfig_eth0="192.168.0.1 netmask 255.255.255.0 broadcast 192.168.0.255"

config_eth0=( "192.168.0.1/24" )

1st line any baselayout version

2nd line baselayout-1.9 and later

3rd line baselayout-1.11 and later

 *Quote:*   

> http://www.gentoo.org/doc/en/handbook/handbook-x86.xml?part=4&chap=4

 

As I said, read that. Doesn't really tell what's going on inside baselayout-1.12/netplug, but I guess that stuff's not marked stable, yet.[/quote]

What's to say?

"emerge netplug to manage your interfaces being started or stopped depending on the cable being plugged in or out."

There is no config - if it doesn't work then file a bug

----------

## depontius

 *UberLord wrote:*   

> Hogwash. You can do this
> 
> ```
> preup() {
> 
> ...

 

Reading the documentation, I like the idea of adding the mii-tool check to preup(), which is one of the things I did to the old RedHat scripts, but they didn't appear to have a structured way to do it, at least not at the time.

As for powering down the wireless, that looks like it will work, but will there be odd interactions with netplug and baselayout-1.12? I guess not, if you're telling me to do this. But at this point it seems mystical and Windows-like, not knowing what's really happening under the covers. (btw, from the script-reading I've done so far, I see your name on most of this stuff. Thanks for your help.)

Just re-found it... in /etc/conf.d/net.example... The laptop still has net.eth1 starting in default. Assuming I haven't told hotplug NOT to start it with hotplug_eth1="no", should I remove it from default? Or lo from boot, for that matter? In other words, should it only be done one way? I'm going to guess you'll say what what I have is OK, but I'm wondering about most correct, least likely to bite back in the future. By the same token, I have a madwifi, so have the virtual? wifi0 interface that never corresponds to a real device. Should I be doing anything with hotplug_ for either that or the real? device ath0?

 *Quote:*   

>  *Quote:*    *Quote:*   So I've got:
> 
> ```
> modules=( "iproute2" "wpa_supplicant" )
> 
> ...

 

So is there a graceful way for me to pull the dnsmasq trick under baselayout-1.12? I'd like /etc/resolv.conf to point to 127.0.0.1 for a nameserver, have dnsmasq use the dhcp-derived resolv.conf for it's primary nameserver, and hard-code my company's nameserver into the line/method that dnsmasq has made available for that function.

As for the VPN, unfortunately it's not OpenVPN, but it's an employer-supplied VPN that does happen to use the tun device. So I'll just use hotplug_tun0="no" as the documentation suggests. If I get dnsmasq integrated, I'll cope with resolv.conf while connected appropriately.

 *Quote:*   

>  *Quote:*    *Quote:*   I'm disturbed by your lack of ability to read the documentation.
> 
> dhcp_eth1 has generic dhcp configuration options applicable to all dhcp clients
> 
> dhcpcd_eth1 has dhcpcd specific configuration options 
> ...

 

This is all I was really asking, thanks. I have some tendancies toward language-lawyer.

 *Quote:*   

>  *Quote:*   Would it supprise you that we also support
> 
> iface_eth0="192.168.0.1 netmask 255.255.255.0 broadcast 192.168.0.255"
> 
> ifconfig_eth0="192.168.0.1 netmask 255.255.255.0 broadcast 192.168.0.255"
> ...

 

How about somewhere, 

"Wired devices will be automatically started, and given priorty. Wireless devices will be started when the wired device becomes unavailble. To remove a device from this management scheme set hotplug_(iface)="no" in /etc/conf.d/net. To powerdown the wireless device when operating standalone on batter, add the these stanzas to preup() and predown(), and execute '/etc/init.d/net.(iface) stop', and execute '/etc/init.d/net.(iface) start'  when you want it available, again. To disable automatic management either remove netplug or set RC_AUTO_INTERFACE="no" in /etc/conf.d/rc."

----------

## UberLord

 *depontius wrote:*   

> As for powering down the wireless, that looks like it will work, but will there be odd interactions with netplug and baselayout-1.12? I guess not, if you're telling me to do this. But at this point it seems mystical and Windows-like, not knowing what's really happening under the covers. (btw, from the script-reading I've done so far, I see your name on most of this stuff. Thanks for your help.)

 

I don't know   :Shocked: 

I've not done that, but the daemons are started/stopped inside of your definable pre/post functions, so it should work

 *Quote:*   

> 
> 
> Just re-found it... in /etc/conf.d/net.example... The laptop still has net.eth1 starting in default. Assuming I haven't told hotplug NOT to start it with hotplug_eth1="no", should I remove it from default? Or lo from boot, for that matter? In other words, should it only be done one way? I'm going to guess you'll say what what I have is OK, but I'm wondering about most correct, least likely to bite back in the future. By the same token, I have a madwifi, so have the virtual? wifi0 interface that never corresponds to a real device. Should I be doing anything with hotplug_ for either that or the real? device ath0?

 

What you have is ok  :Wink: 

Seriously, there normally is no right or best way of doing something. If it works then yay!

Do what I do, ignore wifi0 and hope the madwifi devs take it away!

 *Quote:*   

> 
> 
> So is there a graceful way for me to pull the dnsmasq trick under baselayout-1.12? I'd like /etc/resolv.conf to point to 127.0.0.1 for a nameserver, have dnsmasq use the dhcp-derived resolv.conf for it's primary nameserver, and hard-code my company's nameserver into the line/method that dnsmasq has made available for that function.

 

So you just want to hardcode a nameserver? That's simple!

```
dns_servers_lo="1.2.3.4"
```

 *Quote:*   

> How about somewhere, "Wired devices will be automatically started, and given priorty. Wireless devices will be started when the wired device becomes unavailble. To remove a device from this management scheme set hotplug_(iface)="no" in /etc/conf.d/net. To powerdown the wireless device when operating standalone on batter, add the these stanzas to preup() and predown(), and execute '/etc/init.d/net.(iface) stop', and execute '/etc/init.d/net.(iface) start'  when you want it available, again. To disable automatic management either remove netplug or set RC_AUTO_INTERFACE="no" in /etc/conf.d/rc."

 

Feel free to open a documentation bug when baselayout-1.12 goes stable then  :Smile: 

----------

