Greeting dear Tech,
This is my first time posting in the OpenBSD mailing list so first I'd
like to thank every one who makes this great OS available to all of us (:
so thank you!
OpenBSD 5.7 on i386 machine.
Long story short: AR2413 device is not listed in ath(4) man page. I am
able to scan
On Sun, May 17, 2015 at 07:51:03PM +0200, Alessandro DE LAURENZIS wrote:
> Folks,
>
> I discussed this topic with stsp@ some months ago, without doing a real
> follow-up.
>
> The bge driver lacks WOL support in the official tree, but a first
> version of the needed modifications were ready since
On Mon, May 18, 2015 at 08:55:49AM +0200, Antranig Vartanian wrote:
> The network is encrypted with WPA2-PSK.
Please show the entire line which 'ifconfig ath0 scan' prints for
the campus network.
> Date: Mon, 18 May 2015 10:47:01 +0200
> From: Stefan Sperling
>
> OTOH, many laptops nowadays ship with Intel AMT and suffer the same issue
> or worse. Yet we still run on them. Current AMT versions have an attack
> surface that dwarfs ASF's. Perhaps this is a lost cause and we'll simply
> have
On 2015/05/18 11:54, Mark Kettenis wrote:
> > Date: Mon, 18 May 2015 10:47:01 +0200
> > From: Stefan Sperling
> >
> > OTOH, many laptops nowadays ship with Intel AMT and suffer the same issue
> > or worse. Yet we still run on them. Current AMT versions have an attack
> > surface that dwarfs ASF's
yes. here is my shell's input and output.
---shell-
# ifconfig ath0 scan
ath0: flags=8822 mtu 1500
lladdr 00:1b:9e:06:89:df
priority: 4
groups: wlan
media: IEEE802.11 autoselect (DS1)
status: no network
ieee80211: nwid ""
Actually, ASF is so horribly bad. So years ago we did make a decision
to avoid it. WOL is not enough cause for enabling ASF.
i sent this to bugs@ but it didn't seem to get posted. granted that it has
only been a few hours, but that is the second time in two days, so i am
taking a chance sending it here instead.
this is related to the first report i sent, which others experienced too.
(https://marc.info/?l=openbsd-misc&m
i missed a few things.
On Mon, 18 May 2015 08:05:05 -0400 dan mclaughlin
wrote:
> i sent this to bugs@ but it didn't seem to get posted. granted that it has
> only been a few hours, but that is the second time in two days, so i am
> taking a chance sending it here instead.
>
> this is related t
Hello,
during our testing we've discovered small glitch in ICMP state handling.
we use simple rule as follows:
# pfctl -sr
pass in on vnet2 all flags S/SA
next we create a local outbound traffic using ping to arbitrary destination
over vnet2 interface. This is what we get:
# ping 17
On Mon, May 18, 2015 at 19:24 +0200, Alexandr Nedvedicky wrote:
> Hello,
>
> during our testing we've discovered small glitch in ICMP state handling.
> we use simple rule as follows:
>
Hi,
> # pfctl -sr
> pass in on vnet2 all flags S/SA
>
If that is the only rule there is, then you need
Hi,
We've got an onboard bge that has got this annoying printf that
also shows up on every up and down (comes from bge_reset):
bge0 at pci4 dev 0 function 0 "Broadcom BCM5718" rev 0x10, BCM5717 B0 \
(0x5717100), APE firmware NCSI 1.1.19.0: msi, address fc:aa:14:16:14:26
brgphy0 at bge0 phy 1: BCM
Hello,
> Thanks for the patch, we'll be investigating this further.
my deep apologize, I was too fast on send trigger. the patch
is toxic. It breaks the opposite case:
pass out on vnet2 all flags S/SA
once rule above is used with patch applied we drop the first
ICMP reply, so ping stops
On Tue, May 12, 2015 at 05:34:58PM -0400, Bertrand PROVOST wrote:
> I found a crash in relayd when using http relay. `bev` pointer is
> used after a free in `relay_http.c` lines: 438, 492 and 609
Thanks for the bug report and analysis. I have added test cases
in /usr/src/regress/usr.sbin/relayd/
This adds "id -c" to display a user's login class. If no user is
specified, it looks up the passwd entry based on the real uid and
displays the corresponding login class.
This is similar to "id -c" in FreeBSD (but they keep the login class
in the kernel).
- todd
Index: usr.bin/id/id.1
Currently, "chroot -u" doesn't use the settings in /etc/login.conf.
This adds a -c option to apply the via setusercontext(). We can't
use LOGIN_SETALL since the uid change has to happen after chroot(2)
and the groups may be specified via the -g option.
Open questions:
1) Should this just be defa
On Mon, May 18, 2015 at 04:30:33PM -0600, Todd C. Miller wrote:
> Currently, "chroot -u" doesn't use the settings in /etc/login.conf.
> This adds a -c option to apply the via setusercontext(). We can't
> use LOGIN_SETALL since the uid change has to happen after chroot(2)
> and the groups may be sp
17 matches
Mail list logo