[nanopir1] [ports eth0 et port eth1 & kernel 4.xx et kernel 5.xx]

[jeanmarc]

Bonjour,

Après avoir relu ce post ....https://forum.armbian.com/topic/12152-n ... rnet-port/,
je me reposais la question de savoir le bien fondé de garder un parc de nanopir1 en 100% Debian Buster (donc en kernel 4.19xxx) et un second parc en 100% Debian Buster, mais avec un noyau de Debian backport, donc en version 5.xx

En fait, la réponse est très simple (!)
Le second port Ethernet (1 Gbit/sec) n'est disponible que sur le noyau 5.xx.
En effet, bien qu'en tentant une tentative d'installation de firmwares en version bulleseye sur un noyau Debian 4.xx, le résultat est non satisfaisant puisque ....

Code: Select all

ansible@nanopir1-210:~$ uname -a
Linux nanopir1-210 4.19.0-16-armmp #1 SMP Debian 4.19.181-1 (2021-03-19) armv7l GNU/Linux
ansible@nanopir1-210:~$ dpkg -l |grep firmware
ii  firmware-ath9k-htc               1.4.0-106-gc583009+dfsg1-1          all          firmware for AR7010 and AR9271 USB wireless adapters
ii  firmware-atheros                 20210315-2                          all          Binary firmware for Qualcomm Atheros wireless cards
ii  firmware-brcm80211               20210315-2                          all          Binary firmware for Broadcom/Cypress 802.11 wireless cards
ii  firmware-linux-free              3.4                                 all          Binary firmware for various drivers in the Linux kernel
ii  firmware-misc-nonfree            20210315-2                          all          Binary firmware for various drivers in the Linux kernel
ii  firmware-realtek                 20210315-2                          all          Binary firmware for Realtek wired/wifi/BT adapters
ansible@nanopir1-210:~$ 

Alors que sur une autre nanopir1 avec une configuration de noyau plus récente ...

Code: Select all

ansible@nanopir1-270:~$ uname -a
Linux nanopir1-270 5.10.0-0.bpo.4-armmp-lpae #1 SMP Debian 5.10.19-1~bpo10+1 (2021-03-13) armv7l GNU/Linux
ansible@nanopir1-270:~$ sudo dmesg |grep -i 1c30000
[   10.166346] dwmac-sun8i 1c30000.ethernet: IRQ eth_wake_irq not found
[   10.166364] dwmac-sun8i 1c30000.ethernet: IRQ eth_lpi not found
[   10.167680] dwmac-sun8i 1c30000.ethernet: PTP uses main clock
[   10.191042] dwmac-sun8i 1c30000.ethernet: Current syscon value is not the default 50006 (expect 58000)
[   10.332794] dwmac-sun8i 1c30000.ethernet: No HW DMA feature register supported
[   10.340780] dwmac-sun8i 1c30000.ethernet: RX Checksum Offload Engine supported
[   10.354010] dwmac-sun8i 1c30000.ethernet: COE Type 2
[   10.354034] dwmac-sun8i 1c30000.ethernet: TX Checksum insertion supported
[   10.366132] dwmac-sun8i 1c30000.ethernet: Normal descriptors
[   10.383342] dwmac-sun8i 1c30000.ethernet: Chain mode enabled
[   10.399716] dwmac-sun8i 1c30000.ethernet: Found internal PHY node
[   10.413658] dwmac-sun8i 1c30000.ethernet: Switch mux to internal PHY
[   10.420122] dwmac-sun8i 1c30000.ethernet: Powering internal PHY
[   10.461140] dwmac-sun8i 1c30000.ethernet: Switch mux to external PHY
[   10.540868] dwmac-sun8i 1c30000.ethernet et-wan: renamed from eth0
[   53.916558] dwmac-sun8i 1c30000.ethernet et-wan: PHY [0.2:07] driver [RTL8211E Gigabit Ethernet] (irq=POLL)
[   53.954160] dwmac-sun8i 1c30000.ethernet et-wan: No Safety Features support found
[   53.961894] dwmac-sun8i 1c30000.ethernet et-wan: No MAC Management Counters available
[   53.969801] dwmac-sun8i 1c30000.ethernet et-wan: PTP not supported by HW
[   53.999694] dwmac-sun8i 1c30000.ethernet et-wan: configuring for phy/rgmii link mode
[53602.051564] dwmac-sun8i 1c30000.ethernet et-wan: Link is Up - 1Gbps/Full - flow control rx/tx
ansible@nanopir1-270:~$ dpkg -l |grep linux-image
ii  linux-image-5.10.0-0.bpo.4-armmp-lpae 5.10.19-1~bpo10+1                   armhf        Linux 5.10 for ARMv7 multiplatform compatible SoCs supporting LPAE
ii  linux-image-armmp-lpae                5.10.19-1~bpo10+1                   armhf        Linux for ARMv7 multiplatform compatible SoCs supporting LPAE (meta-package)
ansible@nanopir1-270:~$ 

