This patch is only an adaptation for 9front of the patch located in
http://www.9legacy.org/9legacy/patch/pc-ether82563-i210.diff. The
major difference is that this patch ignores errors in checksum of
eeprom, because in my system the checksum was wrong. After 3 months,
I didn't have problems, and I think the patch can be used. although
it has some things that need to be fixed. If the link is inactive
when the system boots then it will remain inactive forever.
/n/bugs/open/libdrawfont.c_buffer_overflow
http://bugs.9front.org/open/libdrawfont.c_buffer_overflow/readmeray@raylai.com
Hi all,
In plan9port this bug keeps crashing mc when I run lc in a directory with Chinese characters. This is a diff from OpenBSD but it should apply cleanly to the various plan9 sources.
The code is basically trying to do a realloc (I guess realloc wasn't available back then?) but it copies too much from the original buffer.
Since realloc is available, just use it. If realloc isn't available outside plan9port (I haven't checked) the memmove line should be changed from:
memmove(f->subf, of, (f->nsubf+DSUBF)*sizeof *subf);
to:
memmove(f->subf, of, f->nsubf*sizeof *subf);
I hope this is helpful.
Ray
- return distinct error message when attempting to create Globalseg with physseg name
- copy directory name to up->genbuf so it stays valid after we unlock(&glogalseglock)
- cleanup wstat() handling, allow changing uid
- make sure global segment size is below SEGMAXSIZE
- move isoverlap() check from globalsegattach() into segattach()
- remove Proc* argument from globalsegattach(), segattach() and isoverlap()
- make Physseg.attr and segattach attr parameter an int for consistency
to figure out what network connection a particular tls
conversation refers to, we add the path of the underlying
we send the encrypted tls traffic over in the status file,
example:
term% grep -n '^Chan:' '#a'/tls/*/status
#a/tls/0/status:7: Chan: /net/tcp/6/data
#a/tls/1/status:7: Chan: /net/tcp/0/data
/n/bugs/open/multicasts_and_udp_buffers
http://bugs.9front.org/open/multicasts_and_udp_buffers/readmemichal@Lnet.pl
I have ported my small MPEG-TS analisis tool to Plan9.
To allow this application working I had to fix a bug in the kernel IPv4 code and increase UDP input buffer.
Bug is related to listening for IPv4 multicast traffic. There is no problem if you listen for only one group or multiple groups with different UDP ports. This works:
Write to UDP ctl:
anounce PORT
addmulti INTERFACE_ADDR MULTICAST_ADDR
headers
and you can read packets from data file.
You need to set headers option because otherwise every UDP packet for MULTICAST_ADDR!PORT is treat as separate connection. This is a bug and should be fixed too, but I didn't tried it.
There is a problem when you need to receive packets for multiple multicast groups. Usually the same destination port is used by multiple streams and above sequence of commands fails for second group because the port is the same.
Simple and probably non-intrusive fix is adding "|| ipismulticast(addr)" to if statement at /sys/src/9/ip/devip.c:861 line:
if(ipforme(c->p->f, addr) || ipismulticast(addr))
This fixes the problem and now you can use the following sequence to listen for multiple multicast groups even if they all have the same destination port:
announce MULTICAST_ADDR!PORT
addmulti INTERFACE_ADDR MULTICAST_ADDR
headers
After that my application started working but signals packet drops at >2 Mb/s input rate. The same is reported by kernel netlog. Increase capacity of UDP connection input queue fixes this problem /sys/src/9/ip/udp.c:153
c->rq = qopen(512*1024, Qmsg, 0, 0);
--
Michał Derkacz
access to the axi segment hangs the machine when the fpga
is not programmed yet. to prevent access, we introduce a
new SG_FAULT flag, that when set on the Segment.type or
Physseg.attr, causes the fault handler to immidiately
return with an error (as if the segment would not be mapped).
during programming, we temporarily set the SG_FAULT flag
on the axi physseg, flush all processes tlb's that have
the segment mapped and when programming is done, we clear
the flag again.
tsleep() used to cancel the timer with:
if(up->tt != nil)
timerdel(up);
which still can result in twakeup() to fire after tsleep()
returns (because we set Timer.tt to nil *before* we call the tfn).
in most cases, this is not an issue as the Rendez*
usually is just &up->sleep, but when it is dynamically allocated
or on the stack like in tsemacquire(), twakeup() will call
wakeup() on a potentially garbage Rendez structure!
to fix the race, we execute the wakup() with the Timer lock
held, and set p->trend to nil only after we called wakeup().
that way, the timerdel(); which unconditionally locks the Timer;
can act as a proper barrier and use up->trend == nil as the
condition if the timer has already fired.
for queue like non-seekable files, it is impossible to implement an
exportfs because one has to run the kernels devtab read() and write()
in separate processes, and that makes it impossible to maintain 9p message
order as the scheduler can come in and randomly schedule one process before
another.
so as soon as we have a transition from 9p -> syscalls, we'r screwed.
i currently see just two possibilities:
- introduce special file type like QTSEQ with strictly ordered i/o semantics
- fix all fileservers and exportfs to only do one outstanding i/o to QTSEQ files
which means maintaining a queue per fid
this doesnt propagate. so exporting slow 9p mount again will be limited
again by latency of the inner mount.
other option:
- return offset in Rread, so client can bring responses back into order. this
requires changing all fileservers and drivers to maintain such an per fid offset
and change the protocol to include it in the response, and also pass it to userspace
(new syscalls or pass it in TOS)
this only works for read pipelining, write is still screwed.
both options suck.
--
cinap
(ppp->secret comes from factotum and it can have any size)
This patch also sets the correct state after success and
failure cases in chap negotiation (without them the code was
working because it expected the other point to pass to net
phase or due to the timer).
p2.patch: Do not request encriptation with -c or -C in ppp
(it was a bit annoying request compression, and when the ACK
from the server was received then send a NAK).
p3.patch: Add support for md5 and mschap in in chap
(without this patch ppp was passing to the net stage
without worring about chap).
- remove redundant flushimage() calls before readmouse()
- remove flushimage() calls for allocimage(),freeimage() and originwindow()
this is experimental. it will break allocimage() error handling unless the
caller does explicit flushimage() calls, tho the gains
in usability over high latency connections is huge. in most cases, programs
will just terminate when encountering these errors.
both server and client need to be convinced that the connection
is broken for a connection reestablishment to happen as the server
will only start looking for incoming clients when the connection
already broke. so use the 8 second interval sync messages
to check for connection lifeness. if we miss two syncs in time,
we declare the connecton to be broken and will try to reconnect.
k0ga reports:
Hello,
While I was setting my pppoe conexion with my ISP
I discovered several problems in ip/pppoe. I used
the command line ip/pppoe -A '' ether0 and I got
this:
...
dropping unwanted pkt: wrong ac name
panic: D2B called on non-block dc10 (double-free?)
note rcved: sys: trap: fault read addr=0x0 pc=0x000066e1
pppoe 1013: suicide: sys: trap: fault read addr=0x0 pc=0x000066e1
cpu% acid 1013
/proc/1013/text:386 plan 9 executable
/sys/lib/acid/port
/sys/lib/acid/386
acid: stk()
abort()+0x0 /sys/src/libc/9sys/abort.c:6
ppanic(p=0xd1b8,fmt=0xc7f9)+0x146 /sys/src/libc/port/malloc.c:166
D2B(p=0xd1b8,v=0xdc10)+0x57 /sys/src/libc/port/pool.c:926
poolfreel(v=0xdc10,p=0xd1b8)+0x20 /sys/src/libc/port/pool.c:1152
poolfree(p=0xd1b8,v=0xdc10)+0x3b /sys/src/libc/port/pool.c:1287
free(v=0xdc18)+0x23 /sys/src/libc/port/malloc.c:250
clearstate()+0x1b /sys/src/cmd/ip/pppoe.c:328
pppoe(ether=0xdfffefc1)+0x123 /sys/src/cmd/ip/pppoe.c:426
main(argv=0xdfffefa0,argc=0x1)+0x89 /sys/src/cmd/ip/pppoe.c:100
_main+0x31 /sys/src/libc/386/main9.s:16
acid:
clearstate() is called in pppoe.c:424, and it frees acname and sets it
to nil. pktread() is called in pppoe.c:434 with parameter wantoffer,
which frees acname again in line pppoe.c:360 but doesn't set it to
nil, so clearstate() makes a double free in the next iteration.
for version <= TLS1.1, there is no sigalg field in the ServerKeyExchange
message and the signature digest algorithm is fixed to md5+sha1 and we
only support RSA signatures (TLS1.1 doesnt know about ECDSA).
