ThinkPad X1 Carbon Gen3
- zzz
- I can almost resume it from RAM with "Security Chip" ("TPM") disabled
in the BIOS setting. Except display remains off. With TPM enabled,
I couldn't power on the machine after suspend to RAM.
- ZZZ
- Disabling TPM doesn't help hibernation.
- I tried disabling various devices (iwm, em, xhci, ehci, ...). Didn't
help instability of hibernation.
- Most failures are not recognizing hibernation (`/ was not properly
unmounted')
- Unhibernation succeeds when you are really lucky. :)
Re: IPV6 routing issue
Em 26-06-2015 16:44, Christian Weisgerber escreveu: Well, you can add an IPv6 address for each internal host to the external interface of your firewall, use private addresses on the internal network, and then use pf's binat to map between the two. This will preserve port numbers, although it may not be enough for nasty protocols like SIP. I know I could use NAT. But, I really think it's almost an abomination to use it, when you have native IPv6 support. I'll contact my ISP to see if they can change my CPE mode of operation or, at least, allow me to configure it. In the meantime, I'll go with a bridge firewall. It seems like the most hassle free way to go. Perhaps I'll hack some NDP proxy. But I need IPv6 connectivity, and I need it now. Cheers, Giancarlo Razzolini
Re: FFS snapshoting/softupdates status
On 2015-06-20, Karel Gardas wrote: > just going thorough papers/presentations and surprisingly found that > kind of snapshoting is already supported in UFS since '99, FreeBSD > probably supports that, Yes, FreeBSD has had snapshots on UFS for a long time. It doesn't support the combination of snapshots and journaling, though. > On the other hand I've found [4] which is positive about possible > inclusion of functionality in OpenBSD but just manpower is missing. > The question here is if this 11 years old email still apply or the way > to OpenBSD is already planned in a more secure/elegant way? > [4]: http://marc.info/?l=openbsd-misc&m=107954189429732&w=4 Sadly, this still applies. -- Christian "naddy" Weisgerber na...@mips.inka.de
Re: IPV6 routing issue
On 2015-06-26, Giancarlo Razzolini wrote: > I don't know if OpenBSD does have any NDP proxying functionality, > besides the one in ndp(8). But it seems to me that, besides a bridge, a > NDP proxy is the only viable solution (besides my ISP allowing me to > change my router configuration). Well, you can add an IPv6 address for each internal host to the external interface of your firewall, use private addresses on the internal network, and then use pf's binat to map between the two. This will preserve port numbers, although it may not be enough for nasty protocols like SIP. -- Christian "naddy" Weisgerber na...@mips.inka.de
Re: IPV6 routing issue
Em 26-06-2015 16:17, Christian Weisgerber escreveu: So you have TWO networks. One between the CPE and your OpenBSD firewall, and one containing the firewall and your internal machines. Yes. Two interfaces, to be more exactly. So you get ONE network address. I get a prefix on the CPE. And I can configure any address in the prefix on any machine on my LAN (or the OpenBSD LAN iface). And traffic gets out. Just won't get replies. You can't use a single network address for two networks. This has nothing to do with IPv6. It's the same with IPv4. I'm aware of that fact. But, since my CPE replies to an IA_PD request, I imagined it would be able to route the packets correctly. You can use private addresses for your internal network and run NAT on the firewall. Or you can configure your firewall as a bridge and filter there. http://www.openbsd.org/faq/faq6.html#Bridge I'm trying to get some NDP proxy running on OpenBSD. But all of them are linux centric. Perhaps, for now, I will use it as a filtering bridge. Since I have enough interfaces on my OpenBSD machine, I will have a bridge specifically for IPv6. And IPv4 will still be NATed. Cheers, Giancarlo Razzolini
Re: IPV6 routing issue
On 2015-06-26, Giancarlo Razzolini wrote: > I've recently changed my ISP and they have native IPv6. My customer > premises equipment, which is a GPON, supports both stateless as DHCPv6 > on it's LAN interface. I want to put a OpenBSD firewall between this CPE > and my internal network. So you have TWO networks. One between the CPE and your OpenBSD firewall, and one containing the firewall and your internal machines. > I'm using OpenBSD 5.7 stable. My CPE receive a > /64 prefix delegation from my ISP. So you get ONE network address. You can't use a single network address for two networks. This has nothing to do with IPv6. It's the same with IPv4. You can use private addresses for your internal network and run NAT on the firewall. Or you can configure your firewall as a bridge and filter there. http://www.openbsd.org/faq/faq6.html#Bridge -- Christian "naddy" Weisgerber na...@mips.inka.de
Re: alternative places to buy the CDs in US are needed
On Fri, 26 Jun 2015, Boris Goldberg wrote:
> Hello misc,
>
> I've looked (and registered) at openbsdstore.com ("USA site") - don't
> like it (a lot). Use to buy OpenBSD stuff from a US book store, but can't
> find it (there was a link to it on the openbsd.org, but not any more). Are
> there alternative ("local") options to buy the OpenBSD CDs in the US?
>
> --
> Best regards,
> Boris mailto:bo...@twopoint.com
>
That's actually a good idea, .. I suspect many other US purchasers may
have stopped purchasing [as have we] due to VAT assessment.
Lee
Re: alternative places to buy the CDs in US are needed
Download, buy media yourself, and donate. Download docs online, print
them, donate. Iterate every release, or more often. Don't understand how
this can be so hard? Donations = close to zero effort. Printing CDs =
more than zero effort for the project.
On 2015-06-26 16:58, Boris Goldberg wrote:
Hello misc,
I've looked (and registered) at openbsdstore.com ("USA site") - don't
like it (a lot). Use to buy OpenBSD stuff from a US book store, but can't
find it (there was a link to it on the openbsd.org, but not any more). Are
there alternative ("local") options to buy the OpenBSD CDs in the US?
Re: IPV6 routing issue
Em 26-06-2015 10:43, Gregor Best escreveu: https://github.com/DanielAdolfsson/ndppd This doesn't compile on OpenBSD. I'm correcting it's includes and headers, but it seems it's linux centric. I'll probably need to change it's code. I've found some other tools but it seems almost all of them are linux centric: [0]: https://github.com/fishilico/autoneighxy [1]: https://github.com/andriyanov/ndp-proxy I don't know if OpenBSD does have any NDP proxying functionality, besides the one in ndp(8). But it seems to me that, besides a bridge, a NDP proxy is the only viable solution (besides my ISP allowing me to change my router configuration). Cheers, Giancarlo Razzolini
alternative places to buy the CDs in US are needed
Hello misc,
I've looked (and registered) at openbsdstore.com ("USA site") - don't
like it (a lot). Use to buy OpenBSD stuff from a US book store, but can't
find it (there was a link to it on the openbsd.org, but not any more). Are
there alternative ("local") options to buy the OpenBSD CDs in the US?
--
Best regards,
Boris mailto:bo...@twopoint.com
ftp://ftp.fr
Hi. As of tomorrow morning (CET), ftp.fr will stop serving files over FTP. It is time people move to HTTP. Everything else will remain the same (cvs, rsync, ...); it's *only* the FTP service that is going away. Thank you. -- Antoine
Re: IPV6 routing issue
Em 26-06-2015 10:43, Gregor Best escreveu: I've also seen something similar. A friend of mine suggested [0], though I haven't tried it. I circumvented my problem by using a routed /64 on a Hurricane Electric tunnel. I wouldn't like to use a tunnel, since my ISP is (kind of) providing native IPv6 connectivity. Depending on your hosting provider, their setup might actually be vulnerable to a neat little trick: If you see NDP requests for prefixes that are not your own while tcpdump'ing your external interface, you might be able to add an address inside one of those networks to your external interface and have it reachable from the outside, so that in effect you can use an IPv6 address that's outside of your prefix. Since my CPE is working in routed mode, I don't see anything like that. But, I believe that this will be a problem for many ISP's, since I doubt they will implement authenticated NDP. I will look into this ndp proxy daemon, since I couldn't make the ndp(8) proxy functionality to work. Thank all you guys who replied. Both on and off list. Cheers, Giancarlo Razzolini
Re: IPV6 routing issue
Em 26-06-2015 10:07, Patrik Lundin escreveu: I have struggled with a similar problem a few years back. Can it be that the upstream equipment does not create a route for the delegated prefix pointing to your openbsd machine? This would explain why you see neighbour solicitations on the outside interface. The upstream router is not aware that the prefix should be routed to you. Yes, I believe it to be te problem. The prefix is delegated to the CPE, not the OpenBSD machine. When I run the dhcp6c program, it asks for a prefix delegation from the CPE and gets one. But I don't think that the CPE is trully delegating the prefix, hence that's why he's issuing neighbor solicitation messages. Someone pointed to me that I'll need to use a ndp proxy or use the openbsd machine as a bridge filter. I can't change the CPE configuration, it's locked by my ISP. Cheers, Giancarlo Razzolini
Re: IPV6 routing issue
On Fri, Jun 26, 2015 at 03:07:41PM +0200, Patrik Lundin wrote: > [...] > This would explain why you see neighbour solicitations on the outside > interface. The upstream router is not aware that the prefix should be > routed to you. > [...] I've also seen something similar. A friend of mine suggested [0], though I haven't tried it. I circumvented my problem by using a routed /64 on a Hurricane Electric tunnel. Depending on your hosting provider, their setup might actually be vulnerable to a neat little trick: If you see NDP requests for prefixes that are not your own while tcpdump'ing your external interface, you might be able to add an address inside one of those networks to your external interface and have it reachable from the outside, so that in effect you can use an IPv6 address that's outside of your prefix. [0]: https://github.com/DanielAdolfsson/ndppd -- Gregor Best
Re: IPV6 routing issue
I have struggled with a similar problem a few years back. Can it be that the upstream equipment does not create a route for the delegated prefix pointing to your openbsd machine? This would explain why you see neighbour solicitations on the outside interface. The upstream router is not aware that the prefix should be routed to you. -- Patrik Lundin - Original message - From: Giancarlo Razzolini To: "Openbsd-Misc" Subject: IPV6 routing issue Date: Thu, 25 Jun 2015 21:06:51 -0300 HI all, I've recently changed my ISP and they have native IPv6. My customer premises equipment, which is a GPON, supports both stateless as DHCPv6 on it's LAN interface. I want to put a OpenBSD firewall between this CPE and my internal network. I'm using OpenBSD 5.7 stable. My CPE receive a /64 prefix delegation from my ISP. Unfortunately, this is a dynamic prefix, so I can't configure anything manually. I've managed to get wide-dhcp6 working and requesting the prefix to be delegated to my internal network. After that, all I needed to do was to run rtadvd on my internal interface, and my internal LAN machines began to be autoconfigurated getting ip's from the delegated prefix. The OpenBSD firewall has 2 ipv6 addresses. One on the WAN interface and another on the LAN interface. If I use ping6 to ping any ipv6 host from my firewall, I can ping them with no problems. But, If I ping setting the source to be the ipv6 address from the internal interface, it won't work. Also, no machine from my LAN can connect to any host through ipv6. I've inspected the traffic with tcpdump, and I can see the packets leaving my network and getting on the destination. The problem is the packets never gets back. My CPE equipment keeps asking for neighbour solicitation asking who has the ipv6 address, but the OpenBSD firewall never replies, so the packts get dropped. I'm currently with PF disabled. But I had the same problem with it enabled and with the default firewall configuration. I'm trying first to get ipv6 connectivity working to after filter the packets. Anyone had a similar issue? Cheers, Giancarlo Razzolini
Re: nsd configuration problem
On 2015-06-25 Thu 14:22 PM |, Andrew Daugherity wrote: > > The important bits to actually make this work are the > 'do-not-query-localhost: no' and 'local-zone: C.B.A.in-addr.arpa. > transparent' options, needed to override unbound's default behavior of > ignoring localhost and RFC1918 addresses. It took me a while to find > this, until I discovered the proper keywords to Google for. > See this post (& thread) for an example of NSD & unbound on OpenBSD 5.5: http://marc.info/?l=openbsd-misc&m=141113669300630&w=2 Cheers. -- Canadian podcast: The Truth About Edward Snowden http://www.youtube.com/watch?v=9hmOAFFzxj0&feature=related
Re: dnssec-signzone and NSEC3
On 2015-06-26, David Dahlberg wrote: > Am Freitag, den 26.06.2015, 09:53 +0200 schrieb Peter J. Philipp: > >> I can't find the -3 - option to generate NSEC3 RR's with >> dnssec-signzone. Am I reading the manual page wrong or is this a >> missing feature? If it is I'll probably leave NSEC3 out. > > That's because old OpenBSD used an old version of ISC Bind (and thus an > old version of dnssec-tools). If you still have /usr/sbin/dnssec-signzone and /usr/share/man/man8/dnssec-signzone.8 they are old files, dnssec-signzone was removed from base along with most of the rest of bind; only (old versions of) dig, host and nslookup remain.
Re: dnssec-signzone and NSEC3
On 06/26/15 10:10, David Dahlberg wrote: > Am Freitag, den 26.06.2015, 09:53 +0200 schrieb Peter J. Philipp: > >> I can't find the -3 - option to generate NSEC3 RR's with >> dnssec-signzone. Am I reading the manual page wrong or is this a >> missing feature? If it is I'll probably leave NSEC3 out. > > That's because old OpenBSD used an old version of ISC Bind (and thus an > old version of dnssec-tools). > > Solution 1 (ISC): Get a newer version of bind from ports. You do not > need to use the bind itself, it's the /usr/local/bin/dnssec-signzone, > you're looking for. > > Solution 2 (NLnet Labs): Get ldns from ports. > > Cheers > > David > Thanks David, I went with solution 1 and installed net/isc-bind, it has dnssec-signzone in /usr/local/sbin/ Cheers, -peter
Re: dnssec-signzone and NSEC3
Am Freitag, den 26.06.2015, 09:53 +0200 schrieb Peter J. Philipp: > I can't find the -3 - option to generate NSEC3 RR's with > dnssec-signzone. Am I reading the manual page wrong or is this a > missing feature? If it is I'll probably leave NSEC3 out. That's because old OpenBSD used an old version of ISC Bind (and thus an old version of dnssec-tools). Solution 1 (ISC): Get a newer version of bind from ports. You do not need to use the bind itself, it's the /usr/local/bin/dnssec-signzone, you're looking for. Solution 2 (NLnet Labs): Get ldns from ports. Cheers David
dnssec-signzone and NSEC3
Hi, I'm a developer of an authoritative nameserver (delphinusdnsd) and I've always developed this on OpenBSD. Lately I've been putting DNSSEC functionality into this daemon and almost completed RFC 4034 which includes NSEC,DS,RRSIG and DNSKEY RR's. I'd like to go further and put in RFC 5155 (NSEC3 and NSEC3PARAM) but I'm stuck at the dnssec-signzone command on OpenBSD 5.7. I can't find the -3 - option to generate NSEC3 RR's with dnssec-signzone. Am I reading the manual page wrong or is this a missing feature? If it is I'll probably leave NSEC3 out. Thanks for your helpful hints. -peter
Re: OpenBGPd forward update configuration
On 2015 Jun 26 (Fri) at 00:18:40 -0600 (-0600), dsp wrote:
:On Thu, Jun 11, 2015 at 03:21:31PM -0600, dsp wrote:
:> On Wed, Jun 10, 2015 at 08:18:34PM -0600, dsp wrote:
:> > Hello list!
:> >
:> > please excuse my probably idiotic question, but i'm still a new OpenBGPd
user.
:> > (5.7 release)
:> >
:> > what i'm trying to achieve is:
:> > a) connect to a bunch of peers but announce nothing to them. just collect
their updates.
:> > b) send all those updates to another peer ($livebgp)
:> >
:> > my config is :
:> >
:> > AS 65005
:> > router-id a.b.c.d
:> > route-collector yes
:> > transparent-as yes
:> >
:> > neighbor $livebgp {
:> > remote-as 65001
:> > descr livebgp
:> > holdtime180
:> > multihop100
:> > passive
:> > holdtime min3
:> > announceall
:> > }
:> >
:> > group peers {
:> > announce none
:> > holdtime180
:> > holdtime min3
:> > multihop100
:> > neighbor $foo {
:> > remote-as
:> > descr foo
:> > }
:> >...
:> > }
:> allow from any
:> allow to $livebgp
:>
:> solved it for me.
:> sorry for the noise :)
:Hello again list.
:I come back to you with this problem cause it has been bugging me for weeks
now.
:please if anyone has any input, share :)
:
:So the thing is that the updates i'm getting to my $livebgp neighbor seem to
only to be originating from
:2 of the almost 10 connected hosts in the group peers. (one of the 2 is
actually my closest BGP router)
:i'm checking with bgpctl show and seeing updates coming to me from other
connected peers, but my openbgpd
:only sends out ones from my closest AS and one more.
:
you are crossing ASes. the relevent part of the man page for bgpd.conf says:
announce (all|none|self|default-route)
If set to none, no UPDATE messages will be sent to the neighbor.
If set to default-route, only the default route will be announced
to the neighbor. If set to all, all generated UPDATE messages
will be sent to the neighbor. This is usually used for transit
AS's and IBGP peers. The default value for EBGP peers is self,
which limits the sent UPDATE messages to announcements of the
local AS. The default for IBGP peers is all.
:How can i emulate an IXP route server functionality so that my $livebgp peer
gets ALL updates from ALL the hosts
:in the group peers???
:
:thank you very much!
:
:DSP
:>
:> DsP
:> >
:> > on the livebgp side though all i'm seeing are the keepalives.
:> > livebgp is doing active connection so that's why i have the passive there.
:> >
:> > do you guys have any input?
:> >
:> > Thank you so much!
:> >
:> > DsP
:
--
The computing field is always in need of new cliches.
-- Alan Perlis
Re: Is PFSync over IPSec still broken?
W dniu 25.06.2015 o 12:19, Jason McIntyre pisze: >>> Please fix this bug or remove this example from documentation. >>> For me this setup is broken since 2011. >>> http://marc.info/?l=openbsd-misc&m=130624207811609&w=2 >>> >>> Nobody cares or nobody uses? >> > > i've just committed something similar to the diff below, though i > commented out text rather than removing it. > > thanks for the diff, > jmc Thank you. Please also remove this line: 2. Use the ifconfig(8) syncpeer option (see below) so that updates are unicast directly to the peer, then configure ipsec(4) between the hosts to secure the pfsync(4) traffic. from http://www.openbsd.org/faq/pf/carp.html
