| View previous topic :: View next topic |
| Author |
Message |
AdmiralNemo
Apprentice
Joined: 25 Sep 2004
Posts: 247
Location: Overland Park, KS
|
 Posted: Sun Jan 15, 2006 4:03 pm Post subject: Detecting Existance of Network Cable |
 |
|
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
_________________
Help the Unanswered |
|
| Back to top |
|
 |
nielchiano
Veteran
Joined: 11 Nov 2003
Posts: 1287
Location: 50N 3E
|
| Posted: Sun Jan 15, 2006 4:49 pm Post subject: |
|
|
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: | Code: | 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: | Code: | -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: | Code: | 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! |
|
| Back to top |
|
|
UberLord
Retired Dev
Joined: 18 Sep 2003
Posts: 6835
Location: Blighty
|
|
| Back to top |
|
|
depontius
Advocate
Joined: 05 May 2004
Posts: 3525
|
| Posted: Mon Mar 06, 2006 7:49 pm Post subject: |
|
|
| 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?
_________________
.sigs waste space and bandwidth |
|
| Back to top |
|
|
UberLord
Retired Dev
Joined: 18 Sep 2003
Posts: 6835
Location: Blighty
|
| Posted: Mon Mar 06, 2006 8:48 pm Post subject: |
|
|
| 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.
_________________
Use dhcpcd for all your automated network configuration needs
Use dhcpcd-ui (GTK+/Qt) as your System Tray Network tool |
|
| Back to top |
|
|
depontius
Advocate
Joined: 05 May 2004
Posts: 3525
|
| Posted: Tue Mar 07, 2006 4:19 pm Post subject: |
|
|
| 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:
| Code: | 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. |
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, |
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.
_________________
.sigs waste space and bandwidth |
|
| Back to top |
|
|
UberLord
Retired Dev
Joined: 18 Sep 2003
Posts: 6835
Location: Blighty
|
| Posted: Tue Mar 07, 2006 6:09 pm Post subject: |
|
|
| 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
| Code: | 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 
| 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
_________________
Use dhcpcd for all your automated network configuration needs
Use dhcpcd-ui (GTK+/Qt) as your System Tray Network tool |
|
| Back to top |
|
|
depontius
Advocate
Joined: 05 May 2004
Posts: 3525
|
| Posted: Tue Mar 07, 2006 7:35 pm Post subject: |
|
|
| 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.
netplug and ifplugd are for wired interfaces only. |
So I've got:
| Code: | 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
dhcpcd_eth1 has dhcpcd specific configuration options |
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: | | Code: | 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 |
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".
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.
_________________
.sigs waste space and bandwidth |
|
| Back to top |
|
|
UberLord
Retired Dev
Joined: 18 Sep 2003
Posts: 6835
Location: Blighty
|
| Posted: Tue Mar 07, 2006 9:38 pm Post subject: |
|
|
| 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
| Code: | 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:
| Code: | modules=( "iproute2" "wpa_supplicant" )
config_eth1=( "dhcp" )
wpa_supplicant_ath0="-dd -Dmadwifi"
dhcpcd_eth1="-d -D -H -h arnie -e /var/lib/dhcpc" |
|
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
dhcpcd_eth1 has dhcpcd specific configuration options |
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
_________________
Use dhcpcd for all your automated network configuration needs
Use dhcpcd-ui (GTK+/Qt) as your System Tray Network tool |
|
| Back to top |
|
|
depontius
Advocate
Joined: 05 May 2004
Posts: 3525
|
| Posted: Thu Mar 09, 2006 5:02 pm Post subject: |
|
|
| UberLord wrote: | Hogwash. You can do this
| Code: | preup() {
if [[ ${IFACE} == "eth1" ]] ; then
interface_exists "${IFACE}" || modprobe yourmodule
fi
}
postdown() {
if [[ ${IFACE} == "eth1" ]] ; then
interface_exists "${IFACE}" && rmmod yourmodule
fi
} |
|
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:
| Code: | modules=( "iproute2" "wpa_supplicant" )
config_eth1=( "dhcp" )
wpa_supplicant_ath0="-dd -Dmadwifi"
dhcpcd_eth1="-d -D -H -h arnie -e /var/lib/dhcpc" |
|
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. |
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. |
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 |
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? |
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. |
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"
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
|
My oldest running system began life as Gentoo-1.4, and it has just kept working, which is really the goal of backward compatibility, I guess. I'd have to go back and see what form of configuration it had.
| Quote: | | 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. |
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 |
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."
_________________
.sigs waste space and bandwidth |
|
| Back to top |
|
|
UberLord
Retired Dev
Joined: 18 Sep 2003
Posts: 6835
Location: Blighty
|
| Posted: Thu Mar 09, 2006 5:39 pm Post subject: |
|
|
| 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 
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 
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!
| Code: | | 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 
_________________
Use dhcpcd for all your automated network configuration needs
Use dhcpcd-ui (GTK+/Qt) as your System Tray Network tool |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Networking & Security
