Re: openssl in base should install c_rehash

2018-02-08 Thread Jung-uk Kim
On 02/08/2018 19:43, Ian Lepore wrote:
> It's not clear if openssl 1.1.0 installs a link or wrapper for c_rehash
> or not.  That manpage seems to imply that "openssl rehash" and
> "c_rehash" are equivelent.

"openssl rehash" is not a wrapper for "c_rehash".  This command is
available for all Unix-like platforms.

https://github.com/openssl/openssl/blob/master/apps/rehash.c

"c_rehash" is not a wrapper for "openssl rehash", either.  For Unix-like
platforms, it is only provided as a backup.

https://github.com/openssl/openssl/blob/master/tools/c_rehash.in

I guess they just forgot to add "functionally" in front of "equivalent". ;-)

Jung-uk Kim



signature.asc
Description: OpenPGP digital signature


Re: openssl in base should install c_rehash

2018-02-08 Thread Ian Lepore
On Thu, 2018-02-08 at 19:35 -0500, Jung-uk Kim wrote:
> On 02/08/2018 18:51, Ian Lepore wrote:
> > 
> > On Thu, 2018-02-08 at 17:47 -0500, Jung-uk Kim wrote:
> > > 
> > > On 02/08/2018 17:31, Chris H wrote:
> > > > 
> > > > 
> > > > [...]
> > > > Couldn't this be in $base? I'd like to vote yes. :-)
> > > From OpenSSL 1.1.0, openssl(1) added "rehash" command.
> > > 
> > > https://www.openssl.org/docs/man1.1.0/apps/rehash.html
> > > 
> > > I don't think we need yet another implementation in the base.
> > But on a machine I just set up last weekend using -current I get:
> > 
> > ian@th > openssl rehash
> > openssl:Error: 'rehash' is an invalid command.
> > ian@th > openssl version
> > OpenSSL 1.0.2n-freebsd  7 Dec 2017
> > 
> > Are we going to update to 1.1.0 soon?
> When I find some free time.  I don't know how "soon", however.
> 
> > 
> > If not, how does it help that a version we don't use has rehash
> > built in?
> We will have the feature when we import OpenSSL 1.1.0.  Knowing that it
> is obsoleted by the upstream, I don't want to add an equivalent script
> in the base.
> 
> If it is really necessary, you can always install the c_rehash script
> (security/openssl), openssl with rehash command
> (security/openssl-devel), openssl with certhash command
> (security/libressl), etc. from the ports tree.
> 
> BTW, we never had it in the base and it was removed from head src tree
> more than 5 years ago.  Why is it so important now? :-(

When looking for info (because of this thread) I noticed that lots of
how-to writeups on the web tell you to use the c_rehash command, so if
we don't supply one that's bad (or if we supply an alternate-named
thing we should document that somehow).

If we're just a bit behind but we're going to catch up eventually, then
that's good enough I think. 

It's not clear if openssl 1.1.0 installs a link or wrapper for c_rehash
or not.  That manpage seems to imply that "openssl rehash" and
"c_rehash" are equivelent.

-- Ian

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: openssl in base should install c_rehash

2018-02-08 Thread Jung-uk Kim
On 02/08/2018 18:51, Ian Lepore wrote:
> On Thu, 2018-02-08 at 17:47 -0500, Jung-uk Kim wrote:
>> On 02/08/2018 17:31, Chris H wrote:
>>>
>>> [...]
>>> Couldn't this be in $base? I'd like to vote yes. :-)
>> From OpenSSL 1.1.0, openssl(1) added "rehash" command.
>>
>> https://www.openssl.org/docs/man1.1.0/apps/rehash.html
>>
>> I don't think we need yet another implementation in the base.
> 
> But on a machine I just set up last weekend using -current I get:
> 
> ian@th > openssl rehash
> openssl:Error: 'rehash' is an invalid command.
> ian@th > openssl version
> OpenSSL 1.0.2n-freebsd  7 Dec 2017
> 
> Are we going to update to 1.1.0 soon?

When I find some free time.  I don't know how "soon", however.

> If not, how does it help that a version we don't use has rehash
> built in?

We will have the feature when we import OpenSSL 1.1.0.  Knowing that it
is obsoleted by the upstream, I don't want to add an equivalent script
in the base.

If it is really necessary, you can always install the c_rehash script
(security/openssl), openssl with rehash command
(security/openssl-devel), openssl with certhash command
(security/libressl), etc. from the ports tree.

BTW, we never had it in the base and it was removed from head src tree
more than 5 years ago.  Why is it so important now? :-(

Jung-uk Kim



signature.asc
Description: OpenPGP digital signature


Re: openssl in base should install c_rehash

2018-02-08 Thread Ian Lepore
On Thu, 2018-02-08 at 17:47 -0500, Jung-uk Kim wrote:
> On 02/08/2018 17:31, Chris H wrote:
> > 
> > [...]
> > Couldn't this be in $base? I'd like to vote yes. :-)
> From OpenSSL 1.1.0, openssl(1) added "rehash" command.
> 
> https://www.openssl.org/docs/man1.1.0/apps/rehash.html
> 
> I don't think we need yet another implementation in the base.
> 
> Jung-uk Kim
> 

But on a machine I just set up last weekend using -current I get:

ian@th > openssl rehash
openssl:Error: 'rehash' is an invalid command.
ian@th > openssl version
OpenSSL 1.0.2n-freebsd  7 Dec 2017

Are we going to update to 1.1.0 soon?  If not, how does it help that a
version we don't use has rehash built in?

-- Ian

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: openssl in base should install c_rehash

2018-02-08 Thread Jung-uk Kim
On 02/08/2018 17:31, Chris H wrote:
> On Thu, 08 Feb 2018 13:25:13 -0700 "Ian Lepore"  said
>> On Thu, 2018-02-08 at 21:15 +0100, Ulrich Spörlein wrote:
>> > 2018-02-08 21:00 GMT+01:00 Jung-uk Kim :
>> > > > > > On 02/08/2018 08:52, Jan Bramkamp wrote:
>> > > > > > > On 08.02.18 14:24, Ulrich Spörlein wrote:
>> > > > > > > > > Hey,
>> > > > > > > > > c_rehash has somehow disappeared from the base system.
>> We still
>> > > > > install the
>> > > > > manpage it seems, but the tool itself is missing. Can we have
>> > > > > that back?
>> > > > > > > > > > > > > root@acme:/etc/ssl# locate c_rehash
>> > > > > ...
>> > > > > /usr/share/openssl/man/man1/c_rehash.1.gz
>> > > > > /usr/src/crypto/openssl/doc/apps/c_rehash.pod
>> > > > > /usr/src/secure/usr.bin/openssl/man/c_rehash.1
>> > > > > > > > > > > > > The port seems to install it just fine:
>> > > > > > > > > root@acme:/etc/ssl# grep -r c_rehash /usr/ports/
>> > > > > /usr/ports/security/openssl/pkg-plist:bin/c_rehash
>> > > > > /usr/ports/security/openssl/pkg-plist:man/man1/c_rehash.1.gz
>> > > > > > > > > It looks like the merge of OpenSSL 1.0.1c got rid of
>> it (if I'm
>> > > > > reading the
>> > > > > history with git pickaxe right).
>> > > > The LibreSSL port lacks a c_rehash script as well. Putting
>> > > > c_rehash back
>> > > > into base wouldn't solve the problem because it requires Perl 5.
>> > > Correct.  I just removed the manual page to not confuse users.
>> > > > > https://svnweb.freebsd.org/changeset/base/329024
>> > > > > Thanks for letting me know!
>> > > > > Jung-uk Kim
>> > > > > > I would rather that c_rehash is brought back. I can install
>> perl just
>> > fine
>> > (or have it anyway installed), that's not the case with openssl from
>> > ports,
>> > as that will mess up many things.
>> > > Guess I'll download my own version ... :(
>> > > Uli
>>
>>
>> Maybe we should just replace ours in base with a non-perl version,
>> something like this one?
>>
>> https://opensource.apple.com/source/OpenSSL/OpenSSL-5/openssl/tools/c_rehash.in.auto.html
>>
>>
>> -- Ian
> Excellent link, Ian. Thanks!
> Couldn't this be in $base? I'd like to vote yes. :-)

From OpenSSL 1.1.0, openssl(1) added "rehash" command.

https://www.openssl.org/docs/man1.1.0/apps/rehash.html

I don't think we need yet another implementation in the base.

Jung-uk Kim



signature.asc
Description: OpenPGP digital signature


Re: openssl in base should install c_rehash

2018-02-08 Thread Chris H

On Thu, 08 Feb 2018 13:25:13 -0700 "Ian Lepore"  said


