Hi.
(Please keep me in CC as I'm not subscribed to freebsd-net@.)
A router running recent 10-stable configured like this...
re0: flags=8843 metric 0 mtu 1500
options=8209b
ether 90:2b:34:bb:b2:e7
inet 82.x.y.50 netmask 0xfff0 broadcast 82.x.y.255
nd6 options=29
medi
On Fri, 20 Nov 2015 16:18:10 +0100
Kristof Provost wrote:
> Can you post your pf rules too?
Sure, pf.conf attached.
--
Dan
int_if="re1"
ext_if="re0"
vpn_if="tap0"
ext_addr="82.x.y.50"
int_net="192.168.2.0/24"
vpn_net="{ 192.168.1.0/24, 192.168.4.0
On Sat, 21 Nov 2015 22:20:43 +0100
Kristof Provost wrote:
>> Sure, pf.conf attached.
> Thanks. As a first guess, I think the origin of the problem might be
> related to the double nat rule you've got.
Well, even though pf may play some role in the problem, I tend to suspect
the routing table as
On Sun, 22 Nov 2015 13:02:40 +0100
Daniel Bilik wrote:
> Well, even though pf may play some role in the problem, I tend to suspect
> the routing table as the main trigger. There are several facts to support
> this...
It happened again, yesterday, and I can now definitely confirm
On Wed, 25 Nov 2015 12:20:33 +
Gary Palmer wrote:
> When the problem happens, what does the output of
> route -n get
> show?
I'll check this next time it happens. Thanks for the tip. Right now it
seems correct:
route to: 192.168.2.33
destination: 192.168.2.0
mask: 255.255.255.0
On Wed, 25 Nov 2015 12:20:33 +
Gary Palmer wrote:
> route -n get
As suggested by Kevin and Ryan, I set the router to drop redirects...
net.inet.icmp.drop_redirect: 1
... but it happened again today, and again affected host was 192.168.2.33.
Routing and arp entries were correct. Output of
On Sat, 28 Nov 2015 18:06:45 +0800
Julian Elischer wrote:
> next time it happens try flushing the arp table.
Just tried...
arp -d -a
... didn't help. Followed by refreshing default route, which solved it
again.
--
Dan
___
On Mon, 30 Nov 2015 23:47:18 +0800
Julian Elischer wrote:
> ok next time try
> netstat -raAnW before and after
Attached ("Internet6" part removed to reduce noise).
> maybe we can spot at difference.
According to diff(1), entries differ only by "Use" column between .pre
and .during. The .post o
On Tue, 1 Dec 2015 18:24:18 +0800
Julian Elischer wrote:
> if you reload pf it has no effect?
> pf is the part of the picture I have no experience with so I'm
> naturally suspicious of it.
> have you tried a simple ipfw nat instead? just as a sanity check?
Well, I have zero experience with ipf
On Tue, 1 Dec 2015 12:16:45 +0100
Daniel Bilik wrote:
> But next time it happens, I'll try to reload pf rules, and also to
> disable pf completely...
Done. First I've tried to flush nat...
# pfctl -f /etc/pf.conf -F nat -O -N
nat cleared
... then rules...
# pfctl -f /etc/pf.
nymore?
Thank you.
--
Daniel Bilik
___
freebsd-net@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-net
To unsubscribe, send any mail to "freebsd-net-unsubscr...@freebsd.org"
Hi.
(Please keep me in cc, I'm not subscribed to the list.)
After deploying ndproxy[1] on a few 10-stable hosts, some of them have
experienced mbuf clusters exhaustion. Initial analysis showed that after
loading ndproxy.ko, "current" values of "mbuf clusters" and "mbuf+clusters
out of packet seco
On Sat, 22 Jul 2017 12:11:31 +0300
"Andrey V. Elsukov" wrote:
> Freeing mbuf is under pfil hook responsibility, if it returns nonzero
> value it must call m_freem(). So, it is bug in the ndpacket.c.
Ah, thanks for clarifying this. It was quite unclear to me, because at
other place I've seen m_fr
13 matches
Mail list logo
