DHCP not working on new install
A new Kubuntu 12.04 install is not getting IP addresses from either the wired connection nor from any wireless connection. The cables / router ports / wifi adapter / access point are all known good and work with other equipment. I suspected a failed NIC but seeing how the wireless connections also aren't working via USB wifi adapter, that eliminates the NIC as a possible source of the issue. What other hardware might be shared between the wired (onboard NIC) and wireless (USB wifi adapter)? I stress that with the wifi adapter I see other networks, but cannot get an IP address from them either. Testing with a Kubuntu 11.10 LiveCD has the same results.
I notice that there is no /etc/dhcp/dhclient.conf file.
networking dhcp
asked Jun 30 '12 at 12:18
dotancohendotancohen
1,70242436
add a comment |
A new Kubuntu 12.04 install is not getting IP addresses from either the wired connection nor from any wireless connection. The cables / router ports / wifi adapter / access point are all known good and work with other equipment. I suspected a failed NIC but seeing how the wireless connections also aren't working via USB wifi adapter, that eliminates the NIC as a possible source of the issue. What other hardware might be shared between the wired (onboard NIC) and wireless (USB wifi adapter)? I stress that with the wifi adapter I see other networks, but cannot get an IP address from them either. Testing with a Kubuntu 11.10 LiveCD has the same results.
I notice that there is no /etc/dhcp/dhclient.conf file.
networking dhcp
asked Jun 30 '12 at 12:18
dotancohendotancohen
1,70242436
add a comment |
A new Kubuntu 12.04 install is not getting IP addresses from either the wired connection nor from any wireless connection. The cables / router ports / wifi adapter / access point are all known good and work with other equipment. I suspected a failed NIC but seeing how the wireless connections also aren't working via USB wifi adapter, that eliminates the NIC as a possible source of the issue. What other hardware might be shared between the wired (onboard NIC) and wireless (USB wifi adapter)? I stress that with the wifi adapter I see other networks, but cannot get an IP address from them either. Testing with a Kubuntu 11.10 LiveCD has the same results.
I notice that there is no /etc/dhcp/dhclient.conf file.
networking dhcp
asked Jun 30 '12 at 12:18
dotancohendotancohen
1,70242436
A new Kubuntu 12.04 install is not getting IP addresses from either the wired connection nor from any wireless connection. The cables / router ports / wifi adapter / access point are all known good and work with other equipment. I suspected a failed NIC but seeing how the wireless connections also aren't working via USB wifi adapter, that eliminates the NIC as a possible source of the issue. What other hardware might be shared between the wired (onboard NIC) and wireless (USB wifi adapter)? I stress that with the wifi adapter I see other networks, but cannot get an IP address from them either. Testing with a Kubuntu 11.10 LiveCD has the same results.
I notice that there is no /etc/dhcp/dhclient.conf file.
networking dhcp
networking dhcp
asked Jun 30 '12 at 12:18
dotancohendotancohen
1,70242436
asked Jun 30 '12 at 12:18
dotancohendotancohen
1,70242436
asked Jun 30 '12 at 12:18
dotancohendotancohen
1,70242436
asked Jun 30 '12 at 12:18
dotancohendotancohen
1,70242436
asked Jun 30 '12 at 12:18
dotancohendotancohen
1,70242436
1,70242436
add a comment |
add a comment |
3 Answers
3
active
oldest
votes
Try sudo apt-get install isc-dhcp-client, which will install the dhcp client, though it won't explain why it wasn't installed to begin with. This also presumes that your problem is a lack of said client.
If that doesn't work, you should look into using the tcpdump command on one of the interfaces and post back here with the results. For example, sudo tcpdump -i eth0 -n should show you if there is any traffic passing over the eth0 interface, though you may need to correct for the right interface.
Since tcpdump didn't see any traffic, start the tcpcommand again, unplug your LAN connection, wait a couple seconds for the computer to realize you've unplugged it, then plug it back in and look at the tcpdump output. There should be several DHCP request sent out by you're computer, and under ideal circumstances, responses to those queries as well. If you don't see anything at all, then perhaps DHCP is request an address on the wrong port, maybe check DHCP configuration. If after checking your DHCP configuration you're sure that DHCP is requesting an address on the correct port but that you're not seeing any traffic with tcpdump, check the logs for any errors related to DHCP or errors transmitting network traffic. If nothing is obvious, post the logs here.
Beyond that, I don't know what else to do to diagnose this, perhaps your suspicions of faulty hardware were correct, or more unlikely, driver trouble.
answered Jun 30 '12 at 16:03
Jeff WellingJeff Welling
7772512
Thanks. Theisc-dhcp-clientis installed, and tcpdump did not hear anything on the eth0 interface (yes, that is the correct interface). Where should I take it from here?
– dotancohen
Jun 30 '12 at 20:44
Expanded my answer a bit.
– Jeff Welling
Jun 30 '12 at 22:09
Thank you Jeff. After lettingtcpdumpsit overnight, [this is its output)[pastebin.com/WLxf6B5R]. I then unplugged the network cable, waited a minute, then startedtcpdumpagain before plugging the cable back in. There was no output for the 60 seconds that I waited. I tried again with the -vv option, again no output for the duration of the 60 seconds wait after plugging the cable back in. Note that the NIC LED was lit.
– dotancohen
Jul 1 '12 at 8:12
It appears from that output that you aren't getting any replies to any of the packets that you're sending out. Tres strange. At this point, I would scour the logs (any,all) to look for anything related to eth0 or failure to detect network card, or anything that looks like an error or warning at all. And for sanity's sake, double check with a different network cable, it could be a dead cable.
– Jeff Welling
Jul 1 '12 at 15:13
Please pastebin the output ofifconfigas well, this will tell us which IP addresses your NIC has been assigned (or gave itself), perhaps I was wrong about not receiving any responses.
– Jeff Welling
Jul 1 '12 at 15:15
|
show 1 more comment
The problem was in fact syndrome of issues:
1) No kernel support for this NIC in the -23 kernel. Downloading and installing the -26 kernel helped.
2) DHCP problems even with the NIC recognised. I had issues with DHCP on this hardware in openSuse 12.1 as well. Settings a static IP address got the machine online but no DNS.
3) To get DNS working, I renewed the DHCP lease even though I have a static IP address. This sounds stupid but it works. Simply configuring Google's public DNS servers did not resolve the issue.
To add insults to injury, this motherboard (ASUS P8H61-M LX) does not have PCI port to plug a NIC card into. ASUS support took two days to answer my letter of Linux support with "we don't support Linux" and the Realtek site's Linux NIC drivers wouldn't download from any of the six mirrors. They use JavaScript and HTTP access controls to prevent one from downloading the tarball over wget on a real server that I maintain, so I had a colleague download from the US and email the drivers to me. Then I couldn't build them as I could not install gcc from the Kubuntu DVD.
TL;DR: Don't buy an ASUS motherboard, they officially don't support Linux. And in any case, don't buy a motherboard without a PCI slot!
edited Apr 13 '17 at 12:23
Community♦
1
answered Jul 3 '12 at 10:07
dotancohendotancohen
1,70242436
add a comment |
CULPRIT: Copying of files "/etc/NetworkManager/" from the previous installation
Problem: My system had no access to the domain name servers (DNS), provided by my IP provider after a new install of Ubuntu 18.04. No Internet connection. Tests showed: Providing a fixed DNS (such as Google's 8.8.8.8) as described above gave internet connection. The connection to my router worked. The router had the DNS.
After hours I found out: The problem was that I had copied the folder and subfolders "/etc/NetworkManager" from my old installation into this new installation, because I did not want to lose all the installed Wifi connections. And THAT was the culprit.
Solution:
A. Creating a new instance of /etc/NetworkManager
- I renamed /etc/NetworkManager to /etc/NetworkManager-1/.
- I reinstalled my Wifi connection at home: Network name, DHCP, password.
- Result: a new instance of /etc/NetworkManager had been created. The network
settings were in a file in /etc/NetworkManager/system-connections. Now everything worked!
B. Saving my old Wifi connections
- I went into my old (renamed) NetworkManager files under /etc/NetworkManager-1/. In the folder /etc/NetworkManager/system-connections were all the connections (one file per connection) I had gathered during the time of the old installation. I copied these files onto the clipboard.
- I went into /etc/NetworkManager/system-connections, i.e. the same folder of the new NetworkManager. I acquired superuser privileges ("open as system administrator") and pasted the files from the clipboard into this directory.
- I made sure that these files had the owner "root" and the permissions "600", that is owner root can read and write, "group root" and "others" have no permissions whatsoever. In my case I had to change the permissions. I opened a terminal and did "sudo chmod 600 /etc/NetworkManager/system-connections/*.
answered Feb 15 at 17:49
XenonXenon
112
add a comment |
Your Answer
StackExchange.ready(function() {
var channelOptions = {
tags: "".split(" "),
id: "89"
};
initTagRenderer("".split(" "), "".split(" "), channelOptions);
StackExchange.using("externalEditor", function() {
// Have to fire editor after snippets, if snippets enabled
if (StackExchange.settings.snippets.snippetsEnabled) {
StackExchange.using("snippets", function() {
createEditor();
});
}
else {
createEditor();
}
});
function createEditor() {
StackExchange.prepareEditor({
heartbeatType: 'answer',
autoActivateHeartbeat: false,
convertImagesToLinks: true,
noModals: true,
showLowRepImageUploadWarning: true,
reputationToPostImages: 10,
bindNavPrevention: true,
postfix: "",
imageUploader: {
brandingHtml: "Powered by u003ca class="icon-imgur-white" href="https://imgur.com/"u003eu003c/au003e",
contentPolicyHtml: "User contributions licensed under u003ca href="https://creativecommons.org/licenses/by-sa/3.0/"u003ecc by-sa 3.0 with attribution requiredu003c/au003e u003ca href="https://stackoverflow.com/legal/content-policy"u003e(content policy)u003c/au003e",
allowUrls: true
},
onDemand: true,
discardSelector: ".discard-answer"
,immediatelyShowMarkdownHelp:true
});
}
});
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2faskubuntu.com%2fquestions%2f157969%2fdhcp-not-working-on-new-install%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
3 Answers
3
active
oldest
votes
3 Answers
3
active
oldest
votes
active
oldest
votes
active
oldest
votes
Try sudo apt-get install isc-dhcp-client, which will install the dhcp client, though it won't explain why it wasn't installed to begin with. This also presumes that your problem is a lack of said client.
If that doesn't work, you should look into using the tcpdump command on one of the interfaces and post back here with the results. For example, sudo tcpdump -i eth0 -n should show you if there is any traffic passing over the eth0 interface, though you may need to correct for the right interface.
Since tcpdump didn't see any traffic, start the tcpcommand again, unplug your LAN connection, wait a couple seconds for the computer to realize you've unplugged it, then plug it back in and look at the tcpdump output. There should be several DHCP request sent out by you're computer, and under ideal circumstances, responses to those queries as well. If you don't see anything at all, then perhaps DHCP is request an address on the wrong port, maybe check DHCP configuration. If after checking your DHCP configuration you're sure that DHCP is requesting an address on the correct port but that you're not seeing any traffic with tcpdump, check the logs for any errors related to DHCP or errors transmitting network traffic. If nothing is obvious, post the logs here.
Beyond that, I don't know what else to do to diagnose this, perhaps your suspicions of faulty hardware were correct, or more unlikely, driver trouble.
answered Jun 30 '12 at 16:03
Jeff WellingJeff Welling
7772512
Thanks. Theisc-dhcp-clientis installed, and tcpdump did not hear anything on the eth0 interface (yes, that is the correct interface). Where should I take it from here?
– dotancohen
Jun 30 '12 at 20:44
Expanded my answer a bit.
– Jeff Welling
Jun 30 '12 at 22:09
Thank you Jeff. After lettingtcpdumpsit overnight, [this is its output)[pastebin.com/WLxf6B5R]. I then unplugged the network cable, waited a minute, then startedtcpdumpagain before plugging the cable back in. There was no output for the 60 seconds that I waited. I tried again with the -vv option, again no output for the duration of the 60 seconds wait after plugging the cable back in. Note that the NIC LED was lit.
– dotancohen
Jul 1 '12 at 8:12
It appears from that output that you aren't getting any replies to any of the packets that you're sending out. Tres strange. At this point, I would scour the logs (any,all) to look for anything related to eth0 or failure to detect network card, or anything that looks like an error or warning at all. And for sanity's sake, double check with a different network cable, it could be a dead cable.
– Jeff Welling
Jul 1 '12 at 15:13
Please pastebin the output ofifconfigas well, this will tell us which IP addresses your NIC has been assigned (or gave itself), perhaps I was wrong about not receiving any responses.
– Jeff Welling
Jul 1 '12 at 15:15
|
show 1 more comment
Try sudo apt-get install isc-dhcp-client, which will install the dhcp client, though it won't explain why it wasn't installed to begin with. This also presumes that your problem is a lack of said client.
If that doesn't work, you should look into using the tcpdump command on one of the interfaces and post back here with the results. For example, sudo tcpdump -i eth0 -n should show you if there is any traffic passing over the eth0 interface, though you may need to correct for the right interface.
Since tcpdump didn't see any traffic, start the tcpcommand again, unplug your LAN connection, wait a couple seconds for the computer to realize you've unplugged it, then plug it back in and look at the tcpdump output. There should be several DHCP request sent out by you're computer, and under ideal circumstances, responses to those queries as well. If you don't see anything at all, then perhaps DHCP is request an address on the wrong port, maybe check DHCP configuration. If after checking your DHCP configuration you're sure that DHCP is requesting an address on the correct port but that you're not seeing any traffic with tcpdump, check the logs for any errors related to DHCP or errors transmitting network traffic. If nothing is obvious, post the logs here.
Beyond that, I don't know what else to do to diagnose this, perhaps your suspicions of faulty hardware were correct, or more unlikely, driver trouble.
answered Jun 30 '12 at 16:03
Jeff WellingJeff Welling
7772512
Thanks. Theisc-dhcp-clientis installed, and tcpdump did not hear anything on the eth0 interface (yes, that is the correct interface). Where should I take it from here?
– dotancohen
Jun 30 '12 at 20:44
Expanded my answer a bit.
– Jeff Welling
Jun 30 '12 at 22:09
Thank you Jeff. After lettingtcpdumpsit overnight, [this is its output)[pastebin.com/WLxf6B5R]. I then unplugged the network cable, waited a minute, then startedtcpdumpagain before plugging the cable back in. There was no output for the 60 seconds that I waited. I tried again with the -vv option, again no output for the duration of the 60 seconds wait after plugging the cable back in. Note that the NIC LED was lit.
– dotancohen
Jul 1 '12 at 8:12
It appears from that output that you aren't getting any replies to any of the packets that you're sending out. Tres strange. At this point, I would scour the logs (any,all) to look for anything related to eth0 or failure to detect network card, or anything that looks like an error or warning at all. And for sanity's sake, double check with a different network cable, it could be a dead cable.
– Jeff Welling
Jul 1 '12 at 15:13
Please pastebin the output ofifconfigas well, this will tell us which IP addresses your NIC has been assigned (or gave itself), perhaps I was wrong about not receiving any responses.
– Jeff Welling
Jul 1 '12 at 15:15
|
show 1 more comment
Try sudo apt-get install isc-dhcp-client, which will install the dhcp client, though it won't explain why it wasn't installed to begin with. This also presumes that your problem is a lack of said client.
If that doesn't work, you should look into using the tcpdump command on one of the interfaces and post back here with the results. For example, sudo tcpdump -i eth0 -n should show you if there is any traffic passing over the eth0 interface, though you may need to correct for the right interface.
Since tcpdump didn't see any traffic, start the tcpcommand again, unplug your LAN connection, wait a couple seconds for the computer to realize you've unplugged it, then plug it back in and look at the tcpdump output. There should be several DHCP request sent out by you're computer, and under ideal circumstances, responses to those queries as well. If you don't see anything at all, then perhaps DHCP is request an address on the wrong port, maybe check DHCP configuration. If after checking your DHCP configuration you're sure that DHCP is requesting an address on the correct port but that you're not seeing any traffic with tcpdump, check the logs for any errors related to DHCP or errors transmitting network traffic. If nothing is obvious, post the logs here.
Beyond that, I don't know what else to do to diagnose this, perhaps your suspicions of faulty hardware were correct, or more unlikely, driver trouble.
answered Jun 30 '12 at 16:03
Jeff WellingJeff Welling
7772512
Try sudo apt-get install isc-dhcp-client, which will install the dhcp client, though it won't explain why it wasn't installed to begin with. This also presumes that your problem is a lack of said client.
If that doesn't work, you should look into using the tcpdump command on one of the interfaces and post back here with the results. For example, sudo tcpdump -i eth0 -n should show you if there is any traffic passing over the eth0 interface, though you may need to correct for the right interface.
Since tcpdump didn't see any traffic, start the tcpcommand again, unplug your LAN connection, wait a couple seconds for the computer to realize you've unplugged it, then plug it back in and look at the tcpdump output. There should be several DHCP request sent out by you're computer, and under ideal circumstances, responses to those queries as well. If you don't see anything at all, then perhaps DHCP is request an address on the wrong port, maybe check DHCP configuration. If after checking your DHCP configuration you're sure that DHCP is requesting an address on the correct port but that you're not seeing any traffic with tcpdump, check the logs for any errors related to DHCP or errors transmitting network traffic. If nothing is obvious, post the logs here.
Beyond that, I don't know what else to do to diagnose this, perhaps your suspicions of faulty hardware were correct, or more unlikely, driver trouble.
answered Jun 30 '12 at 16:03
Jeff WellingJeff Welling
7772512
edited Jun 30 '12 at 22:09
answered Jun 30 '12 at 16:03
Jeff WellingJeff Welling
7772512
answered Jun 30 '12 at 16:03
Jeff WellingJeff Welling
7772512
answered Jun 30 '12 at 16:03
Jeff WellingJeff Welling
7772512
7772512
Thanks. Theisc-dhcp-clientis installed, and tcpdump did not hear anything on the eth0 interface (yes, that is the correct interface). Where should I take it from here?
– dotancohen
Jun 30 '12 at 20:44
Expanded my answer a bit.
– Jeff Welling
Jun 30 '12 at 22:09
Thank you Jeff. After lettingtcpdumpsit overnight, [this is its output)[pastebin.com/WLxf6B5R]. I then unplugged the network cable, waited a minute, then startedtcpdumpagain before plugging the cable back in. There was no output for the 60 seconds that I waited. I tried again with the -vv option, again no output for the duration of the 60 seconds wait after plugging the cable back in. Note that the NIC LED was lit.
– dotancohen
Jul 1 '12 at 8:12
It appears from that output that you aren't getting any replies to any of the packets that you're sending out. Tres strange. At this point, I would scour the logs (any,all) to look for anything related to eth0 or failure to detect network card, or anything that looks like an error or warning at all. And for sanity's sake, double check with a different network cable, it could be a dead cable.
– Jeff Welling
Jul 1 '12 at 15:13
Please pastebin the output ofifconfigas well, this will tell us which IP addresses your NIC has been assigned (or gave itself), perhaps I was wrong about not receiving any responses.
– Jeff Welling
Jul 1 '12 at 15:15
|
show 1 more comment
Thanks. Theisc-dhcp-clientis installed, and tcpdump did not hear anything on the eth0 interface (yes, that is the correct interface). Where should I take it from here?
– dotancohen
Jun 30 '12 at 20:44
Expanded my answer a bit.
– Jeff Welling
Jun 30 '12 at 22:09
Thank you Jeff. After lettingtcpdumpsit overnight, [this is its output)[pastebin.com/WLxf6B5R]. I then unplugged the network cable, waited a minute, then startedtcpdumpagain before plugging the cable back in. There was no output for the 60 seconds that I waited. I tried again with the -vv option, again no output for the duration of the 60 seconds wait after plugging the cable back in. Note that the NIC LED was lit.
– dotancohen
Jul 1 '12 at 8:12
It appears from that output that you aren't getting any replies to any of the packets that you're sending out. Tres strange. At this point, I would scour the logs (any,all) to look for anything related to eth0 or failure to detect network card, or anything that looks like an error or warning at all. And for sanity's sake, double check with a different network cable, it could be a dead cable.
– Jeff Welling
Jul 1 '12 at 15:13
Please pastebin the output ofifconfigas well, this will tell us which IP addresses your NIC has been assigned (or gave itself), perhaps I was wrong about not receiving any responses.
– Jeff Welling
Jul 1 '12 at 15:15
Thanks. The
isc-dhcp-client is installed, and tcpdump did not hear anything on the eth0 interface (yes, that is the correct interface). Where should I take it from here?– dotancohen
Jun 30 '12 at 20:44
Thanks. The
isc-dhcp-client is installed, and tcpdump did not hear anything on the eth0 interface (yes, that is the correct interface). Where should I take it from here?– dotancohen
Jun 30 '12 at 20:44
Expanded my answer a bit.
– Jeff Welling
Jun 30 '12 at 22:09
Expanded my answer a bit.
– Jeff Welling
Jun 30 '12 at 22:09
Thank you Jeff. After letting
tcpdump sit overnight, [this is its output)[pastebin.com/WLxf6B5R]. I then unplugged the network cable, waited a minute, then started tcpdump again before plugging the cable back in. There was no output for the 60 seconds that I waited. I tried again with the -vv option, again no output for the duration of the 60 seconds wait after plugging the cable back in. Note that the NIC LED was lit.– dotancohen
Jul 1 '12 at 8:12
Thank you Jeff. After letting
tcpdump sit overnight, [this is its output)[pastebin.com/WLxf6B5R]. I then unplugged the network cable, waited a minute, then started tcpdump again before plugging the cable back in. There was no output for the 60 seconds that I waited. I tried again with the -vv option, again no output for the duration of the 60 seconds wait after plugging the cable back in. Note that the NIC LED was lit.– dotancohen
Jul 1 '12 at 8:12
It appears from that output that you aren't getting any replies to any of the packets that you're sending out. Tres strange. At this point, I would scour the logs (any,all) to look for anything related to eth0 or failure to detect network card, or anything that looks like an error or warning at all. And for sanity's sake, double check with a different network cable, it could be a dead cable.
– Jeff Welling
Jul 1 '12 at 15:13
It appears from that output that you aren't getting any replies to any of the packets that you're sending out. Tres strange. At this point, I would scour the logs (any,all) to look for anything related to eth0 or failure to detect network card, or anything that looks like an error or warning at all. And for sanity's sake, double check with a different network cable, it could be a dead cable.
– Jeff Welling
Jul 1 '12 at 15:13
Please pastebin the output of
ifconfig as well, this will tell us which IP addresses your NIC has been assigned (or gave itself), perhaps I was wrong about not receiving any responses.– Jeff Welling
Jul 1 '12 at 15:15
Please pastebin the output of
ifconfig as well, this will tell us which IP addresses your NIC has been assigned (or gave itself), perhaps I was wrong about not receiving any responses.– Jeff Welling
Jul 1 '12 at 15:15
|
show 1 more comment
The problem was in fact syndrome of issues:
1) No kernel support for this NIC in the -23 kernel. Downloading and installing the -26 kernel helped.
2) DHCP problems even with the NIC recognised. I had issues with DHCP on this hardware in openSuse 12.1 as well. Settings a static IP address got the machine online but no DNS.
3) To get DNS working, I renewed the DHCP lease even though I have a static IP address. This sounds stupid but it works. Simply configuring Google's public DNS servers did not resolve the issue.
To add insults to injury, this motherboard (ASUS P8H61-M LX) does not have PCI port to plug a NIC card into. ASUS support took two days to answer my letter of Linux support with "we don't support Linux" and the Realtek site's Linux NIC drivers wouldn't download from any of the six mirrors. They use JavaScript and HTTP access controls to prevent one from downloading the tarball over wget on a real server that I maintain, so I had a colleague download from the US and email the drivers to me. Then I couldn't build them as I could not install gcc from the Kubuntu DVD.
TL;DR: Don't buy an ASUS motherboard, they officially don't support Linux. And in any case, don't buy a motherboard without a PCI slot!
edited Apr 13 '17 at 12:23
Community♦
1
answered Jul 3 '12 at 10:07
dotancohendotancohen
1,70242436
add a comment |
The problem was in fact syndrome of issues:
1) No kernel support for this NIC in the -23 kernel. Downloading and installing the -26 kernel helped.
2) DHCP problems even with the NIC recognised. I had issues with DHCP on this hardware in openSuse 12.1 as well. Settings a static IP address got the machine online but no DNS.
3) To get DNS working, I renewed the DHCP lease even though I have a static IP address. This sounds stupid but it works. Simply configuring Google's public DNS servers did not resolve the issue.
To add insults to injury, this motherboard (ASUS P8H61-M LX) does not have PCI port to plug a NIC card into. ASUS support took two days to answer my letter of Linux support with "we don't support Linux" and the Realtek site's Linux NIC drivers wouldn't download from any of the six mirrors. They use JavaScript and HTTP access controls to prevent one from downloading the tarball over wget on a real server that I maintain, so I had a colleague download from the US and email the drivers to me. Then I couldn't build them as I could not install gcc from the Kubuntu DVD.
TL;DR: Don't buy an ASUS motherboard, they officially don't support Linux. And in any case, don't buy a motherboard without a PCI slot!
edited Apr 13 '17 at 12:23
Community♦
1
answered Jul 3 '12 at 10:07
dotancohendotancohen
1,70242436
add a comment |
The problem was in fact syndrome of issues:
1) No kernel support for this NIC in the -23 kernel. Downloading and installing the -26 kernel helped.
2) DHCP problems even with the NIC recognised. I had issues with DHCP on this hardware in openSuse 12.1 as well. Settings a static IP address got the machine online but no DNS.
3) To get DNS working, I renewed the DHCP lease even though I have a static IP address. This sounds stupid but it works. Simply configuring Google's public DNS servers did not resolve the issue.
To add insults to injury, this motherboard (ASUS P8H61-M LX) does not have PCI port to plug a NIC card into. ASUS support took two days to answer my letter of Linux support with "we don't support Linux" and the Realtek site's Linux NIC drivers wouldn't download from any of the six mirrors. They use JavaScript and HTTP access controls to prevent one from downloading the tarball over wget on a real server that I maintain, so I had a colleague download from the US and email the drivers to me. Then I couldn't build them as I could not install gcc from the Kubuntu DVD.
TL;DR: Don't buy an ASUS motherboard, they officially don't support Linux. And in any case, don't buy a motherboard without a PCI slot!
edited Apr 13 '17 at 12:23
Community♦
1
answered Jul 3 '12 at 10:07
dotancohendotancohen
1,70242436
The problem was in fact syndrome of issues:
1) No kernel support for this NIC in the -23 kernel. Downloading and installing the -26 kernel helped.
2) DHCP problems even with the NIC recognised. I had issues with DHCP on this hardware in openSuse 12.1 as well. Settings a static IP address got the machine online but no DNS.
3) To get DNS working, I renewed the DHCP lease even though I have a static IP address. This sounds stupid but it works. Simply configuring Google's public DNS servers did not resolve the issue.
To add insults to injury, this motherboard (ASUS P8H61-M LX) does not have PCI port to plug a NIC card into. ASUS support took two days to answer my letter of Linux support with "we don't support Linux" and the Realtek site's Linux NIC drivers wouldn't download from any of the six mirrors. They use JavaScript and HTTP access controls to prevent one from downloading the tarball over wget on a real server that I maintain, so I had a colleague download from the US and email the drivers to me. Then I couldn't build them as I could not install gcc from the Kubuntu DVD.
TL;DR: Don't buy an ASUS motherboard, they officially don't support Linux. And in any case, don't buy a motherboard without a PCI slot!
edited Apr 13 '17 at 12:23
Community♦
1
answered Jul 3 '12 at 10:07
dotancohendotancohen
1,70242436
edited Apr 13 '17 at 12:23
Community♦
1
edited Apr 13 '17 at 12:23
Community♦
1
edited Apr 13 '17 at 12:23
Community♦
1
1
answered Jul 3 '12 at 10:07
dotancohendotancohen
1,70242436
answered Jul 3 '12 at 10:07
dotancohendotancohen
1,70242436
answered Jul 3 '12 at 10:07
dotancohendotancohen
1,70242436
1,70242436
add a comment |
add a comment |
CULPRIT: Copying of files "/etc/NetworkManager/" from the previous installation
Problem: My system had no access to the domain name servers (DNS), provided by my IP provider after a new install of Ubuntu 18.04. No Internet connection. Tests showed: Providing a fixed DNS (such as Google's 8.8.8.8) as described above gave internet connection. The connection to my router worked. The router had the DNS.
After hours I found out: The problem was that I had copied the folder and subfolders "/etc/NetworkManager" from my old installation into this new installation, because I did not want to lose all the installed Wifi connections. And THAT was the culprit.
Solution:
A. Creating a new instance of /etc/NetworkManager
- I renamed /etc/NetworkManager to /etc/NetworkManager-1/.
- I reinstalled my Wifi connection at home: Network name, DHCP, password.
- Result: a new instance of /etc/NetworkManager had been created. The network
settings were in a file in /etc/NetworkManager/system-connections. Now everything worked!
B. Saving my old Wifi connections
- I went into my old (renamed) NetworkManager files under /etc/NetworkManager-1/. In the folder /etc/NetworkManager/system-connections were all the connections (one file per connection) I had gathered during the time of the old installation. I copied these files onto the clipboard.
- I went into /etc/NetworkManager/system-connections, i.e. the same folder of the new NetworkManager. I acquired superuser privileges ("open as system administrator") and pasted the files from the clipboard into this directory.
- I made sure that these files had the owner "root" and the permissions "600", that is owner root can read and write, "group root" and "others" have no permissions whatsoever. In my case I had to change the permissions. I opened a terminal and did "sudo chmod 600 /etc/NetworkManager/system-connections/*.
answered Feb 15 at 17:49
XenonXenon
112
add a comment |
CULPRIT: Copying of files "/etc/NetworkManager/" from the previous installation
Problem: My system had no access to the domain name servers (DNS), provided by my IP provider after a new install of Ubuntu 18.04. No Internet connection. Tests showed: Providing a fixed DNS (such as Google's 8.8.8.8) as described above gave internet connection. The connection to my router worked. The router had the DNS.
After hours I found out: The problem was that I had copied the folder and subfolders "/etc/NetworkManager" from my old installation into this new installation, because I did not want to lose all the installed Wifi connections. And THAT was the culprit.
Solution:
A. Creating a new instance of /etc/NetworkManager
- I renamed /etc/NetworkManager to /etc/NetworkManager-1/.
- I reinstalled my Wifi connection at home: Network name, DHCP, password.
- Result: a new instance of /etc/NetworkManager had been created. The network
settings were in a file in /etc/NetworkManager/system-connections. Now everything worked!
B. Saving my old Wifi connections
- I went into my old (renamed) NetworkManager files under /etc/NetworkManager-1/. In the folder /etc/NetworkManager/system-connections were all the connections (one file per connection) I had gathered during the time of the old installation. I copied these files onto the clipboard.
- I went into /etc/NetworkManager/system-connections, i.e. the same folder of the new NetworkManager. I acquired superuser privileges ("open as system administrator") and pasted the files from the clipboard into this directory.
- I made sure that these files had the owner "root" and the permissions "600", that is owner root can read and write, "group root" and "others" have no permissions whatsoever. In my case I had to change the permissions. I opened a terminal and did "sudo chmod 600 /etc/NetworkManager/system-connections/*.
answered Feb 15 at 17:49
XenonXenon
112
add a comment |
CULPRIT: Copying of files "/etc/NetworkManager/" from the previous installation
Problem: My system had no access to the domain name servers (DNS), provided by my IP provider after a new install of Ubuntu 18.04. No Internet connection. Tests showed: Providing a fixed DNS (such as Google's 8.8.8.8) as described above gave internet connection. The connection to my router worked. The router had the DNS.
After hours I found out: The problem was that I had copied the folder and subfolders "/etc/NetworkManager" from my old installation into this new installation, because I did not want to lose all the installed Wifi connections. And THAT was the culprit.
Solution:
A. Creating a new instance of /etc/NetworkManager
- I renamed /etc/NetworkManager to /etc/NetworkManager-1/.
- I reinstalled my Wifi connection at home: Network name, DHCP, password.
- Result: a new instance of /etc/NetworkManager had been created. The network
settings were in a file in /etc/NetworkManager/system-connections. Now everything worked!
B. Saving my old Wifi connections
- I went into my old (renamed) NetworkManager files under /etc/NetworkManager-1/. In the folder /etc/NetworkManager/system-connections were all the connections (one file per connection) I had gathered during the time of the old installation. I copied these files onto the clipboard.
- I went into /etc/NetworkManager/system-connections, i.e. the same folder of the new NetworkManager. I acquired superuser privileges ("open as system administrator") and pasted the files from the clipboard into this directory.
- I made sure that these files had the owner "root" and the permissions "600", that is owner root can read and write, "group root" and "others" have no permissions whatsoever. In my case I had to change the permissions. I opened a terminal and did "sudo chmod 600 /etc/NetworkManager/system-connections/*.
answered Feb 15 at 17:49
XenonXenon
112
CULPRIT: Copying of files "/etc/NetworkManager/" from the previous installation
Problem: My system had no access to the domain name servers (DNS), provided by my IP provider after a new install of Ubuntu 18.04. No Internet connection. Tests showed: Providing a fixed DNS (such as Google's 8.8.8.8) as described above gave internet connection. The connection to my router worked. The router had the DNS.
After hours I found out: The problem was that I had copied the folder and subfolders "/etc/NetworkManager" from my old installation into this new installation, because I did not want to lose all the installed Wifi connections. And THAT was the culprit.
Solution:
A. Creating a new instance of /etc/NetworkManager
- I renamed /etc/NetworkManager to /etc/NetworkManager-1/.
- I reinstalled my Wifi connection at home: Network name, DHCP, password.
- Result: a new instance of /etc/NetworkManager had been created. The network
settings were in a file in /etc/NetworkManager/system-connections. Now everything worked!
B. Saving my old Wifi connections
- I went into my old (renamed) NetworkManager files under /etc/NetworkManager-1/. In the folder /etc/NetworkManager/system-connections were all the connections (one file per connection) I had gathered during the time of the old installation. I copied these files onto the clipboard.
- I went into /etc/NetworkManager/system-connections, i.e. the same folder of the new NetworkManager. I acquired superuser privileges ("open as system administrator") and pasted the files from the clipboard into this directory.
- I made sure that these files had the owner "root" and the permissions "600", that is owner root can read and write, "group root" and "others" have no permissions whatsoever. In my case I had to change the permissions. I opened a terminal and did "sudo chmod 600 /etc/NetworkManager/system-connections/*.
answered Feb 15 at 17:49
XenonXenon
112
edited Feb 15 at 18:03
answered Feb 15 at 17:49
XenonXenon
112
answered Feb 15 at 17:49
XenonXenon
112
answered Feb 15 at 17:49
XenonXenon
112
112
add a comment |
add a comment |
Thanks for contributing an answer to Ask Ubuntu!
- Please be sure to answer the question. Provide details and share your research!
But avoid …
- Asking for help, clarification, or responding to other answers.
- Making statements based on opinion; back them up with references or personal experience.
To learn more, see our tips on writing great answers.
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
StackExchange.ready(
function () {
StackExchange.openid.initPostLogin('.new-post-login', 'https%3a%2f%2faskubuntu.com%2fquestions%2f157969%2fdhcp-not-working-on-new-install%23new-answer', 'question_page');
}
);
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Sign up or log in
StackExchange.ready(function () {
StackExchange.helpers.onClickDraftSave('#login-link');
});
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Sign up using Google
Sign up using Facebook
Sign up using Email and Password
Post as a guest
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
Required, but never shown