On Thu, 2018-02-08 at 21:15 +0100, Ulrich Spörlein wrote:
> 2018-02-08 21:00 GMT+01:00 Jung-uk Kim :
> 
> > 
> > On 02/08/2018 08:52, Jan Bramkamp wrote:
> > > 
> > > On 08.02.18 14:24, Ulrich Spörlein wrote:
> > > > 
> > > > Hey,
> > > > 
> > > > c_rehash has somehow disappeared from the base system. We still

> > > > install the
> > > > manpage it seems, but the tool itself is missing. Can we have
> > > > that back?
> > > > 
> > > > 
> > > > root@acme:/etc/ssl# locate c_rehash

> > > > ...
> > > > /usr/share/openssl/man/man1/c_rehash.1.gz
> > > > /usr/src/crypto/openssl/doc/apps/c_rehash.pod
> > > > /usr/src/secure/usr.bin/openssl/man/c_rehash.1
> > > > 
> > > > 
> > > > The port seems to install it just fine:
> > > > 
> > > > root@acme:/etc/ssl# grep -r c_rehash /usr/ports/

> > > > /usr/ports/security/openssl/pkg-plist:bin/c_rehash
> > > > /usr/ports/security/openssl/pkg-plist:man/man1/c_rehash.1.gz
> > > > 
> > > > It looks like the merge of OpenSSL 1.0.1c got rid of it (if I'm

> > > > reading the
> > > > history with git pickaxe right).
> > > The LibreSSL port lacks a c_rehash script as well. Putting
> > > c_rehash back
> > > into base wouldn't solve the problem because it requires Perl 5.
> > Correct.  I just removed the manual page to not confuse users.
> > 
> > https://svnweb.freebsd.org/changeset/base/329024
> > 
> > Thanks for letting me know!
> > 
> > Jung-uk Kim
> > 
> > 
> I would rather that c_rehash is brought back. I can install perl just

> fine
> (or have it anyway installed), that's not the case with openssl from
> ports,
> as that will mess up many things.
> 
> Guess I'll download my own version ... :(
> 
> Uli



Maybe we should just replace ours in base with a non-perl version,
something like this one?

https://opensource.apple.com/source/OpenSSL/OpenSSL-5/openssl/tools/c_rehash.in.auto.html

-- Ian

Excellent link, Ian. Thanks!
Couldn't this be in $base? I'd like to vote yes. :-)

--Chris


___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"



___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: openssl in base should install c_rehash

2018-02-08 Thread Jung-uk Kim
On 02/08/2018 15:15, Ulrich Spörlein wrote:
> 
> 2018-02-08 21:00 GMT+01:00 Jung-uk Kim  >:
> 
> On 02/08/2018 08:52, Jan Bramkamp wrote:
> > On 08.02.18 14:24, Ulrich Spörlein wrote:
> >> Hey,
> >>
> >> c_rehash has somehow disappeared from the base system. We still
> >> install the
> >> manpage it seems, but the tool itself is missing. Can we have that 
> back?
> >>
> >>
> >> root@acme:/etc/ssl# locate c_rehash
> >> ...
> >> /usr/share/openssl/man/man1/c_rehash.1.gz
> >> /usr/src/crypto/openssl/doc/apps/c_rehash.pod
> >> /usr/src/secure/usr.bin/openssl/man/c_rehash.1
> >>
> >>
> >> The port seems to install it just fine:
> >>
> >> root@acme:/etc/ssl# grep -r c_rehash /usr/ports/
> >> /usr/ports/security/openssl/pkg-plist:bin/c_rehash
> >> /usr/ports/security/openssl/pkg-plist:man/man1/c_rehash.1.gz
> >>
> >> It looks like the merge of OpenSSL 1.0.1c got rid of it (if I'm
> >> reading the
> >> history with git pickaxe right).
> >
> > The LibreSSL port lacks a c_rehash script as well. Putting c_rehash back
> > into base wouldn't solve the problem because it requires Perl 5.
> 
> Correct.  I just removed the manual page to not confuse users.
> 
> https://svnweb.freebsd.org/changeset/base/329024
> 
> 
> Thanks for letting me know!
> 
> Jung-uk Kim
> 
> 
> I would rather that c_rehash is brought back. I can install perl just
> fine (or have it anyway installed), that's not the case with openssl
> from ports, as that will mess up many things.

Although c_rehash was available from src/crypto/openssl/tools, we have
never installed it in the base, AFAIK.  Actually, it does not use proper
perl binary (i.e., /usr/bin/perl vs. /usr/local/bin/perl) and certs
directory (i.e., /usr/local/ssl/certs vs. /etc/ssl/certs).

