Sujet Précédent Sujet Suivant

Problèmes d'accessibilité de certains sites en ethernet

Résolu/Fermé
pepeolive63 Messages postés 60 Date d'inscription mercredi 18 octobre 2017 Statut Membre Dernière intervention 22 octobre 2017 - 18 oct. 2017 à 21:12
brupala Messages postés 109458 Date d'inscription lundi 16 juillet 2001 Statut Membre Dernière intervention 26 avril 2024 - 22 oct. 2017 à 22:03
Bonjour.
J'ai un problème d'accessibilité sur certains sites (les pages jaunes par exemple) lorsque je suis connecté en ethernet. Par contre, lorsque je suis connecté en wifi, tout va bien.
Pouvez-vous m'aider?
Voici mon résultat ipconfig:

C:\Users\olivier> ipconfig/all
Configuration IP de Windows
Nom de l'hôte . . . . . . . . . . : olivier-PC
Suffixe DNS principal . . . . . . :
Type de noeud. . . . . . . . . . : Hybride
Routage IP activé . . . . . . . . : Non
Proxy WINS activé . . . . . . . . : Non
Carte Ethernet Connexion au réseau local :
Suffixe DNS propre à la connexion. . . :
Description. . . . . . . . . . . . . . : Realtek PCIe GBE Family Controller
Adresse physique . . . . . . . . . . . : F8-0F-41-2C-25-68
DHCP activé. . . . . . . . . . . . . . : Oui
Configuration automatique activée. . . : Oui
Adresse IPv4. . . . . . . . . . . . . .: 192.168.1.74(préféré)
Masque de sous-réseau. . . . . . . . . : 255.255.255.0
Bail obtenu. . . . . . . . . . . . . . : mercredi 18 octobre 2017 18:58:46
Bail expirant. . . . . . . . . . . . . : jeudi 19 octobre 2017 18:58:46
Passerelle par défaut. . . . . . . . . : 192.168.1.1
Serveur DHCP . . . . . . . . . . . . . : 192.168.1.1
Serveurs DNS. . . . . . . . . . . . . : 192.168.1.1
NetBIOS sur Tcpip. . . . . . . . . . . : Activé
Carte Tunnel isatap.{75B07834-559B-436C-8763-562F82A6E1FE} :
Statut du média. . . . . . . . . . . . : Média déconnecté
Suffixe DNS propre à la connexion. . . :
Description. . . . . . . . . . . . . . : Carte Microsoft ISATAP
Adresse physique . . . . . . . . . . . : 00-00-00-00-00-00-00-E0
DHCP activé. . . . . . . . . . . . . . : Non
Configuration automatique activée. . . : Oui
Carte Tunnel Connexion au réseau local* 4 :
Statut du média. . . . . . . . . . . . : Média déconnecté
Suffixe DNS propre à la connexion. . . :
Description. . . . . . . . . . . . . . : Teredo Tunneling Pseudo-Interface
Adresse physique . . . . . . . . . . . : 00-00-00-00-00-00-00-E0
DHCP activé. . . . . . . . . . . . . . : Non
Configuration automatique activée. . . : Oui

63 réponses

Précédent
Réponse 61 / 63
pepeolive63 Messages postés 60 Date d'inscription mercredi 18 octobre 2017 Statut Membre Dernière intervention 22 octobre 2017
22 oct. 2017 à 10:51
Ce sont les mêmes sauf que les drivers télécharger sont plus gros en taille. J'imagine que depuis que j'ai acheté mon PC, les drivers ont évolué.
0
brupala Messages postés 109458 Date d'inscription lundi 16 juillet 2001 Statut Membre Dernière intervention 26 avril 2024 13 625
Modifié le 22 oct. 2017 à 13:05
C'est surtout windows qui a évolué,
c'est le plus gros problème pour les fournisseurs de matériel: suivre les nouvelles exigences des systèmes, après, il y a toujours des corrections aussi.
ces pilotes fonctionnaient bien à l'origine ?
ça coinçait depuis quand ?

