On 05/25/2013 08:00 PM, Phil Dobbin wrote:

Hi, all.

I've got several machines on a LAN behind a NAT with DHCP assigning always the same addresses from a dynamic IP.

A couple of days ago the IP changed & since then, one of the machines running Fedora 17 always fails first time to connect to the network: launch Thunderbird, no start screen, first attempt to check mail, it tells me that there's no network connection, second attempt it connects.

The scheduled DejaDup backup always fails with no network but will run manually no problem. Firefox can't find Google but the Nagios web interface is fine as is all the cli stuff (ping, ssh, etc).

Most annoyingly, yum update goes through every mirror before partially downloading part of the updates & if the updates are large, it takes about three attempts to get them all installed.

I'd like to clear this up naturally especially as in the next couple of weeks I'll be upgrading this box to Fedora 18 & the last thing I need is a dodgy network connection.

All the machines below are on the same LAN & they all work fine after the IP address change, it's only the Fedora box that's causing problems.

Any help appreciated. I'm stuck.

Cheers,

Phil...

Check your name server settings. Does /etc/resolv.conf have a name server that from the old IP address? Do you have one machine on the network that runs a catching name server and the rest of the Fedora machines are looking for it at the old address? Or are you running something like dnsmasq on the machines, and have the old IP address in the config file?

Mikkel

On 05/26/2013 11:54 AM, Mikkel L. Ellertson wrote:

On 05/25/2013 08:00 PM, Phil Dobbin wrote:

...

Hi, all.

I've got several machines on a LAN behind a NAT with DHCP assigning always the same addresses from a dynamic IP.

A couple of days ago the IP changed & since then, one of the machines running Fedora 17 always fails first time to connect to the network: launch Thunderbird, no start screen, first attempt to check mail, it tells me that there's no network connection, second attempt it connects.

The scheduled DejaDup backup always fails with no network but will run manually no problem. Firefox can't find Google but the Nagios web interface is fine as is all the cli stuff (ping, ssh, etc).

Most annoyingly, yum update goes through every mirror before partially downloading part of the updates & if the updates are large, it takes about three attempts to get them all installed.

I'd like to clear this up naturally especially as in the next couple of weeks I'll be upgrading this box to Fedora 18 & the last thing I need is a dodgy network connection.

All the machines below are on the same LAN & they all work fine after the IP address change, it's only the Fedora box that's causing problems.

Any help appreciated. I'm stuck.

Cheers,

Phil...

Check your name server settings. Does /etc/resolv.conf have a name server that from the old IP address? Do you have one machine on the network that runs a catching name server and the rest of the Fedora machines are looking for it at the old address? Or are you running something like dnsmasq on the machines, and have the old IP address in the config file?

I've never used any name server settings on any of these machines. The lease is automatically assigned by DHCP so therefore there is no need to.