https://svnweb.freebsd.org/base/vendor-crypto/openssl/dist-0.9.8/tools/c_rehash?revision=247942=co

Jung-uk Kim

> Guess I'll download my own version ... :(



signature.asc
Description: OpenPGP digital signature


Re: openssl in base should install c_rehash

2018-02-08 Thread Ian Lepore
On Thu, 2018-02-08 at 21:15 +0100, Ulrich Spörlein wrote:
> 2018-02-08 21:00 GMT+01:00 Jung-uk Kim :
> 
> > 
> > On 02/08/2018 08:52, Jan Bramkamp wrote:
> > > 
> > > On 08.02.18 14:24, Ulrich Spörlein wrote:
> > > > 
> > > > Hey,
> > > > 
> > > > c_rehash has somehow disappeared from the base system. We still
> > > > install the
> > > > manpage it seems, but the tool itself is missing. Can we have
> > > > that back?
> > > > 
> > > > 
> > > > root@acme:/etc/ssl# locate c_rehash
> > > > ...
> > > > /usr/share/openssl/man/man1/c_rehash.1.gz
> > > > /usr/src/crypto/openssl/doc/apps/c_rehash.pod
> > > > /usr/src/secure/usr.bin/openssl/man/c_rehash.1
> > > > 
> > > > 
> > > > The port seems to install it just fine:
> > > > 
> > > > root@acme:/etc/ssl# grep -r c_rehash /usr/ports/
> > > > /usr/ports/security/openssl/pkg-plist:bin/c_rehash
> > > > /usr/ports/security/openssl/pkg-plist:man/man1/c_rehash.1.gz
> > > > 
> > > > It looks like the merge of OpenSSL 1.0.1c got rid of it (if I'm
> > > > reading the
> > > > history with git pickaxe right).
> > > The LibreSSL port lacks a c_rehash script as well. Putting
> > > c_rehash back
> > > into base wouldn't solve the problem because it requires Perl 5.
> > Correct.  I just removed the manual page to not confuse users.
> > 
> > https://svnweb.freebsd.org/changeset/base/329024
> > 
> > Thanks for letting me know!
> > 
> > Jung-uk Kim
> > 
> > 
> I would rather that c_rehash is brought back. I can install perl just
> fine
> (or have it anyway installed), that's not the case with openssl from
> ports,
> as that will mess up many things.
> 
> Guess I'll download my own version ... :(
> 
> Uli


Maybe we should just replace ours in base with a non-perl version,
something like this one?

https://opensource.apple.com/source/OpenSSL/OpenSSL-5/openssl/tools/c_rehash.in.auto.html

-- Ian

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: openssl in base should install c_rehash

2018-02-08 Thread Justin Hibbits

On Feb 8, 2018, at 2:15 PM, Ulrich Spörlein wrote:


2018-02-08 21:00 GMT+01:00 Jung-uk Kim :


On 02/08/2018 08:52, Jan Bramkamp wrote:

On 08.02.18 14:24, Ulrich Spörlein wrote:

Hey,

c_rehash has somehow disappeared from the base system. We still
install the
manpage it seems, but the tool itself is missing. Can we have  
that back?



root@acme:/etc/ssl# locate c_rehash
...
/usr/share/openssl/man/man1/c_rehash.1.gz
/usr/src/crypto/openssl/doc/apps/c_rehash.pod
/usr/src/secure/usr.bin/openssl/man/c_rehash.1


The port seems to install it just fine:

root@acme:/etc/ssl# grep -r c_rehash /usr/ports/
/usr/ports/security/openssl/pkg-plist:bin/c_rehash
/usr/ports/security/openssl/pkg-plist:man/man1/c_rehash.1.gz

It looks like the merge of OpenSSL 1.0.1c got rid of it (if I'm
reading the
history with git pickaxe right).


The LibreSSL port lacks a c_rehash script as well. Putting  
c_rehash back

into base wouldn't solve the problem because it requires Perl 5.


Correct.  I just removed the manual page to not confuse users.

https://svnweb.freebsd.org/changeset/base/329024

Thanks for letting me know!

Jung-uk Kim


I would rather that c_rehash is brought back. I can install perl  
just fine
(or have it anyway installed), that's not the case with openssl from  
ports,

as that will mess up many things.

Guess I'll download my own version ... :(

Uli


Would this be something useful to add to src/tools?  Or create an  
explicit port for it?  Or just keep it handy yourself?


