cinap_lenrek [Sun, 17 Mar 2019 04:44:55 +0000 (05:44 +0100)]
ip/ipconfig: use defaults for loopback
- do not write /net/ndb for loopback medium unless -p is specified
- use defmask() instead of hardcoded /64 for v6 to get correct /128 mask for ::1
- only do duplicate address detection on ethernet
- increase buffer size to support up to 4096 bit RSA keys
- handle PMTUDiscovery option and respond to pmtu probes
- handle port in Address option
- wlock(&netlk) before closing udpfd to sync with writers
- move default subnet handling out of gethost()
cinap_lenrek [Thu, 7 Mar 2019 21:39:50 +0000 (22:39 +0100)]
devip: ignore the evil bit in fragment info field
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().
only try listen/dial on udp when IndirectData/TcpOnly is not
enabled.
add support for scipts:
host-up
host-down
tinc-up
tinc-down
subnet-up
subnet-down
when dialing udp connection, only switch when there is no
other udp connection active. when we receive an authenticated
message, we switch to that connection immidiately.
cinap_lenrek [Mon, 4 Mar 2019 02:05:30 +0000 (03:05 +0100)]
devip: fix fragment forwarding
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.
cinap_lenrek [Sun, 3 Mar 2019 17:56:18 +0000 (18:56 +0100)]
devip: simplify ip reassembly functions, getting rid of Ipfrag.hlen
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.
cinap_lenrek [Sun, 3 Mar 2019 04:25:00 +0000 (05:25 +0100)]
devip: fix ip fragmentation handling issues with header options
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.
cinap_lenrek [Fri, 1 Mar 2019 00:43:55 +0000 (01:43 +0100)]
lib9p: fix zero msize abort() due to unknown version (thanks kivik)
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.
cinap_lenrek [Mon, 11 Feb 2019 22:26:57 +0000 (23:26 +0100)]
libip: replace v4parsecidr() with new parseipandmask()
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.
cinap_lenrek [Tue, 5 Feb 2019 19:53:40 +0000 (20:53 +0100)]
cifs: fix pruning of . and .. directory entries (thanks steve simon)
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.
cinap_lenrek [Wed, 30 Jan 2019 17:22:52 +0000 (18:22 +0100)]
devdraw: get rid of softscreen==0xa110c hack and make attachscreen() return Memdata*
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.
cinap_lenrek [Sun, 27 Jan 2019 21:12:50 +0000 (22:12 +0100)]
devip: tcp: Don't respond to FIN-less ACKs during TIME-WAIT (thanks Barret Rhoden)
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.
cinap_lenrek [Wed, 23 Jan 2019 20:28:22 +0000 (21:28 +0100)]
troff: fix -ms mug (thanks aksr)
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: