Re: Not all ZFS pools mounting at boot

2016-03-09 Thread Andriy Gapon 
On 09/03/2016 06:54, Morgan Reed wrote:
> I am mounting the third pool under an alternate root, if that has any
> bearing on things.

It does.  A pool imported under an alternative root (-R option) is not added to
zpool.cache.

-- 
Andriy Gapon
___
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"

Re: Not all ZFS pools mounting at boot

2016-03-09 Thread Morgan Reed 
On Wed, Mar 9, 2016 at 7:23 PM, Andriy Gapon  wrote:

> On 09/03/2016 06:54, Morgan Reed wrote:
> > I am mounting the third pool under an alternate root, if that has any
> > bearing on things.
>
> It does.  A pool imported under an alternative root (-R option) is not
> added to
> zpool.cache.
>

Ah, it would seem that this is the root of my issue then, I'll try
importing it without the altroot switch and we'll see what happens.
___
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"

Re: Not all ZFS pools mounting at boot

2016-03-09 Thread Morgan Reed 
On Wed, Mar 9, 2016 at 10:04 PM, Morgan Reed 
wrote:

> On Wed, Mar 9, 2016 at 7:23 PM, Andriy Gapon  wrote:
>
>> On 09/03/2016 06:54, Morgan Reed wrote:
>> > I am mounting the third pool under an alternate root, if that has any
>> > bearing on things.
>>
>> It does.  A pool imported under an alternative root (-R option) is not
>> added to
>> zpool.cache.
>>
>
> Ah, it would seem that this is the root of my issue then, I'll try
> importing it without the altroot switch and we'll see what happens.
>

We have a winner, pool now mounts, a quick zfs set mountpoint later and it
even mounts in the right place. Thanks for the assist.
___
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"

Re: svn commit: r296462 - in stable/9: crypto/openssl/crypto/bio crypto/openssl/crypto/bn crypto/openssl/doc/apps crypto/openssl/ssl secure/usr.bin/openssl/man

2016-03-09 Thread Jeremy Chadwick 
(Please keep me CC'd as I'm not subscribed to -stable)

r296462 is either not ABI-compatible, or if it truly is, it breaks
internal behavioural compatibility with libcrypto/libssl in some way.
Building the below programs (fetchmail + postfix) from ports directly
(i.e. source) **does not** fix the problem.

Hope the gdb in fetchmail helps narrow down where the problem is.  Don't
ask me for "bt full" output, as it's pointless since none of the system
libs are built with -g/-g3/-ggdb.

I have no problems with SSH (unlike Mike), but that means very little
given configuration differences and setups.

Rolling back to r296461 (i.e. svn up -r296461) rectifies the problem
fully.

If jkim@ et al need a box running r296462 w/ full root to troubleshoot
this, let me know and I can set one up.  Might take a day or two though.

$ fetchmail -a -v
fetchmail: removing stale lockfile
fetchmail: 6.3.26 querying mambo.koitsu.org (protocol IMAP) at Wed  9 Mar 
04:55:16 2016: poll started
Trying to connect to 104.238.183.73/993...connected.
fetchmail: Server certificate:
fetchmail: Issuer Organisation: koitsu.org
fetchmail: Issuer CommonName: mambo.koitsu.org
fetchmail: Subject CommonName: mambo.koitsu.org
fetchmail: mambo.koitsu.org key fingerprint: 
F4:35:18:75:88:92:BF:1C:82:14:9E:17:EC:7E:3D:1C
fetchmail: mambo.koitsu.org fingerprints match.
fetchmail: Server certificate:
fetchmail: Issuer Organisation: koitsu.org
fetchmail: Issuer CommonName: mambo.koitsu.org
fetchmail: Subject CommonName: mambo.koitsu.org
Segmentation fault: 11 (core dumped)

