the Ipselftab is designed to not require locking on read
operation. locking the selftab in ipselftabread() risks
deadlock when accessing the user buffer creates a fault.
remove unused fields from the Ipself struct.
initialize the rate limits when the device gets
bound, not when it is created. so that the
rate limtis get reset to default when the ifc
is reused.
adjust the burst delay when the mtu is changed.
this is to make sure that we allow at least one
full sized packet burst.
make a local copy of ifc->m before doing nil
check as it can change under us when we do
not have the ifc locked.
specify Ebound[] and Eunbound[] error strings
and use them consistently.
remove references to the unused Conv.car qlock.
ipifcregisterproxy() is called with the proxy
ifc wlock'd, which means we cannot acquire the
rwlock of the interfaces that will proxy for us
because it is allowed to rlock() multiple ifc's
in any order. to get arround this, we use canrlock()
and skip the interface when we cannot acquire the
lock.
the ifc should get wlock'd only when we are about
to modify the ifc or its lifc chain. that is when
adding or removing addresses. wlock is not required
when we addresses to the selfcache, which has its
own qlock.
mark reader process pointers with (void*)-1 to mean
not started yet. this avoids the race condition when
media unbind happens before the kproc has set its
Proc* pointer. then we would not post the note and
the reader would continue running after unbind.
etherbind can be simplified by reading the #lX/addr
file to get the mac address, avoiding the temporary
buffer.
using ~IP_DF mask to select offset and "more fragments" bits
includes the evil bit 15. so instead define a constant IP_FO
for the fragment offset bits and use (IP_MF|IP_FO). that way
the evil bit gets ignored and doesnt cause any useless calls
to ipreassemble().
unfraglen() had the side effect that it would always copy the
nexthdr field from the fragment header to the previous nexthdr
field. this is fine when we reassemble packets but breaks
fragments that we want to just forward unchanged.
given that we now keep the block size consistent with the
ip packet size, the variable header part of the ip packet
is just: BLEN(bp) - fp->flen == fp->hlen.
fix bug in ip6reassemble() in the non-fragmented case:
reload ih after ip header was moved before writing ih->ploadlen.
use concatbloc() instead of pullupblock().
some protocols assume that Ip4hdr.length[] and Ip6hdr.ploadlen[]
are valid and not out of range within the block but this has
not been verified. also, the ipv4 and ipv6 headers can have variable
length options, which was not considered in the fragmentation and
reassembly code.
to make this sane, ipiput4() and ipiput6() now verify that everything
is in range and trims to block to the expected size before it does
any further processing. now blocklen() and Ip4hdr.length[] are conistent.
ipoput4() and ipoput6() are simpler now, as they can rely on
blocklen() only, not having a special routing case.
ip fragmentation reassembly has to consider that fragments could
arrive with different ip header options, so we store the header+option
size in new Ipfrag.hlen field.
unfraglen() has to make sure not to run past the buffer, and hadle
the case when it encounters multiple fragment headers.
Under the normal close sequence, when we receive a FIN|ACK, we enter
TIME-WAIT and respond to that LAST-ACK with an ACK. Our TCP stack would
send an ACK in response to *any* ACK, which included FIN|ACK but also
included regular ACKs. (Or PSH|ACKs, which is what we were actually
getting/sending).
That was more ACKs than is necessary and results in an endless ACK storm
if we were under the simultaneous close sequence. In that scenario,
both sides of a connection are in TIME-WAIT. Both sides receive
FIN|ACK, and both respond with an ACK. Then both sides receive *those*
ACKs, and respond again. This continues until the TIME-WAIT wait period
elapses and each side's TCP timers (in the Plan 9 / Akaros case) shut
down.
The fix for this is to only respond to a FIN|ACK when we are in TIME-WAIT.
when a prefix is added with the onlink flag clear, packets
towards that prefix needs to be send to the default gateway
so we omit adding the interface route.
when the on-link flag gets changed to 1 later, we add the
interface route.
the on-link flag is sticky, so theres no way to clear it back
to zero except removing and re-adding the prefix.
sending multicast was broken when ipconfig assigned the 0
address for dhcp as they would wrongly classified as Runi.
this could happen when we do slaac and dhcp in parallel,
breaking the sending of router solicitations.
we did not apply the special case to store 0xFFFF (-0)
in the checksum field when the checksum calculation
returned zero. we survived this for v4 as RFC768 states:
> If the computed checksum is zero, it is transmitted as
> all ones (the equivalent in one's complement arithmetic).
>
> An all zero transmitted checksum value means that the
> transmitter generated no checksum (for debuging or for
> higher level protocols that don't care).
for ipv6 however, the checksum is not optional and receivers
would drop packets with a zero checksum.
during dhcp, ipconfig assigns the null address :: which makes
ipforme() return Runi for any destination, which can trigger
arp resolution when we attempt to reply. so have v4local()
skip the null address and have sendarp() check the return
status of v4local(), avoing the spurious arp requests.
closeconv() calls ipifcremmulti() like:
while((mp = cv->multi) != nil)
ipifcremmulti(cv, mp->ma, mp->ia);
so we have to defer freeing the entry after doing:
if((lifc = iplocalonifc(ifc, ia)) != nil)
remselfcache(f, ifc, lifc, ma);
which accesses the otherwise free'd ia and ma arguments.
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.