The external link comes into a NAT router then onto a HP ProCurve switch & then via cat5 cables to each machine (there's no wireless involved anywhere). Then each machine in Network Settings uses the automatic setting to assign each address & DNS (192.168.1.254) & address mask (255.255.255.0).

As I've said, all other machines (all 16 of them) are fine. It's just the Fedora box which leads me to suspect that Fedora's doing, or not doing something, to cause this.

Cheers,

Phil...

On 05/26/2013 02:54 PM, Mikkel L. Ellertson wrote:

On 05/26/2013 07:18 AM, Phil Dobbin wrote:

...

On 05/26/2013 11:54 AM, Mikkel L. Ellertson wrote:

...

On 05/25/2013 08:00 PM, Phil Dobbin wrote:

...

Hi, all.

I've got several machines on a LAN behind a NAT with DHCP assigning always the same addresses from a dynamic IP.

A couple of days ago the IP changed & since then, one of the machines running Fedora 17 always fails first time to connect to the network: launch Thunderbird, no start screen, first attempt to check mail, it tells me that there's no network connection, second attempt it connects.

The scheduled DejaDup backup always fails with no network but will run manually no problem. Firefox can't find Google but the Nagios web interface is fine as is all the cli stuff (ping, ssh, etc).

Most annoyingly, yum update goes through every mirror before partially downloading part of the updates & if the updates are large, it takes about three attempts to get them all installed.

I'd like to clear this up naturally especially as in the next couple of weeks I'll be upgrading this box to Fedora 18 & the last thing I need is a dodgy network connection.

All the machines below are on the same LAN & they all work fine after the IP address change, it's only the Fedora box that's causing problems.

Any help appreciated. I'm stuck.

Cheers,

Phil...

Check your name server settings. Does /etc/resolv.conf have a name server that from the old IP address? Do you have one machine on the network that runs a catching name server and the rest of the Fedora machines are looking for it at the old address? Or are you running something like dnsmasq on the machines, and have the old IP address in the config file?

I've never used any name server settings on any of these machines. The lease is automatically assigned by DHCP so therefore there is no need to.

The external link comes into a NAT router then onto a HP ProCurve switch & then via cat5 cables to each machine (there's no wireless involved anywhere). Then each machine in Network Settings uses the automatic setting to assign each address & DNS (192.168.1.254) & address mask (255.255.255.0).

As I've said, all other machines (all 16 of them) are fine. It's just the Fedora box which leads me to suspect that Fedora's doing, or not doing something, to cause this.

Cheers,

Phil...

Dumb question - have you checked the network connection? See if changing the cable or the port on the switch helps. It seams strange that the external IP address changing would cause this, but for some strange reason hardware problems totally unrelated to the change seam to pick that time to happen.

I put a brand new cat 5 into another HP ProCurve that I have racked as a backup & still the same:

'Could not get metalink https://mirrors.fedoraproject.org/metalink?repo=updates-released-f17&arc... error was 14: curl#6 - "Could not resolve host: mirrors.fedoraproject.org; Name or service not known"'

Thunderbird still needs three manual attempts to connect too (as you can see, it does work eventually).

I've rebooted, looked in logs. I'm at a loss...

Cheers,

Phil...

On Sun, 2013-05-26 at 02:00 +0100, Phil Dobbin wrote:

I've got several machines on a LAN behind a NAT with DHCP assigning always the same addresses from a dynamic IP.

A couple of days ago the IP changed & since then, one of the machines running Fedora 17 always fails first time to connect to the network:

....

All the machines below are on the same LAN & they all work fine after the IP address change, it's only the Fedora box that's causing problems.

What was the cause for the IP change? Equipment reconfiguration or replacement? The fault may be there...

The first thing that springs to mind with some things working and others not, is perhaps MTU is different between the machines, with Fedora's not being a good choice for the network.

Phil Dobbin wrote:

I've got several machines on a LAN behind a NAT with DHCP assigning always the same addresses from a dynamic IP.

As a matter of interest, how do you configure DHCP to work with a dynamic IP?

I use ddclient with dyndns, but are you saying one doesn't need to do something like that?

On 05/27/2013 04:51 PM, Tim wrote:

Allegedly, on or about 27 May 2013, Timothy Murphy sent:

...

As a matter of interest, how do you configure DHCP to work with a dynamic IP?

Um, generally you don't... It does that by default. Your DHCP client (your usual personal computer) asks a DHCP server for an address, and the DHCP server tells it what to do. It's only people trying to bypass that automatic remote control, partially or totally, that go about trying to change the DHCP client configuration.

But are you talking about configuring a DHCP client or server?

Right. Computer asks server for address & it's done by automatic lease.

The state of the play at the moment is the network problem still occurs. I restored (via Clonezilla) from a known good backup that was taken before all this nonsense started & the box is still doing it.

So, to make sure it wasn't a hardware problem, I spun up a VM & installed Ubuntu 13.04. It has no such problems & apt-get functions normally.

When using yum update, curl is the culprit, throwing error after error:

'Could not get metalink https://mirrors.fedoraproject.org/metalink?repo=updates-released-f17&arc... error was 14: curl#6 - "Could not resolve host: mirrors.fedoraproject.org; Name or service not known"'

Anybody know anything about curl under these circumstances? Is it a certificate problem? Curl is installed via the repos so it's nothing out of the ordinary.

Any help appreciated,

Cheers,

Phil...

Tim:

...

But are you talking about configuring a DHCP client or server?

Timothy Murphy:

Sorry, I mis-read the query. I was thinking of a DHCP server

The same basic answer still stands: A DHCP server, by default, doles out dynamic IPs.

In other words, until an administrator customises the configuration, it doesn't absolutely associate a particular IP with a particular device. Leases are doled out from a pool of available addresses, and while there are un-used ones spare, it'll dole out these new un-used ones to new devices, re-issuing the same IPs to previous devices, if possible.

There's a time period involved, so that a leased IP is kept in reserve for that device for a while, then it's no-longer reserved, and may be doled out to anything that asks for an IP. There's no standard period, that's up to whoever configured the package, and administrators can customise the lease time periods to suit themselves.

Once the spare addresses run out, the DHCP server will start re-using IPs where the leases have expired, and that aren't currently in use (only a stupidly configured server will try to rip an IP off a currently active device and try to give it to someone else, but then some networks are run by idiots). A server could re-use expired-lease addresses before the spare un-used IPs have run out, but I haven't seen mine do that. It always worked through the pool of previously un-used IPs before re-using an older one. That way, even when the lease has expired, a machine is still likely to get the same IP as it had last time. My ISP doesn't work that way, if I disconnect for long enough (about over half a minute), I usually get a new random address. Which is handy if there was some sort of networking problem, I'm likely to bypass it on my next connection attempt.

In general, dynamic IPs are doled out sequentially, rather than purely randomly. Some servers may dole them out from highest available IP number down to lowest, others may go the other way. But there's a convention amongst administrators to set static IPs from lowest upwards, and dynamic IPs from highest downwards, that some DHCP programmers seem to go along with.

Static address assignment, where the same device always gets the same address, depends on the administrator configuring the DHCP server to work that way. It's usually done by associating a devices MAC with a particular IP, but there are other ways of doing it.

DHCP clients, probably by default, may ask the server to give them the same IP as they had last time, but the server doesn't have to comply with client requests. Likewise, it should be possible for a client to be manually configured to ask for a specific address, but it's still okay for the server to ignore that and tell the client what it's going to use.

On my LAN, I have a mix of static and dynamic addresses doled out by the DHCP server, and those addresses are put into the local DNS server (static ones put into the DNS server by me, dynamic ones managed by the DHCP server updating the DNS server). Certain machines which are always here get preset addresses, for the sake of my convenience, more than anything else. Any servers would get preset addresses, for the sake of less networking headaches, as wandering server addresses can upset everything else trying to access them, and make configuring their firewalls a lot more annoying. Clients, generally, don't do machine to machine networking, so changing their IP addresses rarely causes a problem. Only the DHCP server and the router have manual network configuration set on themselves with fixed addresses, such machines should never change addresses, and should be able to run stand-alone without having to be configured externally.

Centrally managing all the machine addresses on the DHCP server, whether that be the hands-off dynamic addressing of new computers, or preset addressing of regular computers, means that I never have have mess with hand configuring the network settings of any computer that I plug into the LAN, at all. I don't have to learn six different ways of configuring a client, because they have different OSs, or because of all the changes that different versions of each OS has inflicted upon us. I don't need to get admin passwords to computers to get them on the net. I don't have to set their IPs, netmasks, DNS servers, mess with host files, etc. I just plug them in and they work.

For what it's worth, I find it far better to centrally manage any network greater than about three machines. Above that, it becomes a right pain having to hand configure each machine, and deal with any changes that happen to your network. While you might think that you're not going to change IPs, it happens as soon as you have to replace something like a modem/router, or networked printer, that insists that it has to be 192.168.1.something rather than 192.168.0.something that your network was currently configured to use, because the damn fool device designers don't know enough about networking.

Probably everything you needed to know, and more, about DHCP...

NB: "By default" may refer to what the software does by default, as programmed by the author, and will do whenever there's no configuration file. Or, refer to what the installation of that software does on your computer, as configured by who put the package together, dependent on their prepared configuration files, and may be quite different from the program's defaults. Hence, why one has to be careful at presuming what the defaults may actually be, when reading the man files. When in doubt, do tests, or configure the software exactly how you want it.

On Wed, 2013-05-29 at 18:34 +0100, Timothy Murphy wrote:

Tim wrote:

...

Tim:

...

...

But are you talking about configuring a DHCP client or server?

Timothy Murphy:

...

Sorry, I mis-read the query. I was thinking of a DHCP server

The same basic answer still stands: A DHCP server, by default, doles out dynamic IPs.

I agree that dhcp by default gives an IP address in a given range on a LAN. But I don't think this is what is normally meant by "dynamic IP".

Actually it gives out addresses on any kind of network, not just a LAN. Your ISP probably uses DHCP to assign you an IP address. I know mine does. And DHCP stands for Dynamic Host Configuration Protocol, so in my book it's exactly what "dynamic IP" means.

poc

On 05/29/2013 01:14 PM, Timothy Murphy wrote:

You all seem to be finding it difficult to follow my meaning. I'm saying that the term "dynamic IP" is normally used to refer to an ISP giving the same client different IP addresses at different times, in order to to limit the number of address required. Whether or not that is done using dhcp is irrelevant to this point.

Yes. We all understand that. We also understand that DHCP is the most common way to implement dynamic IP.

Allegedly, on or about 29 May 2013, Timothy Murphy sent:

You all seem to be finding it difficult to follow my meaning. I'm saying that the term "dynamic IP" is normally used to refer to an ISP giving the same client different IP addresses at different times, in order to to limit the number of address required. Whether or not that is done using dhcp is irrelevant to this point.

Well, you did ask *about* "DHCP," at least twice. That wasn't the question you did ask earlier. And I was beginning to wonder whether you wanted to know how to configure one, or just how it worked.

You asked:

...

...

As a matter of interest, how do you configure DHCP to work with a dynamic IP?

I use ddclient with dyndns, but are you saying one doesn't need to do something like that?

Then asked about servers rather than clients. Going back to that first message, you did ask two wildly different things (DHCP and ddclient). Firstly, you don't need to configure DHCP to handle dynamic IPs, it already does that. The second question is unrelated to the first, if there's anything that might need to be configured to handle dynamic IPs, it would be ddclient. But I'm not familiar with it, it may already manage that without needing you to configure anything further, unless you'd already modified it with a fixed IP.

Dynamic IP merely means *not* static IP (and it's not just for ISPs, it's the same for LANs). In that there's no expectation that you'll get the same IP, one is not specifically assigned to you. You may get the same one, you may not, the server gets to choose. And my message explained how DHCP went about giving you one. While it's not the only way to assign dynamic addresses, it'd be the most common. And other protocols would use similar techniques. Other uses of the term, such as you described (where an ISP may try to share 1,000 IPs between 2,000 customers), are just how or why it may be used.

So, regardless of how you get assigned a dynamic address, if you're having to tell something like dyndyns about any changes to it, that's a separate issue.

If you felt like a lot of hard work, you could probably write something that was triggered by your DHCP client to talk to dyndns, if DHCP was responsible for your address changes. Less work would be to use NetworkManager's despatch scripts to update your dyndns data whenever NetworkManager detected a change in your network status. Or, especially if you don't use NetworkManager, you could use something (e.g. ddclient) that's already been designed to handle dynamic address changes, that may use some other technique to determine your external address and notice when it changes.

It's been years since I've done something like this, and I didn't use the dyndns service, nor do I recall whether it used ddclient or something else. But the latter was the technique that mine used (it looked at something outside of my LAN, figures out my external IP address, then updated the external "dynamic IP to a domain name" service, if it noticed that my IP had changed).

On 26.05.2013 17:35, Phil Dobbin wrote: …

'Could not get metalink https://mirrors.fedoraproject.org/metalink?repo=updates-released-f17&arc... error was 14: curl#6 - "Could not resolve host: mirrors.fedoraproject.org; Name or service not known"'

curl -4 "https://mirrors.fedoraproject.org/metalink?repo=updates-released-f17&arc..."

man 1 curl - resolving

/etc/yum.conf ip_resolve=4

man 5 yum.conf - ip_resolve

Thunderbird still needs three manual attempts to connect too (as you can see, it does work eventually).

network.dns.disableIPv6;true about:config - Preferences/Advanced/General/Config Editor

System wide: /boot/extlinux/extlinux.conf append … ipv6.disable=1

/boot/grub2/grub.cfg linux … ipv6.disable=1

poma

On 30.05.2013 04:55, Patrick O'Callaghan wrote: …

I used to use ddclient but actually I've found that the least effort solution is just to let my router do it. Many home routers now support DynDNS (and similar services) directly, so I just configure it once and forget about it. Make sure to set an admin password on the router of course (but you knew that already :-)

Besides inadyn, ddclient do work with a proper cmd directive.

poma

Am 29.05.2013 19:34, schrieb Timothy Murphy:

Tim wrote:

...

...

...

But are you talking about configuring a DHCP client or server?

Timothy Murphy:

...

Sorry, I mis-read the query. I was thinking of a DHCP server

The same basic answer still stands: A DHCP server, by default, doles out dynamic IPs.

I agree that dhcp by default gives an IP address in a given range on a LAN. But I don't think this is what is normally meant by "dynamic IP"

what has DHCP to do with LAN? http://en.wikipedia.org/wiki/Dynamic_Host_Configuration_Protocol

any dynamic address is assigend via DHCP what else should your ISP use?

On 26/05/13 02:00, Phil Dobbin wrote:

Hi, all.

I've got several machines on a LAN behind a NAT with DHCP assigning always the same addresses from a dynamic IP.

A couple of days ago the IP changed & since then, one of the machines running Fedora 17 always fails first time to connect to the network: launch Thunderbird, no start screen, first attempt to check mail, it tells me that there's no network connection, second attempt it connects.

The scheduled DejaDup backup always fails with no network but will run manually no problem. Firefox can't find Google but the Nagios web interface is fine as is all the cli stuff (ping, ssh, etc).

Most annoyingly, yum update goes through every mirror before partially downloading part of the updates & if the updates are large, it takes about three attempts to get them all installed.

I'd like to clear this up naturally especially as in the next couple of weeks I'll be upgrading this box to Fedora 18 & the last thing I need is a dodgy network connection.

All the machines below are on the same LAN & they all work fine after the IP address change, it's only the Fedora box that's causing problems.

As a coda to this I finally solved the problem by looking in '/etc/resolv.conf' & finding out that my router was the only nameserver. So I added Google's nameservers & all is well.

Thought this might help somebody out if they have the same problem.

Cheers,

Phil...