On Mon, Sep 11, 2017 at 10:26:22AM -0500, Christopher Snell wrote:
> Hi,
>
> I have an AT&T fiber connection at home that relies on a crappy,
> proprietary, and insecure [1] router that does proprietary authentication
> with upstream equipment via EAP over 802.1x. Some folks have figured out
> ho
On Sun, Sep 10, 2017 at 4:40 PM, Thierry wrote:
> I've just realized that OpenBSD doesn't defined {SIGRTMIN..SIGRTMAX} in
> (i.e. signal(3)). I was wondering if there are any reasons
> other than willingness
> and/or time as to why those signals are not defined.
>
Mostly just time and higher pr
Hi,
Nan Xiao wrote on Tue, Sep 12, 2017 at 08:58:25AM +0800:
> I want to run dmidecode (https://github.com/mirror/dmidecode)
> on OpenBSD 6.1, but executing it will report following errors:
>
> # ./dmidecode
> # dmidecode 3.1
> Scanning /dev/mem for entry point.
> /dev/mem: Operation not permitt
Hi trondd,
Thanks for your answer!
I try to use "sysctl" command to modify "kern.allowkmem"'s value:
# sysctl kern.allowkmem=1
sysctl: kern.allowkmem: Operation not permitted
Since it doesn't work. So I create a "/etc/sysctl.conf" and add
follwing value:
kern.allowkmem=1
After referring the m
On Mon, September 11, 2017 8:58 pm, Nan Xiao wrote:
> Hi all,
>
> Greetings from me!
>
> I want to run dmidecode (https://github.com/mirror/dmidecode) on OpenBSD
> 6.1, but executing it will report following errors:
>
> # ./dmidecode
> # dmidecode 3.1
> Scanning /dev/mem for entry point.
> /dev/mem
Hi all,
Greetings from me!
I want to run dmidecode (https://github.com/mirror/dmidecode) on OpenBSD
6.1, but executing it will report following errors:
# ./dmidecode
# dmidecode 3.1
Scanning /dev/mem for entry point.
/dev/mem: Operation not permitted
After single-step debugging, I find the erro
Feels like it s impossible to use virtual routing table without a rdomain
on interface with 6.1
# arp -V 122 -s 172.16.1.1 ac:64:dd:b0:00:03 [permanent]
arp: writing to routing socket: No such process
arp: 172.16.1.1: No such process
Even if the routing can be modify with
/sbin/route -T122 add
>On 2017-09-11, Marc Espie wrote:
>> I'm just discovering the issue and the thread with it.
>>
>> I don't quite understand why we don't talk it over with Colin Percival.
>>
>>
>
>PERMIT_*_FTP would seem alright to me, as long as people are careful
>not to add patches ..
Yeah, and the same policy
On 2017-09-09, Lukasz Jendrysik wrote:
> Hello,
>
> Since the main goal of OpenBSD is security, I keep wondering about one
> thing.
> There are packages like irssi or Thunderbird that should be updated to
> the newest upstream version.
> For example irssi's upstream encourages all users to upgra
On 2017-09-11, Marc Espie wrote:
> I'm just discovering the issue and the thread with it.
>
> I don't quite understand why we don't talk it over with Colin Percival.
>
>
PERMIT_*_FTP would seem alright to me, as long as people are careful
not to add patches ..
On Mon, Sep 11 2017, Jan Stary wrote:
> There used to be /usr/sbin/slaacd, which is now /sbin/slaacd
> and current.html says to rm /usr/sbin/slaacd.
>
> There is still /usr/sbin/slaacctl - is that intended,
> or should it be in /sbin as well?
I think it's intended, slaacctl is not needed during e
There used to be /usr/sbin/slaacd, which is now /sbin/slaacd
and current.html says to rm /usr/sbin/slaacd.
There is still /usr/sbin/slaacctl - is that intended,
or should it be in /sbin as well?
Jan
Hi,
I have an AT&T fiber connection at home that relies on a crappy,
proprietary, and insecure [1] router that does proprietary authentication
with upstream equipment via EAP over 802.1x. Some folks have figured out
how to bypass it by putting the AT&T router behind their actual firewalls
and pro
2017-09-11 16:30 GMT+02:00 Karel Gardas :
> Seen the same but on Sep 9 snapshots and on amd64 platform. Another
> reboot to bsd.rd and everything was fine and I upgraded to latest
> snapshot successfully...
>
Many reboots. No luck.
--
Eivind Eide
"ONLY THOSE WHO ATTEMPT THE IMPOSSIBLE WILL
Seen the same but on Sep 9 snapshots and on amd64 platform. Another
reboot to bsd.rd and everything was fine and I upgraded to latest
snapshot successfully...
On Mon, Sep 11, 2017 at 4:05 PM, Eivind Eide wrote:
> Trying to upgrade this old machine with i386 snapshot bsd.rd from
> 2017-09-11. bsd.
Trying to upgrade this old machine with i386 snapshot bsd.rd from
2017-09-11. bsd.rd boots ok, but after fscheck it tries to get dhcp.
After "DHCPOFFER from 192.168.1.1 (mac-address)" it just waits,
nothing more happens.
On the router, running OBSD 6.1 -stable it says:
dhcpd: DHCPDISCOVER from (ma
I'm just discovering the issue and the thread with it.
I don't quite understand why we don't talk it over with Colin Percival.
Hi Peter,
Steiner Peter wrote on Mon, Sep 11, 2017 at 09:35:32AM +:
> man.openbsd.org uses an invalid security certificate.
> The certificate expired on 11.09.2017 06:27.
> The current time is 11.09.2017 11:31.
Fixed.
Sorry for the disruption and thanks for the heads-up.
Yours,
Ingo
On Mon, Sep 11, 2017 at 09:24:55AM +, Christoph Leser wrote:
> I read in an 2013 paper by Reyk Floeter about openIKED
> (https://www.openbsd.org/papers/openiked-asiabsdcon2013.pdf)
>
> "The design intends to allow operation of both protocol versions on the same
> host"
>
> but
>
> "The unp
man.openbsd.org uses an invalid security certificate.
The certificate expired on 11.09.2017 06:27.
The current time is 11.09.2017 11:31.
I read in an 2013 paper by Reyk Floeter about openIKED
(https://www.openbsd.org/papers/openiked-asiabsdcon2013.pdf)
"The design intends to allow operation of both protocol versions on the same
host"
but
"The unprivileged IKEv1 process is currently an empty stub"
Does this mean that I cannot h
22 matches
Mail list logo
