Serveur qui ping que si il nous ping ?!?

Support Debian
#21

Hum, je pensais qu’avec --mac-source on y arrivait mais effectivement c’est logique, arp est traité en dessous de iptables et celui ci ne le voit pas.

#22

Je vois que j’ai à faire à des experts et ça me fait énormément plaisir que mon problème soit traité avec autant de détails qui font que j’apprends plein de choses grâce à vous.
Dès que possible je vous copie/colle toutes les infos voulu.
Merci encore :wink:

#23

Pour refaire simple

Le serveur de domaine, DHCP, DNS etc… sous windows 2003 server c’est : 172.16.43.142
Il n’y a aucun soucis avec tous les postes client (plusieurs XP et debian)

Seul le “serveurdebian” qui est le 172.16.43.161 se trouve invisible sur le réseau.

Sur le serveur win2003 j’ai purgé et nettoyer les cache DNS, j’ai rentré le DNS de type A pour 172.16.43.161 ainsi que son reverse DNS
Coté DHCP j’ai bien réservé l’ip 172.16.43.161 pour l’adresse MAC 00-e0-81-b1-04-58 avec les options

003 Router = 172.16.43.142 006 DNS Servers = 172.16.43.142 015 DNS Domain Name = mondomaine.local 040 NIS Domain Name = mondomaine.local 044 WINS/NBNS Servers = 172.16.43.142 046 WINS/NBT Node Type = 0x8

Mais bon, toutes les machines du réseau ont cette configuration.

Info sur mon serveurdebian 172.16.43.161

# ip addr 1: lo: <LOOPBACK,UP,LOWER_UP> mtu 16436 qdisc noqueue state UNKNOWN link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo 2: eth1: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP qlen 100 link/ether 00:e0:81:b1:04:58 brd ff:ff:ff:ff:ff:ff inet 172.16.43.161/24 brd 172.16.43.255 scope global eth1 3: eth2: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast state DOWN qlen 1000 link/ether 00:e0:81:b1:04:59 brd ff:ff:ff:ff:ff:ff 4: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UNKNOWN qlen 1000 link/ieee1394 00:e0:81:00:00:28:2f:57 brd ff:ff:ff:ff:ff:ff:ff:ff 5: sit0: <NOARP> mtu 1480 qdisc noop state DOWN link/sit 0.0.0.0 brd 0.0.0.0

# ip route 172.16.43.0/24 dev eth1 proto kernel scope link src 172.16.43.161 default via 172.16.43.142 dev eth1

# arp -n Address HWtype HWaddress Flags Mask Iface 172.16.43.142 ether 00:0E:0C:60:06:25 C eth1 172.16.43.155 ether 00:11:43:17:7E:CD C eth1 172.16.43.103 ether 00:30:F1:0D:84:BE C eth1

Ca confirme que eth0 est un port firewire.
Les 3 machines dans arp sont évidemment le serveur de domaine et les 2 autres machines sont les machines ou j’ai intégré ce serveurdebian dans la table arp (avec arp -s)

Info sur la machine de test 172.16.43.143

# ip addr 1: lo: <LOOPBACK,UP,10000> mtu 16436 qdisc noqueue link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00 inet 127.0.0.1/8 scope host lo inet6 ::1/128 scope host valid_lft forever preferred_lft forever 2: eth0: <BROADCAST,MULTICAST,UP,10000> mtu 1500 qdisc pfifo_fast qlen 1000 link/ether 00:05:5d:8c:00:60 brd ff:ff:ff:ff:ff:ff inet 172.16.43.143/24 brd 172.16.43.255 scope global eth0 inet6 fe80::205:5dff:fe8c:60/64 scope link valid_lft forever preferred_lft forever 3: sit0: <NOARP> mtu 1480 qdisc noop link/sit 0.0.0.0 brd 0.0.0.0

# ip route 172.16.43.0/24 dev eth0 proto kernel scope link src 172.16.43.143 default via 172.16.43.142 dev eth0

# arp -n Address HWtype HWaddress Flags Mask Iface 172.16.43.103 ether 00:30:F1:0D:84:BE C eth0 172.16.43.150 ether 00:1D:60:25:D6:2A C eth0 172.16.43.142 ether 00:0E:0C:60:06:25 C eth0

Passons au tcpdump, ping de 172.16.43.143 sur 172.16.43.161

Machine 172.16.43.143

[code]# ping 172.16.43.161
PING 172.16.43.161 (172.16.43.161) 56(84) bytes of data.
From 172.16.43.143 icmp_seq=1 Destination Host Unreachable
From 172.16.43.143 icmp_seq=2 Destination Host Unreachable
From 172.16.43.143 icmp_seq=3 Destination Host Unreachable
From 172.16.43.143 icmp_seq=4 Destination Host Unreachable
From 172.16.43.143 icmp_seq=5 Destination Host Unreachable
From 172.16.43.143 icmp_seq=6 Destination Host Unreachable
From 172.16.43.143 icmp_seq=7 Destination Host Unreachable
From 172.16.43.143 icmp_seq=8 Destination Host Unreachable
From 172.16.43.143 icmp_seq=9 Destination Host Unreachable

— 172.16.43.161 ping statistics —
10 packets transmitted, 0 received, +9 errors, 100% packet loss, time 9026ms, pipe 3[/code]

[code]# tcpdump -nei eth0 arp or icmp
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 96 bytes
08:32:33.991371 00:05:5d:8c:00:60 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: arp who-has 172.16.43.161 tell 172.16.43.143
08:32:34.991481 00:05:5d:8c:00:60 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: arp who-has 172.16.43.161 tell 172.16.43.143
08:32:35.991606 00:05:5d:8c:00:60 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: arp who-has 172.16.43.161 tell 172.16.43.143
08:32:36.999724 00:05:5d:8c:00:60 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: arp who-has 172.16.43.161 tell 172.16.43.143
08:32:37.999859 00:05:5d:8c:00:60 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: arp who-has 172.16.43.161 tell 172.16.43.143
08:32:38.999983 00:05:5d:8c:00:60 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: arp who-has 172.16.43.161 tell 172.16.43.143
08:32:40.008103 00:05:5d:8c:00:60 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: arp who-has 172.16.43.161 tell 172.16.43.143
08:32:41.008236 00:05:5d:8c:00:60 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: arp who-has 172.16.43.161 tell 172.16.43.143
08:32:42.008359 00:05:5d:8c:00:60 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: arp who-has 172.16.43.161 tell 172.16.43.143
08:32:43.016480 00:05:5d:8c:00:60 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: arp who-has 172.16.43.161 tell 172.16.43.143
08:32:44.016606 00:05:5d:8c:00:60 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: arp who-has 172.16.43.161 tell 172.16.43.143
08:32:45.016734 00:05:5d:8c:00:60 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: arp who-has 172.16.43.161 tell 172.16.43.143

