* Ethernet
Type : IP ou un autre, peu importe
CRC : on peut faire un calcul approximatif
300 : transféré sans modification
30 : MAC rajoute du bourrage, c'est la couche supérieure (IP) de la
  destination qui se débrouille pour voir s'il y a du bourrage ou non !
3000 : rien écrit dans la norme, mais sous linux et Windows (au moins)
  la couche IP de la source fragmente le paquet avant de l'envoyer a MAC

* Ethernet + IP
- Juste faire remarquer que les adresses de deux machines connectées ont
  une partie commune au début
- Dessinez et expliquez la destruction et la création de l'en-tête MAC sur
  les routeurs (pas la peine sur R2, mais au moins sur R1)

* ARP
s->diff demande arp
r1->s réponse arp
s->r1 données
r1->diff demande arp
r2->r1 réponse arp
r1->r2 données
r2->diff demande arp
d->r2 réponse arp
r2->d données

* Analyse de paquet binaire
- Paquet MAC, ensuite IP, ensuite TCP (ils ne savent pas l'en-tête
  TCP, mais cela vient du champ "protocole supérieur" dans l'en-tête
  IP).
- Il ne se rend pas compte, c'est la couche qui lit le paquet qui
  l'interprète comme un paquet de son propre type.
  - C'est le programme de départ qui est typé (il sait comment
    interpréter la structure des octets/données).
- Taille datagramme : 1500 octets, même si c'est un sans-fil
  (Cisco/Aironet)
  - À la fin, leur dire que ces octets sont les mêmes qui se retrouvent
    dans la capture wireshark dans le cours
- Somme : 4508 + 05DC + 1A82 + 4000 + 4006 + AC14 + 6958 + C239 + 55BC
  = 312CD.  3, la retenue, est ajoutée à la somme : 12D0.  C1 de 12D0
  = ED2F.  Somme dans le paquet = ED2F.

* Actions (consultation de fichiers et envoi de messages) pour résoudre gtr-serv
Le prof dessine le schéma verticale des protocoles DNS/UDP et SSH/TCP
au-dessus d'IP/Ethernet/physique et explique le trajet des paquets
pendant l'écriture de la solution de l'exercice.
- l'application demande au solveur local la résolution du nom gtr-serv
  par un appel à la fonction de la forme coucheAppliResoudreNom
  ("gtr-serv")
- cette fonction (le solveur de nom) regarde le fichier /etc/hosts
- si une ligne gtr-serv y apparaît, il renvoie l'adresse IP
  correspondante à l'application
- sinon, il regarde le fichier /etc/resolv.conf
- s'il contient au moins une ligne nameserver, il récupère l'adresse
  IP indiquée du serveur DNS
  - il envoie un paquet de requête à ce serveur (descente dans les
    couches)
  - si le serveur répond que le nom n'existe pas, le solveur répond
    par un code d'erreur (par ex. 1), ce qui fait l'application
    afficher une erreur du genre "Name or service not known"
  - si le serveur répond que le nom existe, il retourne l'adresse IP à
    l'application, qui fait le traitement voulu
- sinon, échec de résolution de nom et l'application s'arrête