* Alexandr Nedvedicky [2015-05-21 21:29]:
> > Well, not entirely (: I did it while exploring the code and sent
> > out to provoke further discussion. Today I've talked to reyk@ and
> > we think that it's better to go down a different road: make sure we
> > don't create states on reply packets in
On Sun, May 10, 2015 at 10:20:10PM +0200, Mark Kettenis wrote:
> [ Sending this to tech@ since I don't just want the ports people to
> know about this ]
>
> Invoking the linker directly to build executables or shared libraries
> is strongly discouraged. It really doesn't work properly unless yo
* sven falempin [2015-05-21 17:29]:
> I propose
>
> Index: pfctl/parse.y
> ===
> RCS file: /cvs/src/sbin/pfctl/parse.y,v
> retrieving revision 1.648
> diff -u -p -r1.648 parse.y
> --- pfctl/parse.y 21 Apr 2015 16:34:59 -
* Alexandr Nedvedicky [2015-05-21 21:31]:
> On Thu, May 21, 2015 at 07:43:51PM +0200, Mike Belopuhov wrote:
> > On Thu, May 21, 2015 at 17:34 +0200, Alexandr Nedvedicky wrote:
> > > snippet below comes from pf_create_state():
> > >
> > >3559 if (pf_state_insert(BOUND_IFACE(r, pd->kif)
On Fri, May 22, 2015 at 5:09 AM, Henning Brauer
wrote:
> * sven falempin [2015-05-21 17:29]:
> > I propose
> >
> > Index: pfctl/parse.y
> > ===
> > RCS file: /cvs/src/sbin/pfctl/parse.y,v
> > retrieving revision 1.648
> > diff -u -p
I find it really useful to be able see output packets when tcpdump'ing
a vether(4) interface.
ok?
Index: net/if_vether.c
===
RCS file: /cvs/src/sys/net/if_vether.c,v
retrieving revision 1.23
diff -u -p -r1.23 if_vether.c
--- net/if_v
Let's take carp(4) out of ether_input(). This is quite similar to what
happened to trunk(4) and vlan(4).
I appreciate tests of any kind, reviews and oks.
Index: net/if_ethersubr.c
===
RCS file: /cvs/src/sys/net/if_ethersubr.c,v
retr
On our production systems we did hit the "relay_connect: no connection in
flight" on a so regular bases that I had to make it non-fatal with the
result of leaking sockets.
After more investigation I found the problem to be a race against
connecting to the backend servers. In short:
- relay_read_ht
On 22/05/15(Fri) 15:23, Martin Pieuchot wrote:
> I find it really useful to be able see output packets when tcpdump'ing
> a vether(4) interface.
>
> ok?
Please use this diff instead, the previous one relies on a non-committed
diff that changes carp_input(mbuf *, void *) -> carp_input(mbuf *).
In
Let's take carp(4) out of ether_input(). This is quite similar to what
happened to trunk(4) and vlan(4).
I appreciate tests of any kind, reviews and oks.
Index: net/if_ethersubr.c
===
RCS file: /cvs/src/sys/net/if_ethersubr.c,v
ret
* sven falempin [2015-05-22 14:18]:
> looking the rule actually show and unexpected result :
> match log on vic0 inet proto icmp from any to ! 8.8.8.8
> match log on vic0 inet proto icmp from any to 8.8.4.4
so it's even worse, you lose the negation on expansion for subsequent
rules.
> This resu
On Fri, May 22, 2015 at 10:15 AM, Henning Brauer
wrote:
> * sven falempin [2015-05-22 14:18]:
> > looking the rule actually show and unexpected result :
>
> > match log on vic0 inet proto icmp from any to ! 8.8.8.8
> > match log on vic0 inet proto icmp from any to 8.8.4.4
>
> so it's even worse,
On Thu, May 21, 2015 at 21:08 +0200, Alexandr Nedvedicky wrote:
> Hello,
>
> >
> > Well, not entirely (: I did it while exploring the code and sent
> > out to provoke further discussion. Today I've talked to reyk@ and
> > we think that it's better to go down a different road: make sure we
> > d
* sven falempin [2015-05-22 16:33]:
> But it does not explain the output i have.
otoh I'd say your diff is incomplete and misses a bit in expand_rule.
--
Henning Brauer, h...@bsws.de, henn...@openbsd.org
BS Web Services GmbH, http://bsws.de, Full-Service ISP
Secure Hosting, Mail and DNS. Virtua
Hey,
got a panic as of todays ‘cvs up’
trace below
panic: vmxnet3_rxintr: NULL ring->m[44]
Stopped at Debugger+0x9: leave
RUN AT LEAST 'trace' AND 'ps' AND INCLUDE OUTPUT WHEN REPORTING THIS PANIC!
IF RUNNING SMP, USE 'mach ddbcpu <#>' AND 'trace' ON OTHER PROCESSORS, TOO.
DO NOT EVEN BOTH
On Fri, May 22, 2015 at 19:35 +0200, mxb wrote:
>
> Hey,
> got a panic as of todays ‘cvs up’
> trace below
>
> panic: vmxnet3_rxintr: NULL ring->m[44]
> Stopped at Debugger+0x9: leave
> RUN AT LEAST 'trace' AND 'ps' AND INCLUDE OUTPUT WHEN REPORTING THIS PANIC!
> IF RUNNING SMP, USE 'mach
Not sure if I’ll be able to reproduce this at all.
Never seen this before.
But diff is applied.
//mxb
> On 22 maj 2015, at 19:53, Mike Belopuhov wrote:
>
> On Fri, May 22, 2015 at 19:35 +0200, mxb wrote:
>>
>> Hey,
>> got a panic as of todays ‘cvs up’
>> trace below
>>
>> panic: vmxnet3_rxint
On Fri, May 22, 2015 at 1:13 PM, Henning Brauer
wrote:
> * sven falempin [2015-05-22 16:33]:
> > But it does not explain the output i have.
>
> otoh I'd say your diff is incomplete and misses a bit in expand_rule.
>
>
Ok i get it now, log is not like pass, the is compute
through the ruleset and
This breaks relayd with TLS inspection. Moving down the "called
once" check after the F_TLSINSPECT block fixes the plain SSL case.
But HTTPS still hangs. I have just commited a test. Try
cd /usr/src/regress/usr.sbin/relayd && make run-regress-args-https-inspect.pl
bluhm
On Fri, May 22, 2015 a
On Tue, May 12, 2015 at 2:00 AM, Manuel Giraud wrote:
> Philip Guenther writes:
>
>> Can we suppress the device form if there's a matching DUID entry?
>
> Okay. The DUID/device dance is not that easy (at least for me). So here
> is a new patch that should work.
>
> For your issue, I choose to con
20 matches
Mail list logo
