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
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 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
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 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
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
* 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
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
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,
* 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
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
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
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
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
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
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
* 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)
* 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 -
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
* 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
20 matches
Mail list logo
