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.
kivik wrote:
I've found a nasty bug in lib9p handling of Tversion
messages, where an invalid version string in the request
leads to servers abort()ing the spaceship.
To reproduce:
; ramfs -S ram
; aux/9pcon /srv/ram
Tversion ~0 DIE
The issue lies in sversion() where in case an invalid
version string is received we respond right away with
ofcall.version="unknown"; however, we fail to set the
ofcall.msize, which at this point is cleared to 0. This
causes the convS2M call in respond() to fail and abort being
called.
we want to accept V4 subnets in CIDR notation consistently which
means we need to interpret the mask in context of the IP address.
so parseipmask() now has an additional v4 flag argument which
offsets the prefixlength by 96 so a /24 will be interpreted
as a /120.
parseipandmask() is the new function which handles this automatically
depending on the ip address type.
v4parsecidr() is now obsolete.
steve wrote:
> I cam across a bug in cifs.
>
> An empty directory under windows 7 pro contains a single entry "." but it
> doesn't appear to contain "..". As a result "." is not removed on dirscan
> and plan9 gets when trying to traverse the hierarchy.
all screen implementations use a Memimage* internally
for the framebuffer, so we can return a shared reference
to its Memdata structure in attachscreen() instead of
a framebuffer data pointer.
this eleminates the softscreen == 0xa110c hack as we
always use shared Memdata* now.
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.
Executing .KS after .1C exhibits a bug.
Instead on the next page, the text between .KS and .KE is shown at
the bottom of the page (where footnote would be).
To reproduce the bug: http://sprunge.us/xyCUX7
The bug can be fixed by changing two lines in tmac.s:
if \\n(NX<1 .bp\}
to
if \\n(NX<=1 .bp\}
and
if \\n(NX<1 'bp\}
to
if \\n(NX<=1 'bp\}
At this moment plan9 is using vendorinfo to communicate
some specific plan9 parameters, but there are some boards
that use this attribute to set specific values. This
patch allows netbooting of these boards using ndb attributes
instead of hard coded solutions in dhcpd(1). Vendor attribute
is used for that purpose because it is also used for the
same purpose in bootp.
Lookupip() was already reading rootpath, but it didn't read the
address of the rootserver. As they are very related it makes sense to
read them at the same time.
This patch also fixes a typo, where vendorclass was used instead of
vendor, resulting that vendor ndb attribute was never used.
always start the pager kproc in swapinit(), simplifying kickpager().
allow zero conf.nswap and conf.nswppo. avoid allocating the reference
map and iolist arrays in that case.
use ulong for ioptr and iolist indices.
don't panic when writing pages out to the swapfile fails. just
requeue the page in the io transaction list so we will try
again next time executeio() is run or just free the page when
the swap reference was dropped.
remove unused pagersummary() function.
rfork F closes all file descriptors, so we have to
invalidate the redirections as they are now refering
to closed files. not doing so causes the wrong file
descriptors being closed later on as the fd numbers
get reused.
the FCA registers 0x28, 0x2C have been reassigned to
to FEXTNVM on i217, i218 and i219 so add Fnofca flag
and avoid writing the registers.
make link detection more robust on i217 by delaying the
phy status read after link status change by 150ms. we'd
otherwise get a "phy wedged" (power saving state?) and
not update the link status until the next link change.
the max packet size is configured in 1K increments on these chips,
which can result in the card receiving a 10K packet but the
driver having only allocated 9.5K of buffer. this actually caued
pool corruption with i210, i217, i218, i219, i350.
for 82598 and x550, we explicitely round rbsz to avoid similar bugs
in the future, even tho the Rbsz constant was already a multiple of
1K and is not affected by the bug.
the lru is there to track least recently used messages so
we can evict them from the cache and refetch them again on
demand. for pop3 mailbox, which doesnt provide fetch routine,
the messages should never be put on the freelist.
The previous attempt to fix this problem (see changesets b32199e0f90a
and 00ae79a6ba50) caused all calls to cachefree to free the cached
message contents in addition to updating the LRU list. This causes
problems for the POP3 driver since it provides no fetch function; once
a message is evicted from the LRU cache, its contents is lost.
This time we fix cachefree to always update the LRU list but only free
the cached message contents if the driver provides a fetch function or
the force flag is set.
