Failing eth0 at Raspberry

[Toulon7559]

Due to crash of the software of Raspberry3B had to freshly reinstall the software: Buster and latest Domoticz_stable, and a few more .......

All well except for 1 aspect causing headscratching.

Have set SSH at setup by interface-menu and checked by raspi-config.
Wifi-access by means of Putty-SSH etc. is all OK.

Also activated & connected eth0, but no access over LAN by means of Putty-SSH or URL-call etc..
Cable seems OK [after check by test-tool].
Lights at Ethernet-Switch are flashing as well at side of RPI.
Advanced IP Scanner sees the eth-interface and reports identity-info, but ping fails with timeout.

Cable recheck at daylight is first candidate for troubleshooting:
any suggestion for a next step?

[FireWizard]

Hi,

What do you see, if you are logged in with ssh over your wifi, if you issue the command:

Code: Select all

sudo ifconfig

Regards

[Toulon7559]

@Firewizard

The result of sudo ifconfig is one of the reasons for the headscratching,
because IMHO all looks OK, except that the amount of RX & TX packets is low & unequal for eth0.

Code: Select all

sudo ifconfig
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.1.6  netmask 255.255.255.0  broadcast 192.168.1.255
        inet6 fe80::69af:abe:3390:5444  prefixlen 64  scopeid 0x20<link>
        ether b8:27:eb:3d:04:a9  txqueuelen 1000  (Ethernet)
        RX packets 8679  bytes 837088 (817.4 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 1148  bytes 228064 (222.7 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 1000  (Local Loopback)
        RX packets 32739  bytes 6086543 (5.8 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 32739  bytes 6086543 (5.8 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

wlan0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.0.185  netmask 255.255.255.0  broadcast 192.168.0.255
        inet6 fe80::98db:9275:ff22:ff99  prefixlen 64  scopeid 0x20<link>
        ether b8:27:eb:68:51:fc  txqueuelen 1000  (Ethernet)
        RX packets 756316  bytes 267054749 (254.6 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 625290  bytes 136742574 (130.4 MiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

[freijn]

I am not sure about your networking knowlegde but the Wlan and Eth0 are in different networks, hence you
either need to change one or put routing in place.

inet 192.168.1.6 netmask 255.255.255.0

inet 192.168.0.185 netmask 255.255.255.0

are different networks/

[FireWizard]

@Toulon7559

As @freijn already said, your wireless and your wired network are two different networks.

If I make a guess your eth0 has a fixed IP address (192.168.1.6) and your wireless IP address is issued by your DHCP server (192.168.0.185).
So you will not be able to connect with a device to a network 192.168.1/24, if you are on 192.168.0/24.

It is recommended that servers has a fixed (static) IP, as clients should be able to find them.

So if your network is configured as 192.168.0/24 I would suggest that you check, that your DHCP server has a range configured of static IP addresses and I would give eth0 an address out of that range. E.g 192.168.0.6.

Have a look at: https://soltveit.org/raspbian-buster-st ... to-set-it/

Regards

[Toulon7559]

In my configuration all clients in the subject segment have fixed IP-adresses:
- at WLAN with own router serving in range 192.16.0.x
- at cabled LAN with other router serving in range 192.168.1.y
Without any problems, also for the 'problem-machine' till latest reinstall of the software.

Initial setting of the fixed IP-adresses (in standalone config with keyboard & monitor) either via the setup window of the raspberry, via raspi-config, or via sudo nano /etc/dhcpcd.conf
When an intially set machine has been fitted in the operational network configuration, (if needed) adjustment of setting through PuttySSH via raspi-config or via sudo nano /etc/dhcpcd.conf
In the config-examples in /etc/dhcpcd.conf inclusion of Netmask 255.255.255.0 is nowhere asked.
Nor is setting of SSH.

Initially I was also able after install Buster on the SD-card to set in the root an 'empty' file named SSH without extension in combination with a preset file wpa_supplicant.conf:
with such SD-card configuration the Raspberry immediately tunes to the appropriate SSID and is prepared for access by PuttySSH for all further settings mentioned above, which saves the action to set SSH and the SSID.
Install of Buster still without problems, but unfortunately (for unknown reasons) the above tric does not work anymore:
after installation of Buster at the SD-card using an imager on a Windows-PC, the content of the SD-card is not visible anymore, and therefore above action no longer possible.
[Or on the Windows-PC other software to be applied than Explorer?]

Still headscratching ......

[havnegata]

..
Install of Buster still without problems, but unfortunately (for unknown reasons) the above tric does not work anymore:
after installation of Buster at the SD-card using an imager on a Windows-PC, the content of the SD-card is not visible anymore, and therefore above action no longer possible.
[Or on the Windows-PC other software to be applied than Explorer?]
..

I don't know about your networkproblem, but for me the trick about getting SSH access when working on the image file from a Windows pc, was to eject the SD-card and plug it in again. Then Windows was able to see the D:\ partition on the SD-card and I was able to put the empty ssh.txt file on this partition.

[Toulon7559]

@havnegata

Indeed, simple&effective remedy to read the SD-card after install and for install of the files in the root of the SD-card.
Need to remember next time when making an SD-image .......

Obviously (re)route calls & datastreams via WLAN is OK, but now is exception in my configuration.
Running most calls & datastreams via eth0 is preferred, being faster & safer.
Therefore still looking for a method, either to online[?] enable SSH for eth0, or through settings in a configuration-file:
setting SSH for eth0 is a basic function and must be simple, but how?

[FireWizard]

Hi,
@Toulon7559

You might want to read:

https://raspberrypi.stackexchange.com/q ... ubnetworks

Regards

[Toulon7559]

@Firewizard

True, but this solution unfortunately is out of date and valid for older versions [<4834].
Presently, /etc/network/interfaces for static IP-adressing refers to /etc/dhcpcd.conf

From my experience now inserting settings in /etc/network/interfaces has no effects.
Have tried several variations in dhcpcd.conf based on the examples in that file, but no (positive) result either.

Not intended, but now this machine is equivalent to a Raspberry3A+ with 4 USB-ports:
still useful, but for other applications than planned.

Have tried alternative (guaranteed OK) cables as well for connection of the eth0-interface to the LAN, but unfortunately no different result:
eth0 still striking.
See at this moment 2 possible reasons:
a) hardware of eth0 is defect [but that is contradicted by flashing green and orange indicators when a cable is connected]
b) something subtle in the software control of eth0 is amiss [but how to find & correct?]

Perhaps a very pragmatic/empirical way of checking by 'try&error'.
I have another/2nd RPI3B being prepared for introduction, and therefore running 'empty' with Raspian Buster 'Normal_Edition' & basic_Domoticz (also stable release 2020.2) with equivalent setting for wlan0&eth0 (without problems), free for some experimenting.
Swapping their SD-cards, must show effects, or not:
1) If the 'eth0-problem' with it's SD-card shifts to the 2nd machine, then it seems a 'software problem' for the software on that SD-card.
2) If the 'eth0-problem' stays with the 1st machine, then it's eth0-interface seems at fault.

Result of testing
After swapping the SD-cards between the 2 RPI3Bs, case 1) shows, not case 2).
Conclusion:
Software problem.
Idea popping up: how to refresh/reset the interface driver for eth0?
[Using Raspian Buster 'Normal edition' & basic_Domoticz (= stable release 2020.2)]

