Boujours à tous,

J'ai un problème avec ma Fedora 16. Depuis quelques temps (j'imagine depuis une mise à jour), je perds ma connexion wifi après quelques minutes. POur la relancer, je me déconnecte, puis me reconnecte et rebelote après quelques minutes.

Voici un ping losque le wifi fonctionne: 
xxx@xxx ~]$ ping www.google.com
PING www.l.google.com (209.85.148.104) 56(84) bytes of data.
64 bytes from fra07s07-in-f104.1e100.net (209.85.148.104): icmp_req=1 ttl=55 time=40.8 ms
64 bytes from fra07s07-in-f104.1e100.net (209.85.148.104): icmp_req=2 ttl=55 time=32.6 ms
64 bytes from fra07s07-in-f104.1e100.net (209.85.148.104): icmp_req=3 ttl=55 time=43.7 ms
64 bytes from fra07s07-in-f104.1e100.net (209.85.148.104): icmp_req=4 ttl=55 time=28.7 ms
64 bytes from fra07s07-in-f104.1e100.net (209.85.148.104): icmp_req=5 ttl=55 time=40.9 ms
^C
--- www.l.google.com ping statistics ---
5 packets transmitted, 5 received, 0% packet loss, time 4006ms
rtt min/avg/max/mdev = 28.702/37.388/43.786/5.731 ms

[xxx@xxx ~]$ ifconfig
em1       Link encap:Ethernet  HWaddr 00:24:E8:98:8A:A9  
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)
          Interrupt:22 Memory:f6fe0000-f7000000 

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:527 errors:0 dropped:0 overruns:0 frame:0
          TX packets:527 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:42274 (41.2 KiB)  TX bytes:42274 (41.2 KiB)

wlan0     Link encap:Ethernet  HWaddr 00:22:FB:5D:7C:B6  
          inet addr:192.168.1.3  Bcast:192.168.1.255  Mask:255.255.255.0                                                          
          inet6 addr: fe80::222:fbff:fe5d:7cb6/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:17744 errors:0 dropped:0 overruns:0 frame:0
          TX packets:15737 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:18271230 (17.4 MiB)  TX bytes:3469828 (3.3 MiB)
et lorsque le wifi ne fonctionne plus: 
[xxx@xxx ~]$ ping www.google.com
  ***rien***

[xxx@xxx ~]$ ifconfig
em1       Link encap:Ethernet  HWaddr 00:24:E8:98:8A:A9  
          UP BROADCAST MULTICAST  MTU:1500  Metric:1
          RX packets:0 errors:0 dropped:0 overruns:0 frame:0
          TX packets:0 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:0 (0.0 b)  TX bytes:0 (0.0 b)
          Interrupt:22 Memory:f6fe0000-f7000000 

lo        Link encap:Local Loopback  
          inet addr:127.0.0.1  Mask:255.0.0.0
          inet6 addr: ::1/128 Scope:Host
          UP LOOPBACK RUNNING  MTU:16436  Metric:1
          RX packets:609 errors:0 dropped:0 overruns:0 frame:0
          TX packets:609 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:0 
          RX bytes:48430 (47.2 KiB)  TX bytes:48430 (47.2 KiB)

wlan0     Link encap:Ethernet  HWaddr 00:22:FB:5D:7C:B6  
          inet addr:192.168.1.3  Bcast:192.168.1.255  Mask:255.255.255.0
          inet6 addr: fe80::222:fbff:fe5d:7cb6/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:146886 errors:0 dropped:0 overruns:0 frame:0
          TX packets:106159 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:202992278 (193.5 MiB)  TX bytes:13224984 (12.6 MiB)
Des idées?
Salut,

j'ai un problème similaire depuis mon passage du noyau 3.1.7 au 3.2.2-1 (post croisé).

Redémarrer le wifi est ma solution temporaire, mais on ne peut pas avoir de long téléchargement vu que ça coupera quelques minutes après...

Le problème a eu lieu plusieurs fois lorsque PackageKit tentait de vérifier les mises à jour, peut-être y est-ce lié, mais je n'en sais pas plus... :-?

