Gentoo Forums
Gentoo Forums
Gentoo Forums
Quick Search: in
network swap adsl to fibre
View unanswered posts
View posts from last 24 hours

 
Reply to topic    Gentoo Forums Forum Index Networking & Security
View previous topic :: View next topic  
Author Message
gcyoung
Tux's lil' helper
Tux's lil' helper


Joined: 04 Jul 2007
Posts: 144
Location: England

PostPosted: Fri Mar 06, 2020 3:13 pm    Post subject: network swap adsl to fibre Reply with quote

I was/and am using systemd-networkd.service set up for static IP address. Network failed to connect to Internet on changing to fibre service from copper adsl.Nothing wrong with incoming service since I can connect using system-rescue and memory running xubuntu disks.I have changed the nameserver address to that given by these disks, since I previously used that giver by my previous network service.

Obviously a kernel change or software addition is required. But I know not what. Any informed advice on changes to be made would be appreciated. Regretfully the installers had no knowledge or help to give and I have not found any literature on the subject.
Back to top
View user's profile Send private message
Hu
Moderator
Moderator


Joined: 06 Mar 2007
Posts: 15334

PostPosted: Sat Mar 07, 2020 1:49 am    Post subject: Reply with quote

Please start by posting the output of ip a ; ip r from both the rescue media and the main system. Also, please describe the problem in more detail than "Network failed to connect to Internet." What symptoms do you see? Can you connect to resources by IP address? Are you sure a static IP address is appropriate in the new setup? For distributed deployments, which most residential setups would be, a dynamic configuration such as DHCP is more likely.
Back to top
View user's profile Send private message
gcyoung
Tux's lil' helper
Tux's lil' helper


Joined: 04 Jul 2007
Posts: 144
Location: England

PostPosted: Sat Mar 07, 2020 6:11 pm    Post subject: ADSL to Cable Reply with quote

To Expand: --
:
I am running 4 machines which are all inter-connected via NFS and SSH. They are:
A: An old 386 laptop which uses mainly wireless.
B: A raspberry pi running raspian which I use as a Media frontend.
C: A 'Server' on which I store all my data.
D: My main computer from which I usually manage the others via SSH
All exept A run use ethernet and were were connecting with each other and the internet prior to the change to cable:

After the changeover all were able to interface with each other but only computer A was able to
communicate with the internet via wireless. I haavn't checked whether it will connect via ethernet.

I reinstalled raspian to the pi and changed the nameserver address and that is now able to access
the internet.

I recompiled the kernel to Computer D, and that now functions as it should.

The problem remains with Compuer C. I have tried recompiling the kernel, copying the same network options
as on Computer D, but to no avail. I am reluctant to undertake a total recompile, since the kernel Is one
I have built up to my satisfaction over a long period of time (I certainly can't remember the significance
of many of the options!)
####
The following is the output from 'lp' on Computer D, The network funcioning machine:--

lp a
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: sit0@NONE: <NOARP> mtu 1480 qdisc noop state DOWN group default qlen 1000
link/sit 0.0.0.0 brd 0.0.0.0
3: enp5s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether 88:d7:f6:c9:26:e9 brd ff:ff:ff:ff:ff:ff
inet 192.168.0.5/24 brd 192.168.0.255 scope global enp5s0
valid_lft forever preferred_lft forever
inet 192.168.0.110/24 brd 192.168.0.255 scope global secondary enp5s0
valid_lft forever preferred_lft forever
inet6 fe80::8ad7:f6ff:fec9:26e9/64 scope link
valid_lft forever preferred_lft forever

lp r
lp: Error - unable to access "r" - No such file or directory


On Compuer C the following is the output: ie: Nothing to say.

lp: Error: -unable to access "a" -no such File or directory

lp: Error: -unable to access "b" -no such File or directory

As for static addresses, I prefer the lack of complexity and stabiliy they normally give. Using systemd-networkd
avoids having to get involved with network manager, which I see no need for, but i will certainly give it a try if
I dont get anywhere with the current setup.

It's difficule to give any sympton but they are similar to the lack of a nameserver. ie "Cant connect to server at"
and "Temporary failure in name resolution"
Back to top
View user's profile Send private message
Hu
Moderator
Moderator


