fork of 9front i guess
5aae3d344b
there appears to be confusion about the refresh flag of arpenter(). when we get an arp reply, it makes more sense to just refresh waiting/existing entries instead creating a new one as we do not know if we are going to communicate with the remote host in the future. when we see an arp request for ourselfs however, we want to always enter the senders address into the arp cache as it is likely the sender attempts to communicate with us and with the arp entry, we can reply immidiately. reject senders from multicast/broadcast mac addresses. thats just silly. we can get rid of the multicast/broadcast ip checks in ethermedium and do it in arpenter() instead, checking the route type for the target to see if its a non unicast target. enforce strict separation of interface's arp entries by passing a rlock'd ifc explicitely to arpenter, which we compare against the route target interface. this makes sure arp/ndp replies only affect entries for the receiving interface. handle neighbor solicitation retransmission in nbsendsol() only. that is, both ethermedium and the rxmitproc just call nbsendsol() which maintains the timers and counters and handles the rotation on the re-transmission chain. |
||
|---|---|---|
| 386 | ||
| 68000 | ||
| 68020 | ||
| acme | ||
| adm/timezone | ||
| amd64 | ||
| arm | ||
| lib | ||
| mips | ||
| power | ||
| power64 | ||
| rc | ||
| sparc | ||
| sparc64 | ||
| spim | ||
| sys | ||
| .hgignore | ||