J'écris sur ce forum afin de tenter de résoudre un mystérieux problème
que je rencontre actuellement afin de faire fonctionner correctement mon
réseau wifi installé chez moi sur ma box Linux (j'ai tenté d'inclure le
maximum d'informations dans ce post :p)
Tout d'abord un peu d'informations sur la config ;)
Distrib: Debian testing
Kernel: 2.6.8-2-386
Box: Asus Pundit-R avec un lecteur de carte PCMCIA
Carte wifi: D-Link, avec un chipset Atheros (802.11g)
Driver: Madwifi (CVS)
Routeur: Linksys WRT54GS (firmware DD-WRT v22)
Authentification: WPA avec clé pré-partagée
WPA Supplicant: 0.4.3
madwifi et wpa_supplicant ont été compilé/installé à la main
La config de wpa_supplicant est la suivante et semble fonctionner
correctement:
network={
ssid="Figaro"
key_mgmt=WPA-PSK
psk="secret"
pairwise=TKIP
group=TKIP
proto=WPA
ca_cert="/root/cacert-wifi.crt"
priority=10
}
Lorsque je le lance à la main:
sudo wpa_supplicant -w -t -d -c/etc/wpa_supplicant.conf -iath0 ifup ath0
-Dmadwif
J'ai bien un message me disant que la connexion est établie:
Aug 22 11:58:34.231062: CTRL-EVENT-CONNECTED - Connection to
00:13:10:15:51:fe completed (auth)
Aug 22 11:58:34.231126: EAPOL: SUPP_PAE entering state AUTHENTICATING
Aug 22 11:58:34.231136: EAPOL: SUPP_BE entering state SUCCESS
C'est ensuite que mon problème survient. L'interface ne fonctionne pas
en dhcp (j'y reviendrais ;) mais fonctionne (presque) correctement en
réglage statique:
iface ath0 inet static
address 10.0.1.15
netmask 255.255.255.0
gateway 10.0.1.1
Le presque vient du fait que l'interface n'est pas accessible depuis les
autres machines sur le réseau interne avant que cette dernière fasse
elle même une requête vers une autre IP.
Par exemple un ping 10.0.1.15 depuis mon Mac va pinguer le vide tant que
la machine sous linux n'aura pas fait elle même de ping vers 10.0.1.x.
Dès que l'accès est fait dans le sens Linux => autre, alors autre =>
Linux fonctionne aussi.
Il semble également que même comme ça, une coupure puisse survenir
"aléatoirement" (30 ~ 50 minutes je n'ai pas vraiment vérifié) et qu'il
fasse à nouveau faire cette manip' pour que les autres machines y
accèdent.
Aucune règle présente dans iptables
Il semble que la source du problème soit la même pour ce qui est du
DHCP, l'interface étant configurée comme ceci:
iface ath0 inet dhcp
hostname gogo
En démarrant l'interface en utilisant ifup ath0, je n'ai aucune réponse
DHCPDISCOVER on ath0 to 255.255.255.255 port 67 interval 4
DHCPDISCOVER on ath0 to 255.255.255.255 port 67 interval 8
(...)
No DHCPOFFERS received
Hors d'après le routeur, une réponse est bien envoyée :
Aug 22 12:13:04 berk kern.info udhcpd[1259]: received DISCOVER from
00:0f:3d:a9:5f:89
Aug 22 12:13:06 berk kern.info udhcpd[1259]: No valid arp replies for
this address (10.0.1.10)
Aug 22 12:13:06 berk kern.info udhcpd[1259]: broadcasting OFFER of
10.0.1.10 to 00:0f:3d:a9:5f:89
Il semble que la box sous Linux ne reçoive pas cette offre :/
Ma seule autre machine connectée sur le réseau Wifi est un Mac qui n'a
pas de problème, je n'ai pas encore essayé sans le WPA (ce que je ferais
ce soir)
Voilà, si l'un d'entre vous a une idée sur la source de mon problème
(sachant que je souhaite avoir une config en DHCP :p), les suggestions
sont les bienvenues :)
--
Romuald Brunet, ICQ 33033393
Remplacez nospam par mon prénom pour me contacter par email
C'est ensuite que mon problème survient. L'interface ne fonctionne pas en dhcp (j'y reviendrais ;) mais fonctionne (presque) correctement en réglage statique: iface ath0 inet static address 10.0.1.15 netmask 255.255.255.0 gateway 10.0.1.1
Le presque vient du fait que l'interface n'est pas accessible depuis les autres machines sur le réseau interne avant que cette dernière fasse elle même une requête vers une autre IP. Par exemple un ping 10.0.1.15 depuis mon Mac va pinguer le vide tant que la machine sous linux n'aura pas fait elle même de ping vers 10.0.1.x. Dès que l'accès est fait dans le sens Linux => autre, alors autre => Linux fonctionne aussi. Il semble également que même comme ça, une coupure puisse survenir "aléatoirement" (30 ~ 50 minutes je n'ai pas vraiment vérifié) et qu'il fasse à nouveau faire cette manip' pour que les autres machines y accèdent.
C'est un problème de résolution d'adresse MAC à mon humble avis.
Que donne le résultat de ifconfig ?
Si en tant que root tu fait juste après avoir monter l'interface un :
ifconfig ath0 arp
Est-ce que le ping du Mac fonctionne sans rien faire d'autre.
Les 30-50 minutes correspondraient à une expiration du cache du Mac (qui est un BSD) et qui a appris la MAC via le ping.
Aucune règle présente dans iptables
Cela n'a normalement pas d'effet. Just pour être sûr tu n'utilises pas arptables (je dois être l'un des rares à l'utiliser).
Il semble que la source du problème soit la même pour ce qui est du DHCP, l'interface étant configurée comme ceci: iface ath0 inet dhcp hostname gogo
En démarrant l'interface en utilisant ifup ath0, je n'ai aucune réponse DHCPDISCOVER on ath0 to 255.255.255.255 port 67 interval 4 DHCPDISCOVER on ath0 to 255.255.255.255 port 67 interval 8 (...) No DHCPOFFERS received
Hors d'après le routeur, une réponse est bien envoyée : Aug 22 12:13:04 berk kern.info udhcpd[1259]: received DISCOVER from 00:0f:3d:a9:5f:89 Aug 22 12:13:06 berk kern.info udhcpd[1259]: No valid arp replies for ^^^^^^^^^^^^^^^^^^^^
this address (10.0.1.10)
Cela confirme mon hypothèse.
Aug 22 12:13:06 berk kern.info udhcpd[1259]: broadcasting OFFER of 10.0.1.10 to 00:0f:3d:a9:5f:89
Il semble que la box sous Linux ne reçoive pas cette offre :/
Ma seule autre machine connectée sur le réseau Wifi est un Mac qui n'a pas de problème, je n'ai pas encore essayé sans le WPA (ce que je ferais ce soir)
Voilà, si l'un d'entre vous a une idée sur la source de mon problème (sachant que je souhaite avoir une config en DHCP :p), les suggestions sont les bienvenues :)
Je pense que si c'est bien un problème MAC/ARP on doit pouvoir s'en sortir. Juste une dernière question: tu n'utilise pas de bridge sur le linux ?
-- Julien
Romuald Brunet a écrit(wrote):
Bonjour à tous.
Bonsoir,
[ ... snip les confs qui ont l'air bien... ]
Lorsque je le lance à la main:
sudo wpa_supplicant -w -t -d -c/etc/wpa_supplicant.conf -iath0 ifup ath0
-Dmadwif
Je ne comprend pas la syntax... il y aurait pas un petit problème de
copier-coller... si c'est
C'est ensuite que mon problème survient. L'interface ne fonctionne pas
en dhcp (j'y reviendrais ;) mais fonctionne (presque) correctement en
réglage statique:
iface ath0 inet static
address 10.0.1.15
netmask 255.255.255.0
gateway 10.0.1.1
Le presque vient du fait que l'interface n'est pas accessible depuis les
autres machines sur le réseau interne avant que cette dernière fasse
elle même une requête vers une autre IP.
Par exemple un ping 10.0.1.15 depuis mon Mac va pinguer le vide tant que
la machine sous linux n'aura pas fait elle même de ping vers 10.0.1.x.
Dès que l'accès est fait dans le sens Linux => autre, alors autre =>
Linux fonctionne aussi.
Il semble également que même comme ça, une coupure puisse survenir
"aléatoirement" (30 ~ 50 minutes je n'ai pas vraiment vérifié) et qu'il
fasse à nouveau faire cette manip' pour que les autres machines y
accèdent.
C'est un problème de résolution d'adresse MAC à mon humble avis.
Que donne le résultat de ifconfig ?
Si en tant que root tu fait juste après avoir monter l'interface un :
ifconfig ath0 arp
Est-ce que le ping du Mac fonctionne sans rien faire d'autre.
Les 30-50 minutes correspondraient à une expiration du cache du Mac (qui
est un BSD) et qui a appris la MAC via le ping.
Aucune règle présente dans iptables
Cela n'a normalement pas d'effet. Just pour être sûr tu n'utilises pas
arptables (je dois être l'un des rares à l'utiliser).
Il semble que la source du problème soit la même pour ce qui est du
DHCP, l'interface étant configurée comme ceci:
iface ath0 inet dhcp
hostname gogo
En démarrant l'interface en utilisant ifup ath0, je n'ai aucune réponse
DHCPDISCOVER on ath0 to 255.255.255.255 port 67 interval 4
DHCPDISCOVER on ath0 to 255.255.255.255 port 67 interval 8
(...)
No DHCPOFFERS received
Hors d'après le routeur, une réponse est bien envoyée :
Aug 22 12:13:04 berk kern.info udhcpd[1259]: received DISCOVER from
00:0f:3d:a9:5f:89
Aug 22 12:13:06 berk kern.info udhcpd[1259]: No valid arp replies for
^^^^^^^^^^^^^^^^^^^^
this address (10.0.1.10)
Cela confirme mon hypothèse.
Aug 22 12:13:06 berk kern.info udhcpd[1259]: broadcasting OFFER of
10.0.1.10 to 00:0f:3d:a9:5f:89
Il semble que la box sous Linux ne reçoive pas cette offre :/
Ma seule autre machine connectée sur le réseau Wifi est un Mac qui n'a
pas de problème, je n'ai pas encore essayé sans le WPA (ce que je ferais
ce soir)
Voilà, si l'un d'entre vous a une idée sur la source de mon problème
(sachant que je souhaite avoir une config en DHCP :p), les suggestions
sont les bienvenues :)
Je pense que si c'est bien un problème MAC/ARP on doit pouvoir s'en
sortir. Juste une dernière question: tu n'utilise pas de bridge sur le
linux ?
C'est ensuite que mon problème survient. L'interface ne fonctionne pas en dhcp (j'y reviendrais ;) mais fonctionne (presque) correctement en réglage statique: iface ath0 inet static address 10.0.1.15 netmask 255.255.255.0 gateway 10.0.1.1
Le presque vient du fait que l'interface n'est pas accessible depuis les autres machines sur le réseau interne avant que cette dernière fasse elle même une requête vers une autre IP. Par exemple un ping 10.0.1.15 depuis mon Mac va pinguer le vide tant que la machine sous linux n'aura pas fait elle même de ping vers 10.0.1.x. Dès que l'accès est fait dans le sens Linux => autre, alors autre => Linux fonctionne aussi. Il semble également que même comme ça, une coupure puisse survenir "aléatoirement" (30 ~ 50 minutes je n'ai pas vraiment vérifié) et qu'il fasse à nouveau faire cette manip' pour que les autres machines y accèdent.
C'est un problème de résolution d'adresse MAC à mon humble avis.
Que donne le résultat de ifconfig ?
Si en tant que root tu fait juste après avoir monter l'interface un :
ifconfig ath0 arp
Est-ce que le ping du Mac fonctionne sans rien faire d'autre.
Les 30-50 minutes correspondraient à une expiration du cache du Mac (qui est un BSD) et qui a appris la MAC via le ping.
Aucune règle présente dans iptables
Cela n'a normalement pas d'effet. Just pour être sûr tu n'utilises pas arptables (je dois être l'un des rares à l'utiliser).
Il semble que la source du problème soit la même pour ce qui est du DHCP, l'interface étant configurée comme ceci: iface ath0 inet dhcp hostname gogo
En démarrant l'interface en utilisant ifup ath0, je n'ai aucune réponse DHCPDISCOVER on ath0 to 255.255.255.255 port 67 interval 4 DHCPDISCOVER on ath0 to 255.255.255.255 port 67 interval 8 (...) No DHCPOFFERS received
Hors d'après le routeur, une réponse est bien envoyée : Aug 22 12:13:04 berk kern.info udhcpd[1259]: received DISCOVER from 00:0f:3d:a9:5f:89 Aug 22 12:13:06 berk kern.info udhcpd[1259]: No valid arp replies for ^^^^^^^^^^^^^^^^^^^^
this address (10.0.1.10)
Cela confirme mon hypothèse.
Aug 22 12:13:06 berk kern.info udhcpd[1259]: broadcasting OFFER of 10.0.1.10 to 00:0f:3d:a9:5f:89
Il semble que la box sous Linux ne reçoive pas cette offre :/
Ma seule autre machine connectée sur le réseau Wifi est un Mac qui n'a pas de problème, je n'ai pas encore essayé sans le WPA (ce que je ferais ce soir)
Voilà, si l'un d'entre vous a une idée sur la source de mon problème (sachant que je souhaite avoir une config en DHCP :p), les suggestions sont les bienvenues :)
Je pense que si c'est bien un problème MAC/ARP on doit pouvoir s'en sortir. Juste une dernière question: tu n'utilise pas de bridge sur le linux ?
-- Julien
Pascal
Salut,
Romuald Brunet a écrit(wrote):
Le presque vient du fait que l'interface n'est pas accessible depuis les autres machines sur le réseau interne avant que cette dernière fasse elle même une requête vers une autre IP. Par exemple un ping 10.0.1.15 depuis mon Mac va pinguer le vide tant que la machine sous linux n'aura pas fait elle même de ping vers 10.0.1.x. Dès que l'accès est fait dans le sens Linux => autre, alors autre => Linux fonctionne aussi. Il semble également que même comme ça, une coupure puisse survenir "aléatoirement" (30 ~ 50 minutes je n'ai pas vraiment vérifié) et qu'il fasse à nouveau faire cette manip' pour que les autres machines y accèdent.
C'est un problème de résolution d'adresse MAC à mon humble avis.
C'est ce que j'ai pensé aussi. Ou alors un problème avec la table MAC du routeur. Il faudrait tracer le trafic ARP entre le Mac et la box. Et tester avec une entrée statique dans la table ARP du Mac.
Les 30-50 minutes correspondraient à une expiration du cache du Mac (qui est un BSD) et qui a appris la MAC via le ping.
Plutôt via la requête ARP envoyée par la box juste avant le ping lui-même. Mais je pinaille.
Il semble que la source du problème soit la même pour ce qui est du DHCP, l'interface étant configurée comme ceci: iface ath0 inet dhcp hostname gogo
En démarrant l'interface en utilisant ifup ath0, je n'ai aucune réponse DHCPDISCOVER on ath0 to 255.255.255.255 port 67 interval 4 DHCPDISCOVER on ath0 to 255.255.255.255 port 67 interval 8 (...) No DHCPOFFERS received
Hors d'après le routeur, une réponse est bien envoyée : Aug 22 12:13:04 berk kern.info udhcpd[1259]: received DISCOVER from 00:0f:3d:a9:5f:89 Aug 22 12:13:06 berk kern.info udhcpd[1259]: No valid arp replies for
^^^^^^^^^^^^^^^^^^^^
this address (10.0.1.10)
Cela confirme mon hypothèse.
Non, AMA cette indication est normale et indique seulement que le serveur DHCP a vérifié qu'aucune machine ne répondait à l'adresse IP choisie avant de l'attribuer au client.
Aug 22 12:13:06 berk kern.info udhcpd[1259]: broadcasting OFFER of 10.0.1.10 to 00:0f:3d:a9:5f:89
Par contre je ne comprends pas trop la présence du mot "broadcasting" dans cette ligne ; si je ne m'abuse, la requête DHCPDISCOVER du client est en broadcast ethernet mais la réponses DHCPOFFER du serveur est en unicast et utilise l'adresse MAC du client.
Pour résumer, il semble que les deux types de paquets suivants ne passent pas en direction de la box : - réponse DHCPOFFER - requête ARP (à confirmer)
Quel est le point commun entre les deux ?
Salut,
Romuald Brunet a écrit(wrote):
Le presque vient du fait que l'interface n'est pas accessible depuis les
autres machines sur le réseau interne avant que cette dernière fasse
elle même une requête vers une autre IP.
Par exemple un ping 10.0.1.15 depuis mon Mac va pinguer le vide tant que
la machine sous linux n'aura pas fait elle même de ping vers 10.0.1.x.
Dès que l'accès est fait dans le sens Linux => autre, alors autre =>
Linux fonctionne aussi.
Il semble également que même comme ça, une coupure puisse survenir
"aléatoirement" (30 ~ 50 minutes je n'ai pas vraiment vérifié) et qu'il
fasse à nouveau faire cette manip' pour que les autres machines y
accèdent.
C'est un problème de résolution d'adresse MAC à mon humble avis.
C'est ce que j'ai pensé aussi. Ou alors un problème avec la table MAC du
routeur. Il faudrait tracer le trafic ARP entre le Mac et la box. Et
tester avec une entrée statique dans la table ARP du Mac.
Les 30-50 minutes correspondraient à une expiration du cache du Mac (qui
est un BSD) et qui a appris la MAC via le ping.
Plutôt via la requête ARP envoyée par la box juste avant le ping
lui-même. Mais je pinaille.
Il semble que la source du problème soit la même pour ce qui est du
DHCP, l'interface étant configurée comme ceci:
iface ath0 inet dhcp
hostname gogo
En démarrant l'interface en utilisant ifup ath0, je n'ai aucune réponse
DHCPDISCOVER on ath0 to 255.255.255.255 port 67 interval 4
DHCPDISCOVER on ath0 to 255.255.255.255 port 67 interval 8
(...)
No DHCPOFFERS received
Hors d'après le routeur, une réponse est bien envoyée :
Aug 22 12:13:04 berk kern.info udhcpd[1259]: received DISCOVER from
00:0f:3d:a9:5f:89
Aug 22 12:13:06 berk kern.info udhcpd[1259]: No valid arp replies for
^^^^^^^^^^^^^^^^^^^^
this address (10.0.1.10)
Cela confirme mon hypothèse.
Non, AMA cette indication est normale et indique seulement que le
serveur DHCP a vérifié qu'aucune machine ne répondait à l'adresse IP
choisie avant de l'attribuer au client.
Aug 22 12:13:06 berk kern.info udhcpd[1259]: broadcasting OFFER of
10.0.1.10 to 00:0f:3d:a9:5f:89
Par contre je ne comprends pas trop la présence du mot "broadcasting"
dans cette ligne ; si je ne m'abuse, la requête DHCPDISCOVER du client
est en broadcast ethernet mais la réponses DHCPOFFER du serveur est en
unicast et utilise l'adresse MAC du client.
Pour résumer, il semble que les deux types de paquets suivants ne
passent pas en direction de la box :
- réponse DHCPOFFER
- requête ARP (à confirmer)
Le presque vient du fait que l'interface n'est pas accessible depuis les autres machines sur le réseau interne avant que cette dernière fasse elle même une requête vers une autre IP. Par exemple un ping 10.0.1.15 depuis mon Mac va pinguer le vide tant que la machine sous linux n'aura pas fait elle même de ping vers 10.0.1.x. Dès que l'accès est fait dans le sens Linux => autre, alors autre => Linux fonctionne aussi. Il semble également que même comme ça, une coupure puisse survenir "aléatoirement" (30 ~ 50 minutes je n'ai pas vraiment vérifié) et qu'il fasse à nouveau faire cette manip' pour que les autres machines y accèdent.
C'est un problème de résolution d'adresse MAC à mon humble avis.
C'est ce que j'ai pensé aussi. Ou alors un problème avec la table MAC du routeur. Il faudrait tracer le trafic ARP entre le Mac et la box. Et tester avec une entrée statique dans la table ARP du Mac.
Les 30-50 minutes correspondraient à une expiration du cache du Mac (qui est un BSD) et qui a appris la MAC via le ping.
Plutôt via la requête ARP envoyée par la box juste avant le ping lui-même. Mais je pinaille.
Il semble que la source du problème soit la même pour ce qui est du DHCP, l'interface étant configurée comme ceci: iface ath0 inet dhcp hostname gogo
En démarrant l'interface en utilisant ifup ath0, je n'ai aucune réponse DHCPDISCOVER on ath0 to 255.255.255.255 port 67 interval 4 DHCPDISCOVER on ath0 to 255.255.255.255 port 67 interval 8 (...) No DHCPOFFERS received
Hors d'après le routeur, une réponse est bien envoyée : Aug 22 12:13:04 berk kern.info udhcpd[1259]: received DISCOVER from 00:0f:3d:a9:5f:89 Aug 22 12:13:06 berk kern.info udhcpd[1259]: No valid arp replies for
^^^^^^^^^^^^^^^^^^^^
this address (10.0.1.10)
Cela confirme mon hypothèse.
Non, AMA cette indication est normale et indique seulement que le serveur DHCP a vérifié qu'aucune machine ne répondait à l'adresse IP choisie avant de l'attribuer au client.
Aug 22 12:13:06 berk kern.info udhcpd[1259]: broadcasting OFFER of 10.0.1.10 to 00:0f:3d:a9:5f:89
Par contre je ne comprends pas trop la présence du mot "broadcasting" dans cette ligne ; si je ne m'abuse, la requête DHCPDISCOVER du client est en broadcast ethernet mais la réponses DHCPOFFER du serveur est en unicast et utilise l'adresse MAC du client.
Pour résumer, il semble que les deux types de paquets suivants ne passent pas en direction de la box : - réponse DHCPOFFER - requête ARP (à confirmer)
Quel est le point commun entre les deux ?
nospam
Julien Salgado wrote:
Lorsque je le lance à la main: sudo wpa_supplicant -w -t -d -c/etc/wpa_supplicant.conf -iath0 ifup ath0 -Dmadwif
Je ne comprend pas la syntax... il y aurait pas un petit problème de copier-coller... si c'est
C'est ce que je fais habituellement effectivement. J'ai teste cette ligne de commande au moment ou j'ai écris le post.
Il semble également que même comme ça, une coupure puisse survenir "aléatoirement" (30 ~ 50 minutes je n'ai pas vraiment vérifié) et qu'il fasse à nouveau faire cette manip' pour que les autres machines y accèdent.
C'est un problème de résolution d'adresse MAC à mon humble avis.
Si en tant que root tu fait juste après avoir monter l'interface un :
ifconfig ath0 arp
Est-ce que le ping du Mac fonctionne sans rien faire d'autre.
Malheureusement non. La commande ne retourne rien je présume que c'est normal ?
Aucune règle présente dans iptables
Cela n'a normalement pas d'effet. Just pour être sûr tu n'utilises pas arptables (je dois être l'un des rares à l'utiliser).
Nop ce n'est pas installé
Voilà, si l'un d'entre vous a une idée sur la source de mon problème (sachant que je souhaite avoir une config en DHCP :p), les suggestions sont les bienvenues :)
Je pense que si c'est bien un problème MAC/ARP on doit pouvoir s'en sortir. Juste une dernière question: tu n'utilise pas de bridge sur le linux ?
J'espère aussi car au final j'aimerai bien utiliser cette box autrement que branchée sur l'ethernet ;) Je ne vois pas de quoi tu parles pour le bridge je suppose que je n'en utilise pas donc.
Justement en parlant de branchement ethernet, la machine est actuellement branchée sur le Mac via Ethernet (ni clavier ni souris sur la machine). Le Mac route la connexion Wifi du routeur sur le port ethernet (sur 192.168.2.x). Je tenais aussi a le préciser au cas ou ca ai une incidence.
C'est ce que je fais habituellement effectivement. J'ai teste cette
ligne de commande au moment ou j'ai écris le post.
Il semble également que même comme ça, une coupure puisse survenir
"aléatoirement" (30 ~ 50 minutes je n'ai pas vraiment vérifié) et qu'il
fasse à nouveau faire cette manip' pour que les autres machines y
accèdent.
C'est un problème de résolution d'adresse MAC à mon humble avis.
Si en tant que root tu fait juste après avoir monter l'interface un :
ifconfig ath0 arp
Est-ce que le ping du Mac fonctionne sans rien faire d'autre.
Malheureusement non.
La commande ne retourne rien je présume que c'est normal ?
Aucune règle présente dans iptables
Cela n'a normalement pas d'effet. Just pour être sûr tu n'utilises pas
arptables (je dois être l'un des rares à l'utiliser).
Nop ce n'est pas installé
Voilà, si l'un d'entre vous a une idée sur la source de mon problème
(sachant que je souhaite avoir une config en DHCP :p), les suggestions
sont les bienvenues :)
Je pense que si c'est bien un problème MAC/ARP on doit pouvoir s'en
sortir. Juste une dernière question: tu n'utilise pas de bridge sur le
linux ?
J'espère aussi car au final j'aimerai bien utiliser cette box autrement
que branchée sur l'ethernet ;)
Je ne vois pas de quoi tu parles pour le bridge je suppose que je n'en
utilise pas donc.
Justement en parlant de branchement ethernet, la machine est
actuellement branchée sur le Mac via Ethernet (ni clavier ni souris sur
la machine). Le Mac route la connexion Wifi du routeur sur le port
ethernet (sur 192.168.2.x). Je tenais aussi a le préciser au cas ou ca
ai une incidence.
C'est ce que je fais habituellement effectivement. J'ai teste cette ligne de commande au moment ou j'ai écris le post.
Il semble également que même comme ça, une coupure puisse survenir "aléatoirement" (30 ~ 50 minutes je n'ai pas vraiment vérifié) et qu'il fasse à nouveau faire cette manip' pour que les autres machines y accèdent.
C'est un problème de résolution d'adresse MAC à mon humble avis.
Si en tant que root tu fait juste après avoir monter l'interface un :
ifconfig ath0 arp
Est-ce que le ping du Mac fonctionne sans rien faire d'autre.
Malheureusement non. La commande ne retourne rien je présume que c'est normal ?
Aucune règle présente dans iptables
Cela n'a normalement pas d'effet. Just pour être sûr tu n'utilises pas arptables (je dois être l'un des rares à l'utiliser).
Nop ce n'est pas installé
Voilà, si l'un d'entre vous a une idée sur la source de mon problème (sachant que je souhaite avoir une config en DHCP :p), les suggestions sont les bienvenues :)
Je pense que si c'est bien un problème MAC/ARP on doit pouvoir s'en sortir. Juste une dernière question: tu n'utilise pas de bridge sur le linux ?
J'espère aussi car au final j'aimerai bien utiliser cette box autrement que branchée sur l'ethernet ;) Je ne vois pas de quoi tu parles pour le bridge je suppose que je n'en utilise pas donc.
Justement en parlant de branchement ethernet, la machine est actuellement branchée sur le Mac via Ethernet (ni clavier ni souris sur la machine). Le Mac route la connexion Wifi du routeur sur le port ethernet (sur 192.168.2.x). Je tenais aussi a le préciser au cas ou ca ai une incidence.
Remplacez nospam par mon prénom pour me contacter par email
nospam
wrote:
C'est un problème de résolution d'adresse MAC à mon humble avis.
C'est ce que j'ai pensé aussi. Ou alors un problème avec la table MAC du routeur. Il faudrait tracer le trafic ARP entre le Mac et la box. Et tester avec une entrée statique dans la table ARP du Mac.
Possible, comment je fais ca ? ;)
Aug 22 12:13:06 berk kern.info udhcpd[1259]: No valid arp replies for
^^^^^^^^^^^^^^^^^^^^
this address (10.0.1.10)
Cela confirme mon hypothèse.
Non, AMA cette indication est normale et indique seulement que le serveur DHCP a vérifié qu'aucune machine ne répondait à l'adresse IP choisie avant de l'attribuer au client.
Je pense aussi que c'est juste une verification de disponibilité
-- Romuald Brunet, ICQ 33033393
Remplacez nospam par mon prénom pour me contacter par email
Pascal@plouf <pascal@plouf.invalid> wrote:
C'est un problème de résolution d'adresse MAC à mon humble avis.
C'est ce que j'ai pensé aussi. Ou alors un problème avec la table MAC du
routeur. Il faudrait tracer le trafic ARP entre le Mac et la box. Et
tester avec une entrée statique dans la table ARP du Mac.
Possible, comment je fais ca ? ;)
Aug 22 12:13:06 berk kern.info udhcpd[1259]: No valid arp replies for
^^^^^^^^^^^^^^^^^^^^
this address (10.0.1.10)
Cela confirme mon hypothèse.
Non, AMA cette indication est normale et indique seulement que le
serveur DHCP a vérifié qu'aucune machine ne répondait à l'adresse IP
choisie avant de l'attribuer au client.
Je pense aussi que c'est juste une verification de disponibilité
--
Romuald Brunet, ICQ 33033393
Remplacez nospam par mon prénom pour me contacter par email
C'est un problème de résolution d'adresse MAC à mon humble avis.
C'est ce que j'ai pensé aussi. Ou alors un problème avec la table MAC du routeur. Il faudrait tracer le trafic ARP entre le Mac et la box. Et tester avec une entrée statique dans la table ARP du Mac.
Possible, comment je fais ca ? ;)
Aug 22 12:13:06 berk kern.info udhcpd[1259]: No valid arp replies for
^^^^^^^^^^^^^^^^^^^^
this address (10.0.1.10)
Cela confirme mon hypothèse.
Non, AMA cette indication est normale et indique seulement que le serveur DHCP a vérifié qu'aucune machine ne répondait à l'adresse IP choisie avant de l'attribuer au client.
Je pense aussi que c'est juste une verification de disponibilité
-- Romuald Brunet, ICQ 33033393
Remplacez nospam par mon prénom pour me contacter par email
Pascal
wrote:
C'est un problème de résolution d'adresse MAC à mon humble avis.
C'est ce que j'ai pensé aussi. Ou alors un problème avec la table MAC du routeur. Il faudrait tracer le trafic ARP entre le Mac et la box. Et tester avec une entrée statique dans la table ARP du Mac.
Possible, comment je fais ca ? ;)
Afficher le contenu du cache ARP :
$ arp
Créer une entrée ARP statique (pour éviter de devoir faire une requête ARP avant d'envoyer un paquet IP à une adresse) :
$arp -s <adresse_ip> <adresse_mac>
Effacer une entrée du cache ARP (statique ou dynamique) pour repartir de zéro :
$ arp -d <adresse_ip>
Capturer le trafic ARP avec tcpdump :
$ tcpdump -e -n -i <interface> arp
(L'option -e affiche les adresses MAC des paquets, l'option -n affiche les adresses sous forme numérique)
Le tout à faire sur les deux machines pour comparer ce qui sort de l'une et arrive (ou pas) sur l'autre.
Pascal@plouf <pascal@plouf.invalid> wrote:
C'est un problème de résolution d'adresse MAC à mon humble avis.
C'est ce que j'ai pensé aussi. Ou alors un problème avec la table MAC du
routeur. Il faudrait tracer le trafic ARP entre le Mac et la box. Et
tester avec une entrée statique dans la table ARP du Mac.
Possible, comment je fais ca ? ;)
Afficher le contenu du cache ARP :
$ arp
Créer une entrée ARP statique (pour éviter de devoir faire une requête
ARP avant d'envoyer un paquet IP à une adresse) :
$arp -s <adresse_ip> <adresse_mac>
Effacer une entrée du cache ARP (statique ou dynamique) pour repartir de
zéro :
$ arp -d <adresse_ip>
Capturer le trafic ARP avec tcpdump :
$ tcpdump -e -n -i <interface> arp
(L'option -e affiche les adresses MAC des paquets, l'option -n affiche
les adresses sous forme numérique)
Le tout à faire sur les deux machines pour comparer ce qui sort de l'une
et arrive (ou pas) sur l'autre.
C'est un problème de résolution d'adresse MAC à mon humble avis.
C'est ce que j'ai pensé aussi. Ou alors un problème avec la table MAC du routeur. Il faudrait tracer le trafic ARP entre le Mac et la box. Et tester avec une entrée statique dans la table ARP du Mac.
Possible, comment je fais ca ? ;)
Afficher le contenu du cache ARP :
$ arp
Créer une entrée ARP statique (pour éviter de devoir faire une requête ARP avant d'envoyer un paquet IP à une adresse) :
$arp -s <adresse_ip> <adresse_mac>
Effacer une entrée du cache ARP (statique ou dynamique) pour repartir de zéro :
$ arp -d <adresse_ip>
Capturer le trafic ARP avec tcpdump :
$ tcpdump -e -n -i <interface> arp
(L'option -e affiche les adresses MAC des paquets, l'option -n affiche les adresses sous forme numérique)
Le tout à faire sur les deux machines pour comparer ce qui sort de l'une et arrive (ou pas) sur l'autre.