12 packets captured
12 packets received by filter
0 packets dropped by kernel[/code]

Rien n’a bougé sur serveurdebian 172.16.43.161

Ping de 172.16.43.161 sur 172.16.43.143

Machine 172.16.43.161

# ping 172.16.43.143 PING 172.16.43.143 (172.16.43.143) 56(84) bytes of data. 64 bytes from 172.16.43.143: icmp_seq=1 ttl=64 time=4.49 ms 64 bytes from 172.16.43.143: icmp_seq=2 ttl=64 time=0.375 ms 64 bytes from 172.16.43.143: icmp_seq=3 ttl=64 time=0.370 ms 64 bytes from 172.16.43.143: icmp_seq=4 ttl=64 time=0.229 ms

08:35:19.926242 00:e0:81:b1:04:58 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: arp who-has 172.16.43.143 tell 172.16.43.161 08:35:19.926540 00:05:5d:8c:00:60 > 00:e0:81:b1:04:58, ethertype ARP (0x0806), length 60: arp reply 172.16.43.143 is-at 00:05:5d:8c:00:60 08:35:19.926553 00:e0:81:b1:04:58 > 00:05:5d:8c:00:60, ethertype IPv4 (0x0800), length 98: 172.16.43.161 > 172.16.43.143: ICMP echo request, id 36907, seq 1, length 64 08:35:19.926789 00:05:5d:8c:00:60 > 00:e0:81:b1:04:58, ethertype IPv4 (0x0800), length 98: 172.16.43.143 > 172.16.43.161: ICMP echo reply, id 36907, seq 1, length 64 08:35:20.922464 00:e0:81:b1:04:58 > 00:05:5d:8c:00:60, ethertype IPv4 (0x0800), length 98: 172.16.43.161 > 172.16.43.143: ICMP echo request, id 36907, seq 2, length 64 08:35:20.922761 00:05:5d:8c:00:60 > 00:e0:81:b1:04:58, ethertype IPv4 (0x0800), length 98: 172.16.43.143 > 172.16.43.161: ICMP echo reply, id 36907, seq 2, length 64 08:35:21.922550 00:e0:81:b1:04:58 > 00:05:5d:8c:00:60, ethertype IPv4 (0x0800), length 98: 172.16.43.161 > 172.16.43.143: ICMP echo request, id 36907, seq 3, length 64 08:35:21.922826 00:05:5d:8c:00:60 > 00:e0:81:b1:04:58, ethertype IPv4 (0x0800), length 98: 172.16.43.143 > 172.16.43.161: ICMP echo reply, id 36907, seq 3, length 64 08:35:22.922523 00:e0:81:b1:04:58 > 00:05:5d:8c:00:60, ethertype IPv4 (0x0800), length 98: 172.16.43.161 > 172.16.43.143: ICMP echo request, id 36907, seq 4, length 64 08:35:22.922730 00:05:5d:8c:00:60 > 00:e0:81:b1:04:58, ethertype IPv4 (0x0800), length 98: 172.16.43.143 > 172.16.43.161: ICMP echo reply, id 36907, seq 4, length 64 08:35:23.922601 00:e0:81:b1:04:58 > 00:05:5d:8c:00:60, ethertype IPv4 (0x0800), length 98: 172.16.43.161 > 172.16.43.143: ICMP echo request, id 36907, seq 5, length 64 08:35:23.922791 00:05:5d:8c:00:60 > 00:e0:81:b1:04:58, ethertype IPv4 (0x0800), length 98: 172.16.43.143 > 172.16.43.161: ICMP echo reply, id 36907, seq 5, length 64

Machine 172.16.43.143

08:35:19.694928 00:e0:81:b1:04:58 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: arp who-has 172.16.43.143 tell 172.16.43.161 08:35:19.695004 00:05:5d:8c:00:60 > 00:e0:81:b1:04:58, ethertype ARP (0x0806), length 42: arp reply 172.16.43.143 is-at 00:05:5d:8c:00:60 08:35:19.695218 00:e0:81:b1:04:58 > 00:05:5d:8c:00:60, ethertype IPv4 (0x0800), length 98: 172.16.43.161 > 172.16.43.143: ICMP echo request, id 36907, seq 1, length 64 08:35:19.695284 00:05:5d:8c:00:60 > 00:e0:81:b1:04:58, ethertype IPv4 (0x0800), length 98: 172.16.43.143 > 172.16.43.161: ICMP echo reply, id 36907, seq 1, length 64 08:35:20.691207 00:e0:81:b1:04:58 > 00:05:5d:8c:00:60, ethertype IPv4 (0x0800), length 98: 172.16.43.161 > 172.16.43.143: ICMP echo request, id 36907, seq 2, length 64 08:35:20.691280 00:05:5d:8c:00:60 > 00:e0:81:b1:04:58, ethertype IPv4 (0x0800), length 98: 172.16.43.143 > 172.16.43.161: ICMP echo reply, id 36907, seq 2, length 64 08:35:21.691293 00:e0:81:b1:04:58 > 00:05:5d:8c:00:60, ethertype IPv4 (0x0800), length 98: 172.16.43.161 > 172.16.43.143: ICMP echo request, id 36907, seq 3, length 64 08:35:21.691362 00:05:5d:8c:00:60 > 00:e0:81:b1:04:58, ethertype IPv4 (0x0800), length 98: 172.16.43.143 > 172.16.43.161: ICMP echo reply, id 36907, seq 3, length 64 08:35:22.691216 00:e0:81:b1:04:58 > 00:05:5d:8c:00:60, ethertype IPv4 (0x0800), length 98: 172.16.43.161 > 172.16.43.143: ICMP echo request, id 36907, seq 4, length 64 08:35:22.691285 00:05:5d:8c:00:60 > 00:e0:81:b1:04:58, ethertype IPv4 (0x0800), length 98: 172.16.43.143 > 172.16.43.161: ICMP echo reply, id 36907, seq 4, length 64 08:35:23.691291 00:e0:81:b1:04:58 > 00:05:5d:8c:00:60, ethertype IPv4 (0x0800), length 98: 172.16.43.161 > 172.16.43.143: ICMP echo request, id 36907, seq 5, length 64 08:35:23.691359 00:05:5d:8c:00:60 > 00:e0:81:b1:04:58, ethertype IPv4 (0x0800), length 98: 172.16.43.143 > 172.16.43.161: ICMP echo reply, id 36907, seq 5, length 64 08:35:24.692715 00:05:5d:8c:00:60 > 00:e0:81:b1:04:58, ethertype ARP (0x0806), length 42: arp who-has 172.16.43.161 tell 172.16.43.143 08:35:25.692839 00:05:5d:8c:00:60 > 00:e0:81:b1:04:58, ethertype ARP (0x0806), length 42: arp who-has 172.16.43.161 tell 172.16.43.143 08:35:26.692965 00:05:5d:8c:00:60 > 00:e0:81:b1:04:58, ethertype ARP (0x0806), length 42: arp who-has 172.16.43.161 tell 172.16.43.143