[FireWizard]

HI,

@Toulon

You are right, the solution in the link applies to earlier versions of Raspbian,

a) hardware of eth0 is defect [but that is contradicted by flashing green and orange indicators when a cable is connected]

You can check that by connecting an Ethernet cable from a PC or Laptop to your Raspberry Pi.
Change temporary the IP address of that PC or Laptop to a fixed address, e.g 192.168.1.100 and check if you can reach the pi, both with a browser and with ssh (putty). Then you are sure that the Ethernet port is functioning correctly.

Do that first.

Regards

[FireWizard]

@Toulon7559

Have you seen this: https://www.raspberrypi.org/forums/view ... p?t=251130

I think the solution for your setup, you can find at: https://www.raspberrypi.org/documentati ... -routed.md

Regards

[Toulon7559]

@Firewizard

Because my PC-with-PuttySSH/WinSCP/etc. and the 'problematic' Raspberry are on the same ethernetswitch, your first hint effectively seems fulfilled, however with negative result [= no functional connection].
That was reason for my SD-swapping-experiment, with result pointing to a software-problem.

In that perspective the thread called by the first url in your latest message provides some hints worth exploring.
Resetting routers and switches never harms and easily done.
The last message in that thread identifies some extra software called wicd which kicks out the dhcp-control for eth0, etc..

