On 25/06/16(Sat) 01:03, Alexander Bluhm wrote:
> Hi,
>
> Path MTU discovery in IPv6 is slightly broken. I takes two
> ICMP6_PACKET_TOO_BIG packets to create and change the dynamic route.
>
> When the first ICMP6 packet arrives, a dynamic route gets created
> in icmp6_mtudisc_clone() and icmp6_mt
On 17/06/16(Fri) 22:22, Mark Kettenis wrote:
> As reported earlier, umb(4) currently doesn't attach to devices that
> implement both NCM 1.0 and MBIM, such as the Sierra Wireless EM7345
> that is found in some thinkpads.
>
> The diff below fixes this. It revamps the way we look up interface
> des
On 22/06/16(Wed) 00:53, Lampshade wrote:
> I don't know if this is enough, but I haven't had access to web
> using other device when kernel panicked.
What's the output of ifconfig and route -n show for this system?
> sysctl kern.version
>
2016-06-27 20:30 GMT-03:00 Jeremie Courreges-Anglas :
> Renato Westphal writes:
>
>> 2016-06-27 19:01 GMT-03:00 Alexander Bluhm :
>>> On Mon, Jun 27, 2016 at 11:57:08PM +0200, J??r??mie Courr??ges-Anglas wrote:
Alexander Bluhm writes:
> The man page says IPV6_MINHOPCOUNT is only for uni
Renato Westphal writes:
> 2016-06-27 19:01 GMT-03:00 Alexander Bluhm :
>> On Mon, Jun 27, 2016 at 11:57:08PM +0200, J??r??mie Courr??ges-Anglas wrote:
>>> Alexander Bluhm writes:
>>> > The man page says IPV6_MINHOPCOUNT is only for unicast packets.
>>> > The ugly part of the code is dealing with
2016-06-27 19:01 GMT-03:00 Alexander Bluhm :
> On Mon, Jun 27, 2016 at 11:57:08PM +0200, J??r??mie Courr??ges-Anglas wrote:
>> Alexander Bluhm writes:
>> > The man page says IPV6_MINHOPCOUNT is only for unicast packets.
>> > The ugly part of the code is dealing with multicast packets.
>>
>> IIUC R
On Mon, Jun 27, 2016 at 11:57:08PM +0200, J??r??mie Courr??ges-Anglas wrote:
> Alexander Bluhm writes:
> > The man page says IPV6_MINHOPCOUNT is only for unicast packets.
> > The ugly part of the code is dealing with multicast packets.
>
> IIUC Renato also needs multicast support. I thought it w
Alexander Bluhm writes:
> On Mon, Jun 27, 2016 at 08:46:12PM +0200, Jeremie Courreges-Anglas wrote:
>>
>> Renato would like to implement GTSM in ldpd(8), the first step would be
>> to support IPV6_MINHOPCOUNT on SOCK_DGRAM sockets. The following diff
>> seems to work fine for him.
>>
>> I did
Mark Kettenis writes:
> As reported by several people, mesa contains code that violates W^X.
> As a result glxgears aborts when using the swrast driver. The diff
> below disables the offending code. The code seems to deal the absence
> of W|X memory just fine. There is a fallback path that is
On Thu, Jun 23, 2016 at 12:44:04PM -0400, Ted Unangst wrote:
> Instead of using the old flags and tsleep style lock, switch to rwlock in
> sblock. That's what it's for. More legible, and as a bonus, MP safer.
As mentioned by mikeb@ returning EWOULDBLOCK is important.
> +void
> +sbunlock(struct so
On Mon, Jun 27, 2016 at 15:32 -0400, Ted Unangst wrote:
> Mike Belopuhov wrote:
> > On Thu, Jun 23, 2016 at 12:44 -0400, Ted Unangst wrote:
> > > Instead of using the old flags and tsleep style lock, switch to rwlock in
> > > sblock. That's what it's for. More legible, and as a bonus, MP safer.
> >
On Mon, Jun 27, 2016 at 08:46:12PM +0200, Jeremie Courreges-Anglas wrote:
>
> Renato would like to implement GTSM in ldpd(8), the first step would be
> to support IPV6_MINHOPCOUNT on SOCK_DGRAM sockets. The following diff
> seems to work fine for him.
>
> I did not go down all possible *_input()
This errata fixes several issues in the OCSP code that could result in
the incorrect generation and parsing of OCSP requests. This remediates
a lack of error checking on time parsing in these functions, and
ensures that only
GENERALIZEDTIME formats are accepted for OCSP, as per RFC 6960.
Issues re
Mike Belopuhov wrote:
> On Thu, Jun 23, 2016 at 12:44 -0400, Ted Unangst wrote:
> > Instead of using the old flags and tsleep style lock, switch to rwlock in
> > sblock. That's what it's for. More legible, and as a bonus, MP safer.
> >
>
> RW_NOSLEEP returns EBUSY if it has to wait, however
> old
On Thu, Jun 23, 2016 at 12:44 -0400, Ted Unangst wrote:
> Instead of using the old flags and tsleep style lock, switch to rwlock in
> sblock. That's what it's for. More legible, and as a bonus, MP safer.
>
RW_NOSLEEP returns EBUSY if it has to wait, however
old sblock macro would return EWOULDBLOC
Renato would like to implement GTSM in ldpd(8), the first step would be
to support IPV6_MINHOPCOUNT on SOCK_DGRAM sockets. The following diff
seems to work fine for him.
I did not go down all possible *_input() methods, only regular TCP and
UDP sockets. Is that enough to deserve the associated
Ted Unangst wrote:
> Instead of using the old flags and tsleep style lock, switch to rwlock in
> sblock. That's what it's for. More legible, and as a bonus, MP safer.
going once, going twice... if no oks, any objections?
> From: j...@wxcvbn.org (Jeremie Courreges-Anglas)
> Date: Mon, 27 Jun 2016 20:13:54 +0200
>
> Some time ago someone reported a wird behavior in the shells/zsh ports.
>
> http://marc.info/?l=openbsd-misc&m=146101806918986&w=2
>
> The latter relies on kill(zombie, 0) to succeed, instead we retu
Some time ago someone reported a wird behavior in the shells/zsh ports.
http://marc.info/?l=openbsd-misc&m=146101806918986&w=2
The latter relies on kill(zombie, 0) to succeed, instead we return -1.
This is because zombie processes aren't looked up in sys_kill().
A potential fix was suggested,
ipmi(4) stopped working on my Supermicro-based machine after
upgrading to 5.9. dmesg said:
ipmi0 at mainbus0: version 2.0 interface KCS iobase 0xca2/2 spacing 1
ipmi0: get header fails
ipmi0: no SDRs IPMI disabled
The patch below fixed the problem for me. Perhaps this line was
removed (in rev 1.
On 27/06/16 02:02, Alexander Bluhm wrote:
> On Thu, Jun 23, 2016 at 07:52:06PM +0300, Kapetanakis Giannis wrote:
>> On 23/06/16 18:14, Kapetanakis Giannis wrote:
>>> It adds two switches:
>>> -c client_cert_file
>>> -k client_key_file
>
> That's fine.
>
>>> Minor modification in CAfile setup as
Alexander Bluhm writes:
> On Mon, Jun 27, 2016 at 01:16:51PM +0200, Jeremie Courreges-Anglas wrote:
>> This looks much less confusing indeed. Note that this conflicts with
>> your last diff to fix inp_hops.
>
> Here is a new version of my inp_hops diff. Note that I have moved
> the assingment i
On Mon, Jun 27, 2016 at 01:08:20PM +0200, Jeremie Courreges-Anglas wrote:
>
> The comment is not accurate anymore. Since a few months the hop limit
> that can be specified via RA is ignored. There are two ways to fix the
> comment: amend it or delete it. Here, I think that the function is
> tri
On Mon, Jun 27, 2016 at 01:16:51PM +0200, Jeremie Courreges-Anglas wrote:
> This looks much less confusing indeed. Note that this conflicts with
> your last diff to fix inp_hops.
Here is a new version of my inp_hops diff. Note that I have moved
the assingment into the "if (inp->inp_flags & INP_I
Alexander Bluhm writes:
> Hi,
>
> The variable swapping between inp, newinp and oldinpcb in syn_cache_get()
> is overly complicated. Simplify the code without functional change.
This looks much less confusing indeed. Note that this conflicts with
your last diff to fix inp_hops.
What I don't l
The comment is not accurate anymore. Since a few months the hop limit
that can be specified via RA is ignored. There are two ways to fix the
comment: amend it or delete it. Here, I think that the function is
trivial enough that a comment isn't needed.
ok/nay?
Index: in6_src.c
Stuart Henderson writes:
> On 2016/06/15 19:43, Vincent Gross wrote:
>> On Mon, 13 Jun 2016 16:49:01 +0200
>> Vincent Gross wrote:
>> >
>> > While validating source address inside selection functions is the
>> > right direction, I don't think it would be a good thing to extend
>> > further in_s
27 matches
Mail list logo
