Hello,
I want to use ospf6d but it is a bit rough around the edge.
A simple "ospf6ctl reload" makes it crash ! Come on, this is far from the
expected OpenBSD quality :p
I made a patch that make it crash less often. I still stumble on some "lost
interface" or "unknown interface" from time to
On Tue, Dec 15, 2015 at 14:30 +0100, Mike Belopuhov wrote:
> Hi,
>
> This reserves max_linkhdr bytes for a link layer header in the newly
> allocated cluster in the bpf injection path like it's done for the
> packets originating on the host itself (cf. tcp_output). Saves us
> time doing costly
11n ifmedia doesn't pick up monitor mode correctly.
ok?
Index: ieee80211.c
===
RCS file: /cvs/src/sys/net80211/ieee80211.c,v
retrieving revision 1.51
diff -u -p -r1.51 ieee80211.c
--- ieee80211.c 27 Nov 2015 04:03:45 - 1.51
Hi,
here is one program that i'd better not break.
This isn't used in the ramdisks, right?
Is anybody aware of any reacharound?
A few remarks:
* The important use cases are non-ASCII characters in command line
arguments, environment variables, and program names. Even though
i don't
On 15 December 2015 at 15:36, Alexandr Nedvedicky
wrote:
> Hello,
>
>> >
>> >Another possibility would be to require 'once' rules to be 'quick'.
>> >This closes the candidacy window and makes its serialisation, to
>> >preclude multiple matches, more
Hello,
> It just occurred to me that another possibility would be a match-only
> rule that matches one but doesn't involve any purging machinery. Right
> now we install ftp-proxy rules as having maximum number of states equal
> to 1, however there's a time window between the moment the state is
Ping? No further thoughts on this, no tests? Do I have to conclude that
most people are happy with wsmouse as it is?
I'm aware that the diff isn't small, but anything smaller would make
some of the remaining parts void and possibly blur the concept. The core
of the approach is actually quite
On Tue, 15 Dec 2015, Mike Belopuhov wrote:
> >Yet another possibility is to drop 'once' rules as too complex to
> >implement for multiprocessor but I have no idea if this is viable.
>
> It is. And I have said that before with an authority of the implementor
> of "once" rules: since we
Hi,
This has been in my tree for a while and I believe Yasuoka-san has
tested it in the scenario where it was crashing.
m_pulldown is done here with a zero offset which means that if
there's been no space reserved for the Ethernet header in the mbuf
or the cluster it will allocate a new chunk of
Hi,
This reserves max_linkhdr bytes for a link layer header in the newly
allocated cluster in the bpf injection path like it's done for the
packets originating on the host itself (cf. tcp_output). Saves us
time doing costly pool allocations later on.
I believe this has been tested by
On 13 December 2015 at 18:56, Richard Procter
wrote:
>
> If I understand this patch:
>
> Rule removal requires the consistency lock but to acquire it one must be
> able to sleep. pf_test_rule() cannot sleep as it executes in a (soft)
> interrupt handler, so it passes
Disable sensors * in ntpd.conf and time is good again.
I see this on boot up when things go strange.
hw.sensors.vmt0.timedelta0=1450237689.498077 secs, OK, Tue Nov 29 18:36:38.371
I wonder if it's related to this change? Thoughts?
On Thu, Oct 15, 2015 at 10:30:18PM -0400, Rob Pierce wrote:
> It looks like the subject and issuer variables are no longer used in
> report_tls() since the recent libtls api change. Also a few whitespace
You're correct. while I'm at it how's this.. (I'll hit the whitespace too
separately)
Hello,
> >
> >Another possibility would be to require 'once' rules to be 'quick'.
> >This closes the candidacy window and makes its serialisation, to
> >preclude multiple matches, more feasible.
> >
> >Yet another possibility is to drop 'once' rules as too complex to
> >
if libevent dies it would be nice to have some kind of record of
why it decided that was a good idea. by default those messages go
nowhere.
this has tftp register a log callback for libevent to call. if
something goes wrong it should end up in the logs.
ok?
Index: tftpd.c
Hi!
I recently came across a shell script that uses idiom
var1=var1
var2=var2
echo "${var1+($var2)}"
ksh(1) doesn't like it:
ksh: ${var1+($var2)}": bad substitution
Meanwhile bash and dash just print:
(var2)
Apparently ksh tries to parse parenthesis within substituted word.
16 matches
Mail list logo