Re: radeon driver bug?
I made FreeBSD 12-Release on another disk of the same graphic (HD 6450 graphic card), and got success to run Jahshaka 3D animation. Yes, no animation stop! It uses mesa-18.1.9. Its colors are not so good as OpenBSD's mesa version, however, it works. Kenji 2018年12月11日(火) 13:14 岡本健二 : > Ok, I upgraded my OpenBSD system to -current, and rebuild the Jahshaka. > After all, the results are same as before. > > Skeletal Animations runs for less than 1 second, and halt for about 35 > seconds, > and then runs for less than 1 second, and halt for about 35 second(yes, > it's same)... > Above cycle continues eternally. > > Kenji > > > 2018年12月10日(月) 1:23 tfrohw...@fastmail.com : > >> On December 9, 2018 1:22:42 AM UTC, "岡本健二" wrote: >> >I found mesa-libs-18.1.9 for FreeBSD ports. >> >How can I get it without FreeBSD system? >> > >> >Kenji >> > >> > >> >2018年12月8日(土) 14:48 岡本健二 : >> > >> >> I installed Ubuntu 18.04 to a AMD 6450 graphic card, and played >> >> Jahshaka. It has mesa version 18.2, and runs Jahshaka very >> >> smoothly. >> >> >> >> The colors I reported before are same in this machine, so that >> >> report was not correct. >> >> >> >> Kenji >> >> >> >> 2018年12月7日(金) 11:09 岡本健二 : >> >> >> >>> I checked mesa-18.3.0 sources under src/gallium/drivers/r600 and >> >compared >> >>> with those >> >>> of xenocara. File names are all same, however, individual sizes are >> >very >> >>> different for >> >>> most of those, which would not permit me to copy those to >> >xenocara... >> >>> >> >>> Kenji >> >>> >> >>> >> >>> 2018年12月6日(木) 15:14 岡本健二 : >> >>> >> also, it stull has some bugs, because the colors of some >> parts are different from those of original ones. >> >> Kenji >> >> >> 2018年12月6日(木) 15:10 岡本健二 : >> >> > Sorry, I'm a novice to OpenBSD. >> > Yes, it's current branch of xenocara. >> > I updated my xenocara (stable) to that current, and build new >> >xenocara >> > here. >> > >> > Wow, it makes the Jahshaka works! >> > >> > However, it still has some bugs, because it moves and stop >> >suddenly and >> > then >> > move again. Whine the animation stops, the system seems to >> >halting... >> > >> > Anyway it makes much advance, I included the screenshot of it. >> > >> > Kenji >> > >> > PS: sorry tfrohwein, this is doubled to you >> > >> > 2018年12月6日(木) 13:26 岡本健二 : >> > >> >> in-current means stable 6.4? >> >> >> >> Kenji >> >> >> >> 2018年12月5日(水) 23:58 tfrohw...@fastmail.com >> >: >> >> >> >>> On December 5, 2018 9:41:44 AM UTC, "岡本健二" >> >>> wrote: >> >>> >This errors come from >> >>> >> >>/usr/xenocara/lib/mesa/src/gallium/drivers/r600/r600_state_common.c. >> >>> >The mesa version of OpenBSD6.4 is 13.0.6. >> >>> >I'm running this Jahshaka on Ubutu 18.04, where the mesa >> >version is >> >>> >18.x. >> >>> > >> >>> >So, it may be the mesa problem... >> >>> > >> >>> >Kenji >> >>> > >> >>> > >> >>> >2018年12月4日(火) 16:19 岡本健二 : >> >>> > >> >>> >> I'm using AMD HD6450 graphic card which I reported before, >> >and >> >>> faced >> >>> >a >> >>> >> curious thing >> >>> >> during running Jahshaka Studio (dev version 7.03a). >> >>> >> To run Jahshaka on OpenBSD 6.4 I needed to delete google >> >breakpad >> >>> >> temporally, which >> >>> >> is not the problem now. >> >>> >> >> >>> >> After start to run 'Jahshaka Studio', I got start 3D >> >animation >> >>> sample >> >>> >> 'Skeletal Animation' data to load, then >> >>> >> I got many errors included below which seems to come from >> >radeon >> >>> drm >> >>> >> driver's bug to me. >> >>> >> If you interested please check it. >> >>> >> >> >>> >> Thanks in advance >> >>> >> >> >>> >> Kenji >> >>> >> >> >>> >> >> >>> >> >>> There's a known bug where the shader on r600 uses too many >> >registers: >> >>> >> >>> https://bugs.freedesktop.org/show_bug.cgi?id=99349 >> >>> >> >>> I encountered this bug with godot on a Radeon HD 7570, too, and >> >it >> >>> went away with the updated mesa that's in -current. >> >>> >> >> >> >> I think you are asking for way more than you (or most misc@ readers) can >> handle. Porting low-level libraries from FreeBSD is far from trivial. >> >> My advice remains: if you want working graphics, you should run >> OpenBSD-current, not 6.4-release. What you did is try to plug in stuff from >> -current into 6.4 which is huge gamble and I'm not surprised if the result >> is weird. >> >> Just read the OpenBSD FAQ again for how to install -current. I would stop >> experimenting like you've one until you understand the system much better >> than now. >> >
Re: OpenBSD & OpenBGPD router replacement
Tom, The presentation was very interesting and it's given me a lot of food for thought for another project. Fortunately for this application I don't need to worry about fire walling at the BGP edge, just the router replacement itself. Max On Tue, Dec 18, 2018 at 6:02 PM Tom Smyth wrote: > Max, > > another thing to consider, is that with BGP feeds / Advertising > you only have some control over which direction traffic enters / leaves > the network, you may pefer one transit provider, but another network on the > internet can prefer your second transit provider, so you can have > traffic that appears out of state... > > If you need stateful packet filtering I would suggest stepping that > protection > back from your edge routers ... disadvantage is you would need 4 > devices to do this > but this would give you the redundancy you want from a Transit perspective > and you would have the ability control flow of traffic between your > edge routers > and your Stateful Firewalls > > Hope This Helps > > Tom Smyth > > > > > On Wed, 19 Dec 2018 at 01:52, Max Clark wrote: > > > > Thanks Arnaud - I understand that it's not a stateful protocol/failover. > > It's interesting from the standpoint that if I lose a specific box acting > > as a router I would recover and maintain the route via the affected > > carrier. A few minutes of outage for carp and BGP to come up is better > than > > a prolonged outage until equipment is replaced. > > > > Max > > > > > > On Tue, Dec 18, 2018 at 4:47 PM Arnaud BRAND > > wrote: > > > > > Hi Max, > > > > > > I would advise against using CARP for BGP peers. > > > BGP is a stateful protocol and there's no bgpsyncd, so I don't think > > > this > > > will work. > > > > > > I would rather build two servers, and have 2 BGP sessions/fullfeeds, > > > each > > > on one 10G link in order to provide redundancy. > > > > > > Best regards > > > Arnaud > > > > > > Le 2018-12-19 00:17, Max Clark a écrit : > > > > Hello, > > > > > > > > I've been presented with an opportunity to greatly simplify upstream > > > > networking within a datacenter. At this point I'm expecting to > condense > > > > down to two 10 Gbps full feed IPv4+IPv6 transit links plus a 10 Gbps > > > > link > > > > to the peering fabric. Total 95th percentile transit averages in the > > > > 3-4 > > > > Gbps range with bursts into the 6-7 Gbps (outside of the rare DDoS > then > > > > everything just catches on fire until provider mitigation kicks in). > > > > > > > > With the exception of the full tables it's a pretty simple > requirement. > > > > There's plenty of options to purchase a new TOR device(s) that could > > > > take > > > > the full tables, but I'd just rather not commit the budget for it. > Plus > > > > this feels like the perfect time to do what I've wanted for a while, > > > > and > > > > deploy an OpenBSD & OpenBGPD edge. > > > > > > > > I should probably ask first - am I crazy? > > > > > > > > With that out of the way I could either land the fiber directly into > > > > NICs > > > > on an appropriately sized server, or I was thinking about landing the > > > > transit links on a 10 Gbps L2 switch and using CARP to provide server > > > > redundancy on my side (so each transit link would be part of VLAN > with > > > > two > > > > servers connected, primary server would advertise the /30 to the > > > > carrier > > > > with BGPD, and secondary server could take over with heartbeat > > > > failure). I > > > > would use two interfaces on the server - one facing the Internet and > > > > one > > > > facing our equipment. > > > > > > > > Would the access switch in this configuration be a bad idea? Should I > > > > keep > > > > things directly homed on the server? > > > > > > > > And my last question - are there any specific NICs that I should look > > > > for > > > > and/or avoid when building this? > > > > > > > > Thanks! > > > > Max > > > > > > > -- > Kindest regards, > Tom Smyth > > Mobile: +353 87 6193172 > The information contained in this E-mail is intended only for the > confidential use of the named recipient. If the reader of this message > is not the intended recipient or the person responsible for > delivering it to the recipient, you are hereby notified that you have > received this communication in error and that any review, > dissemination or copying of this communication is strictly prohibited. > If you have received this in error, please notify the sender > immediately by telephone at the number above and erase the message > You are requested to carry out your own virus check before > opening any attachment. >
Re: OpenBSD & OpenBGPD router replacement
Max, another thing to consider, is that with BGP feeds / Advertising you only have some control over which direction traffic enters / leaves the network, you may pefer one transit provider, but another network on the internet can prefer your second transit provider, so you can have traffic that appears out of state... If you need stateful packet filtering I would suggest stepping that protection back from your edge routers ... disadvantage is you would need 4 devices to do this but this would give you the redundancy you want from a Transit perspective and you would have the ability control flow of traffic between your edge routers and your Stateful Firewalls Hope This Helps Tom Smyth On Wed, 19 Dec 2018 at 01:52, Max Clark wrote: > > Thanks Arnaud - I understand that it's not a stateful protocol/failover. > It's interesting from the standpoint that if I lose a specific box acting > as a router I would recover and maintain the route via the affected > carrier. A few minutes of outage for carp and BGP to come up is better than > a prolonged outage until equipment is replaced. > > Max > > > On Tue, Dec 18, 2018 at 4:47 PM Arnaud BRAND > wrote: > > > Hi Max, > > > > I would advise against using CARP for BGP peers. > > BGP is a stateful protocol and there's no bgpsyncd, so I don't think > > this > > will work. > > > > I would rather build two servers, and have 2 BGP sessions/fullfeeds, > > each > > on one 10G link in order to provide redundancy. > > > > Best regards > > Arnaud > > > > Le 2018-12-19 00:17, Max Clark a écrit : > > > Hello, > > > > > > I've been presented with an opportunity to greatly simplify upstream > > > networking within a datacenter. At this point I'm expecting to condense > > > down to two 10 Gbps full feed IPv4+IPv6 transit links plus a 10 Gbps > > > link > > > to the peering fabric. Total 95th percentile transit averages in the > > > 3-4 > > > Gbps range with bursts into the 6-7 Gbps (outside of the rare DDoS then > > > everything just catches on fire until provider mitigation kicks in). > > > > > > With the exception of the full tables it's a pretty simple requirement. > > > There's plenty of options to purchase a new TOR device(s) that could > > > take > > > the full tables, but I'd just rather not commit the budget for it. Plus > > > this feels like the perfect time to do what I've wanted for a while, > > > and > > > deploy an OpenBSD & OpenBGPD edge. > > > > > > I should probably ask first - am I crazy? > > > > > > With that out of the way I could either land the fiber directly into > > > NICs > > > on an appropriately sized server, or I was thinking about landing the > > > transit links on a 10 Gbps L2 switch and using CARP to provide server > > > redundancy on my side (so each transit link would be part of VLAN with > > > two > > > servers connected, primary server would advertise the /30 to the > > > carrier > > > with BGPD, and secondary server could take over with heartbeat > > > failure). I > > > would use two interfaces on the server - one facing the Internet and > > > one > > > facing our equipment. > > > > > > Would the access switch in this configuration be a bad idea? Should I > > > keep > > > things directly homed on the server? > > > > > > And my last question - are there any specific NICs that I should look > > > for > > > and/or avoid when building this? > > > > > > Thanks! > > > Max > > -- Kindest regards, Tom Smyth Mobile: +353 87 6193172 The information contained in this E-mail is intended only for the confidential use of the named recipient. If the reader of this message is not the intended recipient or the person responsible for delivering it to the recipient, you are hereby notified that you have received this communication in error and that any review, dissemination or copying of this communication is strictly prohibited. If you have received this in error, please notify the sender immediately by telephone at the number above and erase the message You are requested to carry out your own virus check before opening any attachment.
Re: OpenBSD & OpenBGPD router replacement
Thanks Arnaud - I understand that it's not a stateful protocol/failover. It's interesting from the standpoint that if I lose a specific box acting as a router I would recover and maintain the route via the affected carrier. A few minutes of outage for carp and BGP to come up is better than a prolonged outage until equipment is replaced. Max On Tue, Dec 18, 2018 at 4:47 PM Arnaud BRAND wrote: > Hi Max, > > I would advise against using CARP for BGP peers. > BGP is a stateful protocol and there's no bgpsyncd, so I don't think > this > will work. > > I would rather build two servers, and have 2 BGP sessions/fullfeeds, > each > on one 10G link in order to provide redundancy. > > Best regards > Arnaud > > Le 2018-12-19 00:17, Max Clark a écrit : > > Hello, > > > > I've been presented with an opportunity to greatly simplify upstream > > networking within a datacenter. At this point I'm expecting to condense > > down to two 10 Gbps full feed IPv4+IPv6 transit links plus a 10 Gbps > > link > > to the peering fabric. Total 95th percentile transit averages in the > > 3-4 > > Gbps range with bursts into the 6-7 Gbps (outside of the rare DDoS then > > everything just catches on fire until provider mitigation kicks in). > > > > With the exception of the full tables it's a pretty simple requirement. > > There's plenty of options to purchase a new TOR device(s) that could > > take > > the full tables, but I'd just rather not commit the budget for it. Plus > > this feels like the perfect time to do what I've wanted for a while, > > and > > deploy an OpenBSD & OpenBGPD edge. > > > > I should probably ask first - am I crazy? > > > > With that out of the way I could either land the fiber directly into > > NICs > > on an appropriately sized server, or I was thinking about landing the > > transit links on a 10 Gbps L2 switch and using CARP to provide server > > redundancy on my side (so each transit link would be part of VLAN with > > two > > servers connected, primary server would advertise the /30 to the > > carrier > > with BGPD, and secondary server could take over with heartbeat > > failure). I > > would use two interfaces on the server - one facing the Internet and > > one > > facing our equipment. > > > > Would the access switch in this configuration be a bad idea? Should I > > keep > > things directly homed on the server? > > > > And my last question - are there any specific NICs that I should look > > for > > and/or avoid when building this? > > > > Thanks! > > Max >
Re: OpenBSD & OpenBGPD router replacement
Hi Max, I think if you run decent Recent servers with Intel NICS (not virtualised) you can get those numbers, We use Hotlava Multiport 10GE Nics (Intel) the only thing with running software only routers is what head room you may have for multiple Connections etc... we have similar traffic levels to your self and hope to grow them ... what we did to get was to Use OpenBSD As Multi-hop Edge Routers which also act as iBGP route reflectors... these take the Feeds from 2x Transits and then inject a subset of routes + Default to a pair of Trident-II based Switches (ours happen to be arista) these switches BGP peer directly with the exchange what is nice about the above setup... is the 2x L3 switches are doing the heavy lifting interms of packet forwarding ... but OpenBSD +OpenBGPD are injecting routes into the two Layer 3 Switches via IBGPso im using openBSD to do the Control Plane... but my L3 Switches are the forwarding plane (sort of ) This has been running in our production for about month and seems very performant and stable ... here is a video about a guy talking about using OpenBSD in a multi 10G setup https://www.youtube.com/watch?v=veqKM4bHesM Hope this helps,... On Tue, 18 Dec 2018 at 23:32, Max Clark wrote: > > Hello, > > I've been presented with an opportunity to greatly simplify upstream > networking within a datacenter. At this point I'm expecting to condense > down to two 10 Gbps full feed IPv4+IPv6 transit links plus a 10 Gbps link > to the peering fabric. Total 95th percentile transit averages in the 3-4 > Gbps range with bursts into the 6-7 Gbps (outside of the rare DDoS then > everything just catches on fire until provider mitigation kicks in). > > With the exception of the full tables it's a pretty simple requirement. > There's plenty of options to purchase a new TOR device(s) that could take > the full tables, but I'd just rather not commit the budget for it. Plus > this feels like the perfect time to do what I've wanted for a while, and > deploy an OpenBSD & OpenBGPD edge. > > I should probably ask first - am I crazy? > > With that out of the way I could either land the fiber directly into NICs > on an appropriately sized server, or I was thinking about landing the > transit links on a 10 Gbps L2 switch and using CARP to provide server > redundancy on my side (so each transit link would be part of VLAN with two > servers connected, primary server would advertise the /30 to the carrier > with BGPD, and secondary server could take over with heartbeat failure). I > would use two interfaces on the server - one facing the Internet and one > facing our equipment. > > Would the access switch in this configuration be a bad idea? Should I keep > things directly homed on the server? > > And my last question - are there any specific NICs that I should look for > and/or avoid when building this? > > Thanks! > Max -- Kindest regards, Tom Smyth Mobile: +353 87 6193172 The information contained in this E-mail is intended only for the confidential use of the named recipient. If the reader of this message is not the intended recipient or the person responsible for delivering it to the recipient, you are hereby notified that you have received this communication in error and that any review, dissemination or copying of this communication is strictly prohibited. If you have received this in error, please notify the sender immediately by telephone at the number above and erase the message You are requested to carry out your own virus check before opening any attachment.
OpenBSD & OpenBGPD router replacement
Hello, I've been presented with an opportunity to greatly simplify upstream networking within a datacenter. At this point I'm expecting to condense down to two 10 Gbps full feed IPv4+IPv6 transit links plus a 10 Gbps link to the peering fabric. Total 95th percentile transit averages in the 3-4 Gbps range with bursts into the 6-7 Gbps (outside of the rare DDoS then everything just catches on fire until provider mitigation kicks in). With the exception of the full tables it's a pretty simple requirement. There's plenty of options to purchase a new TOR device(s) that could take the full tables, but I'd just rather not commit the budget for it. Plus this feels like the perfect time to do what I've wanted for a while, and deploy an OpenBSD & OpenBGPD edge. I should probably ask first - am I crazy? With that out of the way I could either land the fiber directly into NICs on an appropriately sized server, or I was thinking about landing the transit links on a 10 Gbps L2 switch and using CARP to provide server redundancy on my side (so each transit link would be part of VLAN with two servers connected, primary server would advertise the /30 to the carrier with BGPD, and secondary server could take over with heartbeat failure). I would use two interfaces on the server - one facing the Internet and one facing our equipment. Would the access switch in this configuration be a bad idea? Should I keep things directly homed on the server? And my last question - are there any specific NICs that I should look for and/or avoid when building this? Thanks! Max
Re: IPv6 Multicast Listener Discovery - Listing and Disabling Group Membership
On Tue, Dec 18, 2018 at 07:13:28PM +, Stuart Henderson wrote: | On 2018-12-17, Fernando Gont wrote: | > On 1/10/18 17:18, Aham Brahmasmi wrote: | >> Hello misc, | >> | >> Running 6.4-beta from approximately a week ago. | >> | >> 1) How to determine the IPv6 multicast groups which have been joined by | >> a particular interface? | > | > Use ifmcstat | > | > But you need to install the corresponding package first. | > | > Thanks, | | ifmcstat hasn't worked since 2013, nobody fixed it after a round of | kernel changes to multicast. And the port was removed by danj as a result 2 months ago, after having been marked BROKEN for nearly five years. In those five years, nobody complained (at least, not to me), so aparently it wasn't a big loss :) Paul 'WEiRD' de Weerd -- >[<++>-]<+++.>+++[<-->-]<.>+++[<+ +++>-]<.>++[<>-]<+.--.[-] http://www.weirdnet.nl/
Xorg crash every few days
Hello, Xorg is crashing every few days. I increased the limits and it increased the time between crashes. This is the back trace from gdb of the core: Loaded symbols for /usr/X11R6/lib/modules/input/ws_drv.so #0 0x18d22d68329e in VGAarbiterSpriteMoveCursor () from /usr/X11R6/bin/X (gdb) bt #0 0x18d22d68329e in VGAarbiterSpriteMoveCursor () from /usr/X11R6/bin/X #1 0x18d22d6832c6 in VGAarbiterSpriteMoveCursor () from /usr/X11R6/bin/X #2 0x18d22d6832c6 in VGAarbiterSpriteMoveCursor () from /usr/X11R6/bin/X #3 0x18d22d6832c6 in VGAarbiterSpriteMoveCursor () from /usr/X11R6/bin/X #4 0x18d22d6832c6 in VGAarbiterSpriteMoveCursor () from /usr/X11R6/bin/X #5 0x18d22d6832c6 in VGAarbiterSpriteMoveCursor () from /usr/X11R6/bin/X #6 0x18d22d6832c6 in VGAarbiterSpriteMoveCursor () from /usr/X11R6/bin/X #7 0x18d22d6832c6 in VGAarbiterSpriteMoveCursor () from /usr/X11R6/bin/X #8 0x18d22d6832c6 in VGAarbiterSpriteMoveCursor () from /usr/X11R6/bin/X #9 0x18d22d6832c6 in VGAarbiterSpriteMoveCursor () from /usr/X11R6/bin/X #10 0x18d22d6832c6 in VGAarbiterSpriteMoveCursor () from /usr/X11R6/bin/X #11 0x18d22d6832c6 in VGAarbiterSpriteMoveCursor () from /usr/X11R6/bin/X #12 0x18d22d6832c6 in VGAarbiterSpriteMoveCursor () from /usr/X11R6/bin/X #13 0x18d22d6832c6 in VGAarbiterSpriteMoveCursor () from /usr/X11R6/bin/X #14 0x18d22d6832c6 in VGAarbiterSpriteMoveCursor () from /usr/X11R6/bin/X #15 0x18d22d6832c6 in VGAarbiterSpriteMoveCursor () from /usr/X11R6/bin/X #16 0x18d22d6832c6 in VGAarbiterSpriteMoveCursor () from /usr/X11R6/bin/X #17 0x18d22d6832c6 in VGAarbiterSpriteMoveCursor () from /usr/X11R6/bin/X #18 0x18d22d6832c6 in VGAarbiterSpriteMoveCursor () from /usr/X11R6/bin/X #19 0x18d22d6832c6 in VGAarbiterSpriteMoveCursor () from /usr/X11R6/bin/X #20 0x18d22d6832c6 in VGAarbiterSpriteMoveCursor () from /usr/X11R6/bin/X #21 0x18d22d6832c6 in VGAarbiterSpriteMoveCursor () from /usr/X11R6/bin/X #22 0x18d22d6832c6 in VGAarbiterSpriteMoveCursor () from /usr/X11R6/bin/X #23 0x18d22d6832c6 in VGAarbiterSpriteMoveCursor () from /usr/X11R6/bin/X #24 0x18d22d6832c6 in VGAarbiterSpriteMoveCursor () from /usr/X11R6/bin/X and it keeps going on until #34870 0x18d22d6832c6 in VGAarbiterSpriteMoveCursor () from /usr/X11R6/bin/X #34871 0x18d22d6832c6 in VGAarbiterSpriteMoveCursor () from /usr/X11R6/bin/X #34872 0x18d22d6832c6 in VGAarbiterSpriteMoveCursor () from /usr/X11R6/bin/X #34873 0x18d22d6832c6 in VGAarbiterSpriteMoveCursor () from /usr/X11R6/bin/X #34874 0x18d22d6832c6 in VGAarbiterSpriteMoveCursor () from /usr/X11R6/bin/X #34875 0x18d22d6832c6 in VGAarbiterSpriteMoveCursor () from /usr/X11R6/bin/X #34876 0x18d22d6832c6 in VGAarbiterSpriteMoveCursor () from /usr/X11R6/bin/X #34877 0x18d22d6832c6 in VGAarbiterSpriteMoveCursor () from /usr/X11R6/bin/X #34878 0x18d22d6832c6 in VGAarbiterSpriteMoveCursor () from /usr/X11R6/bin/X #34879 0x18d22d6832c6 in VGAarbiterSpriteMoveCursor () from /usr/X11R6/bin/X #34880 0x18d22d6832c6 in VGAarbiterSpriteMoveCursor () from /usr/X11R6/bin/X #34881 0x18d22d6832c6 in VGAarbiterSpriteMoveCursor () from /usr/X11R6/bin/X #34882 0x18d22d6832c6 in VGAarbiterSpriteMoveCursor () from /usr/X11R6/bin/X #34883 0x18d22d6832c6 in VGAarbiterSpriteMoveCursor () from /usr/X11R6/bin/X #34884 0x18d22d6832c6 in VGAarbiterSpriteMoveCursor () from /usr/X11R6/bin/X #34885 0x18d22d6832c6 in VGAarbiterSpriteMoveCursor () from /usr/X11R6/bin/X #34886 0x18d22d6832c6 in VGAarbiterSpriteMoveCursor () from /usr/X11R6/bin/X #34887 0x18d22d6832c6 in VGAarbiterSpriteMoveCursor () from /usr/X11R6/bin/X #34888 0x18d22d6832c6 in VGAarbiterSpriteMoveCursor () from /usr/X11R6/bin/X #34889 0x18d22d6832c6 in VGAarbiterSpriteMoveCursor () from /usr/X11R6/bin/X #34890 0x18d22d6832c6 in VGAarbiterSpriteMoveCursor () from /usr/X11R6/bin/X #34891 0x18d22d6832c6 in VGAarbiterSpriteMoveCursor () from /usr/X11R6/bin/X #34892 0x18d22d6832c6 in VGAarbiterSpriteMoveCursor () from /usr/X11R6/bin/X #34893 0x18d22d6832c6 in VGAarbiterSpriteMoveCursor () from /usr/X11R6/bin/X #34894 0x18d22d6832c6 in VGAarbiterSpriteMoveCursor () from /usr/X11R6/bin/X #34895 0x18d22d6832c6 in VGAarbiterSpriteMoveCursor () from /usr/X11R6/bin/X #34896 0x18d22d6832c6 in VGAarbiterSpriteMoveCursor () from /usr/X11R6/bin/X #34897 0x18d22d6832c6 in VGAarbiterSpriteMoveCursor () from /usr/X11R6/bin/X #34898 0x18d22d6832c6 in VGAarbiterSpriteMoveCursor () from /usr/X11R6/bin/X #34899 0x18d22d6832c6 in VGAarbiterSpriteMoveCursor () from /usr/X11R6/bin/X #34900 0x18d22d6832c6 in VGAarbiterSpriteMoveCursor () from /usr/X11R6/bin/X #34901 0x18d22d6832c6 in VGAarbiterSpriteMoveCursor () from /usr/X11R6/bin/X #34902 0x18d22d6832c6 in VGAarbiterSpriteMoveCursor () from /usr/X11R6/bin/X #34903 0x18d22d6832c6 in VGAarbiterSpriteM
Re: Cheaper alternatives for APC UPS
On Mon, Dec 17, 2018 at 09:47:25PM +0100, Radek wrote: > Hello, > > could you recommend me any UPS brands *cheaper* than APC that are fully > supported in OpenBSD? > I always use APC, managing them via USB and apcupsd(both servers and clients) > and PowerChute(windows clients). It works like a charm. APC is quite > expensive brand so I am looking for any cheaper alternatives. Salicru is a good brand. The home models use a third party protocol supported by one of our ports (I don't remember the names). The professional product lines have support for USB HID. I've used a couple of basic models. The batteries lasted for 3 years and I never had a leak. The windows software is the biggest crap ever done. Use a third party application. -- Juan Francisco Cantero Hurtado http://juanfra.info
Re: IPv6 Multicast Listener Discovery - Listing and Disabling Group Membership
On 2018-12-17, Fernando Gont wrote: > On 1/10/18 17:18, Aham Brahmasmi wrote: >> Hello misc, >> >> Running 6.4-beta from approximately a week ago. >> >> 1) How to determine the IPv6 multicast groups which have been joined by >> a particular interface? > > Use ifmcstat > > But you need to install the corresponding package first. > > Thanks, ifmcstat hasn't worked since 2013, nobody fixed it after a round of kernel changes to multicast.
Re: Documentation patches?
On 2018-12-18, Chris McGee wrote: > Hi: > > I'd like to submit some info for the install64.octeon documentation. > I just installed 6.4 on a newer EdgeRouter than the documentation was > written for. The instructions in the install document are probably not > enough to get the average user booted on that particular piece of > hardware. I'd like to document the install while I still remember it. > Can I submit a patch somewhere? Adding to Ingo's reply: the install docs are generated by m4 from files in /usr/src/distrib/notes, so the most useful method would be to send a "cvs diff -u" against the input files. If it's more convenient to edit and test on a machine of another architecture (e.g. an amd64 workstation), you can do this: cd /usr/src/distrib/notes make obj make M=octeon less obj/INSTALL.octeon
Re: Cheaper alternatives for APC UPS
Hello, I have been using OpenUPS for my rack for at least 3 years without a single problem powering server + switch + media converter with 12VDC. This is a DC-DC UPS meaning that it does not replicate a UPS that you simply plug in and it works. The reasons for me using OpenUPS are: -An open system, you chose all aspects of your system! -I can add as many batteries as I want. The OpenUPS is a 10A@12V device, but to it I have 80Ah 12V batteries connected meaning that even at 10A load I get about 7 hours of uptime, in reality I get about 30 hours after power out. -Efficient! Your computer consumes DC, your battery stores DC. Why convert to AC in between? -Programmable (through a windows application) for different battery charging modes meaning that you are even free to chose battery size, battery chemistry, fast and damaging charging or slow and healthy etc. For this you need a source of 12V and a supply for your computer from 12V - which my supermicro board already has built in. dmesg gives me the following: upd0 at uhidev2 and dotbit$ sysctl hw.sensors.upd0 hw.sensors.upd0.indicator0=Off (BatteryPresent), OK hw.sensors.upd0.indicator1=On (Charging), OK hw.sensors.upd0.indicator2=Off (Discharging), OK hw.sensors.upd0.indicator3=Off (NeedReplacement), OK hw.sensors.upd0.indicator4=Off (ShutdownImminent), OK hw.sensors.upd0.indicator5=On (ACPresent), OK hw.sensors.upd0.indicator6=Off (Overload), OK See: http://www.mini-box.com/OpenUPS?sc=8&category=981 Hope this helps! On Mon, Dec 17, 2018 at 09:47:25PM +0100, Radek wrote: > Hello, > > could you recommend me any UPS brands *cheaper* than APC that are fully supported in OpenBSD? > I always use APC, managing them via USB and apcupsd(both servers and clients) and PowerChute(windows clients). It works like a charm. APC is quite expensive brand so I am looking for any cheaper alternatives. > > Thanks! > > -- > radek >
Re: [OpenBSD 6.4][OpenIKED] Route to IPSec tunnel?
GRE(4) is the one to save. GIF(4) might work as well, but my tunnel setting was not correct. Thanks, Siegfried > On Dec 13, 2018, at 10:15 PM, Zhi-Qiang Lei wrote: > > After changed my from-to selectors in iked configuration, the gateway is > almost working. > > [VPN Server] /etc/iked.conf: > > ikev2 quick passive ipcomp esp \ >from 0.0.0.0/0 to 192.168.1.0/24 \ >local egress \ >ikesa auth hmac-sha2-512 enc aes-256 prf hmac-sha2-512 group > curve25519 \ >childsa enc chacha20-poly130 group curve25519 \ >dstid "blackjack.local" > > [Gateway] /etc/iked.conf: > > ikev2 quick active ipcomp esp \ >from 192.168.1.0/24 to $some_network \ >local egress peer $vpn_server_ip \ >ikesa auth hmac-sha2-512 enc aes-256 prf hmac-sha2-512 group > curve25519 \ >childsa enc chacha20-poly130 group curve25519 \ >dstid "asgard.local" > > This is truly convenient thanks to the transparency. I don’t even have to > mind the route. However, I still have some issues to add more policies: > > I have a blacklist contains the networks I don’t want to apply IPSec. When I > was using OpenVPN, it was done by a pf rule: > > pass out quick from to ! route-to tun0 > > What is the best practice to do the same in /etc/iked.conf? > > My intuitive thoughts were: > > [Gateway] /etc/iked.conf: > > ikev2 quick active ipcomp esp \ >from 192.168.1.0/24 to !$network1 \ > … thousands of from-to … > from 192.168.1.0/24 to !$network8000 \ >local egress peer $vpn_server_ip \ >ikesa auth hmac-sha2-512 enc aes-256 prf hmac-sha2-512 group > curve25519 \ >childsa enc chacha20-poly130 group curve25519 \ >dstid "asgard.local" > > But ! operator and too many flows are causing error. > >> On Dec 12, 2018, at 10:37 PM, Zhi-Qiang Lei wrote: >> >> Hi Aaron, >> >> Thanks! I also tried gif. But the behavior is quite weird. Through the gif >> devices, the gateway and VPN server can ping each other, while the packets >> on gateway enc0 from the client routing to the gif device always got bad >> checksums. I think it is related to the bugs on gif(4) man page? >> >> "There are many tunnelling protocol specifications, defined differently from >> each other. gif may not interoperate with peers which are based on different >> specifications, and are picky about outer header fields. For example, you >> cannot usually use gif to talk with IPsec devices that use IPsec tunnel >> mode.” >> >> [Gateway] /etc/hostname.gif0: >> 10.0.0.2 10.0.0.1 >> >> [VPN server] /etc/hostname.gif0: >> 10.0.0.1 10.0.0.2 >> >> Best regards, >> Siegfried >> >>> On Dec 12, 2018, at 7:39 PM, Aaron Mason wrote: >>> >>> Hi Siegfried >>> >>> (Maintainers of the IPSec stack and ISAKMPD are welcome to tear my answer >>> apart) >>> >>> IPSec tunnels are, for want of a better term, entirely transparent - >>> the underlying OS and its clients have no idea that it exists. In >>> order to route across an IPSec tunnel, use gif(4) to create an >>> IP-to-IP tunnel between the endpoints. IPSec will encrypt all traffic >>> that goes across it - from there it's a matter of setting up the >>> static routes on either side. >>> On Wed, Dec 12, 2018 at 7:40 AM Zhi-Qiang Lei >>> wrote: I’m building a gateway to encrypt some traffics: Client —> Gateway —> VPN Server —> Internet (192.168.1.16) (10.0.0.2) [Gateway] /etc/iked.conf: ikev2 quick active ipcomp esp \ from 10.0.0.2 to 0.0.0.0/0 \ local egress peer $vpn_server_ip \ ikesa auth hmac-sha2-512 enc aes-256 prf hmac-sha2-512 group curve25519 \ childsa enc chacha20-poly130 group curve25519 \ dstid "asgard.local" [VPN Server] /etc/iked.conf: ikev2 quick passive ipcomp esp \ from 0.0.0.0/0 to 10.0.0.2 \ local egress \ ikesa auth hmac-sha2-512 enc aes-256 prf hmac-sha2-512 group curve25519 \ childsa enc chacha20-poly130 group curve25519 \ dstid "blackjack.local" The SA has been established. When I ping 10.0.0.2 on VPN Server and tcpdump on gateway enc0 I got: # tcpdump -envps 1500 -i enc0 -l tcpdump: listening on enc0, link-type ENC 03:48:20.778584 (authentic,confidential): SPI 0x7f27bd3b: $vpn_server_ip > $gateway_ip: $vpn_server_ip > 10.0.0.2: icmp: echo request (id:4656 seq:0) [icmp cksum ok] (ttl 255, id 60419, len 84) (ttl 50, id 59144, len 104) 03:48:21.788330 (authentic,confidential): SPI 0x7f27bd3b: $vpn_server_ip > $gateway_ip: $vpn_server_ip > 10.0.0.2: icmp: echo request (id:4656 seq:1) [icmp cksum ok] (ttl 255, id 1688, len 84) (ttl 50, id 31496, len 104) How can I route the packets from the client to the VPN server on the gateway? When I was using OpenVPN, I did the routing in pf.conf: >
TLS'ed popa3d (+pledge, +unveil)
Hi, I have checked out popa3d from the OpenBSD tree from 20131214 (that's the day before it was tedu'd) and wrote a tls multiplexer to it. I also added an imsg framework to further protect shadowed passwords when getpwnam_shadow() is used. The popa3d is unveiled from the start, and much later pledges because under pledge /etc/spwd.db can't be read. But because of privsep the network facing TLS multiplexer can pledge with "stdio", which is awesome. The tarball is here: https://www.centroid.eu/public/popa3d-tls-20181218.tgz My repo is here: https://centroid.eu/cgi-bin/cvsweb/popa3d/popa3d/ Hints on improvement welcome! I'm hopefully going to have a maildir format in the early weeks in january (have to write it unless I find code somewhere for it). Until then I'm probably not using it in production. I have never run a client on it but I have used the POP3 commands USER, PASS, LIST, RETR, DELE and TOP on it and it worked. One thing you'll need is a configfile, mine looks like this in /etc/popa3d.conf: ---> listen on 0.0.0.0 port 995 listen on :: port 995 tls certfile "/etc/ssl/popserver.crt" tls keyfile "/etc/ssl/private/popserver.key" <-- You make the tls keys with help from the ssl manpage. Also when you test this be sure to give openssl s_client the -quiet flag other wise you'll be tripped up on RETR command which is renegotiation for openssl s_client. Finally a project that isn't a complete failure! Because of unveil and pledge this program is not portable to any OS other than OpenBSD, but I don't count on this being taken from the attic back into the source environment... maybe we can make it a port? Patches for me are welcome! Regards, -peter
Re: Cheaper alternatives for APC UPS
This isn't what you want to hear, but all the alternatives to APC I'd be happy to use are more expensive. I've used cheaper alternatives in the past and they don't put out a decent sine wave or cope with dirty power from a generator. Minimum of SmartUPS, and nothing less. There's a load of second hand ones on ebay for a more reasonable price. PK