Pour ceux que ça intéresse, j'ai regardé ta capture,
en fait les checksum ip et tcp envoyés par windows sont faux me dit wireshark, ceux reçus sont OK, mais normalement ils sont recalculés par la carte réseau (c'est paramétrable par les options avancées du pilote).
ça pourrait être une explication, mais non, car le serveur te répond bien, on le voit, mais windows semble ignorer la réponse :-(
C'est là que je ne comprends pas pourquoi et surtout pourquoi ce site, sur une phase aussi triviale que les synchronisations tcp. 
No.     Time           Source                Destination           Protocol Length Info
      1 0.000000       192.168.1.74          193.252.242.25        TCP      66     50391 → 80 [SYN] Seq=0 Win=8192 [TCP CHECKSUM INCORRECT] Len=0 MSS=1460 WS=256 SACK_PERM=1

Frame 1: 66 bytes on wire (528 bits), 66 bytes captured (528 bits) on interface 0
Ethernet II, Src: WistronI_2c:25:68 (f8:0f:41:2c:25:68), Dst: Sfr_a9:c9:e0 (24:95:04:a9:c9:e0)
Internet Protocol Version 4, Src: 192.168.1.74, Dst: 193.252.242.25
    0100 .... = Version: 4
    .... 0101 = Header Length: 20 bytes (5)
    Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT)
    Total Length: 52
    Identification: 0x54f0 (21744)
    Flags: 0x02 (Don't Fragment)
        0... .... = Reserved bit: Not set
        .1.. .... = Don't fragment: Set
        ..0. .... = More fragments: Not set
    Fragment offset: 0
    Time to live: 128
    Protocol: TCP (6)
    Header checksum: 0x0000 [incorrect, should be 0x2fcb](may be caused by "IP checksum offload"?)
    [Header checksum status: Bad]
    [Calculated Checksum: 0x2fcb]
    Source: 192.168.1.74
    Destination: 193.252.242.25
    [Source GeoIP: Unknown]
    [Destination GeoIP: AS13034 PAGESJAUNES SA, France, 48.860001, 2.350000]
Transmission Control Protocol, Src Port: 50391, Dst Port: 80, Seq: 0, Len: 0
    Source Port: 50391
    Destination Port: 80
    [Stream index: 0]
    [TCP Segment Len: 0]
    Sequence number: 0    (relative sequence number)
    Acknowledgment number: 0
    Header Length: 32 bytes
    Flags: 0x002 (SYN)
    Window size value: 8192
    [Calculated window size: 8192]
    Checksum: 0x762f [incorrect, should be 0x4ca7](maybe caused by "TCP checksum offload"?)
    [Checksum Status: Bad]
    [Calculated Checksum: 0x4ca7]
    Urgent pointer: 0
    Options: (12 bytes), Maximum segment size, No-Operation (NOP), Window scale, No-Operation (NOP), No-Operation (NOP), SACK permitted

No.     Time           Source                Destination           Protocol Length Info
      2 0.026104       193.252.242.25        192.168.1.74          TCP      60     80 → 50391 [SYN, ACK] Seq=0 Ack=1 Win=4356 Len=0 MSS=1452

Frame 2: 60 bytes on wire (480 bits), 60 bytes captured (480 bits) on interface 0
Ethernet II, Src: Sfr_a9:c9:e0 (24:95:04:a9:c9:e0), Dst: WistronI_2c:25:68 (f8:0f:41:2c:25:68)
Internet Protocol Version 4, Src: 193.252.242.25, Dst: 192.168.1.74
    0100 .... = Version: 4
    .... 0101 = Header Length: 20 bytes (5)
    Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT)
    Total Length: 44
    Identification: 0x7d36 (32054)
    Flags: 0x02 (Don't Fragment)
        0... .... = Reserved bit: Not set
        .1.. .... = Don't fragment: Set
        ..0. .... = More fragments: Not set
    Fragment offset: 0
    Time to live: 244
    Protocol: TCP (6)
    Header checksum: 0x938c [correct]
    [Header checksum status: Good]
    [Calculated Checksum: 0x938c]
    Source: 193.252.242.25
    Destination: 192.168.1.74
    [Source GeoIP: AS13034 PAGESJAUNES SA, France, 48.860001, 2.350000]
    [Destination GeoIP: Unknown]
Transmission Control Protocol, Src Port: 80, Dst Port: 50391, Seq: 0, Ack: 1, Len: 0
    Source Port: 80
    Destination Port: 50391
    [Stream index: 0]
    [TCP Segment Len: 0]
    Sequence number: 0    (relative sequence number)
    Acknowledgment number: 1    (relative ack number)
    Header Length: 24 bytes
    Flags: 0x012 (SYN, ACK)
    Window size value: 4356
    [Calculated window size: 4356]
    Checksum: 0x083f [correct]
    [Checksum Status: Good]
    [Calculated Checksum: 0x083f]
    Urgent pointer: 0
    Options: (4 bytes), Maximum segment size
    [SEQ/ACK analysis]
        [This is an ACK to the segment in frame: 1]
        [The RTT to ACK the segment was: 0.026104000 seconds]

No.     Time           Source                Destination           Protocol Length Info
      3 0.250347       192.168.1.74          193.252.242.25        TCP      66     50392 → 80 [SYN] Seq=0 Win=8192 [TCP CHECKSUM INCORRECT] Len=0 MSS=1460 WS=256 SACK_PERM=1

Frame 3: 66 bytes on wire (528 bits), 66 bytes captured (528 bits) on interface 0
Ethernet II, Src: WistronI_2c:25:68 (f8:0f:41:2c:25:68), Dst: Sfr_a9:c9:e0 (24:95:04:a9:c9:e0)
Internet Protocol Version 4, Src: 192.168.1.74, Dst: 193.252.242.25
    0100 .... = Version: 4
    .... 0101 = Header Length: 20 bytes (5)
    Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT)
    Total Length: 52
    Identification: 0x54f4 (21748)
    Flags: 0x02 (Don't Fragment)
        0... .... = Reserved bit: Not set
        .1.. .... = Don't fragment: Set
        ..0. .... = More fragments: Not set
    Fragment offset: 0
    Time to live: 128
    Protocol: TCP (6)
    Header checksum: 0x0000 [incorrect, should be 0x2fc7](may be caused by "IP checksum offload"?)
    [Header checksum status: Bad]
    [Calculated Checksum: 0x2fc7]
    Source: 192.168.1.74
    Destination: 193.252.242.25
    [Source GeoIP: Unknown]
    [Destination GeoIP: AS13034 PAGESJAUNES SA, France, 48.860001, 2.350000]
Transmission Control Protocol, Src Port: 50392, Dst Port: 80, Seq: 0, Len: 0
    Source Port: 50392
    Destination Port: 80
    [Stream index: 1]
    [TCP Segment Len: 0]
    Sequence number: 0    (relative sequence number)
    Acknowledgment number: 0
    Header Length: 32 bytes
    Flags: 0x002 (SYN)
    Window size value: 8192
    [Calculated window size: 8192]
    Checksum: 0x762f [incorrect, should be 0xcf87](maybe caused by "TCP checksum offload"?)
    [Checksum Status: Bad]
    [Calculated Checksum: 0xcf87]
    Urgent pointer: 0
    Options: (12 bytes), Maximum segment size, No-Operation (NOP), Window scale, No-Operation (NOP), No-Operation (NOP), SACK permitted

No.     Time           Source                Destination           Protocol Length Info
      4 0.276868       193.252.242.25        192.168.1.74          TCP      60     80 → 50392 [SYN, ACK] Seq=0 Ack=1 Win=4356 Len=0 MSS=1452

Frame 4: 60 bytes on wire (480 bits), 60 bytes captured (480 bits) on interface 0
Ethernet II, Src: Sfr_a9:c9:e0 (24:95:04:a9:c9:e0), Dst: WistronI_2c:25:68 (f8:0f:41:2c:25:68)
Internet Protocol Version 4, Src: 193.252.242.25, Dst: 192.168.1.74
    0100 .... = Version: 4
    .... 0101 = Header Length: 20 bytes (5)
    Differentiated Services Field: 0x00 (DSCP: CS0, ECN: Not-ECT)
    Total Length: 44
    Identification: 0x3334 (13108)
    Flags: 0x02 (Don't Fragment)
        0... .... = Reserved bit: Not set
        .1.. .... = Don't fragment: Set
        ..0. .... = More fragments: Not set
    Fragment offset: 0
    Time to live: 244
    Protocol: TCP (6)
    Header checksum: 0xdd8e [correct]
    [Header checksum status: Good]
    [Calculated Checksum: 0xdd8e]
    Source: 193.252.242.25
    Destination: 192.168.1.74
    [Source GeoIP: AS13034 PAGESJAUNES SA, France, 48.860001, 2.350000]
    [Destination GeoIP: Unknown]
Transmission Control Protocol, Src Port: 80, Dst Port: 50392, Seq: 0, Ack: 1, Len: 0
    Source Port: 80
    Destination Port: 50392
    [Stream index: 1]
    [TCP Segment Len: 0]
    Sequence number: 0    (relative sequence number)
    Acknowledgment number: 1    (relative ack number)
    Header Length: 24 bytes
    Flags: 0x012 (SYN, ACK)
    Window size value: 4356
    [Calculated window size: 4356]
    Checksum: 0x9e3e [correct]
    [Checksum Status: Good]
    [Calculated Checksum: 0x9e3e]
    Urgent pointer: 0
    Options: (4 bytes), Maximum segment size
    [SEQ/ACK analysis]
        [This is an ACK to the segment in frame: 3]
        [The RTT to ACK the segment was: 0.026521000 seconds]

No.     Time           Source                Destination           Protocol Length Info
      5 2.999025       192.168.1.74          193.252.242.25        TCP      66     [TCP Spurious Retransmission] 50391 → 80 [SYN] Seq=0 Win=8192 [TCP CHECKSUM INCORRECT] Len=0 MSS=1460 WS=256 SACK_PERM=1

Par la même occasion en révisant cette histoire de tcp checksum offload, donc le calcul par le contrôleur réseau au lieu du CPU, j'ai compris pourquoi wireshark me trouvait des paquets de taille très supérieure à la MTU (2970 octets): c'est parce que c'est la carte réseau qui s'occupe aussi de réassembler la segmentation ethernet, j'avais oublié cette autre possibilité des contrôleurs réseau modernes.
Mais, globalement, la négociation MSS que l'on voit sur ta capture: ta machine propose 1460 et le serveur propose 1456,
qui gère la taille maxi des paquets TCP.
En ipv4 la MSS est égale à MTU-40 (40 est la taille de l'entête tcpip sans options)
0
pepeolive63 Messages postés 60 Date d'inscription mercredi 18 octobre 2017 Statut Membre Dernière intervention 22 octobre 2017 > brupala Messages postés 109458 Date d'inscription lundi 16 juillet 2001 Statut Membre Dernière intervention 26 avril 2024
22 oct. 2017 à 13:36
Et voilà, c'est reparti dans le chinois LOLLLL.
A l'origine, ça marchait parfaitement. J'ai remarqué le problème lorsque j'ai changé de FAI.
Mais sachant que je me sers rarement de mon ordi, est-ce que le problème était présent avant? est-ce que ça vient de mon FAI? je peux pas être catégorique.
En tout cas, ça marche maintenant.
0
brupala Messages postés 109458 Date d'inscription lundi 16 juillet 2001 Statut Membre Dernière intervention 26 avril 2024 13 625 > pepeolive63 Messages postés 60 Date d'inscription mercredi 18 octobre 2017 Statut Membre Dernière intervention 22 octobre 2017
Modifié le 22 oct. 2017 à 15:59
OK,
J'ai remarqué le problème lorsque j'ai changé de FAI.
Surtout de box probablement ...
Reste que si sur la façade tout est réglé, tant mieux, sur le fond, on reste dans le flou.
Allez,
改天见。 :-))
0
Réponse 62 / 63
tovlin
22 oct. 2017 à 20:08
Bravo a vous deux.

Ps: Un comble pour un type qui ici, c'est du chinois mais qui veut à tout prix les pages jaunes :)
0
brupala Messages postés 109458 Date d'inscription lundi 16 juillet 2001 Statut Membre Dernière intervention 26 avril 2024 13 625
22 oct. 2017 à 22:03
:-))
0
Réponse 63 / 63
pepeolive63 Messages postés 60 Date d'inscription mercredi 18 octobre 2017 Statut Membre Dernière intervention 22 octobre 2017
22 oct. 2017 à 20:29
:D :D :D ;)
0

Discussions similaires

Colis en cours de transport vers votre site de livraison ?
Ninan_5568 -
senda -

8 réponses
'Votre colis est dans le site de livraison qui dessert votre adresse' que faire
relakztek82 -
Unemeuf -

25 réponses
Prises murales RJ45 ne fonctionnent pas
Maitrekong -
brupala -

8 réponses
il est en cours de transport vers votre site de livraison
3rin -
Afrikarnak -

4 réponses
Transformer Ethernet en wifi
floflo -
floflo -

4 réponses