[patch] dhclient: support for RFC 3442 "Local Subnet Routes"

>From RFC 3442: Local Subnet Routes In some cases more than one IP subnet may be configured on a link. In such cases, a host whose IP address is in one IP subnet in the link could communicate directly with a host whose IP address is in a different IP subnet on the s

openssl.cnf req defaults -> default_md sha256

Over the coming months, web browsers will progressively start to first warn for certificate chains including SHA-1 hashes, then treat them as insecure (including disabling certain content - scripts etc). Chrome are initially doing this for certs expiring after Jan 2017, but will progressively slide

fix for nginx SSL session reuse

This issue also affects 5.4, 5.5 and 5.6. Patches available in the respective directories. 5.5 patch follows. http://ftp.openbsd.org/pub/OpenBSD/patches/5.5/common/011_nginx.patch.sig untrusted comment: signature from openbsd 5.5 base secret key RWRGy8gxk9N93yafiuGu4x20xhAgMsmcjCmHJrYJBolmNu2NJU

nofault mappings

The diff below intorduces a new flag for mmap(2) that creates mappings that cannot fault. Normally, if you mmap a file, and your mapping is larger than the mapped file, memory access to full pages beyond the end of the file will fault. Depending on the OS you will get a SIGSEGV or SIGBUS and if y

Re: 802.11 autoassoc

2014-09-30 15:16 GMT+04:00 Stefan Sperling : > On Tue, Sep 30, 2014 at 02:37:08PM +0400, Vadim Zhukov wrote: >> Yes, I've seen that behaviour. And it actually bothers me - what if I >> get associated with untrusted network, and my already opened >> Ajax-enabled browser will start to transfer data v

unused argument in pfr_create_kentry()

Hello, while working with PF code we've found the arg1 (flags) of pfr_create_kentry() is unused. the patch is trivial, just in case you are interested. regards sasha cut here to get patch -- Index: pf_table.c === RCS file

Re: 802.11 autoassoc

On Tue, Sep 30, 2014 at 14:18, Stefan Sperling wrote: > If you are bringing an interface up, you're telling the kernel > that you want link on it. Of course, we could stop connecting > to the strongest open network and always require users to type > an nwid before they get link. But that can be an

improving OpenBSD's gmac.c...

So, as I was working on FreeBSD's implementation of gmac.c, I noticed that I was able to get a significant speed up by using a mask instead of an if branch in ghash_gfmul in gmac.c from OpenBSD... Add a mask var and replace the code between the comments "update Z" and "update V" w/:

Re: 802.11 autoassoc

On Tue, Sep 30, 2014 at 07:59:04AM -0400, sven falempin wrote: > If openBSD auto connect to I will have to patch the > kernel > to use it. > Auto connection to hotspot, especially the 'open' one is the worse thing ever. You need to bring the wifi interface up first, manually or via /etc/hostnam

Re: 802.11 autoassoc

On 2014 Sep 30 (Tue) at 08:10:40 -0400 (-0400), sven falempin wrote: :On Tue, Sep 30, 2014 at 8:04 AM, Peter Hessler wrote: :> On 2014 Sep 30 (Tue) at 14:37:08 +0400 (+0400), Vadim Zhukov wrote: :> :2014-09-30 14:27 GMT+04:00 Stefan Sperling : :> :> On Tue, Sep 30, 2014 at 11:59:25AM +0200, Martin

Re: 802.11 autoassoc

On Tue, Sep 30, 2014 at 8:04 AM, Peter Hessler wrote: > On 2014 Sep 30 (Tue) at 14:37:08 +0400 (+0400), Vadim Zhukov wrote: > :2014-09-30 14:27 GMT+04:00 Stefan Sperling : > :> On Tue, Sep 30, 2014 at 11:59:25AM +0200, Martin Pieuchot wrote: > :>> Hey Vadim, I'm happy to see you've put some effort

Re: 802.11 autoassoc

On 2014 Sep 30 (Tue) at 14:37:08 +0400 (+0400), Vadim Zhukov wrote: :2014-09-30 14:27 GMT+04:00 Stefan Sperling : :> On Tue, Sep 30, 2014 at 11:59:25AM +0200, Martin Pieuchot wrote: :>> Hey Vadim, I'm happy to see you've put some efforts into improving :>> how wireless networks are configured on Op

Re: 802.11 autoassoc

On Tue, Sep 30, 2014 at 7:16 AM, Stefan Sperling wrote: > On Tue, Sep 30, 2014 at 02:37:08PM +0400, Vadim Zhukov wrote: >> Yes, I've seen that behaviour. And it actually bothers me - what if I >> get associated with untrusted network, and my already opened >> Ajax-enabled browser will start to tra