Je profite de ce ping pour repinguer dans l’autre sens de 172.16.43.143 vers 172.16.43.161

# arp -n Address HWtype HWaddress Flags Mask Iface 172.16.43.103 ether 00:30:F1:0D:84:BE C eth0 172.16.43.150 ether 00:1D:60:25:D6:2A C eth0 172.16.43.161 (incomplete) eth0

# ping 172.16.43.161 PING 172.16.43.161 (172.16.43.161) 56(84) bytes of data. 64 bytes from 172.16.43.161: icmp_seq=1 ttl=64 time=0.560 ms 64 bytes from 172.16.43.161: icmp_seq=2 ttl=64 time=0.285 ms 64 bytes from 172.16.43.161: icmp_seq=3 ttl=64 time=0.234 ms 64 bytes from 172.16.43.161: icmp_seq=4 ttl=64 time=0.266 ms

08:38:14.309094 00:e0:81:b1:04:58 > 00:05:5d:8c:00:60, ethertype ARP (0x0806), length 60: arp who-has 172.16.43.143 tell 172.16.43.161 08:38:14.309124 00:05:5d:8c:00:60 > 00:e0:81:b1:04:58, ethertype ARP (0x0806), length 42: arp reply 172.16.43.143 is-at 00:05:5d:8c:00:60 08:38:19.037513 00:05:5d:8c:00:60 > 00:e0:81:b1:04:58, ethertype IPv4 (0x0800), length 98: 172.16.43.143 > 172.16.43.161: ICMP echo request, id 16398, seq 1, length 64 08:38:19.037957 00:e0:81:b1:04:58 > 00:05:5d:8c:00:60, ethertype IPv4 (0x0800), length 98: 172.16.43.161 > 172.16.43.143: ICMP echo reply, id 16398, seq 1, length 64 08:38:20.036439 00:05:5d:8c:00:60 > 00:e0:81:b1:04:58, ethertype IPv4 (0x0800), length 98: 172.16.43.143 > 172.16.43.161: ICMP echo request, id 16398, seq 2, length 64 08:38:20.036685 00:e0:81:b1:04:58 > 00:05:5d:8c:00:60, ethertype IPv4 (0x0800), length 98: 172.16.43.161 > 172.16.43.143: ICMP echo reply, id 16398, seq 2, length 64 08:38:21.035441 00:05:5d:8c:00:60 > 00:e0:81:b1:04:58, ethertype IPv4 (0x0800), length 98: 172.16.43.143 > 172.16.43.161: ICMP echo request, id 16398, seq 3, length 64 08:38:21.035635 00:e0:81:b1:04:58 > 00:05:5d:8c:00:60, ethertype IPv4 (0x0800), length 98: 172.16.43.161 > 172.16.43.143: ICMP echo reply, id 16398, seq 3, length 64 08:38:21.859375 00:0e:0c:60:06:25 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: arp who-has 172.16.43.143 tell 172.16.43.142 08:38:21.859410 00:05:5d:8c:00:60 > 00:0e:0c:60:06:25, ethertype ARP (0x0806), length 42: arp reply 172.16.43.143 is-at 00:05:5d:8c:00:60 08:38:22.034941 00:05:5d:8c:00:60 > 00:e0:81:b1:04:58, ethertype IPv4 (0x0800), length 98: 172.16.43.143 > 172.16.43.161: ICMP echo request, id 16398, seq 4, length 64 08:38:22.035179 00:e0:81:b1:04:58 > 00:05:5d:8c:00:60, ethertype IPv4 (0x0800), length 98: 172.16.43.161 > 172.16.43.143: ICMP echo reply, id 16398, seq 4, length 64 08:38:23.035081 00:05:5d:8c:00:60 > 00:e0:81:b1:04:58, ethertype IPv4 (0x0800), length 98: 172.16.43.143 > 172.16.43.161: ICMP echo request, id 16398, seq 5, length 64 08:38:23.035288 00:e0:81:b1:04:58 > 00:05:5d:8c:00:60, ethertype IPv4 (0x0800), length 98: 172.16.43.161 > 172.16.43.143: ICMP echo reply, id 16398, seq 5, length 64 08:38:23.879014 00:11:43:17:7e:cd > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 60: arp who-has 172.16.43.201 tell 172.16.43.155

tcpdump de 172.16.43.161