Joined: 06 Mar 2007
Posts: 15334

PostPosted: Sat Mar 07, 2020 10:31 pm    Post subject: Re: ADSL to Cable Reply with quote

gcyoung wrote:
I reinstalled raspian to the pi and changed the nameserver address and that is now able to access the internet.
That is promising. Are all the other systems already using that same nameserver?
gcyoung wrote:
The following is the output from 'lp' on Computer D, The network funcioning machine:--
I asked for ip, not lp. You provided ip a once (but called it lp a), and used lp everywhere else, which simply failed.

Also, please use code tags for program output.
gcyoung wrote:
3: enp5s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether 88:d7:f6:c9:26:e9 brd ff:ff:ff:ff:ff:ff
inet 192.168.0.5/24 brd 192.168.0.255 scope global enp5s0
valid_lft forever preferred_lft forever
inet 192.168.0.110/24 brd 192.168.0.255 scope global secondary enp5s0
valid_lft forever preferred_lft forever
inet6 fe80::8ad7:f6ff:fec9:26e9/64 scope link
valid_lft forever preferred_lft forever
Multiple addresses is a bit odd, but this otherwise looks reasonable.
gcyoung wrote:
As for static addresses, I prefer the lack of complexity and stabiliy they normally give.
Except when they don't work? :) I'm not particularly concerned about you using static addressing on the LAN, though I prefer DHCP for the centralized management capability. If you want to change nameservers on a statically configured LAN, you change it on every system. If you want to change nameservers on a DHCP managed LAN, you change the instructions given by the DHCP daemon, renew addresses (or wait for them to renew on their own) and you are done.
gcyoung wrote:
Using systemd-networkd avoids having to get involved with network manager, which I see no need for, but i will certainly give it a try if I dont get anywhere with the current setup.
Why use NetworkManager at all? It is vastly overcomplicated for systems that never travel. I use net-misc/dhcpcd for client systems and net-misc/dhcp for the server, and it has served me well for years. I can't recall ever having a problem that I traced to a bug in either program.
gcyoung wrote:
It's difficule to give any sympton but they are similar to the lack of a nameserver. ie "Cant connect to server at" and "Temporary failure in name resolution"
Do you get a failure even when you try to connect to a system by IP address?
Back to top
View user's profile Send private message
gcyoung
Tux's lil' helper
Tux's lil' helper


Joined: 04 Jul 2007
Posts: 144
Location: England

PostPosted: Sat Mar 07, 2020 11:56 pm    Post subject: Reply with quote

Sorry about the i V l. The forum print out on my scrreen was so small that I couldn't can't easily see the difference. I was puzzled by 'lp'.I have adjusted it now.

the corrected info is as set out below. The reference to wireless occurs now because I have just inserted a wireless card. That was not previously
there and I have not yet set it up other than include the module in the kernel

Computer D
ip r
Quote:
default via 192.168.0.1 dev enp5s0 proto static
192.168.0.0/24 dev enp5s0 proto kernel scope link src 192.168.0.5

####
Computer C
ip a
Quote:
lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default qlen 1000
link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
inet 127.0.0.1/8 scope host lo
valid_lft forever preferred_lft forever
inet6 ::1/128 scope host
valid_lft forever preferred_lft forever
2: ip6_vti0@NONE: <NOARP> mtu 1364 qdisc noop state DOWN group default qlen 1000
link/tunnel6 :: brd ::
3: sit0@NONE: <NOARP> mtu 1480 qdisc noop state DOWN group default qlen 1000
link/sit 0.0.0.0 brd 0.0.0.0
4: ip6tnl0@NONE: <NOARP> mtu 1452 qdisc noop state DOWN group default qlen 1000
link/tunnel6 :: brd ::
5: enp3s0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
link/ether 54:04:a6:99:d1:1b brd ff:ff:ff:ff:ff:ff
inet 192.168.0.3/24 brd 192.168.0.255 scope global enp3s0
valid_lft forever preferred_lft forever
inet6 fe80::5604:a6ff:fe99:d11b/64 scope link
valid_lft forever preferred_lft forever
6: wlp1s5: <BROADCAST,MULTICAST> mtu 1500 qdisc noop state DOWN group default qlen 1000
link/ether 64:66:b3:be:fe:d1 brd ff:ff:ff:ff:ff:ff


