On Thu, Nov 14, 2013 at 4:27 AM, Alexander Bluhm
alexander.bl...@gmx.net wrote:
On Fri, Oct 18, 2013 at 08:45:02PM +0200, Alexander Bluhm wrote:
Our IPv6 stack scans all extension headers for routing header type
0 and drops the packet if it finds one. RFC 5095 demands to handle
a routing
Hi,
from: sys/arch/amd64/stand/libsa/cmd_i386.c:
#ifdef DEBUG
int
Xregs(void)
{
DUMP_REGS;
return 0;
}
#endif
which is undeclared.
i386 has one in sys/arch/i386/stand/libsa/debug_md.h
--pb
* Alexander Bluhm alexander.bl...@gmx.net [2013-11-14 01:29]:
Theo and others don't like that change as it decreases security.
There are hosts out there that still process RH0 and there are
OpenBSD routers with pf disabled.
This diff brings back the header chain scanning. As an improvement
I guess it would help people who decide to disable pf for slight
performance benefit ?
Quite obviously people are doing this on a variety of machines,
such as bgp routers.
* Alexander Bluhm alexander.bl...@gmx.net [2013-11-14 01:29]:
Theo and others don't like that change as it decreases security.
There are hosts out there that still process RH0 and there are
OpenBSD routers with pf disabled.
This diff brings back the header chain scanning. As an
The diff below might fix the corruption and/or artifacts that people
have reported seeing with the new Mesa in -current on older Intel
hardware. And older Intel hardware here means more or less everything
before Sandy Bridge.
Index: agp_i810.c
This patch seems to fix running pfsync in rdomains.
--- sys/net/if_pfsync.c.origThu Nov 14 15:58:00 2013
+++ sys/net/if_pfsync.c Thu Nov 14 16:51:30 2013
@@ -1682,6 +1682,8 @@
sc-sc_if.if_opackets++;
sc-sc_if.if_obytes += m-m_pkthdr.len;
+ m-m_pkthdr.rdomain =
Date: Thu, 14 Nov 2013 16:55:59 +0100 (CET)
From: Mark Kettenis mark.kette...@xs4all.nl
The diff below might fix the corruption and/or artifacts that people
have reported seeing with the new Mesa in -current on older Intel
hardware. And older Intel hardware here means more or less
I just tried this. It gives a blank screen while booting (after
initalizing inteldrm). Nothing shows up on screen, but system does not
hang.
The second one works better -- it now shows the picture, but GPU hangs
anyway.
* Theo de Raadt dera...@cvs.openbsd.org [2013-11-14 16:35]:
* Alexander Bluhm alexander.bl...@gmx.net [2013-11-14 01:29]:
Theo and others don't like that change as it decreases security.
There are hosts out there that still process RH0 and there are
OpenBSD routers with pf disabled.
it is the status quo *right now*
Look, you can't call something the status quo when a commit was made 1
month ago, to a REAL status quo that existed for 10 years when itojun
made the change... and immediately after this recent commit we
started arguying about the change.
Go find out what
Hey everybody,
I have a proprietary box from a vendor (an appliance). The only
problem with getting OpenBSD on it was initializing the network
interfaces. dmesg:
em0 at pci1 dev 0 function 0 Intel PRO/1000MT (82573L) rev 0x00:
msiem0: Invalid mac address
Its a security thing I'm sure as they
* Theo de Raadt dera...@cvs.openbsd.org [2013-11-14 18:47]:
it is the status quo *right now*
Look, you can't call something the status quo when a commit was made 1
month ago, to a REAL status quo that existed for 10 years when itojun
made the change... and immediately after this recent
* Theo de Raadt dera...@cvs.openbsd.org [2013-11-14 18:47]:
it is the status quo *right now*
Look, you can't call something the status quo when a commit was made 1
month ago, to a REAL status quo that existed for 10 years when itojun
made the change... and immediately after this
On 14 November 2013 18:52, Henning Brauer lists-openbsdt...@bsws.de wrote:
* Theo de Raadt dera...@cvs.openbsd.org [2013-11-14 18:47]:
it is the status quo *right now*
Look, you can't call something the status quo when a commit was made 1
month ago, to a REAL status quo that existed for 10
Mike,
we have discussed that with bluhm in berlin and initially i had the same
opinion: leave the check in the stack, but he has convinced me that it's
rather pf's job to do it.
I agree. If pf is enabled, it can do the job and there is no need for
a second scan.
i'm not against bringing
On Thu, Nov 14, 2013 at 10:04 PM, Mike Belopuhov m...@belopuhov.com wrote:
On 14 November 2013 18:52, Henning Brauer lists-openbsdt...@bsws.de wrote:
* Theo de Raadt dera...@cvs.openbsd.org [2013-11-14 18:47]:
it is the status quo *right now*
Look, you can't call something the status quo
Hello,
Here is Genesys Logic's GL620USB-A driver, new version.
I fixed crashing bug when peer is not connected, rewrite sc_dying to
usbd_is_dying() (advices from mpi@), and deleted useless codes.
This is still work in progress, man is not yet. And please tell me
which I have to write copyright
we have discussed that with bluhm in berlin and initially i had the same
opinion: leave the check in the stack, but he has convinced me that it's
rather pf's job to do it. i'm not against bringing it back and his diff
looks fine to me, esp. since it avoids double check that was there
* Theo de Raadt dera...@cvs.openbsd.org [2013-11-14 19:00]:
* Theo de Raadt dera...@cvs.openbsd.org [2013-11-14 18:47]:
it is the status quo *right now*
Look, you can't call something the status quo when a commit was made 1
month ago, to a REAL status quo that existed for 10 years when
Hi,
I noticed that setpassent(1) probably doesn't work as intended, as this
program should open the spwd.db file once, not four times?
int main() {
setpassent(1);
getpwnam(root); getpwnam(root); getpwuid(0); getpwuid(0);
return 0;
}
It seems to be due to faulty logic in
On 14/11/13 3:29 PM, SASANO Takayoshi wrote:
Hello,
Here is Genesys Logic's GL620USB-A driver, new version.
I fixed crashing bug when peer is not connected, rewrite sc_dying to
usbd_is_dying() (advices from mpi@), and deleted useless codes.
This is still work in progress, man is not yet. And
On Thu, Nov 14, 2013 at 11:00:37AM -0700, Theo de Raadt wrote:
It was not shown to enough people. PERIOD.
My diff was on tech@ for one day during a hackathon before I commited it.
Not enough people discussed it back then. Fine. Let's discuss it now.
The reasons why I removed the check in the
Hello!
I'm strugling to find any documentation for RTL8188* wireless devices
(including those already supported in urtwn driver). I wrote to Realtek,
but no responce followed.
My problem is that I have a MiniPCI RTL8188CE device in my ThinkPad, and
I want to try writing a driver for it. AFAIK
My diff was on tech@ for one day during a hackathon before I commited it.
Not enough people discussed it back then. Fine. Let's discuss it now.
The reasons why I removed the check in the stack are:
- Scanning headers in the forwarding path is against the spirit of IPv6.
One day someone should
Hey all,
I was looking through some OpenBSD code and noticed that rs and jot
are both missing #include unistd.h even though they use getopt. It
seems that stdlib.h defines getopt on OpenBSD. However, this is not
the correct header file, and it makes it not possible to compile
OpenBSD's
On Nov 14, 2013 7:30 PM, Dmitrij D. Czarkoff czark...@gmail.com wrote:
Hello!
I'm strugling to find any documentation for RTL8188* wireless devices
(including those already supported in urtwn driver). I wrote to Realtek,
but no responce followed.
My problem is that I have a
28 matches
Mail list logo