08:38:14.540495 00:e0:81:b1:04:58 > 00:05:5d:8c:00:60, ethertype ARP (0x0806), length 42: arp who-has 172.16.43.143 tell 172.16.43.161 08:38:14.540680 00:05:5d:8c:00:60 > 00:e0:81:b1:04:58, ethertype ARP (0x0806), length 60: arp reply 172.16.43.143 is-at 00:05:5d:8c:00:60 08:38:19.269157 00:05:5d:8c:00:60 > 00:e0:81:b1:04:58, ethertype IPv4 (0x0800), length 98: 172.16.43.143 > 172.16.43.161: ICMP echo request, id 16398, seq 1, length 64 08:38:19.269358 00:e0:81:b1:04:58 > 00:05:5d:8c:00:60, ethertype IPv4 (0x0800), length 98: 172.16.43.161 > 172.16.43.143: ICMP echo reply, id 16398, seq 1, length 64 08:38:20.268062 00:05:5d:8c:00:60 > 00:e0:81:b1:04:58, ethertype IPv4 (0x0800), length 98: 172.16.43.143 > 172.16.43.161: ICMP echo request, id 16398, seq 2, length 64 08:38:20.268098 00:e0:81:b1:04:58 > 00:05:5d:8c:00:60, ethertype IPv4 (0x0800), length 98: 172.16.43.161 > 172.16.43.143: ICMP echo reply, id 16398, seq 2, length 64 08:38:21.267000 00:05:5d:8c:00:60 > 00:e0:81:b1:04:58, ethertype IPv4 (0x0800), length 98: 172.16.43.143 > 172.16.43.161: ICMP echo request, id 16398, seq 3, length 64 08:38:21.267047 00:e0:81:b1:04:58 > 00:05:5d:8c:00:60, ethertype IPv4 (0x0800), length 98: 172.16.43.161 > 172.16.43.143: ICMP echo reply, id 16398, seq 3, length 64 08:38:22.266556 00:05:5d:8c:00:60 > 00:e0:81:b1:04:58, ethertype IPv4 (0x0800), length 98: 172.16.43.143 > 172.16.43.161: ICMP echo request, id 16398, seq 4, length 64 08:38:22.266593 00:e0:81:b1:04:58 > 00:05:5d:8c:00:60, ethertype IPv4 (0x0800), length 98: 172.16.43.161 > 172.16.43.143: ICMP echo reply, id 16398, seq 4, length 64 08:38:23.266622 00:05:5d:8c:00:60 > 00:e0:81:b1:04:58, ethertype IPv4 (0x0800), length 98: 172.16.43.143 > 172.16.43.161: ICMP echo request, id 16398, seq 5, length 64 08:38:23.266698 00:e0:81:b1:04:58 > 00:05:5d:8c:00:60, ethertype IPv4 (0x0800), length 98: 172.16.43.161 > 172.16.43.143: ICMP echo reply, id 16398, seq 5, length 64

et après ca recommence

[code]# ping 172.16.43.161
PING 172.16.43.161 (172.16.43.161) 56(84) bytes of data.
From 172.16.43.143 icmp_seq=1 Destination Host Unreachable
From 172.16.43.143 icmp_seq=2 Destination Host Unreachable
From 172.16.43.143 icmp_seq=3 Destination Host Unreachable

— 172.16.43.161 ping statistics —
4 packets transmitted, 0 received, +3 errors, 100% packet loss, time 3008ms, pipe 3[/code]

# arp -n Address HWtype HWaddress Flags Mask Iface 172.16.43.150 ether 00:1D:60:25:D6:2A C eth0 172.16.43.161 (incomplete) eth0
Pour info, iptable n’est pas utilisé, il n’y a d’ailleurs aucun firewall sur les machines.
C’est vraiment un truc de ouf :astonished:

#24

“Rien n’a bougé sur serveurdebian 172.16.43.161”, ça veut dire que tcpdump n’a rien vu passer ?

A première vue, j’ai l’impression que serveurdebian ne reçoit pas les requêtes ARP. Il envoie les requêtes ARP et reçoit les réponses ARP en revanche. Je me suis demandé si ça pouvait être lié à un problème de réception de broadcast ethernet (les requêtes ARP sont généralement émises en broadcast), mais d’une part en épluchant les traces précédentes j’ai vu que la machine recevait des broadcast Netbios

et d’autre part elle ne voit pas non plus les requêtes ARP envoyées à son adresse MAC unicast :

08:35:25.692839 00:05:5d:8c:00:60 > 00:e0:81:b1:04:58, ethertype ARP (0x0806), length 42: arp who-has 172.16.43.161 tell 172.16.43.143 08:35:26.692965 00:05:5d:8c:00:60 > 00:e0:81:b1:04:58, ethertype ARP (0x0806), length 42: arp who-has 172.16.43.161 tell 172.16.43.143
ne se retrouvent pas côté serveur et restent sans réponse.

Pour éliminer définitivement l’hypothèse du broadcast, il suffit d’envoyer un ping broadcast, qui ne requiert pas de résolution ARP, depuis la machine de test et de faire une capture sur le serveur pour voir s’il est reçu.

Peu importe que le serveur y réponde ou pas. Par défaut les noyaux Linux “récents” ignorent les pings broadcast.

En tout cas je ne vois guère que deux causes possibles du problème : un bug dans le switch ethernet ou dans le contrôleur ethernet du serveur ou son pilote. Pour info, quel est le type de contrôleur et la version du noyau (des fois que ce soit un bug connu) ?

#25

Je pencherais plus sur le switch, car même dans le cas où le serveur répondrait mal à la reque, tcpdump la montrerait. En fait si c’est possible, j’essayerais deux choses:

  1. extinction et rallumage du switch
  2. si ça ne marche pas, chgmt de port où est connecté le serveur sur le switch.
#26

ok, alors j’ai lancé le ping du broadcast à partir de la machine de test (172.16.43.143)

Le tcpdump du serveurdebian (172.16.43.161) a donné ca

18:38:37.930426 00:05:5d:8c:00:60 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800),length 98: 172.16.43.143 > 172.16.43.255: ICMP echo request, id 13071, seq 1, length 64 18:38:37.935301 00:e0:81:b1:04:58 > ff:ff:ff:ff:ff:ff, ethertype ARP (0x0806), length 42: arp who-has 172.16.43.143 tell 172.16.43.161 18:38:37.935425 00:05:5d:8c:00:60 > 00:e0:81:b1:04:58, ethertype ARP (0x0806), length 60: arp reply 172.16.43.143 is-at 00:05:5d:8c:00:60 18:38:37.935430 00:e0:81:b1:04:58 > 00:05:5d:8c:00:60, ethertype IPv4 (0x0800),length 98: 172.16.43.161 > 172.16.43.143: ICMP echo reply, id 13071, seq 1, length 64 18:38:38.931360 00:05:5d:8c:00:60 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800),length 98: 172.16.43.143 > 172.16.43.255: ICMP echo request, id 13071, seq 2, length 64 18:38:38.931366 00:e0:81:b1:04:58 > 00:05:5d:8c:00:60, ethertype IPv4 (0x0800),length 98: 172.16.43.161 > 172.16.43.143: ICMP echo reply, id 13071, seq 2, length 64 18:38:39.931419 00:05:5d:8c:00:60 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800),length 98: 172.16.43.143 > 172.16.43.255: ICMP echo request, id 13071, seq 3, length 64 18:38:39.931425 00:e0:81:b1:04:58 > 00:05:5d:8c:00:60, ethertype IPv4 (0x0800),length 98: 172.16.43.161 > 172.16.43.143: ICMP echo reply, id 13071, seq 3, length 64