...et en effet, sur la nanopir1 en noyau 4.x, le chargement du même driver ne permet pas d'obtenir l'interface Ethernet, puisque ...

Code: Select all

ansible@nanopir1-210:~$ uname -a
Linux nanopir1-210 4.19.0-16-armmp #1 SMP Debian 4.19.181-1 (2021-03-19) armv7l GNU/Linux
ansible@nanopir1-210:~$  sudo modprobe  dwmac-sun8i
ansible@nanopir1-210:~$  sudo dmesg |grep -i 1c30000
ansible@nanopir1-210:~$ 

Conclusions: Pour qui souhaite disposer des 2 interfaces Ethernet, seul le noyau 5.x est une solution (!)

[-W.-]

Bonjour

Merci pour cette information, Au delà de cette nano pi cela me conforte sur une chose que je suopconne depuis quelques mois sur le kernel 5 sans réussir à mettre le doigt dessus., il y aurait quelque chose de pourris au royaume de l'USB avec les événements perso des derniers mois j 'ai fait le grand saut kernel 4 vers 5 du jour au lendemain sans chercher certaines causes profondes, et j'ai des soucis sur certaines boards, différentes mais toujours il y a l'USB dans la boucle peut être que je me fais un film pour justifier les problèmes, mais je suis surpris de voir que des soucis nous ramènent toujours à cela sur la R1, la HC1, la cubie 5, etc... que le kernel viennent de Debian, Armbian ou Firmware Toolkit (DFT).

C'est troublant tout de même.. Je sens que je vais me refaire une série de test de robustesse sur un kernel 4 quitte à me passer de certaines features quelques temps. Après si le stable c'est le 4 chez Debian et pas le 5 il y a peu être une raison Enfin moi je dis cà je dis rien... donc je sors

@+W.

[jeanmarc]

Bonjour,
Je continue de me battre sur cette interface Ethernet.
Visiblement, avec une simple adresse IPV4 en statique et un câble croisé, je n'arrive pas à faire un ping ....
Bref, encore une soucis sur ce driver ...

[jeanmarc]

Bonjour,

Pour compléter le test en cours, la configuration décrite ici se compose de 2 nanopir1 à priori de même version de matériel (?, sauf que la seule certitude est un achat en une seule fois le même jour !).
Ces 2 équipements (nanopir1-210 et nanopir1-220) sont en Debian 10.9 à l'état de l'art, mais avec un noyau Debian pas tout à fait dans la même version comme le montre les logs suivants :

Code: Select all

