Re: [PLUG] Troubleshooting DHCP...
On Sun, 2009-12-27 at 21:13 -0800, Daniel Johnson wrote: > > The other diskless machine on another nic off of the same server, dodo, > > boots just fine by the way. Is something obviously wrong in my dhcp > > config file or am I looking at a problem with the switch? DHCP worked > > when I was using a 10BaseT hub which makes me wonder if the line can't > > support 100baseTX. > > It could be a problem with autoconfiguring the speed, and duplex of > the connection. I've had two switches decide on different modes, and > thus get a broken network. When one side is a dumb 10 megabit hub it > doesn't try to negotiate, so you never have to worry about that > problem. If you can force it into different modes try that. I forced the server to half duplex using ethtool, but I can't force the client to go to half duplex. Put the 10Mbit dumb hub back in, dhcp worked like a charm and the machine network booted no problem. I wonder if being a switch it was blocking the dhcp replies? I should in theory be able to pull the hub and replace it with a crossover coupler. I'm starting to think that the switch I was trying to use is bad or maybe I need a 100 megabit per second hub instead. Thing is, I use another DSS5+ switch with a linksys wireless WAP11 plugged into it that configures via dhcp no problem. I'm not sure what the issue is here. Just to double check, 190' is within the range limitations for 100BaseTX, right? ___ PLUG mailing list PLUG@lists.pdxlinux.org http://lists.pdxlinux.org/mailman/listinfo/plug
Re: [PLUG] Troubleshooting DHCP...
> The other diskless machine on another nic off of the same server, dodo, > boots just fine by the way. Is something obviously wrong in my dhcp > config file or am I looking at a problem with the switch? DHCP worked > when I was using a 10BaseT hub which makes me wonder if the line can't > support 100baseTX. It could be a problem with autoconfiguring the speed, and duplex of the connection. I've had two switches decide on different modes, and thus get a broken network. When one side is a dumb 10 megabit hub it doesn't try to negotiate, so you never have to worry about that problem. If you can force it into different modes try that. -- teknotus Take Notice (503) 409-1735 ___ PLUG mailing list PLUG@lists.pdxlinux.org http://lists.pdxlinux.org/mailman/listinfo/plug
Re: [PLUG] Troubleshooting DHCP...
On Sun, Dec 27, 2009 at 8:54 PM, Michael Robinson
wrote:
> I'm trying to replace a 10BaseT DLink hub with a 100 Base TX DSS 5+
> switch. DHCP doesn't work anymore.
>
> The server is on one end connected via an FA311 netgear card. From
> there, a 100' Cat5e cable runs to the switch in the attic. Then I
> go to Cat5 STP cable for an additional 90' outside, underground,
> and back above ground into the next building. The diskless machine
> that boots via floppy is on the far end. A 190' run made up of a
> 100' and a 90' run seems to be within the range limitations for
> 100BaseTX. Then again, the cable is shallowly buried and could
> be getting weathered.
>
> I see DHCPDISCOVER and DHCPOFFER, but nothing past that.
>
> Dec 27 20:32:36
> goose dhcpd: DHCPDISCOVER from 00:02:e3:02:46:37 via eth2
> Dec 27 20:32:36
> goose dhcpd: DHCPOFFER on 192.168.4.17 to 00:02:e3:02:46:37 via eth2
>
> Most of my dhcpd.conf follows:
>
> failover peer "dhcp"
> {
> primary;
> address 192.168.5.2;
> port 647;
>
> peer address 192.168.5.1;
> peer port 647;
> max-response-delay 60;
> max-unacked-updates 10;
> mclt 600;
> split 128;
> load balance max seconds 3;
>
> peer address 192.168.5.4;
> }
>
>
>
> ddns-update-style none;
> authoritative;
> allow booting;
> next-server 192.168.5.2;
>
>
>
> # %%% wifi-2 %%%
> shared-network WIFI-2
> {
> subnet 192.168.4.0 netmask 255.255.255.240
> {
>option domain-name "w2.robinson-west.pri";
>option domain-name-servers 192.168.4.2;
>option routers 192.168.4.2;
>option broadcast-address 192.168.4.15;
>option ntp-servers 192.168.4.2;
> }
>
> subnet 192.168.4.16 netmask 255.255.255.240
> {
>option domain-name "w2.robinson-west.pri";
>option domain-name-servers 192.168.4.18;
>option routers 192.168.4.18;
>option broadcast-address 192.168.4.31;
>option ntp-servers 192.168.4.18;
> }
>
> # %%% wifi-2 network segment 1 %%%
> group
> {
> use-host-decl-names on;
> next-server 192.168.4.2;
>
> host dodo.w2.robinson-west.pri
> {
> hardware ethernet 00:02:E3:14:1C:94;
> fixed-address 192.168.4.1;
> option root-path "192.168.4.2:/nfsroot/dodo";
> filename="\dodo.nbi";
> }
> }
> # %%% wifi-2 network segment 1 %%%
>
> # %%% wifi-2 network segment 2 %%%
> group
> {
> use-host-decl-names on;
> next-server 192.168.4.18;
>
> host condor.w2.robinson-west.pri
> {
> hardware ethernet 00:02:E3:02:46:37;
> fixed-address 192.168.4.17;
> option root-path "192.168.4.18:/nfsroot/condor";
> filename="\condor.nbi";
> }
> }
> # %%% wifi-2 network segment 2 %%%
> }
> # %%% wifi-2 %%%
>
>
>
> # %%% local lan %%%
> shared-network LAN-1
> {
> subnet 192.168.5.0 netmask 255.255.255.0
> {
>pool
>{
> failover peer "dhcp";
> range 192.168.5.129 192.168.5.254;
> deny dynamic bootp clients;
>}
>
>option routers 192.168.5.6;
>option domain-name-servers 192.168.5.1, 192.168.5.4;
>option domain-name "robinson-west.com";
>option broadcast-address 192.168.5.255;
>option ntp-servers 192.168.5.2;
> }
>
> group
> {
> ...
> # This is populated by host records...
> }
> # %%% local lan %%%
> }
> ...
> # I define the Internet subnet...
>
> The other diskless machine on another nic off of the same server, dodo,
> boots just fine by the way. Is something obviously wrong in my dhcp
> config file or am I looking at a problem with the switch? DHCP worked
> when I was using a 10BaseT hub which makes me wonder if the line can't
> support 100baseTX.
>
> ___
> PLUG mailing list
> PLUG@lists.pdxlinux.org
> http://lists.pdxlinux.org/mailman/listinfo/plug
>
Have you verified you have a solid link between switch and hub? Have you
verified the switch sees the hub at 10mb? Auto-negotiate can fail and at
times forced or turned off. Plenty of reasons why it might not work beyond
DHCP.
Drew-
___
PLUG mailing list
PLUG@lists.pdxlinux.org
http://lists.pdxlinux.org/mailman/listinfo/plug
[PLUG] Troubleshooting DHCP...
I'm trying to replace a 10BaseT DLink hub with a 100 Base TX DSS 5+
switch. DHCP doesn't work anymore.
The server is on one end connected via an FA311 netgear card. From
there, a 100' Cat5e cable runs to the switch in the attic. Then I
go to Cat5 STP cable for an additional 90' outside, underground,
and back above ground into the next building. The diskless machine
that boots via floppy is on the far end. A 190' run made up of a
100' and a 90' run seems to be within the range limitations for
100BaseTX. Then again, the cable is shallowly buried and could
be getting weathered.
I see DHCPDISCOVER and DHCPOFFER, but nothing past that.
Dec 27 20:32:36
goose dhcpd: DHCPDISCOVER from 00:02:e3:02:46:37 via eth2
Dec 27 20:32:36
goose dhcpd: DHCPOFFER on 192.168.4.17 to 00:02:e3:02:46:37 via eth2
Most of my dhcpd.conf follows:
failover peer "dhcp"
{
primary;
address 192.168.5.2;
port 647;
peer address 192.168.5.1;
peer port 647;
max-response-delay 60;
max-unacked-updates 10;
mclt 600;
split 128;
load balance max seconds 3;
peer address 192.168.5.4;
}
ddns-update-style none;
authoritative;
allow booting;
next-server 192.168.5.2;
# %%% wifi-2 %%%
shared-network WIFI-2
{
subnet 192.168.4.0 netmask 255.255.255.240
{
option domain-name "w2.robinson-west.pri";
option domain-name-servers 192.168.4.2;
option routers 192.168.4.2;
option broadcast-address 192.168.4.15;
option ntp-servers 192.168.4.2;
}
subnet 192.168.4.16 netmask 255.255.255.240
{
option domain-name "w2.robinson-west.pri";
option domain-name-servers 192.168.4.18;
option routers 192.168.4.18;
option broadcast-address 192.168.4.31;
option ntp-servers 192.168.4.18;
}
# %%% wifi-2 network segment 1 %%%
group
{
use-host-decl-names on;
next-server 192.168.4.2;
host dodo.w2.robinson-west.pri
{
hardware ethernet 00:02:E3:14:1C:94;
fixed-address 192.168.4.1;
option root-path "192.168.4.2:/nfsroot/dodo";
filename="\dodo.nbi";
}
}
# %%% wifi-2 network segment 1 %%%
# %%% wifi-2 network segment 2 %%%
group
{
use-host-decl-names on;
next-server 192.168.4.18;
host condor.w2.robinson-west.pri
{
hardware ethernet 00:02:E3:02:46:37;
fixed-address 192.168.4.17;
option root-path "192.168.4.18:/nfsroot/condor";
filename="\condor.nbi";
}
}
# %%% wifi-2 network segment 2 %%%
}
# %%% wifi-2 %%%
# %%% local lan %%%
shared-network LAN-1
{
subnet 192.168.5.0 netmask 255.255.255.0
{
pool
{
failover peer "dhcp";
range 192.168.5.129 192.168.5.254;
deny dynamic bootp clients;
}
option routers 192.168.5.6;
option domain-name-servers 192.168.5.1, 192.168.5.4;
option domain-name "robinson-west.com";
option broadcast-address 192.168.5.255;
option ntp-servers 192.168.5.2;
}
group
{
...
# This is populated by host records...
}
# %%% local lan %%%
}
...
# I define the Internet subnet...
The other diskless machine on another nic off of the same server, dodo,
boots just fine by the way. Is something obviously wrong in my dhcp
config file or am I looking at a problem with the switch? DHCP worked
when I was using a 10BaseT hub which makes me wonder if the line can't
support 100baseTX.
___
PLUG mailing list
PLUG@lists.pdxlinux.org
http://lists.pdxlinux.org/mailman/listinfo/plug
Re: [PLUG] resolve.conf file
On Sun, Dec 27, 2009 at 2:36 PM, Denis Heidtmann wrote: > Thanks for all the information and advice. Unfortunately, Carlos' > comment about dsl modems applies in my situation: an Actiontec modem > from Qwest. So attempts to change its dhcp behavior will not bear > fruit. My use of resolvconf is a sensible solution to a > less-than-perfect state of affairs. Mike's suggestions seem a better > solution, and I will study those, but until then, resolvconf is my > ticket to functioning. (To settle the question of what this modem > can/cannot do, from Actiontec I received: "The PK5000 itself is NOT a > DNS server or redirection device. There is no programming in fact to > do a DNS redirection internally. It cannot do that at all.") I had one of those modems, and as I remember it the problem has something to do with it trying to support ip6, and failing. Turning off ip6 support in linux was one solution. A work around that I used was just installing bind on my computer, setting resolve.conf to use 127.0.0.1 as my name server, and hard setting the DHCP client to not use the DNS servers it got. Though I think I had some problems with roaming and needing to use the DNS servers at work that resolved names local to the office. If I was setting it up again today I would probably make wpa_supplicant use a mapping to use different network settings depending on what network it connected to. ___ PLUG mailing list PLUG@lists.pdxlinux.org http://lists.pdxlinux.org/mailman/listinfo/plug
Re: [PLUG] resolve.conf file
On Sun, Dec 27, 2009 at 6:36 PM, Russell Senior wrote: > > "Carlos" == Carlos Konstanski > writes: > > Carlos> Easy pal, no one is trying to steer you wrong. It can feel > Carlos> like that if you remain fixated on a solution that isn't > Carlos> necessarily the best. The best solution: get off qwest, go > Carlos> with a cable provider that uses a pass-through modem, and use > Carlos> your own router/firewall (a $30 hardware job or a linux box). > > Not to hijack the thread, but ... comcast and "best solution" don't > belong in the same sentence, at least not without an odd number of > emphatic negations. > > > I could go along with "lesser of the available evils" -wes ___ PLUG mailing list PLUG@lists.pdxlinux.org http://lists.pdxlinux.org/mailman/listinfo/plug
Re: [PLUG] resolve.conf file
> "Carlos" == Carlos Konstanski writes: Carlos> Easy pal, no one is trying to steer you wrong. It can feel Carlos> like that if you remain fixated on a solution that isn't Carlos> necessarily the best. The best solution: get off qwest, go Carlos> with a cable provider that uses a pass-through modem, and use Carlos> your own router/firewall (a $30 hardware job or a linux box). Not to hijack the thread, but ... comcast and "best solution" don't belong in the same sentence, at least not without an odd number of emphatic negations. -- Russell Senior ``I have nine fingers; you have ten.'' seni...@aracnet.com ___ PLUG mailing list PLUG@lists.pdxlinux.org http://lists.pdxlinux.org/mailman/listinfo/plug
[PLUG] FVX538 and IP assignments...
The FVX538 has a DHCP server and it works okay, but the addressing scheme is a random one. Uge! Is there any way to fix the IP addresses and still assign them from the FVX 538? Can the FVX 538 support dynamic DNS updating so I can name the darn addresses regardless of what they happen to be at the moment? I'm trying to use the FVX 538 in a different sort of way. I DON'T want to access the Internet through it and I don't want to be able to. I DO want to access the systems on it's private LAN and systems in private LANs connected via tunnel. I am also trying to connect the FVX538's LAN to another LAN. I think I plugged into the wrong port choosing one of the LAN ports instead of the DMZ port, but maybe I didn't. It seems that the DMZ is only intended for hosts which possibly serve the Internet that cannot go through NAT. A downside of the DMZ on the FVX 538 is that networking between LAN and DMZ is blocked. How does dynamic dns work? Does the DHCP server send a MAC/IP address pair? This is the information I need to assign the same name to the same computer regardless of the IP assignment if I write a program to generate the zone files. Can the FVX 538 support assigning static routes to other private networks via one of the statically configured hosts on the LAN segment? I've tried google, but my situation doesn't seem to be covered. ___ PLUG mailing list PLUG@lists.pdxlinux.org http://lists.pdxlinux.org/mailman/listinfo/plug
Re: [PLUG] resolve.conf file
Denis Heidtmann wrote: > Thanks for all the information and advice. Unfortunately, Carlos' > comment about dsl modems applies in my situation: an Actiontec modem > from Qwest. I think you mentioned a while back you're with DSL Northwest. If this is still true, then you're putting too much emphasis in the Qwest part. DSLNW is your ISP. Call them and ask for your modem to be put into Bridged mode if that's what you want. Some ISP's are willing to do this (or even have this as the default) and some aren't. This will allow you to use your own router appliance or computer as your router/gateway/firewall. Qwest has nothing to do with this part. They only provide the copper. The ISP will provide the modem for whatever phone company the customer is with, but they have control over how the device configured. Sorry if I'm not tracking, I didn't want to go read all history here. -- m0gely ___ PLUG mailing list PLUG@lists.pdxlinux.org http://lists.pdxlinux.org/mailman/listinfo/plug
Re: [PLUG] resolve.conf file
On Sun, 27 Dec 2009, Denis Heidtmann wrote: > Date: Sun, 27 Dec 2009 14:36:31 -0800 > From: Denis Heidtmann > Reply-To: "General Linux/UNIX discussion and help;civil and on-topic" > > To: "General Linux/UNIX discussion and help, civil and on-topic" > > Subject: Re: [PLUG] resolve.conf file > > Thanks for all the information and advice. Unfortunately, Carlos' > comment about dsl modems applies in my situation: an Actiontec modem > from Qwest. So attempts to change its dhcp behavior will not bear > fruit. My use of resolvconf is a sensible solution to a > less-than-perfect state of affairs. Mike's suggestions seem a better > solution, and I will study those, but until then, resolvconf is my > ticket to functioning. (To settle the question of what this modem > can/cannot do, from Actiontec I received: "The PK5000 itself is NOT a > DNS server or redirection device. There is no programming in fact to > do a DNS redirection internally. It cannot do that at all.") > > With regard to the /etc/resolv.conf file, it is a link to > etc/resolvconf/run/resolv.conf, which is maintained by resolvconf. > > Now, to get to the unanswered questions in my post: > > Why does the presence of "nameserver 192.168.0.1" in resolv.conf not > break dns searches occasionally? > > Should I attempt to clean up this file? If I should, how might that > be done? Since a dhcp client in not now running on my machine, the > bogus entries, once gone, should stay gone. > > -Denis Easy pal, no one is trying to steer you wrong. It can feel like that if you remain fixated on a solution that isn't necessarily the best. The best solution: get off qwest, go with a cable provider that uses a pass-through modem, and use your own router/firewall (a $30 hardware job or a linux box). But to stick within the confines of your situation: It is quite possible to do DHCP without rewriting the resolv.conf file. Gentoo allows a line like the following to be placed into /etc/conf.d/net: dhcp_eth0="nodns" This produces the required behavior of leaving resolv.conf alone. It does so by adding the appropriate command-line option to the DHCP client. I use pump. It has this option: -d --no-dnsDon't update DNS resolver configuration Every distro has its own way of configuring custom options for startup services like DHCP. Which distro are you using? Once we know that, we can figure out where the -d must go. Once you achieve this, you can write the resolv.conf file any way you like, and it will remain so. Or, if you don't want to turn DHCP back on, simply edit resolv.conf right now in an editor, and it will stay put as long as you aren't running any services that can change it, like resolvconf. Simply turn resolvconf off. It has performed its duty of sniffing out the qwest nameservers for you; its work is done. It doesn't need to redo this on every boot. Carlos ___ PLUG mailing list PLUG@lists.pdxlinux.org http://lists.pdxlinux.org/mailman/listinfo/plug
Re: [PLUG] resolve.conf file
> > > Why does the presence of "nameserver 192.168.0.1" in resolv.conf not > break dns searches occasionally? > > I can only theorize that the resolvconf program handles its contents differently, if at all. Should I attempt to clean up this file? If I should, how might that > be done? Since a dhcp client in not now running on my machine, the > bogus entries, once gone, should stay gone. > > If it ain't broke, don't fix it. > -Denis > -wes ___ PLUG mailing list PLUG@lists.pdxlinux.org http://lists.pdxlinux.org/mailman/listinfo/plug
Re: [PLUG] resolve.conf file
Thanks for all the information and advice. Unfortunately, Carlos' comment about dsl modems applies in my situation: an Actiontec modem from Qwest. So attempts to change its dhcp behavior will not bear fruit. My use of resolvconf is a sensible solution to a less-than-perfect state of affairs. Mike's suggestions seem a better solution, and I will study those, but until then, resolvconf is my ticket to functioning. (To settle the question of what this modem can/cannot do, from Actiontec I received: "The PK5000 itself is NOT a DNS server or redirection device. There is no programming in fact to do a DNS redirection internally. It cannot do that at all.") With regard to the /etc/resolv.conf file, it is a link to etc/resolvconf/run/resolv.conf, which is maintained by resolvconf. Now, to get to the unanswered questions in my post: Why does the presence of "nameserver 192.168.0.1" in resolv.conf not break dns searches occasionally? Should I attempt to clean up this file? If I should, how might that be done? Since a dhcp client in not now running on my machine, the bogus entries, once gone, should stay gone. -Denis ___ PLUG mailing list PLUG@lists.pdxlinux.org http://lists.pdxlinux.org/mailman/listinfo/plug
Re: [PLUG] resolve.conf file
> Of course these DSL > modems are notoriously crappy, and it is quite possible that fiddling > with its configuration will have no effect. That's why I use cable and > my own linux box as a router/firewall. Cable modems do not contain > router/firewalls; they simply pass the connection through. > > This is not necessarily true. In my current field of work, I talk to a lot of people using home-based internet connections, and some of them do have Comcast cable with a router/modem device. I will say that they are typically far better than the Actiontec DSL modems, but they still don't always do what I want. Further, many (if not most) DSL modems can be configured for "bridged" mode, which turns off the router part and makes it act like just a modem, as you describe about cable modems. -wes ___ PLUG mailing list PLUG@lists.pdxlinux.org http://lists.pdxlinux.org/mailman/listinfo/plug
Re: [PLUG] resolve.conf file
Carlos Konstanski wrote: > I hate to be a party pooper, but I still feel that using resolvconf > and static IPs is a bandaid that will continue to peel off when > wet. The right thing to do is to get your own DNS and DHCP servers > (the ones on the DSL router) working properly. Of course these DSL > modems are notoriously crappy, and it is quite possible that fiddling > with its configuration will have no effect. That's why I use cable and > my own linux box as a router/firewall. I have to say I agree pretty strongly w. Carlos on this. And unlike your "visiting geek", problems are always interesting to me until things work the way that I understand that they should work. With that said, the config file /etc/dhcp3/dhclient.conf on Debian should control your DNS destiny... To the best of my knowledge you have a few options to control what info you get from the DHCP server when you send a DHCP request. 1. Make sure the following requirement line is commented / deleted: #require subnet-mask, domain-name-servers 2. In the "request" stanza below you can remove "domain-name-servers": request subnet-mask, broadcast-address, routers, *domain-name-servers*, interface-mtu,rfc3442-classless-static-routes, 3. In the event that the above doesn't stop the overwriting of your resolv.conf file with bad DNS info you can add this prepend statement: prepend domain-name-servers 127.0.0.1; 4. You can make the resolv.conf file unchangeable by setting the "immutable" attribute: chattr +i /etc/resolv.conf 5. Last but not least you could make the resolvoconf script itself either unreadable , rename it, or hack it /etc/dhcp3/dhclient-enter-hooks.d/resolvconf ___ PLUG mailing list PLUG@lists.pdxlinux.org http://lists.pdxlinux.org/mailman/listinfo/plug
Re: [PLUG] resolve.conf file
Carlos Konstanski wrote: > I hate to be a party pooper, but I still feel that using resolvconf > and static IPs is a bandaid that will continue to peel off when > wet. The right thing to do is to get your own DNS and DHCP servers > (the ones on the DSL router) working properly. Of course these DSL > modems are notoriously crappy, and it is quite possible that fiddling > with its configuration will have no effect. That's why I use cable and > my own linux box as a router/firewall. > I have to say I agree pretty strongly w. Carlos on this. And unlike your "visiting geek", problems are always interesting to me until things work the way that I understand that they should work. With that said, the config file /etc/dhcp3/dhclient.conf on Debian should control your DNS destiny... To the best of my knowledge you have a few options to control what info you get from the DHCP server when you send a DHCP request. 1. Make sure the following requirement line is commented / deleted: #require subnet-mask, domain-name-servers 2. In the "request" stanza below you can remove "domain-name-servers": request subnet-mask, broadcast-address, routers, *domain-name-servers*, interface-mtu,rfc3442-classless-static-routes, 3. In the event that the above doesn't stop the overwriting of your resolv.conf file with bad DNS info you can add this prepend statement: prepend domain-name-servers 127.0.0.1; 4. You can make the resolv.conf file unchangeable by setting the "immutable" attribute: chattr +i /etc/resolv.conf 5. Last but not least you could make the resolvoconf script itself either unreadable , rename it, or hack it /etc/dhcp3/dhclient-enter-hooks.d/resolvconf ___ PLUG mailing list PLUG@lists.pdxlinux.org http://lists.pdxlinux.org/mailman/listinfo/plug
Re: [PLUG] resolve.conf file
> > > As best as I can determine, everything is working fine. But I seek > some understanding. The resolv.conf contains some entries which make > no sense to me. The visiting geek is no longer interested in these > questions, as it is no longer broken. So I appeal to you. > > resolv.conf: > > # Dynamic resolv.conf(5) file for glibc resolver(3) generated by > resolvconf(8) > # DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN > nameserver 192.168.0.1 > nameserver 69.64.224.67 > nameserver 69.64.224.66 > search domain.actdsltmp > from reading the resolvconf manpage ( http://www.clab.it/cgi-bin/man/man2html?resolvconf+8) I infer that it causes the resolv.conf file to no longer be used, meaning the data in that file is now irrelevant. Resolvconf appears to store its data somewhere else, but I didn't read long enough to find out where. The "search" entry would have come from your DSL modem and is there because whatever ISP originally configured it wanted it there. -wes ___ PLUG mailing list PLUG@lists.pdxlinux.org http://lists.pdxlinux.org/mailman/listinfo/plug
Re: [PLUG] resolve.conf file
On Sun, 27 Dec 2009, Carlos Konstanski wrote: > Date: Sun, 27 Dec 2009 11:39:24 -0700 (MST) > From: Carlos Konstanski > Reply-To: "General Linux/UNIX discussion and help;civil and on-topic" > > To: "General Linux/UNIX discussion and help; civil and on-topic" > > Subject: Re: [PLUG] resolve.conf file > > On Sun, 27 Dec 2009, Denis Heidtmann wrote: > >> Date: Sun, 27 Dec 2009 10:10:59 -0800 >> From: Denis Heidtmann >> Reply-To: "General Linux/UNIX discussion and help; civil and on-topic" >> >> To: "General Linux/UNIX discussion and help, civil and on-topic" >> >> Subject: [PLUG] resolve.conf file >> >> I mentioned earlier that I was having trouble with a new dsl modem's >> behavior as a dns server. That has been resolved by avoiding dhcp. >> This was accomplished with the help of a visiting geek (my son). >> Resolveconf was installed; dns addresses set statically, >> >> As best as I can determine, everything is working fine. But I seek >> some understanding. The resolv.conf contains some entries which make >> no sense to me. The visiting geek is no longer interested in these >> questions, as it is no longer broken. So I appeal to you. >> >> resolv.conf: >> >> # Dynamic resolv.conf(5) file for glibc resolver(3) generated by >> resolvconf(8) >> # DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN >> nameserver 192.168.0.1 >> nameserver 69.64.224.67 >> nameserver 69.64.224.66 >> search domain.actdsltmp >> >> I expect that the nameserver 192.168.0.1 entry is left over from >> earlier dhcp responses. (Visiting geek's Debian machine has only the >> two valid nameserver entries in his file--he had not run a dhcp >> client.) Why does it persist in this file? And why does it not break >> dns searches occasionally? If I run dig repeatedly, only the >> 69.64.224.67 address seems to get used. If I force use of >> 192.168.0.1, it fails, as expected. >> >> What does "search domain.actdsltmp" do? Is domain.actdsltmp a valid name? >> >> Should I attempt to clean up this file? If I should, how might that be done? >> >> Thanks for any education you can throw my way. >> >> -Denis > > 192.168.0.1 is most likely the IP address of your DSL router. I never > used resolvconf, but if it's writing this file, then I'll bet that > there is some sort of DNS server running on the router. Run the > following command from a root shell (it will take a long time to run): > > nmap -sU 192.168.0.1 > > If you see UDP port 53 listed as open, then there is a DNS server > running on the router. (If you see port 68, that's the DHCP server.) > If this is true, it would be in your best interests to get it working > properly, and use it instead of going directly to the ISP DNS > servers. The local DNS server should be doing lookups on behalf of all > users on your LAN, and caching the results for faster speed and less > internet chatter. > > The "search" line is for when you attempt to resolve a > non-fully-qualified hostname. For instance, my local domain is > pippiandcarlos.com, and this is reflected in my resolv.conf file as > "search pippiandcarlos.com". If I try to "ping ns", it will be > converted to "ping ns.pippiandcarlos.com". > > I hate to be a party pooper, but I still feel that using resolvconf > and static IPs is a bandaid that will continue to peel off when > wet. The right thing to do is to get your own DNS and DHCP servers > (the ones on the DSL router) working properly. Of course these DSL > modems are notoriously crappy, and it is quite possible that fiddling > with its configuration will have no effect. That's why I use cable and > my own linux box as a router/firewall. Cable modems do not contain > router/firewalls; they simply pass the connection through. The last > DSL modem I had was an Actiontek which did not respond to any of my > attempts to configure it. Qwest refused to replace it. They told me I > could buy my own. Customer exits stage. > > Carlos Correction: DHCP is on UDP port 67, not 68. Carlos ___ PLUG mailing list PLUG@lists.pdxlinux.org http://lists.pdxlinux.org/mailman/listinfo/plug
Re: [PLUG] resolve.conf file
On Sun, 27 Dec 2009, Denis Heidtmann wrote: > Date: Sun, 27 Dec 2009 10:10:59 -0800 > From: Denis Heidtmann > Reply-To: "General Linux/UNIX discussion and help;civil and on-topic" > > To: "General Linux/UNIX discussion and help, civil and on-topic" > > Subject: [PLUG] resolve.conf file > > I mentioned earlier that I was having trouble with a new dsl modem's > behavior as a dns server. That has been resolved by avoiding dhcp. > This was accomplished with the help of a visiting geek (my son). > Resolveconf was installed; dns addresses set statically, > > As best as I can determine, everything is working fine. But I seek > some understanding. The resolv.conf contains some entries which make > no sense to me. The visiting geek is no longer interested in these > questions, as it is no longer broken. So I appeal to you. > > resolv.conf: > > # Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8) > # DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN > nameserver 192.168.0.1 > nameserver 69.64.224.67 > nameserver 69.64.224.66 > search domain.actdsltmp > > I expect that the nameserver 192.168.0.1 entry is left over from > earlier dhcp responses. (Visiting geek's Debian machine has only the > two valid nameserver entries in his file--he had not run a dhcp > client.) Why does it persist in this file? And why does it not break > dns searches occasionally? If I run dig repeatedly, only the > 69.64.224.67 address seems to get used. If I force use of > 192.168.0.1, it fails, as expected. > > What does "search domain.actdsltmp" do? Is domain.actdsltmp a valid name? > > Should I attempt to clean up this file? If I should, how might that be done? > > Thanks for any education you can throw my way. > > -Denis 192.168.0.1 is most likely the IP address of your DSL router. I never used resolvconf, but if it's writing this file, then I'll bet that there is some sort of DNS server running on the router. Run the following command from a root shell (it will take a long time to run): nmap -sU 192.168.0.1 If you see UDP port 53 listed as open, then there is a DNS server running on the router. (If you see port 68, that's the DHCP server.) If this is true, it would be in your best interests to get it working properly, and use it instead of going directly to the ISP DNS servers. The local DNS server should be doing lookups on behalf of all users on your LAN, and caching the results for faster speed and less internet chatter. The "search" line is for when you attempt to resolve a non-fully-qualified hostname. For instance, my local domain is pippiandcarlos.com, and this is reflected in my resolv.conf file as "search pippiandcarlos.com". If I try to "ping ns", it will be converted to "ping ns.pippiandcarlos.com". I hate to be a party pooper, but I still feel that using resolvconf and static IPs is a bandaid that will continue to peel off when wet. The right thing to do is to get your own DNS and DHCP servers (the ones on the DSL router) working properly. Of course these DSL modems are notoriously crappy, and it is quite possible that fiddling with its configuration will have no effect. That's why I use cable and my own linux box as a router/firewall. Cable modems do not contain router/firewalls; they simply pass the connection through. The last DSL modem I had was an Actiontek which did not respond to any of my attempts to configure it. Qwest refused to replace it. They told me I could buy my own. Customer exits stage. Carlos ___ PLUG mailing list PLUG@lists.pdxlinux.org http://lists.pdxlinux.org/mailman/listinfo/plug
[PLUG] resolve.conf file
I mentioned earlier that I was having trouble with a new dsl modem's behavior as a dns server. That has been resolved by avoiding dhcp. This was accomplished with the help of a visiting geek (my son). Resolveconf was installed; dns addresses set statically, As best as I can determine, everything is working fine. But I seek some understanding. The resolv.conf contains some entries which make no sense to me. The visiting geek is no longer interested in these questions, as it is no longer broken. So I appeal to you. resolv.conf: # Dynamic resolv.conf(5) file for glibc resolver(3) generated by resolvconf(8) # DO NOT EDIT THIS FILE BY HAND -- YOUR CHANGES WILL BE OVERWRITTEN nameserver 192.168.0.1 nameserver 69.64.224.67 nameserver 69.64.224.66 search domain.actdsltmp I expect that the nameserver 192.168.0.1 entry is left over from earlier dhcp responses. (Visiting geek's Debian machine has only the two valid nameserver entries in his file--he had not run a dhcp client.) Why does it persist in this file? And why does it not break dns searches occasionally? If I run dig repeatedly, only the 69.64.224.67 address seems to get used. If I force use of 192.168.0.1, it fails, as expected. What does "search domain.actdsltmp" do? Is domain.actdsltmp a valid name? Should I attempt to clean up this file? If I should, how might that be done? Thanks for any education you can throw my way. -Denis ___ PLUG mailing list PLUG@lists.pdxlinux.org http://lists.pdxlinux.org/mailman/listinfo/plug
[PLUG] LTSP MK700...
I'm running ltsp 4.2 on CentOS 5.3. I am wondering if it supports the mouse that comes with the Logitech MK700 keyboard/mouse combo? So far, I haven't been able to get it working at all. I've tried modifying lts.conf, but I'm not sure what to put in it. This message was sent using IMP, the Internet Messaging Program. ___ PLUG mailing list PLUG@lists.pdxlinux.org http://lists.pdxlinux.org/mailman/listinfo/plug