Juste après, la machine test réussissait à pinguer serveurdebian et la table arp était correct

# arp -n Address HWtype HWaddress Flags Mask Iface 172.16.43.142 ether 00:0E:0C:60:06:25 C eth0 172.16.43.154 ether 00:12:3F:3C:04:03 C eth0 172.16.43.161 ether 00:E0:81:B1:04:58 C eth0 172.16.43.103 ether 00:30:F1:0D:84:BE C eth0

Le temps d’écrire ce message et POUF !

[root@machine de test:~]# arp -n Address HWtype HWaddress Flags Mask Iface 172.16.43.154 ether 00:12:3F:3C:04:03 C eth0 [root@machine de test:~]# ping teracpc8 PING teracpc8.airaps.local (172.16.43.161) 56(84) bytes of data. From 172.16.43.143 icmp_seq=1 Destination Host Unreachable From 172.16.43.143 icmp_seq=2 Destination Host Unreachable

De nouveau impossible de pinguer et aucun message n’apparait sur tcpdump sur serveurdebian.

Le serveurdebian a ce noyau

# uname -a Linux teracpc8 2.6.18-6-amd64 #1 SMP Tue Aug 19 04:30:56 UTC 2008 x86_64 GNU/Linux
et à comme controleur ethernet

# lspci | grep Ethernet 0f:00.0 Ethernet controller: Intel Corporation 80003ES2LAN Gigabit Ethernet Controller (Copper) (rev 01) 0f:00.1 Ethernet controller: Intel Corporation 80003ES2LAN Gigabit Ethernet Controller (Copper) (rev 01)

Dès lundi je tenterai de connecter ce PC sur un autre port du hub (ou switch je ne sais plus)
En attendant je vous souhaites à tous un bon week-end :wink:

#27

Je pensais plutôt au cas où l’interface (au sens large, le contrôleur ou son pilote) “avalerait” ces paquets sans les transmettre à la couche supérieure, donc même tcpdump ne les verrait pas.

edmc73 :
Le fait que tcpdump sur le serveur voie bien les pings broadcast entrants confirme que le problème n’est pas lié à la réception des trames broadcast ethernet.

2.6.18, c’est un peu vieux. Si la machine est encore en etch, tu aurais la possibilité de tester avec un noyau 2.6.24 etchnhalf plus récent ?

Quel est le module pilote qui gère ces interfaces ethernet ? e1000 (cf. dmesg, lsmod) ?
Pour lspci je suggère d’ajouter l’option -nn qui affiche en plus les identifiants PCI numériques.

#28

Désolé je vais faire un peu de remplissage, mais c’est pour la bonne cause j’espère :slightly_smiling:

lspci -nn

00:00.0 Host bridge [0600]: Intel Corporation 5400 Chipset Memory Controller Hub [8086:4001] (rev 20)
00:01.0 PCI bridge [0604]: Intel Corporation 5400 Chipset PCI Express Port 1 [8086:4021] (rev 20)
00:05.0 PCI bridge [0604]: Intel Corporation 5400 Chipset PCI Express Port 5 [8086:4025] (rev 20)
00:09.0 PCI bridge [0604]: Intel Corporation 5400 Chipset PCI Express Port 9 [8086:4029] (rev 20)
00:10.0 Host bridge [0600]: Intel Corporation 5400 Chipset FSB Registers [8086:4030] (rev 20)
00:10.1 Host bridge [0600]: Intel Corporation 5400 Chipset FSB Registers [8086:4030] (rev 20)
00:10.2 Host bridge [0600]: Intel Corporation 5400 Chipset FSB Registers [8086:4030] (rev 20)
00:10.3 Host bridge [0600]: Intel Corporation 5400 Chipset FSB Registers [8086:4030] (rev 20)
00:10.4 Host bridge [0600]: Intel Corporation 5400 Chipset FSB Registers [8086:4030] (rev 20)
00:11.0 Host bridge [0600]: Intel Corporation 5400 Chipset CE/SF Registers [8086:4031] (rev 20)
00:15.0 Host bridge [0600]: Intel Corporation 5400 Chipset FBD Registers [8086:4035] (rev 20)
00:15.1 Host bridge [0600]: Intel Corporation 5400 Chipset FBD Registers [8086:4035] (rev 20)
00:16.0 Host bridge [0600]: Intel Corporation 5400 Chipset FBD Registers [8086:4036] (rev 20)
00:16.1 Host bridge [0600]: Intel Corporation 5400 Chipset FBD Registers [8086:4036] (rev 20)
00:1b.0 Audio device [0403]: Intel Corporation 631xESB/632xESB High Definition Audio Controller [8086:269a] (rev 09)
00:1c.0 PCI bridge [0604]: Intel Corporation 631xESB/632xESB/3100 Chipset PCI Express Root Port 1 [8086:2690] (rev 09)
00:1d.0 USB Controller [0c03]: Intel Corporation 631xESB/632xESB/3100 Chipset UHCI USB Controller #1 [8086:2688] (rev 09)
00:1d.1 USB Controller [0c03]: Intel Corporation 631xESB/632xESB/3100 Chipset UHCI USB Controller #2 [8086:2689] (rev 09)
00:1d.2 USB Controller [0c03]: Intel Corporation 631xESB/632xESB/3100 Chipset UHCI USB Controller #3 [8086:268a] (rev 09)
00:1d.3 USB Controller [0c03]: Intel Corporation 631xESB/632xESB/3100 Chipset UHCI USB Controller #4 [8086:268b] (rev 09)
00:1d.7 USB Controller [0c03]: Intel Corporation 631xESB/632xESB/3100 Chipset EHCI USB2 Controller [8086:268c] (rev 09)
00:1e.0 PCI bridge [0604]: Intel Corporation 82801 PCI Bridge [8086:244e] (rev d9)
00:1f.0 ISA bridge [0601]: Intel Corporation 631xESB/632xESB/3100 Chipset LPC Interface Controller [8086:2670] (rev 09)
00:1f.1 IDE interface [0101]: Intel Corporation 631xESB/632xESB IDE Controller [8086:269e] (rev 09)
00:1f.2 IDE interface [0101]: Intel Corporation 631xESB/632xESB/3100 Chipset SATA IDE Controller [8086:2680] (rev 09)
00:1f.3 SMBus [0c05]: Intel Corporation 631xESB/632xESB/3100 Chipset SMBus Controller [8086:269b] (rev 09)
09:00.0 PCI bridge [0604]: Intel Corporation 6311ESB/6321ESB PCI Express Upstream Port [8086:3500] (rev 01)
09:00.3 PCI bridge [0604]: Intel Corporation 6311ESB/6321ESB PCI Express to PCI-X Bridge [8086:350c] (rev 01)
0a:00.0 PCI bridge [0604]: Intel Corporation 6311ESB/6321ESB PCI Express Downstream Port E1 [8086:3510] (rev 01)
0a:02.0 PCI bridge [0604]: Intel Corporation 6311ESB/6321ESB PCI Express Downstream Port E3 [8086:3518] (rev 01)
0b:00.0 PCI bridge [0604]: Intel Corporation 80333 Segment-A PCI Express-to-PCI Express Bridge [8086:0370]
0b:00.2 PCI bridge [0604]: Intel Corporation 80333 Segment-B PCI Express-to-PCI Express Bridge [8086:0372]
0c:0e.0 RAID bus controller [0104]: Adaptec AAC-RAID [9005:0285]
0f:00.0 Ethernet controller [0200]: Intel Corporation 80003ES2LAN Gigabit Ethernet Controller (Copper) [8086:1096] (rev 01)
0f:00.1 Ethernet controller [0200]: Intel Corporation 80003ES2LAN Gigabit Ethernet Controller (Copper) [8086:1096] (rev 01)
20:04.0 VGA compatible controller [0300]: S3 Inc. ViRGE/DX or /GX [5333:8a01] (rev 01)
20:05.0 FireWire (IEEE 1394) [0c00]: Texas Instruments TSB43AB22/A IEEE-1394a-2000 Controller (PHY/Link) [104c:8023]