'Routed wireless access point' is not the intention of my raspberry-setup, but the Raspberry as client accessing 2 networks [wlan0 and eth0].

Result of check on presence of file wicd
Reported in all configurations on my Raspberries as follows

Code: Select all

$ sudo rgrep -w wicd /
Binair bestand /usr/bin/lxsession bevat de gezochte tekst.

Because apparently found nowhere else, it seems that that subject file wicd is not present in the 'problem'- Raspberry,
although (oviously) another way of search may reveal other results .......

[FireWizard]

@Toulon7559

Hi,

One more guess.

See: https://www.debian.org/releases/stable/ ... ation.html

5.1.6. Migrating from legacy network interface names

Could this be an issue.

If it isn"t something like this, I´m out of options.

Regards

[Toulon7559]

@FireWizard

After resetting all routers and switches within view, to get the OS i latest version obviously tried

Code: Select all

sudo apt-get update
sudo apt-get upgrade

Not positively surprised with further observations ....
Reading and trying that paragraph 5.1.6 hinted in your latest message, I get the following results

Code: Select all

$ sudo rgrep -w eth0 /etc

lists

Code: Select all

/etc/dhcpcd.conf:#interface eth0
/etc/dhcpcd.conf:# fallback to static profile on eth0
/etc/dhcpcd.conf:#interface eth0
/etc/dhcpcd.conf:interface eth0
/etc/dhcp/dhclient.conf:#  interface "eth0";
/etc/dhcp/dhclient.conf:#  interface "eth0";
/etc/initramfs-tools/initramfs.conf:# Specify a specific network interface, like eth0
/etc/avahi/avahi-daemon.conf:#allow-interfaces=eth0
/etc/dhcpd.conf:interface eth0

Code: Select all

$ udevadm test-builtin net_id /sys/class/net/eth0 2>/dev/null

lists

Code: Select all

ID_NET_NAMING_SCHEME=v240
ID_NET_NAME_MAC=enxb827eb3d04a9
ID_OUI_FROM_DATABASE=Raspberry Pi Foundation

More headscratching how to proceed ......
Seems practical to first have a look into all those files mentioning eth0.

Considering to perform another reinstall, but have the nagging/unsupported feeling that reinstall of domoticz.db from backup might in some unknown ways have effects:
IMHO that is the only difference between a reinstall of a configuration and a configuration really fresh from scratch.
Reason for this thinking:
the configuration before crash when accessed through PuttySSH gave strange responses on the CLI, which may hint on corruption of files.
Restore of last backup of domoticz.db gave crash, forcing me to use last but one backup, but then question is how 'healthy' is that version?
Restauration of the crashed configuration Set2 starting from scratch is a lot of work:
perhaps better idea to perform provisional repairs, correct the visible, 'erring results' and to make planned shift to the 'waiting, fresh' Raspberry-with-working-eth0 for those functions for which application of eth0 has advantages.

Cleanup & redistribution of functions to make the configuration leaner & meaner is never a bad idea ........

[Toulon7559]

The subject Raspberry should have ports open at wlan0 and eth0 both for http and ftp:
the latter because vsftpd installed.