ip r
Quote:
default via 192.168.0.1 dev enp3s0 proto static


All computers have the same nameserver. ping, nfs commands, and ssh commands all work with both <hostname>
and IP's on and between my computers, it's just that they can't/couldn't access the 'world' outside. It is that that has made
me suspect an extra option/module is needed to cope with the fibre cable.I read somewhere that the mac no. can
be affected by whether fibre or copper cable is used and setting "mac_eth0=random-anykind" to cope with copper and cable should cope with that.
It diidn't say where this should be set up, so I put it in to the grub entries.It doesn't seem to have helpe, but I don't think it has caused any harm.
Piinging external hostnames and IP numbers cause the computer to hang up. Crashing out with ^C give an error message "Temporary failure in name resolution"
With Ip numbers a typical response is "48 packets transmitted,0 received, 100% package loss,time 168ms"

I should perhaps also poiint out that I have not made any ipv6 settings

Also --I am not familliar with BBCode and will try to rectify that later, although I was not aware that a compouter's output qualifies as 'code'
NB. Latest edit incorporates BBCode quotes


Last edited by gcyoung on Sun Mar 08, 2020 1:52 pm; edited 4 times in total
Back to top
View user's profile Send private message
freke
Guru
Guru


Joined: 23 Jan 2003
Posts: 588
Location: Somewhere in Denmark

PostPosted: Sun Mar 08, 2020 8:53 am    Post subject: Reply with quote

Can you ping ip-adresses from the trouble some computer?
(ie. ping 8.8.8.8 ) - just to verify if it's 'just' name-resolution that fails.
Back to top
View user's profile Send private message
gcyoung
Tux's lil' helper
Tux's lil' helper


Joined: 04 Jul 2007
Posts: 144
Location: England

PostPosted: Sun Mar 08, 2020 9:22 am    Post subject: Reply with quote

To Freke
Yes. See my previous Post. But only my own 192.168.0.x addresses. Which made me susspect a faulty nameserver.
Back to top
View user's profile Send private message
gcyoung
Tux's lil' helper
Tux's lil' helper


Joined: 04 Jul 2007
Posts: 144
Location: England

PostPosted: Sun Mar 08, 2020 1:41 pm    Post subject: Reply with quote

Edits above are mainly text editing. I have enlarged my browsers fonts!
The following is some output from journalctl -xb. I don't understand it's significance, but thought it might have some to my problem.
Quote:
Mar 08 12:54:55 mythbox systemd-udevd[2119]: ethtool: autonegotiation is unset or enabled, the speed and duplex are not writable.
Mar 08 12:54:55 mythbox systemd-udevd[2119]: Using default interface naming scheme 'v243'.
Mar 08 12:54:55 mythbox systemd-udevd[2119]: Could not set Alias=, MACAddress= or MTU= on ip6_vti0: Invalid argument
Mar 08 12:54:55 mythbox systemd-udevd[2119]: ip6_vti0: Could not apply link config, ignoring: Invalid argument
Mar 08 12:54:55 mythbox systemd-udevd[2116]: ethtool: autonegotiation is unset or enabled, the speed and duplex are not writable.
Mar 08 12:54:55 mythbox systemd-udevd[2117]: ethtool: autonegotiation is unset or enabled, the speed and duplex are not writable.
Mar 08 12:54:55 mythbox systemd-udevd[2122]: ethtool: autonegotiation is unset or enabled, the speed and duplex are not writable.
Mar 08 12:54:55 mythbox systemd-udevd[2122]: Using default interface naming scheme 'v243'.
Mar 08 12:54:55 mythbox systemd-udevd[2122]: Could not set Alias=, MACAddress= or MTU= on ip6tnl0: Invalid argument
Mar 08 12:54:55 mythbox systemd-udevd[2122]: ip6tnl0: Could not apply link config, ignoring: Invalid argument
Mar 08 12:54:55 mythbox systemd-udevd[2115]: Using default interface naming scheme 'v243'.
Mar 08 12:54:55 mythbox systemd-udevd[2105]: Using default interface naming scheme 'v243'.
Mar 08 12:54:55 mythbox systemd-udevd[2115]: ethtool: autonegotiation is unset or enabled, the speed and duplex are not writable.
Mar 08 12:54:55 mythbox systemd-udevd[2105]: ethtool: autonegotiation is unset or enabled, the speed and duplex are not writable.
Mar 08 12:54:55 mythbox systemd-udevd[2114]: Using default interface naming scheme 'v243'.
Mar 08 12:54:55 mythbox systemd-networkd[2110]: Enumeration completed
Back to top
View user's profile Send private message
Hu
Moderator
Moderator