lsmod

lsmod Module Size Used by snd_seq_dummy 8580 0 snd_seq_oss 37248 0 snd_seq_midi 13632 0 snd_rawmidi 31392 1 snd_seq_midi snd_seq_midi_event 12544 2 snd_seq_oss,snd_seq_midi snd_seq 59520 6 snd_seq_dummy,snd_seq_oss,snd_seq_midi,snd_seq_midi_event snd_seq_device 13204 5 snd_seq_dummy,snd_seq_oss,snd_seq_midi,snd_rawmidi,snd_seq binfmt_misc 17292 1 rfcomm 48040 2 l2cap 32512 9 rfcomm bluetooth 61572 4 rfcomm,l2cap ppdev 14088 0 lp 17736 0 ipv6 286048 34 video 22664 0 button 12192 0 ac 10376 0 battery 15496 0 speedstep_centrino 12448 5 cpufreq_userspace 9856 0 cpufreq_conservative 12808 0 cpufreq_stats 10656 0 freq_table 9728 2 speedstep_centrino,cpufreq_stats cpufreq_ondemand 11920 4 cpufreq_powersave 6400 0 dm_snapshot 20664 0 dm_mirror 25216 0 dm_mod 62800 2 dm_snapshot,dm_mirror w83627ehf 20108 0 i2c_isa 10752 1 w83627ehf eeprom 12560 0 sbp2 28680 0 loop 20112 0 snd_hda_intel 23708 1 snd_hda_codec 184192 1 snd_hda_intel snd_pcm_oss 48672 0 snd_mixer_oss 21888 1 snd_pcm_oss snd_pcm 89096 3 snd_hda_intel,snd_hda_codec,snd_pcm_oss snd_timer 29192 2 snd_seq,snd_pcm snd 65256 12 snd_seq_oss,snd_rawmidi,snd_seq,snd_seq_device,snd_hda_intel,snd_hda_codec,snd_pcm_oss,snd_mixer_oss,snd_pcm,snd_timer parport_pc 41640 1 psmouse 44432 0 soundcore 15392 1 snd parport 44684 3 ppdev,lp,parport_pc floppy 67112 0 serio_raw 12036 0 i2c_i801 13076 0 snd_page_alloc 15504 2 snd_hda_intel,snd_pcm i2c_core 27776 4 w83627ehf,i2c_isa,eeprom,i2c_i801 shpchp 42156 0 pci_hotplug 20872 1 shpchp pcspkr 7808 0 tsdev 13056 0 evdev 15360 1 eth1394 24840 0 ext3 138512 2 jbd 65392 1 ext3 mbcache 14216 1 ext3 ide_generic 5760 0 [permanent] ide_cd 45088 0 cdrom 40488 1 ide_cd sd_mod 25856 4 generic 10500 0 [permanent] usbhid 45088 0 ata_piix 20360 0 aacraid 63616 3 piix 15492 0 [permanent] ohci1394 38216 0 libata 106784 1 ata_piix ieee1394 361976 3 sbp2,eth1394,ohci1394 ehci_hcd 36104 0 scsi_mod 153008 4 sbp2,sd_mod,aacraid,libata ide_core 147584 4 ide_generic,ide_cd,generic,piix e1000 124352 0 uhci_hcd 28696 0 thermal 20240 0 processor 38248 2 speedstep_centrino,thermal fan 9864 0

dmesg

Bootdata ok (command line is auto BOOT_IMAGE=2.6.18-6-amd64 ro root=801) Linux version 2.6.18-6-amd64 (Debian 2.6.18.dfsg.1-22etch2) (dannf@debian.org) (gcc version 4.1.2 20061115 (prerelease) (Debian 4.1.1-21)) #1 SMP Tue Aug 19 04:30:56 UTC 2008 ... Memory: 8170344k/9437184k available (1928k kernel code, 216672k reserved, 867k data, 176k init) ... Intel(R) Xeon(R) CPU E5430 @ 2.66GHz stepping 06 Brought up 8 CPUs ... e1000: eth1: e1000_watchdog: NIC Link is Up 100 Mbps Full Duplex e1000: eth1: e1000_watchdog: 10/100 speed: disabling TSO ACPI: Power Button (FF) [PWRF] ACPI: Power Button (CM) [PWRB] NET: Registered protocol family 10 lo: Disabled Privacy Extensions IPv6 over IPv4 tunneling driver lp0: using parport0 (interrupt-driven). ppdev: user-space parallel port driver eth1: no IPv6 routers present Bluetooth: Core ver 2.10 NET: Registered protocol family 31 ... ADDRCONF(NETDEV_UP): eth2: link is not ready mtrr: type mismatch for d8000000,400000 old: uncachable new: write-combining eth1: no IPv6 routers present device eth1 entered promiscuous mode audit(1236937967.214:2): dev=eth1 prom=256 old_prom=0 auid=4294967295 device eth2 entered promiscuous mode audit(1236937967.214:3): dev=eth2 prom=256 old_prom=0 auid=4294967295 device eth0 entered promiscuous mode audit(1236937967.214:4): dev=eth0 prom=256 old_prom=0 auid=4294967295 device eth1 left promiscuous mode audit(1236938039.783:5): dev=eth1 prom=0 old_prom=256 auid=4294967295 device eth2 left promiscuous mode audit(1236938039.783:6): dev=eth2 prom=0 old_prom=256 auid=4294967295 device eth0 left promiscuous mode audit(1236938039.783:7): dev=eth0 prom=0 old_prom=256 auid=4294967295 device eth1 entered promiscuous mode audit(1236938402.070:8): dev=eth1 prom=256 old_prom=0 auid=4294967295 device eth2 entered promiscuous mode audit(1236938402.070:9): dev=eth2 prom=256 old_prom=0 auid=4294967295 device eth0 entered promiscuous mode audit(1236938402.070:10): dev=eth0 prom=256 old_prom=0 auid=4294967295 device eth1 left promiscuous mode audit(1236938414.279:11): dev=eth1 prom=0 old_prom=256 auid=4294967295 device eth2 left promiscuous mode audit(1236938414.279:12): dev=eth2 prom=0 old_prom=256 auid=4294967295 device eth0 left promiscuous mode audit(1236938414.279:13): dev=eth0 prom=0 old_prom=256 auid=4294967295 udevd version 125 started ADDRCONF(NETDEV_UP): eth2: link is not ready ADDRCONF(NETDEV_UP): eth1: link is not ready e1000: eth1: e1000_watchdog: NIC Link is Up 100 Mbps Full Duplex e1000: eth1: e1000_watchdog: 10/100 speed: disabling TSO ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready eth1: no IPv6 routers present ADDRCONF(NETDEV_UP): eth2: link is not ready ADDRCONF(NETDEV_UP): eth1: link is not ready e1000: eth1: e1000_watchdog: NIC Link is Up 100 Mbps Full Duplex e1000: eth1: e1000_watchdog: 10/100 speed: disabling TSO ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready eth1: no IPv6 routers present device eth1 entered promiscuous mode audit(1236950600.873:14): dev=eth1 prom=256 old_prom=0 auid=4294967295 device eth2 entered promiscuous mode audit(1236950600.873:15): dev=eth2 prom=256 old_prom=0 auid=4294967295 device eth0 entered promiscuous mode ... [[[ Répété au moins 100 fois !!! ]]] ... audit(1237466220.230:65): dev=eth1 prom=0 old_prom=256 auid=4294967295 device eth1 entered promiscuous mode audit(1237466245.953:66): dev=eth1 prom=256 old_prom=0 auid=4294967295 device eth1 left promiscuous mode audit(1237466278.577:67): dev=eth1 prom=0 old_prom=256 auid=4294967295 BUG: warning at kernel/cpu.c:51/unlock_cpu_hotplug() e1000: eth1: e1000_watchdog: NIC Link is Down e1000: eth1: e1000_watchdog: NIC Link is Up 100 Mbps Full Duplex e1000: eth1: e1000_watchdog: 10/100 speed: disabling TSO ADDRCONF(NETDEV_CHANGE): eth1: link becomes ready eth1: no IPv6 routers present

Ensuite, question bête mais comment mettre à jour le noyau, j’ai toujours eu du mal avec ca.
Sous ubuntu ca se fait tout seul mais sous debian je rame un peu…

Dans aptitude j’ai le paquet linux-image-2.6.18-6-amd64 d’installé
Je vois qu’il y a le paquet linux-image-2.6.26-1-amd64
Pourquoi il ne se met pas à jour tout seul ? Bref une petite aide serait la bienvenue :wink:

PS: j’ai changé de port sur le switch, rien n’a changé.

#29

Chez moi les messages du type

device eth1 entered promiscuous mode audit(1236937967.214:2): dev=eth1 prom=256 old_prom=0 auid=4294967295
se produisent à chaque fois que j’exécute tcpdump, donc a priori je dirais qu’ils sont normaux. Sauf pour le nombre, tu n’as quand même pas exécuté tcpdump des centaines de fois ?

Dans le noyau 2.6.18 qui tourne sur ce serveur le contrôleur ethernet 80003ES2LAN est géré par le module e1000. En jetant un coup d’oeil aux sources du module, on voit d’une part que les contrôleurs pris en charge par ce module peuvent “décharger” (offload) la pile TCP/IP du système de certaines opérations comme la gestion d’ARP et notamment intercepter (tiens tiens) les paquets ARP (je ne sais pas si c’est le cas du 80003ES2LAN), et d’autre part que des bouts de code relatifs à ces capacités sont assortis d’un commentaire indiquant qu’ils sont incorrects pour PCI-express.

A partir du noyau 2.6.25, les contrôleurs ethernet sur bus PCI-express comme le 80003ES2LAN qui étaient gérés par le module e1000 sont désormais gérés par le nouveau module e1000e, le module e1000 ne gérant plus que les contrôleurs sur bus PCI. Et je vois dans les changelogs des noyaux 2.6.25 et 2.6.26 deux correctifs concernant des paquets ARP perdus avec le module e1000e. Donc je pense que ça vaudrait le coup de tester avec un noyau 2.6.26.

Le noyau 2.6.18 qui tourne vient de l’ancienne Debian stable, etch. Si la machine a été mise à niveau en lenny, le processus de mise à niveau peut avoir installé un nouveau noyau 2.6.26 en plus du noyau existant, sans le remplacer car ce n’est pas une nouvelle version du même paquet mais un paquet différent. Une nouvelle version de noyau n’est installée automatiquement lors de la mise à jour de la distribution que si un pseudo-paquet linux-image qui dépend de la dernière version de noyau binaire est installé. Exemple : linux-image-2.6-amd64 dépendait de linux-image-2.6.18-6-amd64 dans etch et dépend de linux-image-2.6.26-1-amd64 dans lenny. Bien sûr il faut redémarrer la machine pour que le nouveau noyau soit actif.

