On 26.02.2018 15:53, Misak Khachatryan wrote:
> Hi Andrey,
>
> thanks for the patch! Is it safe to use it on 10.3?
It should be applicable to 10.3, but I don't know how it is safe :)
When there are no errors, it should work like before. When some error
occurs like you have, it will be ignore and
Hi Andrey,
thanks for the patch! Is it safe to use it on 10.3?
Best regards,
Misak Khachatryan
On Mon, Feb 26, 2018 at 4:39 PM, Andrey V. Elsukov wrote:
> On 22.02.2018 22:12, Misak Khachatryan wrote:
kernel`key_sendup0+0xee
kernel`key_sendup_mbuf+0x1e6
>>>
On 22.02.2018 22:12, Misak Khachatryan wrote:
>>> kernel`key_sendup0+0xee
>>> kernel`key_sendup_mbuf+0x1e6
>>> kernel`key_parse+0x87f
>>>
>>
>> Then probably this output will be changed.
I think the problem is that there are several PF_KEY sockets present,
bu
Here is changed output:
# sysctl net.raw
net.raw.recvspace: 8192
net.raw.sendspace: 8192
# sysctl net.raw.recvspace=65535
net.raw.recvspace: 8192 -> 65535
# sysctl net.raw.sendspace=65535
net.raw.sendspace: 8192 -> 65535
#
#
#
# setkey -x
setkey: send: No buffer space available
# dtrace -s /tmp/ke
On 22.02.2018 18:28, Misak Khachatryan wrote:
> # dtrace -s key.d
> dtrace: script 'key.d' matched 14 probes
> CPU IDFUNCTION:NAME
So, what I can say:
> 4 25400 soreserve:entry 8192 8192
> kernel`raw_attach+0x2a
> kernel`key_att
# dtrace -s key.d
dtrace: script 'key.d' matched 14 probes
CPU IDFUNCTION:NAME
2 25400 soreserve:entry 2048 4096
kernel`uipc_attach+0x76
kernel`socreate+0x1af
kernel`sys_socket+0xf7
3 25400 soreser
On 22.02.2018 16:27, Misak Khachatryan wrote:
> Here is the result:
>
> # dtrace -s key.d
> dtrace: script 'key.d' matched 8 probes
> CPU IDFUNCTION:NAME
> 3 25400 soreserve:entry 32768 65536
I hope the last update, to understand what is going on.
--
W
Here is the result:
# dtrace -s key.d
dtrace: script 'key.d' matched 8 probes
CPU IDFUNCTION:NAME
3 25400 soreserve:entry 32768 65536
7 25400 soreserve:entry 8192 8192
7 7957key_attach:return 0
7 12872
On 22.02.2018 15:13, Misak Khachatryan wrote:
> I did this way:
>
> # dtrace -s key.d
> dtrace: script 'key.d' matched 6 probes
> CPU IDFUNCTION:NAME
> 7 7957key_attach:return 0
> 7 7969 key_sendup0:return 0
> 7 7969 key_
I did this way:
# dtrace -s key.d
dtrace: script 'key.d' matched 6 probes
CPU IDFUNCTION:NAME
7 7957key_attach:return 0
7 7969 key_sendup0:return 0
7 7969 key_sendup0:return 55
7 24402 key_sendup_mbuf:return 5
I'm getting this:
# ./key.d
: No such file or directory
# which dtrace
/usr/sbin/dtrace
Best regards,
Misak Khachatryan
On Thu, Feb 22, 2018 at 3:42 PM, Andrey V. Elsukov wrote:
> On 22.02.2018 12:08, Misak Khachatryan wrote:
>> That didn help.
>>
>> Best regards,
>> Misak Khachatryan
>
> Can
On 22.02.2018 12:08, Misak Khachatryan wrote:
> That didn help.
>
> Best regards,
> Misak Khachatryan
Can you stop racoon and use the following commands and then show the output?
# kldload dtraceall
# chmod +x ./key.d
# ./key.d
and from another console run `setkey -x`, show what key.d will prin
That didn help.
Best regards,
Misak Khachatryan
On Thu, Feb 22, 2018 at 11:50 AM, Eugene Grosbein wrote:
> On 22.02.2018 14:10, Misak Khachatryan wrote:
>> Hello there,
>>
>> just a quick feedback. I've added rules to my ipfw to block all isakmp
>> ports on interfaces not involved in ipsec and
On 22.02.2018 14:10, Misak Khachatryan wrote:
> Hello there,
>
> just a quick feedback. I've added rules to my ipfw to block all isakmp
> ports on interfaces not involved in ipsec and rebooted 3 of 4
> machines. Situation returned to normal on them, but rebooting fourth
> host is very painful. It
Hello there,
just a quick feedback. I've added rules to my ipfw to block all isakmp
ports on interfaces not involved in ipsec and rebooted 3 of 4
machines. Situation returned to normal on them, but rebooting fourth
host is very painful. It seems i have some kind of massive ipsec
probes from botnet
On 20.02.2018 08:55, Eugene Grosbein wrote:
>> yes, all output is from same machine. I'll recheck all configs again,
>> or, if it's OK, I can post them here. The most confusing thing is that
>> everything worked as a charm several years. And nothing changed in
>> configurations until logs stars to
One of the machines didn't connected to the Internet, have only private ip
address on it's interfaces, so i have doubts about that. But thanks, I'll
check for that too. I'm exporting traffic from two machines to netflow
collector, should be easy.
On Feb 20, 2018 9:55 AM, "Eugene Grosbein" wrote:
On 20.02.2018 00:44, Misak Khachatryan wrote:
> Hi Andrey,
>
> yes, all output is from same machine. I'll recheck all configs again,
> or, if it's OK, I can post them here. The most confusing thing is that
> everything worked as a charm several years. And nothing changed in
> configurations until
Hi Andrey,
yes, all output is from same machine. I'll recheck all configs again,
or, if it's OK, I can post them here. The most confusing thing is that
everything worked as a charm several years. And nothing changed in
configurations until logs stars to fill up with these messages and i
tried to p
On 19.02.2018 12:28, Misak Khachatryan wrote:
> Hi,
>
> # vmstat -m | egrep "sec|sah|pol"
> inpcbpolicy 122 4K - 4955796 32
> secasvar 48558 12140K - 1572045 256
> sahead 3 1K - 15 256
> ipsecpolicy 25664K - 9911740 256
> ipsecre
BTW, restarting racoon produces this output:
# service racoon stop
Stopping racoon.
Waiting for PIDS: 54657.
# setkey -F; setkey -FP
send: No buffer space available
send: No buffer space available
# service racoon start
Starting racoon.
I did ktrace of setkey:
5499 setkey CALL socket(PF_KEY
HThis machine was rebooted few days ago and immediately it starts
behave like this,
FreeBSD xx.net 10.4-RELEASE-p1 FreeBSD 10.4-RELEASE-p1 #0: Mon Oct
30 21:13:49 +04 2017 x...@xx.net:/usr/obj/usr/src/sys/RTR
amd64
It's 64 bit system with 2 MB of memory:
# vmstat
procs memory
19.02.2018 16:28, Misak Khachatryan wrote:
> # vmstat -m | egrep "sec|sah|pol"
> inpcbpolicy 122 4K - 4955796 32
> secasvar 48558 12140K - 1572045 256
> sahead 3 1K - 15 256
> ipsecpolicy 25664K - 9911740 256
> ipsecrequest12
Hi,
# vmstat -m | egrep "sec|sah|pol"
inpcbpolicy 122 4K - 4955796 32
secasvar 48558 12140K - 1572045 256
sahead 3 1K - 15 256
ipsecpolicy 25664K - 9911740 256
ipsecrequest12 2K - 48 128
ipsec-misc 389632 1
19.02.2018 13:27, Misak Khachatryan wrote:
>1644111 messages with memory allocation failure
>
> 3 of machines running 10.4-RELEASE-p1, one 10.3.
> Two of the machine almost the same, only ip addresses and few lines of
> configs differ. One is OK, other one have problem.
>
> Running alm
Thanks, will try right now!
Best regards,
Misak Khachatryan
On Mon, Feb 19, 2018 at 12:23 PM, Andrey V. Elsukov wrote:
> On 19.02.2018 09:27, Misak Khachatryan wrote:
>>1644111 messages with memory allocation failure
>>
>> 3 of machines running 10.4-RELEASE-p1, one 10.3.
>> Two of the
On 19.02.2018 09:27, Misak Khachatryan wrote:
>1644111 messages with memory allocation failure
>
> 3 of machines running 10.4-RELEASE-p1, one 10.3.
> Two of the machine almost the same, only ip addresses and few lines of
> configs differ. One is OK, other one have problem.
You can inspe
Hello there,
I 4 machines with ipsec confingured by racoon and running well by
several years. A three week ago 3 of them starting to fill the log
with messages like this:
Feb 19 10:17:57 rtr-1 racoon: [10.1.0.2] ERROR: failed to process ph2
packet (side: 1, status: 8).
Feb 19 10:17:57 r
28 matches
Mail list logo
