On Mon, Sep 03, 2012 at 04:37:42PM +0200, rustyBSD wrote:
> /usr/src/sbin/disklabel/disklabel.c
> lines: 333 & 1092 & 1096
>
> Is this me, or these strncpy() may cause off-by-one
> overflows ?
>
> In an use like this:
>
> strncpy(a, b, sizeof(a));
>
> the null terminator will be added beyond t
On Thu, Jul 26, 2012 at 11:24:31PM +0200, Peter Laufenberg wrote:
> >That said, the attitude you're displaying does no one any favors: nobody'ss
> >here to make you feel special; either you're willing to put in the work
> >or you aren't.
>
> Who the fuck do you think you are to use that tone? The
s? Why does
the world insist on 7 steps for a no-step process?
>
> anyway, there are those of us out here willing to do the work, but would
> appreciate some preliminary documentation from DEVS as to what goes where.
man roff
>
> -eric
>
> On Jul 26, 2012, at 10:20 A
On Thu, Jul 26, 2012 at 04:43:10PM +0200, Peter Laufenberg wrote:
> >> The site can look butt-ugly (or wikimedia-bland) but needs a
> >> semi-official stamp of approval instead of blinking red THIS IS NOT
> >> AFFILIATED WITH OPENBSD.ORG!!!
> >
> >Set up the site, make it work. Approval will come.
Hi,
Can anyone shed some light on this?
Thanks.
Bert
On Tue, May 22, 2012 at 10:37 AM, Bert Smith
wrote:
> Hi,
>
> I am trying to set up a Layer 3 MPLS VPN (RFC 4364) with GRE tunnels
> between PEs (RFC 4797) instead of an MPLS backbone. I have followed the
> instructions in th
someone please help me figure out what the solution is? What I really
want is a way to say that for MPLS label 300720 the next hop should be the
gre0 interface, but I can't figure out a way to do that.
Regards,
Bert
someone please help me figure out what the solution is? What I really
want is a way to say that for MPLS label 300720 the next hop should be the
gre0 interface, but I can't figure out a way to do that.
Regards,
Bert
This has also worked for me in the past.
Bert
On 3/13/10 9:27 AM, "L. V. Lammert" wrote:
> On Sat, 13 Mar 2010, Sunnz wrote:
>
>> 2010/3/12 Daniel Gracia Garallar :
>>> Not quite a solution, I think. What about if /var/www mounts in a different
>>>
9:ae"
and this uuid.bios won't:
uuid.bios = "56 4d 06 40 43 9c 36 70-df 0a cb d7 9f 61 22 b7"
ethernet0.generatedAddress = "00:0c:29:61:22:b7"
Could somebody try to reproduce?
Thanks,
Bert
Reyk Floeter wrote:
On Thu, May 03, 2007 at 08:01:53PM +0200, Bert Koelew
Here is the trace.
You could download my whole vmware image to reproduce...
Reyk Floeter wrote:
> On Thu, May 03, 2007 at 08:01:53PM +0200, Bert Koelewijn wrote:
>> Is anybody successfully using the vmxnet network driver (vic)?
>
> yes, i was using it with esx and the freewar
oad_mbuf+0xf: movl$0,0x18(%esi)
-Bert
lo0: flags=8049 mtu 33224
groups: lo
inet 127.0.0.1 netmask 0xff00
inet6 ::1 prefixlen 128
inet6 fe80::1%lo0 prefixlen 64 scopeid 0x4
vic0: flags=8843 mtu 1500
lladdr 00:0c:29:07:b9:ae
groups
Thanks Brad! ;=)
Bert Koelewijn wrote:
Hi,
Are all security patches applied to MAIN, already applied to the
OPENBSD_4_0 stable branche?
If not, does this have any security consequences?
Thanks,
Bert
Hi,
Are all security patches applied to MAIN, already applied to the OPENBSD_4_0
stable branche?
If not, does this have any security consequences?
Thanks,
Bert
Stuart Henderson wrote:
Could someone explain this behaviour?
When an IP address is assigned to a bridge member interface, an arp
broadcast request to this interface bypasses bridge filter rules. But, an
arp unicast request is blocked as it should.
If you can, it might be helpful to confirm
Hello all,
Could someone explain this behaviour?
When an IP address is assigned to a bridge member interface, an arp broadcast request to this interface bypasses bridge filter rules. But, an arp
unicast request is blocked as it should.
Setup:
192.168.1.1(00:aa:bb:01:02:03) --pcn0-[bridge]-pc
15 matches
Mail list logo