- Justin

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: openssl in base should install c_rehash

2018-02-08 Thread Ulrich Spörlein
2018-02-08 21:00 GMT+01:00 Jung-uk Kim :

> On 02/08/2018 08:52, Jan Bramkamp wrote:
> > On 08.02.18 14:24, Ulrich Spörlein wrote:
> >> Hey,
> >>
> >> c_rehash has somehow disappeared from the base system. We still
> >> install the
> >> manpage it seems, but the tool itself is missing. Can we have that back?
> >>
> >>
> >> root@acme:/etc/ssl# locate c_rehash
> >> ...
> >> /usr/share/openssl/man/man1/c_rehash.1.gz
> >> /usr/src/crypto/openssl/doc/apps/c_rehash.pod
> >> /usr/src/secure/usr.bin/openssl/man/c_rehash.1
> >>
> >>
> >> The port seems to install it just fine:
> >>
> >> root@acme:/etc/ssl# grep -r c_rehash /usr/ports/
> >> /usr/ports/security/openssl/pkg-plist:bin/c_rehash
> >> /usr/ports/security/openssl/pkg-plist:man/man1/c_rehash.1.gz
> >>
> >> It looks like the merge of OpenSSL 1.0.1c got rid of it (if I'm
> >> reading the
> >> history with git pickaxe right).
> >
> > The LibreSSL port lacks a c_rehash script as well. Putting c_rehash back
> > into base wouldn't solve the problem because it requires Perl 5.
>
> Correct.  I just removed the manual page to not confuse users.
>
> https://svnweb.freebsd.org/changeset/base/329024
>
> Thanks for letting me know!
>
> Jung-uk Kim
>
>
I would rather that c_rehash is brought back. I can install perl just fine
(or have it anyway installed), that's not the case with openssl from ports,
as that will mess up many things.

Guess I'll download my own version ... :(

Uli
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: openssl in base should install c_rehash

2018-02-08 Thread Jung-uk Kim
On 02/08/2018 08:52, Jan Bramkamp wrote:
> On 08.02.18 14:24, Ulrich Spörlein wrote:
>> Hey,
>>
>> c_rehash has somehow disappeared from the base system. We still
>> install the
>> manpage it seems, but the tool itself is missing. Can we have that back?
>>
>>
>> root@acme:/etc/ssl# locate c_rehash
>> ...
>> /usr/share/openssl/man/man1/c_rehash.1.gz
>> /usr/src/crypto/openssl/doc/apps/c_rehash.pod
>> /usr/src/secure/usr.bin/openssl/man/c_rehash.1
>>
>>
>> The port seems to install it just fine:
>>
>> root@acme:/etc/ssl# grep -r c_rehash /usr/ports/
>> /usr/ports/security/openssl/pkg-plist:bin/c_rehash
>> /usr/ports/security/openssl/pkg-plist:man/man1/c_rehash.1.gz
>>
>> It looks like the merge of OpenSSL 1.0.1c got rid of it (if I'm
>> reading the
>> history with git pickaxe right).
> 
> The LibreSSL port lacks a c_rehash script as well. Putting c_rehash back
> into base wouldn't solve the problem because it requires Perl 5.

Correct.  I just removed the manual page to not confuse users.

https://svnweb.freebsd.org/changeset/base/329024

Thanks for letting me know!

Jung-uk Kim



signature.asc
Description: OpenPGP digital signature


Re: I2C trackpad

2018-02-08 Thread Oleksandr Tymoshenko
Ian FREISLICH (ian.freisl...@capeaugusta.com) wrote:
> Hey,
> 
> I recently acquired a new laptop (Asus UX490U) which for the most part
> works with current except that:
> 
> 1. Sound output doesn't work.
> 2. The trackpad doesn't work.
> 
> I'm not bothered about sound and I haven't investigated that yet.  The
> trackpad not working is a nuisance, but I don't think that there's a
> short term fix.  I think it's connected via an I2C bus on one of two I2C
> controllers that don't have a driver attached:
> 
> none2@pci0:0:21:0:  class=0x118000 card=0x1c301043 chip=0x9d608086
> rev=0x21 hdr=0x00
>     vendor = 'Intel Corporation'
>     device = 'Sunrise Point-LP Serial IO I2C Controller'
>     class  = dasp
> none3@pci0:0:21:1:  class=0x118000 card=0x1c301043 chip=0x9d618086
> rev=0x21 hdr=0x00
>     vendor = 'Intel Corporation'
>     device = 'Sunrise Point-LP Serial IO I2C Controller'
>     class  = dasp
> 
> I've done some research and it looks like support is a long way off but
> I'm hoping someone has a work in progress I can test or hack on.

