8. Network Monitoring and Debugging (网络监控与调试)
🇨🇳 中文
上述地址解析协议允许机器了解以太网电缆上的更高层协议活动（例如，CHAOS、Internet、PUP、DECnet）。它可以确定正在使用哪些以太网协议类型字段（通过值）以及每种协议类型内的协议地址。事实上，监视器不需要使用任何相关的更高层协议。它的工作方式如下:
当监视器接收到地址解析数据包时，它总是将 <协议类型, 发送者协议地址, 发送者硬件地址> 输入表中。它可以从数据包的 ar$hln 和 ar$pln 字段确定硬件和协议地址的长度。如果操作码是REPLY，监视器可以丢弃该数据包。如果操作码是REQUEST且目标协议地址与监视器的协议地址匹配，监视器会像通常那样发送REPLY。监视器只会以这种方式获得一个映射，因为对REQUEST的REPLY将直接发送到请求主机。监视器可以尝试发送自己的REQUEST，但这可能会使两个监视器陷入REQUEST发送循环，必须小心处理。
由于协议和操作码没有合并到一个字段中，监视器不需要知道哪个请求操作码与同一更高层协议的哪个回复操作码相关联。长度字段还应该提供足够的信息来使其能够"解析"协议地址，尽管它不知道协议地址的含义。
地址解析协议的工作实现也可以用于调试不工作的实现。据推测，硬件驱动程序将成功广播以太网类型字段为 ether_type$ADDRESS_RESOLUTION 的数据包。数据包的格式可能不完全正确，因为初始实现可能有错误，并且表管理可能有点棘手。因为请求是广播的，监视器将接收数据包，如果需要，可以显示它以进行调试。
🇬🇧 English
The above Address Resolution protocol allows a machine to gain knowledge about the higher level protocol activity (e.g., CHAOS, Internet, PUP, DECnet) on an Ethernet cable. It can determine which Ethernet protocol type fields are in use (by value) and the protocol addresses within each protocol type. In fact, it is not necessary for the monitor to speak any of the higher level protocols involved. It goes something like this:
When a monitor receives an Address Resolution packet, it always enters the <protocol type, sender protocol address, sender hardware address> in a table. It can determine the length of the hardware and protocol address from the ar$hln and ar$pln fields of the packet. If the opcode is a REPLY the monitor can then throw the packet away. If the opcode is a REQUEST and the target protocol address matches the protocol address of the monitor, the monitor sends a REPLY as it normally would. The monitor will only get one mapping this way, since the REPLY to the REQUEST will be sent directly to the requesting host. The monitor could try sending its own REQUEST, but this could get two monitors into a REQUEST sending loop, and care must be taken.
Because the protocol and opcode are not combined into one field, the monitor does not need to know which request opcode is associated with which reply opcode for the same higher level protocol. The length fields should also give enough information to enable it to "parse" a protocol addresses, although it has no knowledge of what the protocol addresses mean.
A working implementation of the Address Resolution protocol can also be used to debug a non-working implementation. Presumably a hardware driver will successfully broadcast a packet with Ethernet type field of ether_type$ADDRESS_RESOLUTION. The format of the packet may not be totally correct, because initial implementations may have bugs, and table management may be slightly tricky. Because requests are broadcast a monitor will receive the packet and can display it for debugging if desired.
🇯🇵 日本語
上記のアドレス解決プロトコルにより、マシンはイーサネットケーブル上の上位レベルのプロトコル活動（例: CHAOS、Internet、PUP、DECnet）について知識を得ることができます。使用されているイーサネットプロトコルタイプフィールド（値による）と各プロトコルタイプ内のプロトコルアドレスを決定できます。実際、モニターが関与する上位レベルのプロトコルを使用する必要はありません。次のように機能します:
モニターがアドレス解決パケットを受信すると、常に <プロトコルタイプ, 送信者プロトコルアドレス, 送信者ハードウェアアドレス> をテーブルに入力します。パケットの ar$hln および ar$pln フィールドからハードウェアとプロトコルアドレスの長さを決定できます。オペコードがREPLYの場合、モニターはパケットを破棄できます。オペコードがREQUESTで、ターゲットプロトコルアドレスがモニターのプロトコルアドレスと一致する場合、モニターは通常どおりREPLYを送信します。モニターはこの方法で1つのマッピングのみを取得します。なぜなら、REQUESTに対するREPLYはリクエスト元のホストに直接送信されるからです。モニターは独自のREQUESTを送信しようとすることができますが、これにより2つのモニターがREQUEST送信ループに陥る可能性があり、注意が必要です。
プロトコルとオペコードが1つのフィールドに結合されていないため、モニターは同じ上位レベルプロトコルについて、どのリクエストオペコードがどのリプライオペコードに関連付けられているかを知る必要がありません。長さフィールドは、プロトコルアドレスを「解析」できるようにするのに十分な情報も提供するはずですが、プロトコルアドレスが何を意味するかについての知識はありません。
アドレス解決プロトコルの動作する実装は、動作しない実装をデバッグするためにも使用できます。おそらく、ハードウェアドライバはイーサネットタイプフィールドが ether_type$ADDRESS_RESOLUTION のパケットを正常にブロードキャストするでしょう。初期実装にはバグがある可能性があり、テーブル管理が少し厄介な場合があるため、パケットの形式は完全に正しくない可能性があります。リクエストはブロードキャストされるため、モニターはパケットを受信し、必要に応じてデバッグのために表示できます。
🇫🇷 Français
Le protocole de résolution d'adresse ci-dessus permet à une machine d'acquérir des connaissances sur l'activité des protocoles de niveau supérieur (par exemple, CHAOS, Internet, PUP, DECnet) sur un câble Ethernet. Il peut déterminer quels champs de type de protocole Ethernet sont utilisés (par valeur) et les adresses de protocole dans chaque type de protocole. En fait, il n'est pas nécessaire que le moniteur utilise l'un des protocoles de niveau supérieur impliqués. Cela se passe à peu près comme ceci :
Lorsqu'un moniteur reçoit un paquet de résolution d'adresse, il entre toujours le <type de protocole, adresse de protocole de l'expéditeur, adresse matérielle de l'expéditeur> dans une table. Il peut déterminer la longueur de l'adresse matérielle et de protocole à partir des champs ar$hln et ar$pln du paquet. Si le code d'opération est une RÉPONSE, le moniteur peut alors jeter le paquet. Si le code d'opération est une DEMANDE et que l'adresse de protocole cible correspond à l'adresse de protocole du moniteur, le moniteur envoie une RÉPONSE comme il le ferait normalement. Le moniteur n'obtiendra qu'un seul mappage de cette manière, car la RÉPONSE à la DEMANDE sera envoyée directement à l'hôte demandeur. Le moniteur pourrait essayer d'envoyer sa propre DEMANDE, mais cela pourrait amener deux moniteurs dans une boucle d'envoi de DEMANDE, et des précautions doivent être prises.
Parce que le protocole et le code d'opération ne sont pas combinés en un seul champ, le moniteur n'a pas besoin de savoir quel code d'opération de demande est associé à quel code d'opération de réponse pour le même protocole de niveau supérieur. Les champs de longueur devraient également fournir suffisamment d'informations pour lui permettre d'« analyser » les adresses de protocole, bien qu'il n'ait aucune connaissance de ce que signifient les adresses de protocole.
Une implémentation fonctionnelle du protocole de résolution d'adresse peut également être utilisée pour déboguer une implémentation non fonctionnelle. Vraisemblablement, un pilote matériel diffusera avec succès un paquet avec un champ de type Ethernet de ether_type$ADDRESS_RESOLUTION. Le format du paquet peut ne pas être totalement correct, car les implémentations initiales peuvent contenir des bogues et la gestion des tables peut être légèrement délicate. Parce que les demandes sont diffusées, un moniteur recevra le paquet et pourra l'afficher pour le débogage si désiré.
🇩🇪 Deutsch
Das oben genannte Adressauflösungsprotokoll ermöglicht es einer Maschine, Kenntnisse über die Aktivität der höheren Protokollebenen (z.B. CHAOS, Internet, PUP, DECnet) auf einem Ethernet-Kabel zu erlangen. Es kann bestimmen, welche Ethernet-Protokolltypfelder verwendet werden (nach Wert) und die Protokolladressen innerhalb jedes Protokolltyps. Tatsächlich ist es nicht notwendig, dass der Monitor eines der beteiligten höheren Protokolle spricht. Es funktioniert ungefähr so:
Wenn ein Monitor ein Adressauflösungspaket empfängt, trägt er immer das <Protokolltyp, Absender-Protokolladresse, Absender-Hardware-Adresse> in eine Tabelle ein. Er kann die Länge der Hardware- und Protokolladresse aus den Feldern ar$hln und ar$pln des Pakets bestimmen. Wenn der Opcode eine ANTWORT ist, kann der Monitor das Paket dann wegwerfen. Wenn der Opcode eine ANFRAGE ist und die Ziel-Protokolladresse mit der Protokolladresse des Monitors übereinstimmt, sendet der Monitor eine ANTWORT, wie er es normalerweise tun würde. Der Monitor erhält auf diese Weise nur eine Zuordnung, da die ANTWORT auf die ANFRAGE direkt an den anfordernden Host gesendet wird. Der Monitor könnte versuchen, seine eigene ANFRAGE zu senden, aber dies könnte zwei Monitore in eine ANFRAGE-Sendeschleife bringen, und Vorsicht ist geboten.
Da Protokoll und Opcode nicht in einem Feld kombiniert sind, muss der Monitor nicht wissen, welcher Anfrage-Opcode mit welchem Antwort-Opcode für dasselbe höhere Protokoll verbunden ist. Die Längenfelder sollten auch genügend Informationen liefern, um ihm zu ermöglichen, Protokolladressen zu „parsen", obwohl er keine Kenntnis davon hat, was die Protokolladressen bedeuten.
Eine funktionierende Implementierung des Adressauflösungsprotokolls kann auch verwendet werden, um eine nicht funktionierende Implementierung zu debuggen. Vermutlich wird ein Hardware-Treiber erfolgreich ein Paket mit einem Ethernet-Typfeld von ether_type$ADDRESS_RESOLUTION senden. Das Format des Pakets ist möglicherweise nicht vollständig korrekt, da anfängliche Implementierungen Fehler haben können und die Tabellenverwaltung etwas knifflig sein kann. Da Anfragen gesendet werden, empfängt ein Monitor das Paket und kann es bei Bedarf zum Debuggen anzeigen.
🇮🇹 Italiano
Il protocollo di risoluzione degli indirizzi sopra descritto consente a una macchina di acquisire conoscenze sull'attività dei protocolli di livello superiore (ad es., CHAOS, Internet, PUP, DECnet) su un cavo Ethernet. Può determinare quali campi tipo di protocollo Ethernet sono in uso (per valore) e gli indirizzi di protocollo all'interno di ciascun tipo di protocollo. Infatti, non è necessario che il monitor utilizzi nessuno dei protocolli di livello superiore coinvolti. Funziona più o meno così:
Quando un monitor riceve un pacchetto di risoluzione degli indirizzi, inserisce sempre il <tipo di protocollo, indirizzo di protocollo del mittente, indirizzo hardware del mittente> in una tabella. Può determinare la lunghezza dell'indirizzo hardware e di protocollo dai campi ar$hln e ar$pln del pacchetto. Se l'opcode è una RISPOSTA, il monitor può quindi scartare il pacchetto. Se l'opcode è una RICHIESTA e l'indirizzo di protocollo target corrisponde all'indirizzo di protocollo del monitor, il monitor invia una RISPOSTA come farebbe normalmente. Il monitor otterrà solo un mapping in questo modo, poiché la RISPOSTA alla RICHIESTA verrà inviata direttamente all'host richiedente. Il monitor potrebbe provare a inviare la propria RICHIESTA, ma questo potrebbe far entrare due monitor in un loop di invio di RICHIESTE, e bisogna prestare attenzione.
Poiché il protocollo e l'opcode non sono combinati in un unico campo, il monitor non ha bisogno di sapere quale opcode di richiesta è associato a quale opcode di risposta per lo stesso protocollo di livello superiore. I campi di lunghezza dovrebbero anche fornire informazioni sufficienti per consentirgli di "analizzare" gli indirizzi di protocollo, anche se non ha conoscenza di cosa significhino gli indirizzi di protocollo.
Un'implementazione funzionante del protocollo di risoluzione degli indirizzi può anche essere utilizzata per eseguire il debug di un'implementazione non funzionante. Presumibilmente un driver hardware trasmetterà con successo un pacchetto con campo tipo Ethernet di ether_type$ADDRESS_RESOLUTION. Il formato del pacchetto potrebbe non essere totalmente corretto, perché le implementazioni iniziali potrebbero avere bug, e la gestione della tabella potrebbe essere leggermente complicata. Poiché le richieste vengono trasmesse, un monitor riceverà il pacchetto e può visualizzarlo per il debug se desiderato.