# network swap adsl to fibre

## gcyoung

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

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

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

 *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
> ...

 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?  :Smile:   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?

----------

## gcyoung

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
> ...

 

 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 quotesLast edited by gcyoung on Sun Mar 08, 2020 1:52 pm; edited 4 times in total

----------

## freke

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

To Freke

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

----------

## gcyoung

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
> ...

 

----------

## Hu

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

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

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

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

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.

----------

