divert_output() has a basic sanity check to ensure that the m_pkthdr.len
for reinjected packets is not shorter than the minimum length based on
the protocol:
if (p_hdrlen && m->m_pkthdr.len < off + p_hdrlen)
goto fail;
off is the length of the IP header, and p_hdrlen is th
i think i'll try to find the sk at work and wire it up. its just annoying cos
im pretty sure its sr optics with sc connectors.
thanks for testing.
On 13 Jul 2014, at 4:45 am, Brad Smith wrote:
> On 12/07/14 4:32 AM, David Gwynne wrote:
>> how about this?
>
> Now it attaches without error but
> Maybe I (and the other users who actually
> give a shit about having non-crippled software) should have switched to
> BitRig (or NetBSD, or maybe even something else) already.
Good luck, I won't miss you!
On Sat, 2014-07-12 at 06:11 -0500, Shawn K. Quinn wrote:
> If it's code bloat, I'd like to know just how much code we're talking
> about. Unless we're going to try to put Lynx on install media (and I am
> definitely not suggesting that we do), 1.7 megabytes really isn't all
> that big (it's actuall
Currently there's a lot of redundancy between dopselect() and
doppoll(). This diff cleans them up in the following ways:
- Better variable names. Instead of "rts", "ats", and "tts" they're
now called "deadline", "now", and "diff"; and "ncoll" is now
"selcookie". They're also all more
On 12/07/14 4:32 AM, David Gwynne wrote:
how about this?
Now it attaches without error but tcpdump shows no traffic coming in
at all and there is regular traffic on the segment from spanning tree,
CARP, RA, etc.
$ vmstat -iz
interrupt total rate
schizo0:pci_a
On Fri, Jul 11, 2014 at 08:11, Ted Unangst wrote:
>> I also think there's one simple case that can be added: the MMAP call
>> at the bottom of map().
On further inspection, I think this needed a slight reordering to be
safe.
I have also been seeing random munmap errors running jruby:
java(3451)
trace ->
stopped at uao_reference+0x88: movq %rcx,0x8(%rax)
uao_reference at ..+0x88
uao_set_swslot at ..+0x55
uvmpd_scan_inactive at ..+0x681
uvmpd_scan at ..+0x23c
uvm_pageout at ..+0x5b
active process is pagedaemon
screenshots at
https://drive.google.com/folderview?id=0B8t-sinTZPnucERodGdCcT
> I am however curious about the rational behind this change. Does it
> solve any particular problem/risk?
> I seldomly use this style in my own scripts when I need to be able to
> dynamically determine variables at runtime. So it might be wise to know
> what hidden daemons I might be facing.
T
On 07/12/14 14:13, Stuart Henderson wrote:
On 2014/07/12 14:04, Martijn van Duren wrote:
Hello tech@,
I just saw the commit message below.
Currently I use the source functionality to determine whether I'm in my home
network or not and use it to customize sndiod_flags to redirect sound to my
mai
On Sat, Jul 12, 2014 at 06:11:16AM -0500, Shawn K. Quinn wrote:
> On Fri, 2014-07-11 at 03:03 -0600, Theo de Raadt wrote:
> > If lynx was removed from base, and only available in ports... how many of
> > you would even know of it's existance and use it?
>
> Not only would I know of its existence a
> CCLD openssl
>../crypto/.libs/libcrypto.so: undefined reference to `clock_gettime'
>collect2: ld returned 1 exit status
>make[1]: *** [openssl] Error 1
>
>Setting LDFLAGS to -lrt fixes the issue.
Rather than LDFLAGS, it should be in LDADD/LIBADD.
--8<--
Subject: build: resolve link-time fa
On 2014/07/12 14:04, Martijn van Duren wrote:
> Hello tech@,
>
> I just saw the commit message below.
> Currently I use the source functionality to determine whether I'm in my home
> network or not and use it to customize sndiod_flags to redirect sound to my
> main server.
>
> Is there an alterna
Hello tech@,
I just saw the commit message below.
Currently I use the source functionality to determine whether I'm in my
home network or not and use it to customize sndiod_flags to redirect
sound to my main server.
Is there an alternative to dynamically change the rc.conf flags based on
my
> If there's a security hole related to gopher or bibp, let's fix it,
> let's not up and drop support for those protocols because of it. People
> do use these protocols even in 2014.
"let's" is a contraction for "let us".
Basically the community must audit lynx, if they want it to remain in base.
On Fri, 2014-07-11 at 03:03 -0600, Theo de Raadt wrote:
> If lynx was removed from base, and only available in ports... how many of
> you would even know of it's existance and use it?
Not only would I know of its existence and go install it to use, I would
wonder out loud why the hell it's not in
>The first release of LibreSSL portable has been released. LibreSSL
>can be found in the LibreSSL directory of your favorite OpenBSD
>mirror.
>
>http://ftp.openbsd.org/pub/OpenBSD/LibreSSL has it, and other
>mirrors will soon.
>
>libressl-2.0.0.tar.gz has been tested to build on various versions
>
On 2014-07-11 Fri 03:03 AM |, Theo de Raadt wrote:
> If lynx was removed from base, and only available in ports... how many of
> you would even know of it's existance and use it?
>
Several times a week I use lynx for http or local html docs.
If it wasn't in base, I'd install it/some similar pack
On Sat, Jul 12, 2014 at 10:43, Hanno Böck wrote:
> On Sat, 12 Jul 2014 10:29:31 +0200
> Philip Guenther wrote:
>
>> On Sat, Jul 12, 2014 at 10:20 AM, Hanno Böck wrote:
>> >
>> > I had a number of compilation problems with packages when linking to
>> > libressl that I could trace back to the appe
On Sat, 12 Jul 2014 10:29:31 +0200
Philip Guenther wrote:
> On Sat, Jul 12, 2014 at 10:20 AM, Hanno Böck wrote:
> >
> > I had a number of compilation problems with packages when linking to
> > libressl that I could trace back to the appearance of a "main"
> > symbol in libcrypto.so.
> >
>
> Hmm
how about this?
Index: if_sk.c
===
RCS file: /cvs/src/sys/dev/pci/if_sk.c,v
retrieving revision 1.168
diff -u -p -r1.168 if_sk.c
--- if_sk.c 19 Apr 2014 18:29:39 - 1.168
+++ if_sk.c 12 Jul 2014 08:29:20 -
@@ -157
On Sat, Jul 12, 2014 at 10:20 AM, Hanno Böck wrote:
>
> I had a number of compilation problems with packages when linking to
> libressl that I could trace back to the appearance of a "main" symbol
> in libcrypto.so.
>
Hmm, can you please provide a detailed example of one of these?
> I'm far fr
Hi,
I had a number of compilation problems with packages when linking to
libressl that I could trace back to the appearance of a "main" symbol
in libcrypto.so.
I'm far from an expert in dynamic linking and so-files, but afaik
libraries shouldn't have a main function symbol. It came from
getentrop
On Fri, Jul 11, 2014 at 9:52 PM, tekk wrote:
> Thanks Bob and all the other LibreSSL hackers.
Thanks - While I seem to have been quasi defaulted into the public
face for this thing (probably due to size and volume) I hope you can
emphasize the "all the other hackers". Yes, I've done a lot of wor
As seen in FreeBSD ASLR, we can open things up on 64-bit platforms.
effects:
alpha: limit to 1GB (maxdsiz/brksiz)
amd64 and sparc64: limit to 4gb (8gb maxdsiz)
Index: uvm_map.c
===
RCS file: /cvs/src/sys/uvm/uvm_map.c,v
retrieving re
Thanks to the ever attentive eyes of mlarkin, who spotted some unused
code to print a battleship in battleship.
Diff below enables printing the battleship, changes the name to the
S.S. Puffy, and adds my attempt at a tiny ascii blowfish to the side.
OK?
Index: bs.c
==
> I didn't know what egd was up until today, but reading what it is I
> completely understand that consideration. However, this breaks a number
> of packages (wget, python, ruby).
>
> There's probably a simple solution: Just add dummy functions that
> always return -1 (which according to the docs
On Fri, Jul 11, 2014 at 11:07:10PM +, Miod Vallat wrote:
> > it. As expected, OPENSSL does the opposite and makes life harder for
> > everyone.
>
> Hasn't this been the OpenSSL roadmap since the very beginning?
Jury is still out as whether they did it on purpose, or whether it was
just a side
28 matches
Mail list logo