There is work in progress for I2C controller, not sure about touchpad
part: https://reviews.freebsd.org/D13654

-- 
gonzo
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


KDE crashed

2018-02-08 Thread johan callen
Hi,

Just after update my system on FreeBSD - HEAD, r328986, I have a crash on
my KDE with this message :
reading pre-existiting kdmrc /usr/local/share/config/kdm/kdmrc
shared object "libdl.so.1" not found, required by "kdm"

Desinstall and reinstall doesn't work by the way.

Anyone has an idea to solve it?

Thanks to all,

Johan
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


I2C trackpad

2018-02-08 Thread Ian FREISLICH
Hey,

I recently acquired a new laptop (Asus UX490U) which for the most part
works with current except that:

1. Sound output doesn't work.
2. The trackpad doesn't work.

I'm not bothered about sound and I haven't investigated that yet.  The
trackpad not working is a nuisance, but I don't think that there's a
short term fix.  I think it's connected via an I2C bus on one of two I2C
controllers that don't have a driver attached:

none2@pci0:0:21:0:  class=0x118000 card=0x1c301043 chip=0x9d608086
rev=0x21 hdr=0x00
    vendor = 'Intel Corporation'
    device = 'Sunrise Point-LP Serial IO I2C Controller'
    class  = dasp
none3@pci0:0:21:1:  class=0x118000 card=0x1c301043 chip=0x9d618086
rev=0x21 hdr=0x00
    vendor = 'Intel Corporation'
    device = 'Sunrise Point-LP Serial IO I2C Controller'
    class  = dasp

I've done some research and it looks like support is a long way off but
I'm hoping someone has a work in progress I can test or hack on.

Ian

-- 
Ian Freislich


-- 

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: openssl in base should install c_rehash

2018-02-08 Thread Jan Bramkamp

On 08.02.18 14:24, Ulrich Spörlein wrote:

Hey,

c_rehash has somehow disappeared from the base system. We still install the
manpage it seems, but the tool itself is missing. Can we have that back?


root@acme:/etc/ssl# locate c_rehash
...
/usr/share/openssl/man/man1/c_rehash.1.gz
/usr/src/crypto/openssl/doc/apps/c_rehash.pod
/usr/src/secure/usr.bin/openssl/man/c_rehash.1


The port seems to install it just fine:

root@acme:/etc/ssl# grep -r c_rehash /usr/ports/
/usr/ports/security/openssl/pkg-plist:bin/c_rehash
/usr/ports/security/openssl/pkg-plist:man/man1/c_rehash.1.gz

It looks like the merge of OpenSSL 1.0.1c got rid of it (if I'm reading the
history with git pickaxe right).


The LibreSSL port lacks a c_rehash script as well. Putting c_rehash back 
into base wouldn't solve the problem because it requires Perl 5.

___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


openssl in base should install c_rehash

2018-02-08 Thread Ulrich Spörlein
Hey,

c_rehash has somehow disappeared from the base system. We still install the
manpage it seems, but the tool itself is missing. Can we have that back?


root@acme:/etc/ssl# locate c_rehash
...
/usr/share/openssl/man/man1/c_rehash.1.gz
/usr/src/crypto/openssl/doc/apps/c_rehash.pod
/usr/src/secure/usr.bin/openssl/man/c_rehash.1


The port seems to install it just fine:

root@acme:/etc/ssl# grep -r c_rehash /usr/ports/
/usr/ports/security/openssl/pkg-plist:bin/c_rehash
/usr/ports/security/openssl/pkg-plist:man/man1/c_rehash.1.gz

It looks like the merge of OpenSSL 1.0.1c got rid of it (if I'm reading the
history with git pickaxe right).

Cheers,
Uli
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Re: Fatal trap 12 booting FreeBSD-CURRENT via isboot kernel module.

2018-02-08 Thread Maurizio Vairani
2018-02-07 19:29 GMT+01:00 John Nielsen :