ansible@nanopir1-210:~$ uname -a
Linux nanopir1-210 5.10.0-5-armmp-lpae #1 SMP Debian 5.10.24-1 (2021-03-19) armv7l GNU/Linux
ansible@nanopir1-210:~$ cat /etc/debian_version 
10.9
ansible@nanopir1-210:~$ 
ansible@nanopir1-210:~$ dpkg -l |grep linux-image
ii  linux-image-5.10.0-5-armmp-lpae 5.10.24-1                    armhf        Linux 5.10 for ARMv7 multiplatform compatible SoCs supporting LPAE
ii  linux-image-armmp-lpae          5.10.24-1                    armhf        Linux for ARMv7 multiplatform compatible SoCs supporting LPAE (meta-package)

... et

Code: Select all

ansible@nanopir1-220:~$ uname -a
Linux nanopir1-220 5.10.0-0.bpo.4-armmp-lpae #1 SMP Debian 5.10.19-1~bpo10+1 (2021-03-13) armv7l GNU/Linux
ansible@nanopir1-220:~$ cat /etc/debian_version 
10.9

ansible@nanopir1-220:~$  dpkg -l |grep linux-image
ii  linux-image-5.10.0-0.bpo.4-armmp-lpae 5.10.19-1~bpo10+1                   armhf        Linux 5.10 for ARMv7 multiplatform compatible SoCs supporting LPAE
ii  linux-image-armmp-lpae                5.10.19-1~bpo10+1                   armhf        Linux for ARMv7 multiplatform compatible SoCs supporting LPAE (meta-package)
ansible@nanopir1-220:~$ 

Les 2 équipements sont joignables par l'interface noté LAN sur la sérigraphie. C'est important car visiblement, il s'agit ici d'un chip Ethernet totalement en service sur la série des noyaux Linux 4.x, ce qui n'est pas le cas du composant Ethernet de l'interface noté WAN sur la sérigraphie.
Donc, afin de tester au mieux cette interface, j'ai connecté les 2 ports WAN de chaque nanopir1 à travers un câble RJ45.
Enfin, chaque interface WAN est identifiée au niveau du noyau sous le nom et-wan avec une route statique comme suit :

Code: Select all

ansible@nanopir1-210:~$ ip route ls 
192.168.22.0/24 dev et-serv proto kernel scope link src 192.168.22.49 
192.168.25.0/24 dev et-admi proto kernel scope link src 192.168.25.49 
192.168.253.0/24 dev et-wan proto kernel scope link src 192.168.253.1 
ansible@nanopir1-210:~$ 

..et

Code: Select all

ansible@nanopir1-220:~$ ip route ls
192.168.22.0/24 dev et-serv proto kernel scope link src 192.168.22.65 
192.168.25.0/24 dev et-admi proto kernel scope link src 192.168.25.65 
192.168.253.0/24 dev et-wan proto kernel scope link src 192.168.253.2 
ansible@nanopir1-220:~$ 

Pour terminer le scénario, quel que part sur le réseau, un serveur syslog-ng est en écoute de tous les flux de tous les équipements. Les logs peuvent être triés simplement par rapport à l'adresse source basé sur le nom DNS (on prendra donc ici les mots clés nanopir1-210 et nanopir1-220.
Sachant qu'un doute existe sur la gestion de l'interface (mode up/down), on ajoute un filtre permettant de ne regarder que les messages du noyau..

Le comportement attendu de ce test est que sur un débranchement puis rebranchement d'un coté quelconque du câble RJ45 connectant les 2 nanopir1, on s’attende donc à avoir un événement dans le noyau de déconnexion/reconnexion du link sur les équipements.

Ce qui donne un filtre du genre ....

Code: Select all

ansible@vm-syslog-295:~$ tail -f /var/log/syslog-ng/current_logs/BY_HOST.nanopir1-210-service.log /var/log/syslog-ng/current_logs/BY_HOST.nanopir1-220-service.log |grep kern

soit donc pour la déconnexion du câble RJ45 les logs suivants ....

Code: Select all

2021-04-09T13:45:06+02:00 s_dev_kernel_kmsg@nanopir1-210 kernel: 6,20027,159054662462,-;dwmac-sun8i 1c30000.ethernet et-wan: Link is Down
2021-04-09T13:45:06+02:00 s_dev_kernel_kmsg@nanopir1-220 kernel: 6,876,237197409970,-;dwmac-sun8i 1c30000.ethernet et-wan: Link is Down