Ajout : et personnellement, j'ai désactivé le support ipv6 parce qu'il était en conflit avec ipv4, et que les réseaux sur lesquels je suis ne supportent pas ipv6.
Je viens de tester (ça bloque souvent, donc c'est assez simple à tester) :
[xion@ix ~]$ ping 209.85.148.104
PING 209.85.148.104 (209.85.148.104) 56(84) bytes of data.
^C
Les adresses IP (en tout cas deux différentes pour google.com que j'ai essayées) ne fonctionnent pas plus que les urls.

J'ai fait un diff de ifconfig : 
[xion@ix ~]$ diff ifcfg.*
13,14c13,14
<           RX packets:62202 errors:0 dropped:0 overruns:0 frame:0
<           TX packets:62202 errors:0 dropped:0 overruns:0 carrier:0
---
>           RX packets:62207 errors:0 dropped:0 overruns:0 frame:0
>           TX packets:62207 errors:0 dropped:0 overruns:0 carrier:0
16c16
<           RX bytes:2558258 (2.4 MiB)  TX bytes:2558258 (2.4 MiB)
---
>           RX bytes:2559068 (2.4 MiB)  TX bytes:2559068 (2.4 MiB)
22,23c22,23
<           RX packets:117813 errors:0 dropped:0 overruns:0 frame:0
<           TX packets:82030 errors:0 dropped:0 overruns:0 carrier:0
---
>           RX packets:130406 errors:0 dropped:0 overruns:0 frame:0
>           TX packets:92839 errors:0 dropped:0 overruns:0 carrier:0
25c25
<           RX bytes:122288210 (116.6 MiB)  TX bytes:10571689 (10.0 MiB)
---
>           RX bytes:134334745 (128.1 MiB)  TX bytes:13142964 (12.5 MiB)
pour la même connexion, avant (au début de la connexion) et après que le bug se manifeste. Donc la connexion ne semble pas modifiée. Par contre est-ce qu'il y a quelque chose dans dmesg ou autre qui puissent être utile ?

Ajout : après test, dmesg ne contient rien d'intéressant (juste mes pings), par contre /var/log/messages contient (pour la période de fonctionnel à plus fonctionnel) :
Jan 31 14:44:00 ix kernel: [35612.190140] iwlwifi 0000:06:00.0: Tx aggregation enabled on ra = 64:87:d7:2c:6b:d9 tid = 0
Jan 31 14:45:21 ix kernel: [35692.981506] iwlwifi 0000:06:00.0: Tx aggregation enabled on ra = 64:87:d7:2c:6b:d9 tid = 6
Jan 31 14:45:26 ix kernel: [35697.699200] iwlwifi 0000:06:00.0: Tx aggregation enabled on ra = 64:87:d7:2c:6b:d9 tid = 0
Jan 31 14:45:49 ix kernel: [35721.402942] iwlwifi 0000:06:00.0: Tx aggregation enabled on ra = 64:87:d7:2c:6b:d9 tid = 0
Jan 31 14:47:11 ix kernel: [35802.714575] iwlwifi 0000:06:00.0: Tx aggregation enabled on ra = 64:87:d7:2c:6b:d9 tid = 0
Jan 31 14:47:26 ix kernel: [35817.732291] iwlwifi 0000:06:00.0: Tx aggregation enabled on ra = 64:87:d7:2c:6b:d9 tid = 0
Jan 31 14:48:27 ix kernel: [35879.035444] iwlwifi 0000:06:00.0: Tx aggregation enabled on ra = 64:87:d7:2c:6b:d9 tid = 6
Jan 31 14:49:11 ix kernel: [35923.299209] iwlwifi 0000:06:00.0: Tx aggregation enabled on ra = 64:87:d7:2c:6b:d9 tid = 0
Jan 31 14:49:49 ix kernel: [35961.176235] iwlwifi 0000:06:00.0: Tx aggregation enabled on ra = 64:87:d7:2c:6b:d9 tid = 0
Jan 31 14:50:08 ix acvpnagent[1161]: Function: tableCallbackHandler File: RouteMgr.cpp Line: 1723 Invoked Function: recv Return Code: 11 (0x0000000B) Description: unknown 
Jan 31 14:51:08 ix acvpnagent[1161]: Function: tableCallbackHandler File: RouteMgr.cpp Line: 1723 Invoked Function: recv Return Code: 11 (0x0000000B) Description: unknown 
Jan 31 14:51:10 ix kernel: [36041.738595] iwlwifi 0000:06:00.0: Tx aggregation enabled on ra = 64:87:d7:2c:6b:d9 tid = 0
Jan 31 14:51:35 ix kernel: [36066.677139] iwlwifi 0000:06:00.0: Tx aggregation enabled on ra = 64:87:d7:2c:6b:d9 tid = 0
Jan 31 14:52:01 ix kernel: [36093.073713] iwlwifi 0000:06:00.0: Tx aggregation enabled on ra = 64:87:d7:2c:6b:d9 tid = 0
Jan 31 14:52:20 ix kernel: [36112.077255] iwlwifi 0000:06:00.0: Tx aggregation enabled on ra = 64:87:d7:2c:6b:d9 tid = 0
Jan 31 14:53:03 ix kernel: [36154.916283] iwlwifi 0000:06:00.0: Tx aggregation enabled on ra = 64:87:d7:2c:6b:d9 tid = 0
Jan 31 14:53:56 ix kernel: [36207.982820] iwlwifi 0000:06:00.0: Tx aggregation enabled on ra = 64:87:d7:2c:6b:d9 tid = 6
Soit, des tas de pings, ainsi que le problème avec acvpnagent.

Note : ça plante très souvent (genre après 30 secondes là) maintenant...

Ajout 2 : la ligne référence acvpnagent, et j'ai bien un client vpn, mais je ne suis pas en train de l'utiliser (les problèmes interviennent sans utilisation du vpn)

Ajout 3 : y a plein de personnes qui parlent d'un bug wifi avec le noyau 3.2.2-1 sur internet, donc je suis repassé sur l'ancien 3.2.1-3
See https://bugzilla.redhat.com/show_bug.cgi?id=785561

(je ne sais pas encore si je n'ai plus de problème sur 3.2.1-3, je vous redis si ça fonctionne sans problème. 😉
Finalement, bas ça a bien résolu mon problème. Le noyau 3.2.2-1 est fautif dans mon cas car la version précédente (3.2.1-3) n'a aucun soucis avec le wifi. 😉
Bonjours,

Désolé pour la réponse tardive.

Comme xion.luhnis, aucunes différences entre URL ou IP.

Après quelques recherches sur les forums anglophones de fedora, cela semble bien venir du kernel. Je vais revenir à l'ancien, et faire quelques test.

Je suis assez surpris que ce type de bug, sur un service ultra utilisé, puisse passer les controles de release. enfin bref...