Checked the status of the ports by use of Advanced Port Scanner.

The Raspberry is detected as present at related IP-address, both for wlan0 and for etho.
For wlan0 also access reported for http and for ftp.
For eth0 no open ports reported.

Conclusion:
wlan0 OK, but eth0 apparently locked by Raspberry-software.

[FireWizard]

@Toulon7559

Could you publish your /etc/dhcpcd.conf file. so that I can compare with mine?

Regards

[Toulon7559]

Copied by WinSCP from /etc/dhcpcd.conf in the 'problem-Raspberry'.
Just the bottom part of my file /etc/dhcpcd.conf, starting with examples etc. for static ip-addres-setting
The 2 blocks at the bottom are equivalent to a version in another well-working setup.
Originally the second block in this quote was inactive, marked on all lines with front-#:
later activated those lines trying to force a solution of the 'problem' (without any result).

Code: Select all

# Example static IP configuration:
#interface eth0
#static ip_address=192.168.0.10/24
#static ip6_address=fd51:42f8:caae:d92e::ff/64
#static routers=192.168.0.1
#static domain_name_servers=192.168.0.1 8.8.8.8 fd51:42f8:caae:d92e::1

# It is possible to fall back to a static IP if DHCP fails:
# define static profile
profile static_eth0
static ip_address=192.168.1.6/24
static routers=192.168.1.2
static domain_name_servers=192.168.0.1 8.8.8.8

# fallback to static profile on eth0
#interface eth0
#fallback static_eth0

interface eth0
inform 192.168.1.6
static routers=192.168.1.2

interface wlan0
inform 192.168.0.185
static routers=192.168.0.1

Most (Older?) setup-instructions tell to modifiy the settings through Putty's CLI with

Code: Select all

sudo nano /etc/dhcpcd.conf

To my surprise in this latest release setup I then see a completely different text for /etc/dhcpcd.conf

Code: Select all

# A sample configuration for dhcpcd.
# See dhcpcd.conf(5) for details.

# Allow users of this group to interact with dhcpcd via the control socket.
#controlgroup wheel

# Inform the DHCP server of our hostname for DDNS.
hostname

# Use the hardware address of the interface for the Client ID.
clientid
# or
# Use the same DUID + IAID as set in DHCPv6 for DHCPv4 ClientID as per RFC4361.
# Some non-RFC compliant DHCP servers do not reply with this set.
# In this case, comment out duid and enable clientid above.
#duid

# Persist interface configuration when dhcpcd exits.
persistent

# Rapid commit support.
# Safe to enable by default because it requires the equivalent option set
# on the server to actually work.
option rapid_commit

# A list of options to request from the DHCP server.
option domain_name_servers, domain_name, domain_search, host_name
option classless_static_routes
# Respect the network MTU. This is applied to DHCP routes.
option interface_mtu

# Most distributions have NTP support.
#option ntp_servers

# A ServerID is required by RFC2131.
require dhcp_server_identifier

# Generate SLAAC address using the Hardware Address of the interface
#slaac hwaddr
# OR generate Stable Private IPv6 Addresses based from the DUID
slaac private

Just bewildering:
something related to latest release of Buster & Domoticz?
Because do not remember that difference of /etc/dhcpcd.conf for 'older' versions:
is this now something (undocumented?) similar to making a cronjob where it makes a difference whether you use

Code: Select all

crontab -e

or

Code: Select all

sudo crontab -e

?

[FireWizard]

Hi,

@Toulon7559

Ahaa

Copied by WinSCP from /etc/dhcpcd.conf in the 'problem-Raspberry'.
Just the bottom part of my file /etc/dhcpcd.conf, starting with examples etc. for static ip-addres-setting
The 2 blocks at the bottom are equivalent to a version in another well-working setup.
Originally the second block in this quote was inactive, marked on all lines with front-#:
later those lines activated trying to force a solution of the 'problem' (without any result).

