-
Notifications
You must be signed in to change notification settings - Fork 1
/
Copy pathreport.txt
48 lines (31 loc) · 2.69 KB
/
report.txt
1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
17
18
19
20
21
22
23
24
25
26
27
28
29
30
31
32
33
34
35
36
37
38
39
40
41
42
43
44
45
46
47
48
# 課題A
ぼくのPCの情報である。このMac Addressは確かにSenderとして書かれているものに一致する
```
en5: flags=8963<UP,BROADCAST,SMART,RUNNING,PROMISC,SIMPLEX,MULTICAST> mtu 1500
options=4<VLAN_MTU>
ether 28:37:37:00:15:9f
inet 192.168.0.10 netmask 0xffffff00 broadcast 192.168.0.255
inet6 fe80::886:8421:d4e6:fb1c%en5 prefixlen 64 secured scopeid 0xf
inet 169.254.106.142 netmask 0xffff0000 broadcast 169.254.255.255
nd6 options=201<PERFORMNUD,DAD>
media: autoselect (10baseT/UTP <full-duplex,flow-control>)
status: active
```
# 課題B
仕様書によれば、Receive Descriptor Status Fieldが、処理後にビットが変化する。Statusフィールドの0bit 目である、DD bitは、パケットが完全にメインメモリに入ったタイミングで立つと書いてある。
すなわち、ポーリングとして、RDHの変化ではなく、このbitを監視すれば良い。これは、メインメモリのアクセスなので、MMIOよりも速い。
# 課題C-E
現状は、Ring Bufferを動くようにして、ring bufferのサイズ以上のパケットが受け取れ、送信できるようにしたうえで、課題Dとして、Arp Replyを返すようなプログラムを実装した。
kadai-d.pngはarp-scanの結果である
また、UDPパケットを受け取って解釈するコードを書いた。この様子はkadai-e-1.png, kadai-e-2.pngにある。
上に加えてUDPパケットをechoで返すようにした(UDPの送信)。
さらにDHCPプロトコルをハンドリングし、IPアドレスのリースを行うような処理をした。すなわち
* UDPの67番ポートを監視し、ここにきたDHCPパケットを検知する
* DHCPパケットを解析し、Discoverならば、プールから新しくIPAddrを予約し、リースをOfferする
* Requestが飛んできたとき、ほしいとするアドレスと予約時のMacAddrが一致すれば、Ackする
以上の処理により、実際にDHCPのプロトコルのやり取りが可能となった。このプロトコルのやりとりの結果は、dhcp_handling.pcapにそのプロトコルのやりとりをしたものを添付し、結果としてifconfigが渡されたIPアドレス(192.168.0.15)になったことを示す スクリーンショット kadai-e-3.pngを添付した。
この再現は単にハブを用意し、二台のPCを用意して、片方でこのプログラムを起動しもう一方をただつなぐだけで再現できる。
--------------------------
最新のソースコードは以下
https://github.com/moratorium08/driver
にあるので、もしよければこちらを確認していただけると助かります。