Re: 802.11 autoassoc

On Tue, Sep 30, 2014 at 02:37:08PM +0400, Vadim Zhukov wrote: > Yes, I've seen that behaviour. And it actually bothers me - what if I > get associated with untrusted network, and my already opened > Ajax-enabled browser will start to transfer data via it without > notification?.. This can be avoide

Re: [Patch] use exit() directly in usage()

On Tue, Sep 30, 2014 at 10:05:00AM +0100, Nicholas Marriott wrote: > If we do this then these usage functions also need to be marked __dead. Agreed, Fritjof, can you aadd that to your diff? -Otto > > > > On Sat, Sep 27, 2014 at 07:10:01PM +0200, Fritjof Bornebusch wrote: > > Hi, > >

Re: 802.11 autoassoc

2014-09-30 14:27 GMT+04:00 Stefan Sperling : > On Tue, Sep 30, 2014 at 11:59:25AM +0200, Martin Pieuchot wrote: >> Hey Vadim, I'm happy to see you've put some efforts into improving >> how wireless networks are configured on OpenBSD. I have some questions >> below. >> >> On 26/09/14(Fri) 21:38, Va

Re: 802.11 autoassoc

2014-09-30 13:59 GMT+04:00 Martin Pieuchot : > Hey Vadim, I'm happy to see you've put some efforts into improving > how wireless networks are configured on OpenBSD. I have some questions > below. > > On 26/09/14(Fri) 21:38, Vadim Zhukov wrote: >> >> This is a proof-of-concept patch that implements

Re: 802.11 autoassoc

On Tue, Sep 30, 2014 at 11:59:25AM +0200, Martin Pieuchot wrote: > Hey Vadim, I'm happy to see you've put some efforts into improving > how wireless networks are configured on OpenBSD. I have some questions > below. > > On 26/09/14(Fri) 21:38, Vadim Zhukov wrote: > > > > This is a proof-of-conce

Re: 802.11 autoassoc

Hey Vadim, I'm happy to see you've put some efforts into improving how wireless networks are configured on OpenBSD. I have some questions below. On 26/09/14(Fri) 21:38, Vadim Zhukov wrote: > > This is a proof-of-concept patch that implements network "profiles" > in kernel, using IEEE 802.11 netw

Re: [Patch] use exit() directly in usage()

If we do this then these usage functions also need to be marked __dead. On Sat, Sep 27, 2014 at 07:10:01PM +0200, Fritjof Bornebusch wrote: > Hi, > > after usage() was called, there is no where you can go. > > fritjof > > > Index: ci.c > ==

Re: VPLS patch [1/3]: prepare sys/ to receive pseudowire implementation

Hello Rafael, On 14/09/14(Sun) 23:49, Rafael Zalamena wrote: > The following patch is just a preparation for the code that is coming to > implement the wire network interface (the VPLS datapath) to work on OpenBSD. > > This code turns the mpe code that handles route and labels into some general >

Re: [Patch]openrcs: atoi to strtonum

ok nicm On Sat, Sep 27, 2014 at 05:07:58PM +0200, Otto Moerbeek wrote: > On Fri, Sep 26, 2014 at 09:23:08PM +0200, Fritjof Bornebusch wrote: > > > On Wed, Sep 24, 2014 at 10:31:17PM +0200, Otto Moerbeek wrote: > > Hi, > > > > > On Wed, Sep 24, 2014 at 05:13:47PM +0200, Fritjof Bornebusch wrote

Re: splnet() and SIOCSIFADDR

On 11/09/14(Thu) 10:49, Martin Pieuchot wrote: > On 03/09/14(Wed) 20:59, Alexander Bluhm wrote: > > On Wed, Sep 03, 2014 at 03:53:34PM +0200, Martin Pieuchot wrote: > > > @@ -1078,7 +1079,7 @@ in6_purgeaddr(struct ifaddr *ifa) > > > void > > > in6_unlink_ifa(struct in6_ifaddr *ia6, struct ifnet *

Kill rtalloc_noclone()

After rtalloc(), here's a simpler inliner diff to only use rtalloc1() when dealing with route lookups. ok? Index: net/pf.c === RCS file: /home/ncvs/src/sys/net/pf.c,v retrieving revision 1.887 diff -u -p -r1.887 pf.c --- net/pf.c

Re: physical disk support for mfii(4)

On 21 Sep 2014, at 4:26, Mark Kettenis wrote: > The diff below adds support for "physical disks" to mfii(4). Just > like with mfi(4) you can configure this hardware (or at least some > models) to expose disks that have not been assigned to a logical volume > to the host. This diff makes those