I see that you published two blocks of configuration text, which are both part of the /etc/dhcpcd.conf file.

Just bewildering:
something related to latest release of Buster & Domoticz?
Because do not remember that difference for 'old' versions:
then it was easy to insert the static ip_settings through sudo nano.

For what reason what ever, if the upper part is the dhcpcd.conf file, you are missing configuration essentials.
If the bottom part is the dhcpcd.conf file, it is the same.
Short, if this is your configuration file, it is messed up

It is not related to Buster, as I will publish 2 configuration files, I have with buster.
1. RPi3+ (So with eth0 and wlan0, but without Domoticz)
2. Rpi2 (only with eth0, with Domoticz)

If we look to your lower part of the config file. we see:

# Example static IP configuration:
#interface eth0
#static ip_address=192.168.0.10/24
#static ip6_address=fd51:42f8:caae:d92e::ff/64
#static routers=192.168.0.1
#static domain_name_servers=192.168.0.1 8.8.8.8 fd51:42f8:caae:d92e::1

Everything is commented (#), I do not find this section with a valid static IP address and I cannot find a configuration that uses a DHCP issued IP address. So I assume, that you dont use your DHCP server for this Raspberry Pi, but you want a static address.

Then I see:

# It is possible to fall back to a static IP if DHCP fails:
# define static profile
profile static_eth0
static ip_address=192.168.1.6/24
static routers=192.168.1.2
static domain_name_servers=192.168.0.1 8.8.8.8

# fallback to static profile on eth0
#interface eth0
#fallback static_eth0

interface eth0
inform 192.168.1.6
static routers=192.168.1.2

interface wlan0
inform 192.168.0.185
static routers=192.168.0.1

This part is intended for emergency cases, if the DHCP server fails, and as you have not configured DHCP, it does fail.
You should not use this method as the standard to set a static IP address.

Find below a complete dhcpcd.conf file of a RPi3+

Code: Select all

# A sample configuration for dhcpcd.
# See dhcpcd.conf(5) for details.

# Allow users of this group to interact with dhcpcd via the control socket.
#controlgroup wheel

# Inform the DHCP server of our hostname for DDNS.
hostname

# Use the hardware address of the interface for the Client ID.
clientid
# or
# Use the same DUID + IAID as set in DHCPv6 for DHCPv4 ClientID as per RFC4361.
# Some non-RFC compliant DHCP servers do not reply with this set.
# In this case, comment out duid and enable clientid above.
#duid

# Persist interface configuration when dhcpcd exits.
persistent

# Rapid commit support.
# Safe to enable by default because it requires the equivalent option set
# on the server to actually work.
option rapid_commit

# A list of options to request from the DHCP server.
option domain_name_servers, domain_name, domain_search, host_name
option classless_static_routes
# Most distributions have NTP support.
option ntp_servers
# Respect the network MTU. This is applied to DHCP routes.
option interface_mtu

# A ServerID is required by RFC2131.
require dhcp_server_identifier

# Generate Stable Private IPv6 Addresses instead of hardware based ones
slaac private

# Example static IP configuration:
#interface eth0
#static ip_address=192.168.0.10/24
#static ip6_address=fd51:42f8:caae:d92e::ff/64
#static routers=192.168.0.1
#static domain_name_servers=192.168.0.1 8.8.8.8 fd51:42f8:caae:d92e::1

interface eth0
static ip_address=192.168.10.53/24
static routers=192.168.10.30
static domain_name_servers=192.168.10.30

interface wlan0
static ip_address=192.168.10.54/24
static routers=192.168.10.30 
static domain_name_servers=192.168.10.30                             

# It is possible to fall back to a static IP if DHCP fails:
# define static profile
#profile static_eth0
#static ip_address=192.168.1.23/24
#static routers=192.168.1.1
#static domain_name_servers=192.168.1.1

# fallback to static profile on eth0
#interface eth0
#fallback static_eth0

The next one is for RPi2 with Domoticz.

Code: Select all

# A sample configuration for dhcpcd.
# See dhcpcd.conf(5) for details.

# Setup static interface
interface eth0
static ip_address=192.168.10.50/24
static routers=192.168.10.30
static domain_name_servers=192.168.10.30 195.121.1.34 195.121.1.66

# Allow users of this group to interact with dhcpcd via the control socket.
#controlgroup wheel

# Inform the DHCP server of our hostname for DDNS.
hostname

# Use the hardware address of the interface for the Client ID.
clientid
# or
# Use the same DUID + IAID as set in DHCPv6 for DHCPv4 ClientID as per RFC4361.
#duid

# Persist interface configuration when dhcpcd exits.
persistent

# Rapid commit support.
# Safe to enable by default because it requires the equivalent option set
# on the server to actually work.
option rapid_commit

# A list of options to request from the DHCP server.
option domain_name_servers, domain_name, domain_search, host_name
option classless_static_routes
# Most distributions have NTP support.
option ntp_servers
# Respect the network MTU.
# Some interface drivers reset when changing the MTU so disabled by default.
#option interface_mtu

# A ServerID is required by RFC2131.
require dhcp_server_identifier

# Generate Stable Private IPv6 Addresses instead of hardware based ones
slaac private

# A hook script is provided to lookup the hostname if not set by the DHCP
# server, but it should not be run by default.
nohook lookup-hostname

I hope this will help you to solve the issue.

Regards

[Toulon7559]

@Firewizard

As indicated in the earlier message, on purpose I did not include the upper part of /etc/dhcpcd.conf

Copied by WinSCP from /etc/dhcpcd.conf in the 'problem-Raspberry'.
Just the bottom part of my file /etc/dhcpcd.conf, starting with examples etc. for static ip-addres-setting
The 2 blocks at the bottom are equivalent to a version in another well-working setup.
Originally the second block in this quote was inactive, marked on all lines with front-#:
later those lines activated trying to force a solution of the 'problem' (without any result).

Reason: the upper part is same for all RPI3s in this configuration, as now copied below, and not different from the text you show

Code: Select all

# A sample configuration for dhcpcd.
# See dhcpcd.conf(5) for details.

# Allow users of this group to interact with dhcpcd via the control socket.
#controlgroup wheel

# Inform the DHCP server of our hostname for DDNS.
hostname

# Use the hardware address of the interface for the Client ID.
clientid
# or
# Use the same DUID + IAID as set in DHCPv6 for DHCPv4 ClientID as per RFC4361.
# Some non-RFC compliant DHCP servers do not reply with this set.
# In this case, comment out duid and enable clientid above.
#duid

# Persist interface configuration when dhcpcd exits.
persistent

# Rapid commit support.
# Safe to enable by default because it requires the equivalent option set
# on the server to actually work.
option rapid_commit

# A list of options to request from the DHCP server.
option domain_name_servers, domain_name, domain_search, host_name
option classless_static_routes
# Respect the network MTU. This is applied to DHCP routes.
option interface_mtu

# Most distributions have NTP support.
#option ntp_servers

# A ServerID is required by RFC2131.
require dhcp_server_identifier

# Generate SLAAC address using the Hardware Address of the interface
#slaac hwaddr
# OR generate Stable Private IPv6 Addresses based from the DUID
slaac private

Checked against your example for RPI3+ and with

Code: Select all

sudo nano /etc/dhcpcd.conf

aligned the bottom-part to have the 2*4 lines setting the static ip-addresses for eth0 and for wlan0 (in fact identical to the way I used to set the interfaces in earlier systems).
But even less luck: the Advanced IP Scanner and the Advanced Port Scanner no longer see this IP-address.

Found file /etc/dhcpd.conf containing just those 4 same lines defining for eth0 the static ip-addressing:
same layout in another 'faultless' RPI3, therefore (by comparison) the general setup seems OK.

Apparently overlooking something very subtle for setup/operation of eth0 at this RPI3 ......