.. et pour la reconnexion ....

Code: Select all

2021-04-09T13:45:15+02:00 s_dev_kernel_kmsg@nanopir1-220 kernel: 6,877,237206626414,-;dwmac-sun8i 1c30000.ethernet et-wan: Link is Up - 1Gbps/Full - flow control rx/tx
2021-04-09T13:45:16+02:00 s_dev_kernel_kmsg@nanopir1-210 kernel: 6,20028,159064902908,-;dwmac-sun8i 1c30000.ethernet et-wan: Link is Up - 1Gbps/Full - flow control rx/tx

..donc tout est parfait ....mais ..

Code: Select all

ansible@nanopir1-210:~$ sudo ping 192.168.253.2 
PING 192.168.253.2 (192.168.253.2) 56(84) bytes of data.
From 192.168.253.1 icmp_seq=1 Destination Host Unreachable
From 192.168.253.1 icmp_seq=2 Destination Host Unreachable

ce qui est confirmé par ....

Code: Select all

ansible@nanopir1-210:~$ sudo arp -a |grep et-wan
? (192.168.253.2) at <incomplete> on et-wan
ansible@nanopir1-210:~$ 

..et ..

Code: Select all

ansible@nanopir1-210:~$ sudo sysctl -a |grep et-wan |grep -v ipv6
[net.ipv4.conf.et-wan.accept_local = 0
net.ipv4.conf.et-wan.accept_redirects = 1
net.ipv4.conf.et-wan.accept_source_route = 0
net.ipv4.conf.et-wan.arp_accept = 0
net.ipv4.conf.et-wan.arp_announce = 0
net.ipv4.conf.et-wan.arp_filter = 0
net.ipv4.conf.et-wan.arp_ignore = 0
net.ipv4.conf.et-wan.arp_notify = 0
net.ipv4.conf.et-wan.bc_forwarding = 0
net.ipv4.conf.et-wan.bootp_relay = 0
net.ipv4.conf.et-wan.disable_policy = 0
net.ipv4.conf.et-wan.disable_xfrm = 0
net.ipv4.conf.et-wan.drop_gratuitous_arp = 0
net.ipv4.conf.et-wan.drop_unicast_in_l2_multicast = 0
net.ipv4.conf.et-wan.force_igmp_version = 0
net.ipv4.conf.et-wan.forwarding = 1
net.ipv4.conf.et-wan.igmpv2_unsolicited_report_interval = 10000
net.ipv4.conf.et-wan.igmpv3_unsolicited_report_interval = 1000
net.ipv4.conf.et-wan.ignore_routes_with_linkdown = 0
net.ipv4.conf.et-wan.log_martians = 0
net.ipv4.conf.et-wan.mc_forwarding = 0
net.ipv4.conf.et-wan.medium_id = 0
net.ipv4.conf.et-wan.promote_secondaries = 0
net.ipv4.conf.et-wan.proxy_arp = 0
net.ipv4.conf.et-wan.proxy_arp_pvlan = 0
net.ipv4.conf.et-wan.route_localnet = 0
net.ipv4.conf.et-wan.rp_filter = 1
net.ipv4.conf.et-wan.secure_redirects = 1
net.ipv4.conf.et-wan.send_redirects = 1
net.ipv4.conf.et-wan.shared_media = 1
net.ipv4.conf.et-wan.src_valid_mark = 0
net.ipv4.conf.et-wan.tag = 0
net.ipv4.conf.et-wan/9.accept_local = 0
net.ipv4.conf.et-wan/9.accept_redirects = 1
net.ipv4.conf.et-wan/9.accept_source_route = 0
net.ipv4.conf.et-wan/9.arp_accept = 0
net.ipv4.conf.et-wan/9.arp_announce = 0
net.ipv4.conf.et-wan/9.arp_filter = 0
net.ipv4.conf.et-wan/9.arp_ignore = 0
net.ipv4.conf.et-wan/9.arp_notify = 0
net.ipv4.conf.et-wan/9.bc_forwarding = 0
net.ipv4.conf.et-wan/9.bootp_relay = 0
net.ipv4.conf.et-wan/9.disable_policy = 0
net.ipv4.conf.et-wan/9.disable_xfrm = 0
net.ipv4.conf.et-wan/9.drop_gratuitous_arp = 0
net.ipv4.conf.et-wan/9.drop_unicast_in_l2_multicast = 0
net.ipv4.conf.et-wan/9.force_igmp_version = 0
net.ipv4.conf.et-wan/9.forwarding = 1
net.ipv4.conf.et-wan/9.igmpv2_unsolicited_report_interval = 10000
net.ipv4.conf.et-wan/9.igmpv3_unsolicited_report_interval = 1000
net.ipv4.conf.et-wan/9.ignore_routes_with_linkdown = 0
net.ipv4.conf.et-wan/9.log_martians = 0
net.ipv4.conf.et-wan/9.mc_forwarding = 0
net.ipv4.conf.et-wan/9.medium_id = 0
net.ipv4.conf.et-wan/9.promote_secondaries = 0
net.ipv4.conf.et-wan/9.proxy_arp = 0
net.ipv4.conf.et-wan/9.proxy_arp_pvlan = 0
net.ipv4.conf.et-wan/9.route_localnet = 0
net.ipv4.conf.et-wan/9.rp_filter = 1
net.ipv4.conf.et-wan/9.secure_redirects = 1
net.ipv4.conf.et-wan/9.send_redirects = 1
net.ipv4.conf.et-wan/9.shared_media = 1
net.ipv4.conf.et-wan/9.src_valid_mark = 0
net.ipv4.conf.et-wan/9.tag = 0
net.ipv4.neigh.et-wan.anycast_delay = 100
net.ipv4.neigh.et-wan.app_solicit = 0
net.ipv4.neigh.et-wan.base_reachable_time_ms = 30000
net.ipv4.neigh.et-wan.delay_first_probe_time = 5
net.ipv4.neigh.et-wan.gc_stale_time = 60
net.ipv4.neigh.et-wan.locktime = 100
net.ipv4.neigh.et-wan.mcast_resolicit = 0
net.ipv4.neigh.et-wan.mcast_solicit = 3
net.ipv4.neigh.et-wan.proxy_delay = 80
net.ipv4.neigh.et-wan.proxy_qlen = 64
net.ipv4.neigh.et-wan.retrans_time_ms = 1000
net.ipv4.neigh.et-wan.ucast_solicit = 3
net.ipv4.neigh.et-wan.unres_qlen = 91
net.ipv4.neigh.et-wan.unres_qlen_bytes = 180224
net.ipv4.neigh.et-wan/9.anycast_delay = 100
net.ipv4.neigh.et-wan/9.app_solicit = 0
net.ipv4.neigh.et-wan/9.base_reachable_time_ms = 30000
net.ipv4.neigh.et-wan/9.delay_first_probe_time = 5
net.ipv4.neigh.et-wan/9.gc_stale_time = 60
net.ipv4.neigh.et-wan/9.locktime = 100
net.ipv4.neigh.et-wan/9.mcast_resolicit = 0
net.ipv4.neigh.et-wan/9.mcast_solicit = 3
net.ipv4.neigh.et-wan/9.proxy_delay = 80
net.ipv4.neigh.et-wan/9.proxy_qlen = 64
net.ipv4.neigh.et-wan/9.ucast_solicit = 3
net.ipv4.neigh.et-wan/9.unres_qlen = 91
net.ipv4.neigh.et-wan/9.unres_qlen_bytes = 180224
ansible@nanopir1-210:~$ 

Il manque donc qllq chose ...