Although I don't have time to look in great detail, it seems ok on my phone. It
should not effect the update to 5.20 which looks pretty good (apart from vax).
Hopefully being away from the computer this weekend will make my brain grok gdb
and vax enough after work that I can get 5.20 moving for
Hi Alexander,
Alexander Bluhm wrote on Fri, Oct 24, 2014 at 10:55:07PM +0200:
> On Fri, Oct 24, 2014 at 10:40:55PM +0200, Alexander Bluhm wrote:
>> Here is the diff that applies to -current. I have compared it with
>> the perl git and with Data::Dumper on CPAN. It looks correct.
Confirmed.
>
I beg your collective pardons. I didn't notice the netinet6 directory!
Old timer ...
Ian
On Sat, Oct 25, 2014 at 1:02 PM, Henning Brauer
wrote:
> * Ian Grant [2014-10-25 18:15]:
>> #ifdef INET6
>> /* if reassembled packet passed, create new fragments */
>> if (pf_status.reass && action
On Sat, Oct 25, 2014 at 01:23:47PM -0400, Ian Grant wrote:
> > And when you have more than words, please put it on a a
> > web site and do nothing more than tell people once.
>
> Still a lot of words, but code too, and an outline of a test framework
> that others may be interested in using. I woul
> And when you have more than words, please put it on a a
> web site and do nothing more than tell people once.
Still a lot of words, but code too, and an outline of a test framework
that others may be interested in using. I would be happy to take into
account any other ideas people might have abo
* Ian Grant [2014-10-25 18:15]:
> #ifdef INET6
> /* if reassembled packet passed, create new fragments */
> if (pf_status.reass && action == PF_PASS && *m0 && fwdir == PF_FWD) {
> struct m_tag*mtag;
>
> if ((mtag = m_tag_find(*m0, PACKET_TAG_PF_REASSEMBLED, NULL)))
>
1) telnetd removed, so it won't be a parent process
2) Restricted shells can redirect window decor to > /dev/tty
3) In wcd(), only do _ignore() if cd (e.g: can't cd /root)
Index: ksh.kshrc
===
RCS file: /cvs/src/etc/ksh.kshrc,v
ret
This refers to the un-patched OpenBSD 5.5 source tree.
Whilst trying to understand the notion of "direction" of packet flow
in pf(4) I came across this potential problem:
In pf.conf(5) we have:
When forwarding reassembled IPv6 packets, pf refragments them with
the original maximum fragment
>> Date: Sat, 25 Oct 2014 13:18:04 +0100
>> From: Stuart Henderson
>>
>> http://seclists.org/oss-sec/2014/q4/445
>>
>> Any thoughts on changing strings(1) to use -a by default, to avoid
>> libbfd parsing, and add a new option to allow previous behaviour for
>> people who want it?
>>
>> About -a
This diff checks whether the PCI ROMs have been assigned sensible
addresses. If not it resets the address to 0 such that drivers that
want to map the ROM can assign a suitable address themselves. This
replicates what we have been doing for PCI BARs for the last couple of
years.
This should fix i
> Date: Sat, 25 Oct 2014 13:18:04 +0100
> From: Stuart Henderson
>
> http://seclists.org/oss-sec/2014/q4/445
>
> Any thoughts on changing strings(1) to use -a by default, to avoid
> libbfd parsing, and add a new option to allow previous behaviour for
> people who want it?
>
> About -a, posix sa
http://seclists.org/oss-sec/2014/q4/445
Any thoughts on changing strings(1) to use -a by default, to avoid
libbfd parsing, and add a new option to allow previous behaviour for
people who want it?
About -a, posix says "Scan files in their entirety. If -a is not
specified, it is implementation-defi
12 matches
Mail list logo
