On 8/22/2019 6:51 PM, John Baldwin wrote:
> On 8/21/19 5:47 PM, Mike Tancsa wrote:
>> On 8/21/2019 6:38 PM, John Baldwin wrote:
>>> On 8/21/19 9:08 AM, mike tancsa wrote:
>>>> On 8/21/2019 12:00 PM, John Baldwin wrote:
>>>>> dtrace -n 'fbt::_gone_in:entry { @counts[curthread->td_proc->p_comm] =
>>>>> count()'
>>>> Thanks, I am not familiar with dtrace at all. This command gives a
>>>> syntax error
>>>>
>>>> 0(cage)# dtrace -n 'fbt::_gone_in:entry {
>>>> @counts[curthread->td_proc->p_comm] = count()'
>>>> dtrace: invalid probe specifier fbt::_gone_in:entry {
>>>> @counts[curthread->td_proc->p_comm] = count(): syntax error near end of
>>>> input
>>>> 1(cage)#
>>> Oops, I forgot the closing }. First, do "dtrace -l | grep _gone_in" to make
>>> sure dtrace is loaded. You should see something like this:
>>>
>>> # dtrace -l | grep _gone_in
>>> 87003 fbt kernel _gone_in entry
>>> 87004 fbt kernel _gone_in return
>>> 98682 fbt kernel _gone_in_dev entry
>>> 98683 fbt kernel _gone_in_dev return
>>>
>>> Then this should work:
>>>
>>> # dtrace -n 'fbt::_gone_in:entry { @counts[curthread->td_proc->p_comm] =
>>> count() }'
>>> dtrace: description 'fbt::_gone_in:entry ' matched 1 probe
>>>
>> Thanks!
>>
>> # dtrace -l | grep _gone_in
>> 15632 fbt kernel _gone_in entry
>> 22693 fbt kernel _gone_in_dev entry
>>
>> # dtrace -n 'fbt::_gone_in:entry { @counts[curthread->td_proc->p_comm] =
>> count() }'
>> dtrace: description 'fbt::_gone_in:entry ' matched 1 probe
>>
>> However, It doesnt show anything after that even as I get the
>> deprecation messages in dmesg
> Can you hit Ctrl-C after seeing some of the messages? This trace won't
> show any results until you exit dtrace.
Hi,
I am still having problems tracking it down via dtrace, but I am
able to create the problem on demand on sshd. Whats odd is that if I
restrict the list of ciphers in sshd and even specify something like
aes-128 on the client, I still get warnings on the server.
e.g from a client,
% ssh -c aes128-cbc console1 uptime
4:53PM up 1:02, 3 users, load averages: 0.04, 0.08, 0.08
The server shows
Aug 26 16:53:13 console1 kernel: Deprecated code (to be removed in
FreeBSD 13): ARC4 cipher via /dev/crypto
Aug 26 16:53:13 console1 kernel: Deprecated code (to be removed in
FreeBSD 13): DES cipher via /dev/crypto
Aug 26 16:53:13 console1 kernel: Deprecated code (to be removed in
FreeBSD 13): 3DES cipher via /dev/crypto
Aug 26 16:53:13 console1 kernel: Deprecated code (to be removed in
FreeBSD 13): Blowfish cipher via /dev/crypto
Aug 26 16:53:13 console1 kernel: Deprecated code (to be removed in
FreeBSD 13): CAST128 cipher via /dev/crypto
Aug 26 16:53:13 console1 kernel: Deprecated code (to be removed in
FreeBSD 13): ARC4 cipher via /dev/crypto
Aug 26 16:53:13 console1 kernel: Deprecated code (to be removed in
FreeBSD 13): DES cipher via /dev/crypto
Aug 26 16:53:13 console1 kernel: Deprecated code (to be removed in
FreeBSD 13): 3DES cipher via /dev/crypto
Aug 26 16:53:13 console1 kernel: Deprecated code (to be removed in
FreeBSD 13): Blowfish cipher via /dev/crypto
Aug 26 16:53:13 console1 kernel: Deprecated code (to be removed in
FreeBSD 13): CAST128 cipher via /dev/crypto
Aug 26 16:53:13 console1 kernel: Deprecated code (to be removed in
FreeBSD 13): ARC4 cipher via /dev/crypto
Aug 26 16:53:13 console1 kernel: Deprecated code (to be removed in
FreeBSD 13): DES cipher via /dev/crypto
Aug 26 16:53:13 console1 kernel: Deprecated code (to be removed in
FreeBSD 13): 3DES cipher via /dev/crypto
Aug 26 16:53:13 console1 kernel: Deprecated code (to be removed in
FreeBSD 13): Blowfish cipher via /dev/crypto
Aug 26 16:53:13 console1 kernel: Deprecated code (to be removed in
FreeBSD 13): CAST128 cipher via /dev/crypto
Despite having
Ciphers
aes128-cbc,aes192-cbc,aes256-cbc,aes128-ctr,aes192-ctr,aes256-ctr,aes128-...@openssh.com,aes256-...@openssh.com,chacha20-poly1...@openssh.com
in /etc/ssh/sshd_config
Doing ssh -v from the client doesnt show any of the warning ciphers
being used or proposed at all.
Just wondering what the value of the warnings are if there is no way to
really deal with them or even track down where the issues are ? Rather
than filling up the logs, would it be possible to have
kern.cryptodev_warn_interval=0
to disable ?
---Mike
_______________________________________________
freebsd-stable@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-stable
To unsubscribe, send any mail to "freebsd-stable-unsubscr...@freebsd.org"