Si la machine n’a pas été mise a niveau en lenny, il y a trois possibilités :

  1. Mettre à niveau en lenny et installer le noyau 2.6.26.
  2. Installer le noyau 2.6.24 etchnhalf d’etch en espérant qu’il corrige le problème, mais je n’ai pas su trouver de correctif à ce sujet dans les changelogs du noyau entre les versions 2.6.18 et 2.6.24.
  3. Installer le noyau 2.6.26 du dépôt etch-backports, mais les paquets backportés peuvent causer des problèmes lors de la mise à niveau de Debian.
#30

Mince, ce serais donc comme tu le suggérais le pilote qui bouffe quelques paquets arp… Ici ce serait en fait toutes les requêtes arp, c’est un gros bug ça…

#31

Bon alors j’ai installé le paquet linux-image-2.6.26-1-amd64 via aptitude, ensuite j’ai modifié mon /etc/lilo.conf puis lancé un lilo.
Et lorsque je démarre le pc sur ce noyau, j’obtiens un joli kernel panic…

RAMDISK: Couldn't find valid RAM disk image starting at 0. List of all partitions: No filesystem could mount root, tried: Kernel panic - not syncing: VFS: Unable to mount root fs on unknown-block(0,1)

Pourtant mon lilo.conf a l’air correct.

[code]boot="/dev/sda"
lba32
prompt
timeout="100"
root=/dev/sda1
default=2.6.26-1-amd64

image="/boot/vmlinuz-2.6.26-1-amd64"
label=“2.6.26-1-amd64"
root=”/dev/sda1"
read-only
initrd="/boot/initrd.img-2.6.26-1-amd64"

image="/boot/vmlinuz-2.6.18-6-amd64"
label=“2.6.18-6-amd64"
root=”/dev/sda1"
read-only
initrd="/boot/initrd.img-2.6.18-6-amd64"

[/code]

Et la, j’ai bien peur du pire…

#32

Pas de panique, normalement tu peux toujours démarrer avec l’ancien noyau en appuyant sur la touche shift lors de l’affichage de “LILO” au démarrage pour faire apparaître le menu de lilo.

L’erreur avec le nouveau noyau provient peut-être de ceci : <http://www.fr.debian.org/releases/stable/amd64/release-notes/ch-upgrading.fr.html#prepare-initramfs>.

En résumé : initramfs trop gros pour lilo. Solutions suggérées : utiliser grub ou générer un initramfs minimal. Dans ce dernier cas, la modification indiquée dans la page ne suffit pas, il faut ensuite regénérer l’initramfs (et exécuter lilo comme d’hab). Pour la régénération, j’avoue mon incompétence totale car je compile mes noyaux sans initramfs (trop compliqué pour moi). Solution bourrin (je suppose) : forcer la réinstallation ou la reconfiguration du nouveau noyau.

#33

Comme tu peux le voir dans mon lilo.conf, je peux démarrer sur mon ancien noyau sans problème :wink:

En fait j’avais mis lilo car grub ne marchait pas sur ma machine, peut-être que c’est dû au RAID 5 matériel qui est de 2 To je ne sais pas vraiment.

Ce qui me fait peur c’est de devoir modifier plein de chose qui feront qu’au final plus rien ne marchera et que je devrais tout réinstallé de A à Z…

Je préfère encore me contenter de remplir la table arp sur les machines qui doivent accéder à ce serveur, c’est ce qui me parait être la solution la plus rapide en terme de temps.

#34

Si tu dois garder lilo, alors il reste la possibilité de générer un initramfs minimal pour le noyau 2.6.26 comme indiqué. De toute façon, indépendamment de ce bug, dans un an le suivi de sécurité pour le noyau 2.6.18 d’etch s’arrêtera, donc il faudra bien le remplacer.

#35

Bon alors j’ai modifié mon fichier /etc/initramfs-tools/initramfs.conf
J’ai changé
MODULES=most
par
MODULES=dep

et aussi
DEVICE=eth0
par
DEVICE=eth1

(ptete ca qui faisait tout foirer depuis le départ ??)

ensuite j’ai lancé par instinct la commande

# update-initramfs -u update-initramfs: Generating /boot/initrd.img-2.6.26-1-amd64 Added 2.6.26-1-amd64 * Added 2.6.18-6-amd64

La commande lilo dans le doute…
et je reboot !

Suspense… Plus de Kernel Panic !!!
Je file vers mes 2 machines de test, je lance un ping et Ô miracle ca marche !!!

C’était donc bien un bug…
Je vais m’assurer que tout fonctionne bien avant de crier victoire, et je reviendrai mettre en “résolu” :wink:

#36

Par contre, en changeant de noyau, est-ce que je suis passé de etch à lenny ?
Dois-je faire un changement mes sources apt ? et faire un aptitude upgrade ?
Questions bêtes mais j’ai toujours du mal avec ces mises à jours… :blush:

#37

Non, la distribution utilisée, si elle se caractérise par quelque chose est caractérisée par la libc6.
Le noyau lui doit se contenter d’être compatible.
SI tu prends le noyau standard, il y a un noyau par distribution qui bénéficie de mise à jour mais utiliser ce noyau n’est pas une obligation.

J’ai longtemps été sous Etch avec un 2.6.27.

Bilan: Pascal avait donc raison et c’était un bug du e1000 qui bouffait des paquets arp. Je n’avais jamais vu comme bug…

#38

Je ne pense pas que l’option DEVICE= de initramfs.conf ait un rapport avec ton problème. Il me semble que cette option est utilisée lorsque la racine est un volume réseau NFS.

Non, tu n’as pas changé de version de Debian juste en changeant de noyau. Si tu as pu installer un noyau 2.6.26 qui fait partie de lenny simplement avec apt-get, aptitude ou équivalent, c’est que tu avais déjà configuré /etc/apt/sources.list avec les dépôts de lenny. Tu peux vérifier la version de Debian dans le fichier /etc/debian_version.

fran.b :
Non, je n’avais pas raison ; j’ai juste émis une hypothèse (parmi d’autres) qui s’est apparemment révélée correcte, c’est tout. Moi non plus je n’avais jamais vu ce genre de bug, mais je n’ai jamais utilisé non plus de carte ethernet “intelligente” qui prend en charge des fonction au-dessus de la couche liaison comme la segmentation TCP ou l’ARP à la place de l’OS. Une carte “bête” qui ne fait que le minimum, à savoir envoyer et recevoir des paquets, a forcément moins de chances de déconner.

#39

Tu crois que je devrais dire ça à mes élèves :slightly_smiling:

#40

Bon, et bien ça à l’air de tourner sans problème.
Merci à vous, je saurais ou aller la prochaine que j’aurai un problème :wink:
a+