Joined: 06 Mar 2007
Posts: 15334

PostPosted: Sun Mar 08, 2020 4:56 pm    Post subject: Reply with quote

As I said above, please use code tags for program output. Code preserves whitespace-driven indenting, and provides a monospace font. Quote doesn't. (I often edit these into posts for new users, but at some point people need to develop the habit of formatting their posts themselves.)

Your symptoms are consistent with the affected systems being unable to get a packet to travel round trip to a non-local system. Pinging by local IP works, because you don't cross the router. Pinging by foreign IP fails because the packet does not complete a round trip. (We don't know whether it doesn't get to the peer, whether the peer fails to respond, or whether the peer responds and the response is lost in transit.) A nameserver has no impact on your ability to ping by IP address. It is relevant only if the nameserver is the system you are attempting to ping and the nameserver is refusing to process traffic. If you can ping that nameserver successfully from any system, then the nameserver is not (likely) to be at fault here.

Do you have IPv4 forwarding enabled on the router? Are its iptables rules set up to properly masquerade outbound traffic, and to permit return traffic? Please show the output of cat /proc/sys/net/ipv4/ip_forward ; iptables-save -c, as run on the edge device. This explanation does not quite fit with the sudden success after reinstalling Raspbian, though.

What does a traceroute 8.8.8.8 from computer C show? How does it compare to running the same command on computer A?
Back to top
View user's profile Send private message
gcyoung
Tux's lil' helper
Tux's lil' helper


Joined: 04 Jul 2007
Posts: 144
Location: England

PostPosted: Sun Mar 08, 2020 5:41 pm    Post subject: Reply with quote

Solved. And I feel rather foollish. Apologies all round. I had a residdual /etc/resolv.conf file whjich contained the previous
nameserver IP address which obviously differed from the one in the new network settings.So as I suspected the problem did lie
in confllicting nameserver IP's
As for BBCode, you can now see that I have now made some progress above. But I did think that 'code' was that which made up
and was part of a program, not it's output.
Back to top
View user's profile Send private message
Hu
Moderator
Moderator


Joined: 06 Mar 2007
Posts: 15334

PostPosted: Sun Mar 08, 2020 6:53 pm    Post subject: Reply with quote

How did the old /etc/resolv.conf persist? I thought from your prior posts that you had examined it on every system and found it to be correct.
Back to top
View user's profile Send private message
gcyoung
Tux's lil' helper
Tux's lil' helper


Joined: 04 Jul 2007
Posts: 144
Location: England

PostPosted: Mon Mar 09, 2020 5:01 pm    Post subject: Reply with quote

I set my nameserver in the file /etc/systemd/network/50-static.network. I was not aware that resolv.conf was still needed. Is it?
I think the resolv.conf file may have been a remnant of earlier methods prior to the introduction of systemd. Since it contained the
same IP number which I used prior to switching to my current internet provider it would not have affected my earlier internet use.
It might be said that in my case, thinking that, I should have deleted it earlier. However, unlike some. I am not perfect.
Back to top
View user's profile Send private message
Hu
Moderator
Moderator


Joined: 06 Mar 2007
Posts: 15334

PostPosted: Tue Mar 10, 2020 1:55 am    Post subject: Reply with quote

As far as I know, /etc/resolv.conf is still standard on all systems, including those under control of systemd. However, as I keep systemd masked and avoid it at all costs, I could be unaware of it deprecating this decades-old standard. If it is obsolete, you should remove it so that it does not cause problems on your next network upgrade.
Back to top
View user's profile Send private message
Display posts from previous:   
Reply to topic    Gentoo Forums Forum Index Networking & Security All times are GMT
Page 1 of 1

 
Jump to:  
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum