network swap adsl to fibre

gcyoung · Posted: Fri Mar 06, 2020 3:13 pm Post subject: network swap adsl to fibre

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.

Hu · Moderator Joined: 06 Mar 2007 Posts: 21635

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.

gcyoung · Posted: Sat Mar 07, 2020 6:11 pm Post subject: ADSL to Cable

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"

Hu · Moderator Joined: 06 Mar 2007 Posts: 21635

gcyoung · Posted: Sat Mar 07, 2020 11:56 pm Post subject:

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

freke · Posted: Sun Mar 08, 2020 8:53 am Post subject:

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.

gcyoung · Posted: Sun Mar 08, 2020 9:22 am Post subject:

To Freke
Yes. See my previous Post. But only my own 192.168.0.x addresses. Which made me susspect a faulty nameserver.

gcyoung · Posted: Sun Mar 08, 2020 1:41 pm Post subject:

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.

Hu · Moderator Joined: 06 Mar 2007 Posts: 21635

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?

gcyoung · Posted: Sun Mar 08, 2020 5:41 pm Post subject:

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.

Hu · Moderator Joined: 06 Mar 2007 Posts: 21635

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.

gcyoung · Posted: Mon Mar 09, 2020 5:01 pm Post subject:

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.

Hu · Moderator Joined: 06 Mar 2007 Posts: 21635

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.