$ gdb /usr/local/bin/fetchmail fetchmail.core
GNU gdb 6.1.1 [FreeBSD]
Copyright 2004 Free Software Foundation, Inc.
GDB is free software, covered by the GNU General Public License, and you are
welcome to change it and/or distribute copies of it under certain conditions.
Type "show copying" to see the conditions.
There is absolutely no warranty for GDB.  Type "show warranty" for details.
This GDB was configured as "amd64-marcel-freebsd"...(no debugging symbols 
found)...
Core was generated by `fetchmail'.
Program terminated with signal 11, Segmentation fault.
Reading symbols from /usr/local/lib/libintl.so.8...(no debugging symbols 
found)...done.
Loaded symbols for /usr/local/lib/libintl.so.8
Reading symbols from /usr/lib/libopie.so.7...(no debugging symbols 
found)...done.
Loaded symbols for /usr/lib/libopie.so.7
Reading symbols from /lib/libcrypt.so.5...(no debugging symbols found)...done.
Loaded symbols for /lib/libcrypt.so.5
Reading symbols from /lib/libkvm.so.5...(no debugging symbols found)...done.
Loaded symbols for /lib/libkvm.so.5
Reading symbols from /usr/lib/libcom_err.so.5...(no debugging symbols 
found)...done.
Loaded symbols for /usr/lib/libcom_err.so.5
Reading symbols from /usr/lib/libssl.so.6...(no debugging symbols found)...done.
Loaded symbols for /usr/lib/libssl.so.6
Reading symbols from /lib/libcrypto.so.6...(no debugging symbols found)...done.
Loaded symbols for /lib/libcrypto.so.6
Reading symbols from /usr/lib/libgssapi.so.10...(no debugging symbols 
found)...done.
Loaded symbols for /usr/lib/libgssapi.so.10
Reading symbols from /usr/lib/libheimntlm.so.10...(no debugging symbols 
found)...done.
Loaded symbols for /usr/lib/libheimntlm.so.10
Reading symbols from /usr/lib/libkrb5.so.10...(no debugging symbols 
found)...done.
Loaded symbols for /usr/lib/libkrb5.so.10
Reading symbols from /usr/lib/libhx509.so.10...(no debugging symbols 
found)...done.
Loaded symbols for /usr/lib/libhx509.so.10
Reading symbols from /usr/lib/libasn1.so.10...(no debugging symbols 
found)...done.
Loaded symbols for /usr/lib/libasn1.so.10
Reading symbols from /usr/lib/libroken.so.10...(no debugging symbols 
found)...done.
Loaded symbols for /usr/lib/libroken.so.10
Reading symbols from /lib/libc.so.7...(no debugging symbols found)...done.
Loaded symbols for /lib/libc.so.7
Reading symbols from /usr/local/lib/libiconv.so.2...(no debugging symbols 
found)...done.
Loaded symbols for /usr/local/lib/libiconv.so.2
Reading symbols from /lib/libmd.so.5...(no debugging symbols found)...done.
Loaded symbols for /lib/libmd.so.5
Reading symbols from /libexec/ld-elf.so.1...(no debugging symbols found)...done.
Loaded symbols for /libexec/ld-elf.so.1
#0  0x000801616774 in BN_mod_exp_mont_consttime () from /lib/libcrypto.so.6
(gdb) bt
#0  0x000801616774 in BN_mod_exp_mont_consttime () from /lib/libcrypto.so.6
#1  0x0008015f79f7 in DH_OpenSSL () from /lib/libcrypto.so.6
#2  0x0008012c8d25 in ssl3_send_client_key_exchange () from 
/usr/lib/libssl.so.6
#3  0x0008012cc0ab in ssl3_connect () from /usr/lib/libssl.so.6
#4  0x0008012c7d04 in ssl23_connect () from /usr/lib/libssl.so.6
#5  0x004052bf in ?? ()
#6  0x0040e360 in ?? ()
#7  0x0040813d in ?? ()
#8  0x0040a69a in ?? ()
#9  0x00404e01 in ?? ()
#10 0x00080065c000 in ?? ()
#11 0x in ?? ()
(gdb) q

Also tried to send mail to myself locally, as postfix's smtp(8) links to
libcrypt

Re: nfs_getpages: error 4

2016-03-09 Thread Dmitry Sivachenko 

> On 05 Mar 2016, at 23:10, Dmitry Sivachenko  wrote:
> 
> 
>> On 05 Mar 2016, at 21:35, Konstantin Belousov  wrote:
>> 
>> But I suspect that you do have enough free or reclamaible pages for OOM
>> to not trigger, e.g. because you demonstrated commands output from the
>> live system after the situation occured.  It more likely was a temporal
>> free page shortage, after which the system recovered.
>> 
>> I more believe in a bug in the handling of killed process in vm_fault().
>> Could you get the p_flag value for the hung process ?  Like
>>  ps -o flags 
> 
> 
> Unfortunately I already rebooted this machine because our developers needed 
> it and processes did not stop after kill -9.
> 
> When this repeats, I will try to keep this server up for longer time and 
> provide any necessary information.


So far I got the same error:

Mar  8 07:13:08 skazka4 kernel: nfs_getpages: error 4
Mar  8 07:13:08 skazka4 kernel: vm_fault: pager read error, pid 58483 (decodcmd)

But the process in question finished successfully.
___
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"

Re: [FreeBSD-Stable] svn commit: r296462 - in stable/9: crypto/openssl/crypto/bio crypto/openssl/crypto/bn crypto/openssl/doc/apps crypto/openssl/ssl secure/usr.bin/openssl/man

2016-03-09 Thread Mike Tancsa 
On 3/8/2016 1:13 PM, Craig Green wrote:
> 
> 
> On 2016-03-08 7:45 AM, Mike Tancsa wrote:
>> Hi,
>> I tried on 2 separate boxes, and sshd segfaults when this rev is
>> applied
>>
>> ---Mike
> 
> Just adding some debug logs showing a couple places where sshd exited.
> Encryption algorithm, kex and hmac didn't seem to matter.

Here is an example of where sshd chokes

good trace - pre openssl commit

debug2: kex_parse_kexinit:
hmac-sha1,hmac-sha1-96,hmac-md5,hmac-md5-96,umac...@openssh.com [preauth]
debug2: kex_parse_kexinit:
hmac-sha1,hmac-sha1-96,hmac-md5,hmac-md5-96,umac...@openssh.com [preauth]
debug2: kex_parse_kexinit: none [preauth]
debug2: kex_parse_kexinit: none [preauth]
debug2: kex_parse_kexinit:  [preauth]
debug2: kex_parse_kexinit:  [preauth]
debug2: kex_parse_kexinit: first_kex_follows 0  [preauth]
debug2: kex_parse_kexinit: reserved 0  [preauth]
debug2: mac_setup: setup hmac-sha1 [preauth]
debug1: kex: client->server aes256-ctr hmac-sha1 none [preauth]
debug2: mac_setup: setup hmac-sha1 [preauth]
debug1: kex: server->client aes256-ctr hmac-sha1 none [preauth]
debug1: SSH2_MSG_KEX_DH_GEX_REQUEST received [preauth]
debug3: mm_request_send entering: type 0 [preauth]
debug3: mm_request_receive entering
debug3: monitor_read: checking request 0
debug3: mm_answer_moduli: got parameters: 1024 2048 2048
debug3: mm_request_send entering: type 1
debug2: monitor_read: 0 used once, disabling now
debug3: mm_choose_dh: waiting for MONITOR_ANS_MODULI [preauth]
debug3: mm_request_receive_expect entering: type 1 [preauth]
debug3: mm_request_receive entering [preauth]
debug3: mm_choose_dh: remaining 0 [preauth]
*debug1: SSH2_MSG_KEX_DH_GEX_GROUP sent [preauth]*
*debug2: bits set: 1063/2048 [preauth]*
debug1: expecting SSH2_MSG_KEX_DH_GEX_INIT [preauth]
debug2: bits set: 1041/2048 [preauth]
debug3: mm_key_sign entering [preauth]
debug3: mm_request_send entering: type 6 [preauth]
debug3: mm_request_receive entering
debug3: monitor_read: checking request 6
debug3: mm_answer_sign
debug3: mm_answer_sign: signature 0x8034173c0(55)
debug3: mm_request_send entering: type 7
debug2: monitor_read: 6 used once, disabling now
debug3: mm_key_sign: waiting for MONITOR_ANS_SIGN [preauth]



bad trace - with openssl commit.

debug1: SSH2_MSG_KEX_DH_GEX_REQUEST received [preauth]
debug3: mm_request_send entering: type 0 [preauth]
debug3: mm_choose_dh: waiting for MONITOR_ANS_MODULI [preauth]
debug3: mm_request_receive_expect entering: type 1 [preauth]
debug3: mm_request_receive entering [preauth]
debug3: mm_request_receive entering
debug3: monitor_read: checking request 0
debug3: mm_answer_moduli: got parameters: 1024 2048 2048
debug3: mm_request_send entering: type 1
debug2: monitor_read: 0 used once, disabling now
debug3: mm_choose_dh: remaining 0 [preauth]
*debug1: SSH2_MSG_KEX_DH_GEX_GROUP sent [preauth]*
debug1: monitor_read_log: child log fd closed
debug3: mm_request_receive entering
debug1: do_cleanup
debug3: PAM: sshpam_thread_cleanup entering
debug1: Killing privsep child 1837



-- 
---
Mike Tancsa, tel +1 519 651 3400
Sentex Communications, m...@sentex.net
Providing Internet services since 1994 www.sentex.net
Cambridge, Ontario Canada   http://www.tancsa.com/
___
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"

Re: [FreeBSD-Stable] svn commit: r296462 - in stable/9: crypto/openssl/crypto/bio crypto/openssl/crypto/bn crypto/openssl/doc/apps crypto/openssl/ssl secure/usr.bin/openssl/man

2016-03-09 Thread Eric Masson 
Mike Tancsa  writes:

Hi,

> good trace - pre openssl commit
> 
> debug2: kex_parse_kexinit:
> hmac-sha1,hmac-sha1-96,hmac-md5,hmac-md5-96,umac...@openssh.com [preauth]
> debug2: kex_parse_kexinit:
> hmac-sha1,hmac-sha1-96,hmac-md5,hmac-md5-96,umac...@openssh.com [preauth]
> debug2: kex_parse_kexinit: none [preauth]
> debug2: kex_parse_kexinit: none [preauth]
> debug2: kex_parse_kexinit:  [preauth]
> debug2: kex_parse_kexinit:  [preauth]
> debug2: kex_parse_kexinit: first_kex_follows 0  [preauth]
> debug2: kex_parse_kexinit: reserved 0  [preauth]
> debug2: mac_setup: setup hmac-sha1 [preauth]
> debug1: kex: client->server aes256-ctr hmac-sha1 none [preauth]
> debug2: mac_setup: setup hmac-sha1 [preauth]
> debug1: kex: server->client aes256-ctr hmac-sha1 none [preauth]
> debug1: SSH2_MSG_KEX_DH_GEX_REQUEST received [preauth]
> debug3: mm_request_send entering: type 0 [preauth]
> debug3: mm_request_receive entering
> debug3: monitor_read: checking request 0
> debug3: mm_answer_moduli: got parameters: 1024 2048 2048
> bad trace - with openssl commit.
>
> debug1: SSH2_MSG_KEX_DH_GEX_REQUEST received [preauth]
> debug3: mm_request_send entering: type 0 [preauth]
> debug3: mm_choose_dh: waiting for MONITOR_ANS_MODULI [preauth]
> debug3: mm_request_receive_expect entering: type 1 [preauth]
> debug3: mm_request_receive entering [preauth]
> debug3: mm_request_receive entering
> debug3: monitor_read: checking request 0
> debug3: mm_answer_moduli: got parameters: 1024 2048 2048
> debug3: mm_request_send entering: type 1
> debug2: monitor_read: 0 used once, disabling now
> debug3: mm_choose_dh: remaining 0 [preauth]
> *debug1: SSH2_MSG_KEX_DH_GEX_GROUP sent [preauth]*
> debug1: monitor_read_log: child log fd closed
> debug3: mm_request_receive entering
> debug1: do_cleanup
> debug3: PAM: sshpam_thread_cleanup entering
> debug1: Killing privsep child 1837

Similar symptoms on 9.3-p37 when trying to connect with putty from a Win
7 station.

Using cygwin's openssh client doesn't trigger the issue.

Éric Masson

-- 
 J'ai essayé de creer un news un alt.west.virginia ou sur d'autres
 alt.west.wirginia.xxx mais quand je vais sur ces forums rien n'apparait?
 l'emetteur d'un new recoit il un avertissement si celui ci est censuré?
 -+- LM in:  - Bien sansurer ses news sur C-I -+-
___
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"

Build failed in Jenkins: FreeBSD_stable_10 #124

2016-03-09 Thread jenkins-admin 
See 

--
[...truncated 66798 lines...]
printf  '\t.section .note.GNU-stack,"",%%progbits\n' >>fchmodat.S
--- mknodat.S ---
--- fexecve.S ---
printf '#include "compat.h"\n' > fexecve.S
printf '#include "SYS.h"\nRSYSCALL(fexecve)\n' >> fexecve.S
printf  '\t.section .note.GNU-stack,"",%%progbits\n' >>fexecve.S
--- readlinkat.S ---
--- futimesat.S ---
printf '#include "compat.h"\n' > futimesat.S
printf '#include "SYS.h"\nRSYSCALL(futimesat)\n' >> futimesat.S
printf  '\t.section .note.GNU-stack,"",%%progbits\n' >>futimesat.S
--- unlinkat.S ---
--- mknodat.S ---
printf '#include "compat.h"\n' > mknodat.S
printf '#include "SYS.h"\nRSYSCALL(mknodat)\n' >> mknodat.S
printf  '\t.section .note.GNU-stack,"",%%progbits\n' >>mknodat.S
--- shmctl.S ---
--- readlinkat.S ---
printf '#include "compat.h"\n' > readlinkat.S
printf '#include "SYS.h"\nRSYSCALL(readlinkat)\n' >> readlinkat.S
printf  '\t.section .note.GNU-stack,"",%%progbits\n' >>readlinkat.S
--- lpathconf.S ---
--- cap_getmode.S ---
--- unlinkat.S ---
printf '#include "compat.h"\n' > unlinkat.S
printf '#include "SYS.h"\nRSYSCALL(unlinkat)\n' >> unlinkat.S
printf  '\t.section .note.GNU-stack,"",%%progbits\n' >>unlinkat.S
--- shmctl.S ---
printf '#include "compat.h"\n' > shmctl.S
printf '#include "SYS.h"\nRSYSCALL(shmctl)\n' >> shmctl.S
printf  '\t.section .note.GNU-stack,"",%%progbits\n' >>shmctl.S
--- pdfork.S ---
--- lpathconf.S ---
printf '#include "compat.h"\n' > lpathconf.S
printf '#include "SYS.h"\nRSYSCALL(lpathconf)\n' >> lpathconf.S
printf  '\t.section .note.GNU-stack,"",%%progbits\n' >>lpathconf.S
--- pdkill.S ---
--- cap_getmode.S ---
printf '#include "compat.h"\n' > cap_getmode.S
printf '#include "SYS.h"\nRSYSCALL(cap_getmode)\n' >> cap_getmode.S
printf  '\t.section .note.GNU-stack,"",%%progbits\n' >>cap_getmode.S
--- posix_fallocate.S ---
--- pdfork.S ---
printf '#include "compat.h"\n' > pdfork.S
printf '#include "SYS.h"\nRSYSCALL(pdfork)\n' >> pdfork.S
printf  '\t.section .note.GNU-stack,"",%%progbits\n' >>pdfork.S
--- posix_fadvise.S ---
--- pdkill.S ---
printf '#include "compat.h"\n' > pdkill.S
printf '#include "SYS.h"\nRSYSCALL(pdkill)\n' >> pdkill.S
printf  '\t.section .note.GNU-stack,"",%%progbits\n' >>pdkill.S
--- cap_rights_limit.S ---
--- posix_fallocate.S ---
printf '#include "compat.h"\n' > posix_fallocate.S
--- cap_ioctls_get.S ---
--- posix_fallocate.S ---
printf '#include "SYS.h"\nRSYSCALL(posix_fallocate)\n' >> posix_fallocate.S
printf  '\t.section .note.GNU-stack,"",%%progbits\n' >>posix_fallocate.S
--- posix_fadvise.S ---
printf '#include "compat.h"\n' > posix_fadvise.S
printf '#include "SYS.h"\nRSYSCALL(posix_fadvise)\n' >> posix_fadvise.S
printf  '\t.section .note.GNU-stack,"",%%progbits\n' >>posix_fadvise.S
--- cap_fcntls_get.S ---
--- cap_rights_limit.S ---
printf '#include "compat.h"\n' > cap_rights_limit.S
printf '#include "SYS.h"\nRSYSCALL(cap_rights_limit)\n' >> cap_rights_limit.S
printf  '\t.section .note.GNU-stack,"",%%progbits\n' >>cap_rights_limit.S
--- procctl.S ---
--- cap_ioctls_get.S ---
printf '#include "compat.h"\n' > cap_ioctls_get.S
printf '#include "SYS.h"\nRSYSCALL(cap_ioctls_get)\n' >> cap_ioctls_get.S
printf  '\t.section .note.GNU-stack,"",%%progbits\n' >>cap_ioctls_get.S
--- _pwrite.S ---
--- cap_fcntls_get.S ---
printf '#include "compat.h"\n' > cap_fcntls_get.S
printf '#include "SYS.h"\nRSYSCALL(cap_fcntls_get)\n' >> cap_fcntls_get.S
printf  '\t.section .note.GNU-stack,"",%%progbits\n' >>cap_fcntls_get.S
--- _mmap.S ---
--- procctl.S ---
printf '#include "compat.h"\n' > procctl.S
printf '#include "SYS.h"\nRSYSCALL(procctl)\n' >> procctl.S
--- _aio_suspend.S ---
--- procctl.S ---
printf  '\t.section .note.GNU-stack,"",%%progbits\n' >>procctl.S
--- _pwrite.S ---
printf '#include "compat.h"\n' > _pwrite.S
printf '#include "SYS.h"\nPSEUDO(pwrite)\n'  >> _pwrite.S
printf '\t.section .note.GNU-stack,"",%%progbits\n' >>_pwrite.S
--- _close.S ---
--- _mmap.S ---
printf '#include "compat.h"\n' > _mmap.S
printf '#include "SYS.h"\nPSEUDO(mmap)\n'  >> _mmap.S
printf '\t.section .note.GNU-stack,"",%%progbits\n' >>_mmap.S
--- _msync.S ---
--- _openat.S ---
--- _aio_suspend.S ---
printf '#include "compat.h"\n' > _aio_suspend.S
printf '#include "SYS.h"\nPSEUDO(aio_suspend)\n'  >> _aio_suspend.S
printf '\t.section .note.GNU-stack,"",%%progbits\n' >>_aio_suspend.S
--- _close.S ---
printf '#include "compat.h"\n' > _close.S
printf '#include "SYS.h"\nPSEUDO(close)\n'  >> _close.S
--- _poll.S ---
--- _close.S ---
printf '\t.section .note.GNU-stack,"",%%progbits\n' >>_close.S
--- _msync.S ---
printf '#include "compat.h"\n' > _msync.S
printf '#include "SYS.h"\nPSEUDO(msync)\n'  >> _msync.S
--- _ppoll.S ---
--- _msync.S ---
printf '\t.section .note.GNU-stack,"",%%progbits\n' >>_msync.S
--- _openat.S ---
printf '#include "compat.h"\n' > _openat.S
printf '#include "SYS.h"\nPSEUDO(openat)\n'  >> _openat.S
printf '\t.section .note.GNU-stack,""

[Solved] Problems with ucom/uftdi and sendfax on 10.2 p12 (works like a charm with 7.4)

2016-03-09 Thread Holger Kipp 
Dear Ian,

> On 02.03.2016, at 11:45, Holger Kipp  wrote:
>
>
> Am 01.03.2016 um 23:08 schrieb Ian Lepore 
> mailto:i...@freebsd.org>>:
>
> On Tue, 2016-03-01 at 19:58 +, Holger Kipp wrote:
> Hi all,
>
> I currently encounter a problem with sending faxes with new server
> and FreeBSD 10.2-RELEASE p12
> using mgetty+sendfax and RS232-Modems via USB to RS232-Adapter (com,
> uftdi).
>
> Problem is that _after_ sending the first page, the reply of modem is
> not read correctly.
>
> In Error case, Faxlog says:
>
> 02/29 18:46:10 aU4read 64, write 64
> 02/29 18:46:10 aU4read 52, write 52
> 02/29 18:46:10 aU4  page complete, 40900 bytes sent
> 02/29 18:46:10 aU4  sending DLE ','
> 02/29 18:46:10 aU4got:[0a][0d][0a]OK[0d]
> 02/29 18:46:18 aU4  got response: 'OK'
> 02/29 18:46:18 aU4   fax_send_page("f2.g3") started...
> 02/29 18:46:18 aU4   tio_set_flow_control( HARD )
> 02/29 18:46:18 aU4  fax_send: 'AT+FDT'
> 02/29 18:46:18 aU4  fax_wait_for(CONNECT)
> 02/29 18:46:18 aU4got:[0a]
> 02/29 18:48:18 aU4  Warning: got alarm signal!
>
> So I run into timeout because the modem does not reply as expected
> after AT+FDT-command (maybe even after sending DLE ',‘ because the OK
> response seems to take some more time than under FreeBSD 7.4).
>
>
> if I issue "tip modem4" (which is /dev/cuaU4), I get the missing
> replies including CONNECT from the modem (then leaving tip with "~.“)
>
> root@faxserver:/usr/local/etc/mgetty+sendfax # tip modem4
> connected
> AT+FDT
> CONNECT
>
> +FHS:43
>
> OK
> AT+FCLASS=0
> OK
> ~
> [EOT]
> root@faxserver:/usr/local/etc/mgetty+sendfax #
>
>
> This works correctly with same modems and USB to RS232-Adapter
> (uftdi) under FreeBSD 7.4.
>
> 02/29 12:18:26 aU4  receiver cap.: '+FIS:1,5,0,2,1,1,0,3' -> fine 144
> 2D/MR ECM** found **
> 02/29 12:18:26 aU4  sendfax: IGNORE DCD (carrier) status
> 02/29 12:18:26 aU4  fax_send: 'AT+FDT'
> 02/29 12:18:26 aU4  fax_wait_for(CONNECT)
> 02/29 12:18:33 aU4  transmission par.: '+FCS:1,5,0,2,0,0,0,3'** found
> **
> 02/29 12:18:33 aU4  sending f1.g3...
> 02/29 12:19:04 aU4  page complete, 34495 bytes sent
> 02/29 12:19:04 aU4  sending DLE ','
> 02/29 12:19:10 aU4  got response: 'OK'
> 02/29 12:19:10 aU4  fax_send: 'AT+FDT'
> 02/29 12:19:10 aU4  fax_wait_for(CONNECT)** found **
> 02/29 12:19:11 aU4  sending f2.g3...
> 02/29 12:19:55 aU4  page complete, 60064 bytes sent
> 02/29 12:19:55 aU4  sending DLE ','
> 02/29 12:20:01 aU4  got response: 'OK'
> 02/29 12:20:01 aU4  fax_send: 'AT+FDT'
> 02/29 12:20:01 aU4  fax_wait_for(CONNECT)** found **
> 02/29 12:20:01 aU4  sending f3.g3...
> 02/29 12:20:52 aU4  page complete, 71335 bytes sent
> 02/29 12:20:52 aU4  sending DLE ','
> 02/29 12:20:57 aU4  got response: 'OK'
> 02/29 12:20:57 aU4  fax_send: 'AT+FDT'
> 02/29 12:20:57 aU4  fax_wait_for(CONNECT)** found **
> 02/29 12:20:58 aU4  sending f4.g3...
> 02/29 12:21:40 aU4  page complete, 58628 bytes sent
> 02/29 12:21:40 aU4  sending DLE '.'
> 02/29 12:21:49 aU4  connection hangup: '+FHS:00'
> 02/29 12:21:49 aU4  got response: 'OK'
> 02/29 12:21:49 aU4  fax_send: 'AT+FCLASS=0'
>
> This is with devolo 56k i ISDN-modems, but it looks more like a USB
> interface communication issue to me.
>
> Modems and USB-to-RS232 are the same - connected to FreeBSD 7.4
> servers works (sends all pages), connected to 10.2 server does not
> work (sends first page only).
>
> I can also provide dmesg.boot details on request but didn’t want to
> pollute the list.
>
> Difference with stty -a /dev/cuaU4 seems to be clocal instead of
> -clocal which I can’t set for cuaU4, only for .init and .lock. which
> does not help.
> 7.4 Kernel comes with uftdi and ucom compiled in.
> 10.2 Kernel has the same issues with ucom and uftdi loaded as kernel
> modules or compiled in.
>
> mgetty+sendfax is version 1.1.35_1 on FreeBSD 7.4 and version 1.1.37
> on FreeBSD 10.2-RELEASE p12.
>
> Any other ideas where to look further or what to investigate?
>
> Many thanks and best regards,
> Holger
>
> Seeing "tio_set_flow_control( HARD )>" in your output, along with the
> fact that you said the expected output finally appeared after you
> connected with tip, makes me suspect that flow control is at the root
> of this problem.
>
> The biggest ftdi driver difference before/after freebsd 8 is that the
> driver used to automatically re-intialize the chip on every open to set
> up some arbitrary combination of comms parameters (baud, flow control,
> etc) -- I forget all the details now, I'd have to do some digging
> through logs to find exactly what it used to set.  Now the driver
> leaves the chip alone at open time, and the contents of the
> /dev/cuaU#.init and cuaU#.lock files should be completely in control of
> the serial parameters.
>
> Is it possible that you set up the .init and/or .lock devices in some
> rc script in freebsd 7 and forgot about it?  If not, then maybe the
> driver init changes are enough to explain the glitch.
>
> I wonder if this would fix it:
>
> stty -f /dev/cuaU4.init crtsc

Re: [FreeBSD-Stable] svn commit: r296462 - in stable/9: crypto/openssl/crypto/bio crypto/openssl/crypto/bn crypto/openssl/doc/apps crypto/openssl/ssl secure/usr.bin/openssl/man

2016-03-09 Thread Dimitry Andric 
On 09 Mar 2016, at 16:48, Eric Masson  wrote:
> 
> Mike Tancsa  writes:
> 
> Hi,
> 
>> good trace - pre openssl commit
>> 
>> debug2: kex_parse_kexinit:
>> hmac-sha1,hmac-sha1-96,hmac-md5,hmac-md5-96,umac...@openssh.com [preauth]
>> debug2: kex_parse_kexinit:
>> hmac-sha1,hmac-sha1-96,hmac-md5,hmac-md5-96,umac...@openssh.com [preauth]
>> debug2: kex_parse_kexinit: none [preauth]
>> debug2: kex_parse_kexinit: none [preauth]
>> debug2: kex_parse_kexinit:  [preauth]
>> debug2: kex_parse_kexinit:  [preauth]
>> debug2: kex_parse_kexinit: first_kex_follows 0  [preauth]
>> debug2: kex_parse_kexinit: reserved 0  [preauth]
>> debug2: mac_setup: setup hmac-sha1 [preauth]
>> debug1: kex: client->server aes256-ctr hmac-sha1 none [preauth]
>> debug2: mac_setup: setup hmac-sha1 [preauth]
>> debug1: kex: server->client aes256-ctr hmac-sha1 none [preauth]
>> debug1: SSH2_MSG_KEX_DH_GEX_REQUEST received [preauth]
>> debug3: mm_request_send entering: type 0 [preauth]
>> debug3: mm_request_receive entering
>> debug3: monitor_read: checking request 0
>> debug3: mm_answer_moduli: got parameters: 1024 2048 2048
>> bad trace - with openssl commit.
>> 
>> debug1: SSH2_MSG_KEX_DH_GEX_REQUEST received [preauth]
>> debug3: mm_request_send entering: type 0 [preauth]
>> debug3: mm_choose_dh: waiting for MONITOR_ANS_MODULI [preauth]
>> debug3: mm_request_receive_expect entering: type 1 [preauth]
>> debug3: mm_request_receive entering [preauth]
>> debug3: mm_request_receive entering
>> debug3: monitor_read: checking request 0
>> debug3: mm_answer_moduli: got parameters: 1024 2048 2048
>> debug3: mm_request_send entering: type 1
>> debug2: monitor_read: 0 used once, disabling now
>> debug3: mm_choose_dh: remaining 0 [preauth]
>> *debug1: SSH2_MSG_KEX_DH_GEX_GROUP sent [preauth]*
>> debug1: monitor_read_log: child log fd closed
>> debug3: mm_request_receive entering
>> debug1: do_cleanup
>> debug3: PAM: sshpam_thread_cleanup entering
>> debug1: Killing privsep child 1837
> 
> Similar symptoms on 9.3-p37 when trying to connect with putty from a Win
> 7 station.
> 
> Using cygwin's openssh client doesn't trigger the issue.

Can you please try the attached patch, which I also attached to PR
207783?  I think this will solve the crashes.

It should be enough to rebuild secure/lib/libcrypto, and install it.

-Dimitry


fix-pr207783-1.diff
Description: Binary data


signature.asc
Description: Message signed with OpenPGP using GPGMail

Re: [FreeBSD-Stable] svn commit: r296462 - in stable/9: crypto/openssl/crypto/bio crypto/openssl/crypto/bn crypto/openssl/doc/apps crypto/openssl/ssl secure/usr.bin/openssl/man

2016-03-09 Thread Mike Tancsa 
On 3/9/2016 5:06 PM, Dimitry Andric wrote:

> Can you please try the attached patch, which I also attached to PR
> 207783?  I think this will solve the crashes.
> 
> It should be enough to rebuild secure/lib/libcrypto, and install it.

Hi,
Yes it allows sshd to not crash on my one test case (secureCRT client)
so far!  Thanks.

---Mike


-- 
---
Mike Tancsa, tel +1 519 651 3400
Sentex Communications, m...@sentex.net
Providing Internet services since 1994 www.sentex.net
Cambridge, Ontario Canada   http://www.tancsa.com/
___
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"

Re: [FreeBSD-Stable] svn commit: r296462 - in stable/9: crypto/openssl/crypto/bio crypto/openssl/crypto/bn crypto/openssl/doc/apps crypto/openssl/ssl secure/usr.bin/openssl/man

2016-03-09 Thread Craig Green 

On 2016-03-09 5:19 PM, Mike Tancsa wrote:

On 3/9/2016 5:06 PM, Dimitry Andric wrote:


Can you please try the attached patch, which I also attached to PR
207783?  I think this will solve the crashes.

It should be enough to rebuild secure/lib/libcrypto, and install it.

Hi,
Yes it allows sshd to not crash on my one test case (secureCRT client)
so far!  Thanks.


Looks to work as well on the second server here that SSH was crashing on.


Thanks. :-)

Craig.
--
___
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"

Jenkins build is back to normal : FreeBSD_stable_10 #125

2016-03-09 Thread jenkins-admin 
See 

___
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"

fetch(1) always dumps core - openssl issue?

2016-03-09 Thread Chris H 
Greetings,
I just built/installed world/kernel on a fresh
STABLE-9 box. Now building ports almost always results
in fetch(1) dumping core. It appears that this happens
on ssl enabled hosts. Resulting in fetch dropping to
distcache.freebsd.org.
I see a lot of noise on the lists regarding openssl
issues recently. So thought I'd mention this, in hopes
of finding a solution.

Thanks!

--Chris

--


___
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"

Re: fetch(1) always dumps core - openssl issue?

2016-03-09 Thread Xin Li 


On 3/9/16 19:09, Chris H wrote:
> Greetings,
> I just built/installed world/kernel on a fresh
> STABLE-9 box. Now building ports almost always results
> in fetch(1) dumping core. It appears that this happens
> on ssl enabled hosts. Resulting in fetch dropping to
> distcache.freebsd.org.
> I see a lot of noise on the lists regarding openssl
> issues recently. So thought I'd mention this, in hopes
> of finding a solution.

Please update to r296597+.

Cheers,



signature.asc
Description: OpenPGP digital signature

Re: fetch(1) always dumps core - openssl issue?

2016-03-09 Thread Chris H 
On Wed, 9 Mar 2016 21:28:48 -0800 Xin Li  wrote

> On 3/9/16 19:09, Chris H wrote:
> > Greetings,
> > I just built/installed world/kernel on a fresh
> > STABLE-9 box. Now building ports almost always results
> > in fetch(1) dumping core. It appears that this happens
> > on ssl enabled hosts. Resulting in fetch dropping to
> > distcache.freebsd.org.
> > I see a lot of noise on the lists regarding openssl
> > issues recently. So thought I'd mention this, in hopes
> > of finding a solution.
> 
> Please update to r296597+.
> 
> Cheers,
Will do. Thank you very much!


--Chris

--


___
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"