> > On Feb 7, 2018, at 6:07 AM, Maurizio Vairani 
> wrote:
> >
> > 2018-02-06 23:02 GMT+01:00 John Nielsen :
> > > On Feb 6, 2018, at 11:50 AM, Ian Lepore  wrote:
> > >
> > > On Tue, 2018-02-06 at 11:33 -0700, John Nielsen wrote:
> > >>
> > >> Apparently sending a NULL socket pointer to ifioctl hasn't worked
> > >> since this commit in 2011:
> > >> https://svnweb.freebsd.org/base?view=revision=218757
> > >>
> > >> So I'm going to add this patch to the port unconditionally once it
> > >> works.
> > >>
> > >> Unfortunately, I can't compile the port with either my patch below or
> > >> your original replacement version of isboot_ifup(). :( Did you make
> > >> other changes? Here's the error I'm getting:
> > >>
> > >> --- isboot.o ---
> > >> isboot.c:425:53: error: incomplete definition of type 'struct thread'
> > >> error = socreate(AF_INET, , SOCK_DGRAM, 0, td->td_ucred, td);
> > >>   ~~^
> > >> /usr/src/sys/sys/systm.h:185:8: note: forward declaration of 'struct
> > >> thread'
> > >> struct thread;
> > >>^
> > >> 1 error generated.
> > >>
> > >
> > > Try adding #include  if it's not already in the list.  It
> > > may be that that file got included via pollution from some other header
> > > file in the past and maybe now that has changed.
> > >
> > > If you're already including sys/proc.h then I'm clueless.
> >
> > Thanks Ian, that appears to work.
> >
> > Maurizio, can you apply the attached patch to a clean ports tree and see
> if isboot-kmod will build and function properly for you? This is all the
> changes from this thread and the previous one. If you let me know it works
> I'll get the port updated.
> >
> >
> > Hi John, I need some help.
> >
> > I am running:
> >  # uname -a
> > FreeBSD  12.0-CURRENT FreeBSD 12.0-CURRENT #0 r328383: Thu Jan 25
> 04:48:52 UTC 2018 r...@releng3.nyi.freebsd.org:/
> usr/obj/usr/src/amd64.amd64/sys/GENERIC  amd64
> >
> > after upgrading the ports tree with:
> > # portsnap fetch update
> >
> > I have copied the directory /usr/ports/net/isboot-kmod/ in
> /root/src/isboot-kmod and /root/src/isboot-kmod.orig
> > # ls -l /root/src
> > total 6
> > drwxr-xr-x  3 root  wheel 6 Feb  7 13:46 isboot-kmod
> > drwxr-xr-x  3 root  wheel 6 Feb  7 13:46 isboot-kmod.orig
> > -rw-rw-rw-  1 root  wheel  5630 Feb  7 11:38 isboot_patch.txt
> >
> > Trying to apply the patch I obtain the error:
> > # cd /root/src
> > # patch -sC < isboot_patch.txt
> > 2 out of 2 hunks failed while patching isboot-kmod/Makefile
> > 5 out of 5 hunks failed while patching isboot-kmod/files/patch-isboot.c
> >
> > What I am missing ?
> > Thanks again for your work.
>
> Not sure but I ran in to similar issues testing here as well. Here's the
> "svn diff" patch which does work for me. Note that this one should be
> applied from within the isboot-kmod directory.
>
>
With this patch I receive this error :
# pwd
/root/src/isboot-kmod
# patch -sC  < ../isboot-kmod-0.2.13_2.diff.txt
2 out of 2 hunks failed while patching Makefile
5 out of 5 hunks failed while patching files/patch-isboot.c
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


Panic on Boot - Current AMD64

2018-02-08 Thread Juan Ramón Molina Menor

On Wed, Feb 07, 2018 at 12:18:26PM +0100, Juan Ramón Molina Menor wrote:
J> > Same panic here with HEAD from this afternoon in a Lenovo ThinkPad S440 
J> > with 4 GB.
J> > 
J> > Workaround: break into the loader prompt and:
J> > 
J> > set vm.boot_pages=120

J> > boot
J> > 
J> > When booting kernel.old, vm.boot_pages is 64.
J> > 
J> > There is something wrong with r328916.
J> 
J> Recent commits 328955, 328953 and 328952 by glebius@ do not resolve the 
J> issue here.


r328982 should fix the boot without specifing vm.boot_pages.

I'm sorry for problems.

--
Gleb Smirnoff


Yes, it is fixed, thanks!
___
freebsd-current@freebsd.org mailing list
https://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to "freebsd-current-unsubscr...@freebsd.org"


VIMAGE: vnet, epair and lots of jails on bridgeX - routing

2018-02-08 Thread O. Hartmann
Hello,

I fight with the following problem without any kind of success and I need some
help and/or advice.

We are running several CURRENT and 11.1-RELENG-p6 boxes. CURRENT is at the most
recent version as of today.

VIMAGE is compiled in into all kernels.
IPFW is compiled into all kernels and is the one and only firewall used.
On CURRENT, the host's ipfw is set to "OPEN" (using the rc.-scripts so far). By
convention, I address the host running the kernel by "host".

Every jail is created/configured with its own "vnet" cloned network stack
(vnet=new).

All hosts do have at least three physical NICs. The host itself is supposed to
be member of the "friendly" network via a dedicated NIC. The two remaining NICs
are split into fractions belonging to an "hostile" network on which I'd like to
place exposed jails (for now), and to the "friendly" network, on which also
jails will be hosted, but via a dedicated NIC.

Inbetween those two networks, the host will have a third, intermediate,
network, call it the "service" network.

The following will be true for ALL jails created, including the host itself:

net.link.bridge.pfil_member=0
net.link.bridge.pfil_bridge=0
net.link.bridge.pfil_onlyip=0

First, I clone/create three bridge(4) devices, bridge0 (considered to be the
"glue" between the "service" jails), bridge1 (considered to be the glue between
the jails on the friednly network side) and bridge2, which is the glue between
the jails on the hostile side. bridge1 has eth1 as a member, which provides the
physical access to the friendly network, eth2 is member of bridge2, which
provides access to the hostile network.

By convention, when creating epair(4), the a-portion belongs to the jail itself
and is assigned with an IPv6 address. The b-portion of the epair(4) is member
of its bridge according to its realm (friendly, service or hostile network). 

Additionally, there is a special jail, the router, which has three epair(4)
devices, the b-portion of the epair is member of the appropriate bridge(4) and
this router jail has static routes assigned, pointing to the appropriate
epairXXXa that is suppoesd to be the link into the correct bridge/network. IPFW
is set to open on this jail (for now). On this special
jail it is set: net.inet.ip.forwarding=1.

I hope, the topology is clear so far. All epairs or epair endpoints as well as
the bridges are UP! Double checked this.

Jails on bridge0 (service net) have IPs in the range 10.10.0.0/24, the
b-portion of the routing jail's epair is member of bridge0, as described above,
and the a-portion of the epair has IP 10.10.0.1. Default route on each jeail
on bridge0 is set to 10.10.0.1 accordingly.

Consider a similar setup on the other jails on the friendly and hostile
network, except the fact that their bridges do have a physical NIC to which
they may have access to a real network.

The setup might not be ideal and/or applicable for the purpose of separartion
of networks virtually, but that shouldn't be the subject here. More important
is that I assume that I haven't understood some essentials, because the setup
doens't work as expected. Furthermore, it behaves on FreeBSD 11.1-RELENG-p6
sometimes completely unpredictable - but in that special case, I think I ran
IPFW on the host as "WORKSTATION" and dynamic rules may play an important role
here. But focussing on the CURRENT box, the host's IPFW is set to OPEN.

With jexec -l hostA I gain access to host A on the "service" bridge0 and I
want to ping its neighbour, hostB, on the same bridge and in the same net. It
doesn't work! From the routing jail, I CAN NOT ping any host on bridge0. The
routing jail has these network settings:

[... routing jail ...]
 lo0: flags=8049 metric 0 mtu 16384
options=63
inet 127.0.0.1 netmask 0xff00 
groups: lo
[epair to bridge0 - service net] 
epair4000a: flags=8843 metric 0 mtu 1500
options=8
ether 02:57:d0:00:07:0a
inet 10.10.0.1 netmask 0xff00 broadcast 10.10.0.255 
media: Ethernet 10Gbase-T (10Gbase-T )
status: active
groups: epair
[epair to bridge1, friendly net] 
epair4001a: flags=8843 metric 0 mtu 1500
options=8
ether 02:57:d0:00:09:0a
inet 192.168.11.1 netmask 0xff00 broadcast 192.168.11.255 
media: Ethernet 10Gbase-T (10Gbase-T )
status: active
groups: epair
[epair to bridge2, hostile net] 
epair4002a: flags=8843 metric 0 mtu 1500
options=8
ether 02:57:d0:00:0b:0a
inet 10.10.10.1 netmask 0xfc00 broadcast 10.10.10.255 
media: Ethernet 10Gbase-T (10Gbase-T )
status: active
groups: epair 

routing:
netstat -Warn
Routing tables

Internet:
DestinationGatewayFlags   UseMtu  Netif Expire