Re: octeon port, ubiquity edgerouter

[Karel Gardas]

On Wed, Jul 26, 2017 at 10:23 AM, Rui Ribeiro  wrote:
> I am very satisfied with the results. Plus, I do not feel comfortable on
> having a proprietary system+proprietary blobs facing the Internet, and will
> irregular or no existent security updates.

What platform do you use such that it does not have blob-based
firmware? Thanks! Karel

Re: octeon port, ubiquity edgerouter

[Doggie]

W dniu 2017-07-26 o 03:25, Theo de Raadt pisze:

Wow.

So there is a series of self-education problems hiding behind this
conversation.

There is a completely proprietary HW-assist platform that the
vendor has as a blob.  You want us to use that?  You want a blob?
You think it will be reverse engineered?  Keep dreaming.

Or let's go back to using the blob.  What else does it do?  Thought
about that?  Nope, I think that went WHOOSH overhead.

And even if the HW was figured out.  Does it work with the way PF
manages every packet from arrival to delivery?  Or is it a switch-style
cut-through approach, without good inspection/management inflection
points.

Probably something designed for PERFORMANCE, and acting to the detriment
of any attempt to smart filter/route packets.

But still, the statement stands that this is a 'performance penalty'?

How do you figure that??

None of the other architectures have the benefit of such a blob.
They do it all in software.

When we run on amd64, we don't have such a blob.  So we operate with
a 'performance penalty' defacto?

Where do you guys keep coming from??  I mean I keep seeing people who
just don't spend an OUNCE OF EFFORT at actually learning how things
are put together, and then cheerily pat each other on the back on
mailing lists with hope and glee, and cheering on about changing a fan?

You really do deserve each other, and to large degree I think perhaps
on that platform perhaps you should stick with the blob-enhanced
vendor-locked Linux.


I learn each day and I like the process!

Apparently erroneously, I assumed that if certain things are already 
"hardware offloaded" in OpenBSD network drivers, one day it will also 
become possible in case of this subject. Which *does not* mean I would 
like to see any blobs around. That's for sure.


Because of the fact I also use FreeBSD, FreeNAS and Windows, I cannot 
say I'm an orthodox OpenBSD user. But I do appreciate the fact I use the 
most secure and well-thought-of system in my routers / firewalls. And 
wouldn't like to change it in any way.


I'm sure no one wanted to insult the OpenBSD/octeon port, or any other. 
In my case it must have been just a bit of dissapointment with the 
current network speed of my ERL's. But again, I simply rate overall 
OpenBSD features higher than this.


Further, if our recent conversation have gone too much offtopic for this 
list - I apologize for that.


And pretty please: do not banish us to Linux land :)

--
Cheers,
Pawel Waga

Re: octeon port, ubiquity edgerouter

[Joe Holden]

On 26/07/2017 00:56, jungle Boogie wrote:
> On 25 July 2017 at 15:20, Doggie  wrote:
>> W dniu 2017-07-25 o 19:39, Peter J. Philipp pisze:
>>>
>>> Actually I bought the silent fans.  So I don't have to write any code,
>>> too bad the foxconn fans are a misdesign.  I'll maintenance this router
>>> next week for the new fans.  I'm putting it into production at home
>>> tomorrow though.
>>
>>
>> Thanks for all the details, Peter, and good luck during next steps of your
>> project.
>>
>> I wonder how fast the NIC's will be - using this CPU and still no hardware
>> acceleration.
>>
> 
> Yeah, I'm wondering that too. It's pretty cool this platform is
> becoming more popular to run openBSD on.
> People are willing to take an unknown (right now) performance penalty
> to run openBSD on it and with pf.
> 
> Sounds like ubiquity should just sell it with openBSD loaded on it
> support the project. ;)
> 
As far as the ERL goes, it seems to be limited to about 250Mbps per
interface (only tested with in+out, 2 500 ish total), regardless of
packet size

Re: octeon port, ubiquity edgerouter

[Peter J. Philipp]

On Wed, Jul 26, 2017 at 12:20:23AM +0200, Doggie wrote:
> W dniu 2017-07-25 o 19:39, Peter J. Philipp pisze:
> > Actually I bought the silent fans.  So I don't have to write any code,
> > too bad the foxconn fans are a misdesign.  I'll maintenance this router
> > next week for the new fans.  I'm putting it into production at home
> > tomorrow though.
> 
> Thanks for all the details, Peter, and good luck during next steps of your
> project.
> 
> I wonder how fast the NIC's will be - using this CPU and still no hardware
> acceleration.
> 
> If you ever want to replace the fans again, I have been having very good
> experience with Noctua devices (http://noctua.at/en/products/fan). The folks
> at the company do know what "silence" means.

Thanks for the hint on the fans.  I have been putting the ER-8 into production
today.  Here is what I found:

1. named doesn't work right, it SIGBUS'es around what I ktraced as kbind() 
issues most likely.  I used the working config file from my APU that was
replace by this router.  Recompiling named without threads starts the daemon 
but it behaves weirdly and doesn't do anything (SERVFAIL).

2. The router is pretty snappy but I did a speed test and it resulted in 
67 Mbps download from my 100 Mbit link.  While I'm ok with that, it's slower
than my old APU1 that I replaced with this thing.  Now in all fairness when 
I download it must be calculated as 4 times 67 Mbps of what the router is
capable of.  Because after I recieve the download on cnmac1/pppoe0 I send it 
out cnmac2 to a NUC that IPSEC's the download and sends it back into cnmac2, 
then it gets routed out cnmac4 to my other computers.  So in aggregate it's 
268 Mbit/s that's going through the router.  While I was doing this I observed 
the CPU at 75% so it may have allowed a bit more but not much more.

Hope that gives you more information.  If I had the choice to get it again
I'd think a bit longer.

-peter

Re: octeon port, ubiquity edgerouter

[Rui Ribeiro]

I also migrated a TP-Link with proprietary acceleration to OpenWRT. But
then tweaked it, and on the plus side, put a *BSD* box/router on front of
it doing NAT, which is what the acceleration was for.  As usually, you
cannot expect deploying a system, namely a *wrt/Linux system in a machine
with limited resources, and not tweaking it/disabling things for better
performance.

I am very satisfied with the results. Plus, I do not feel comfortable on
having a proprietary system+proprietary blobs facing the Internet, and will
irregular or no existent security updates.



On 26 July 2017 at 02:59, Sean Murphy  wrote:

> >>   People are willing to take an unknown (right now) performance
> penalty
> >>   to run openBSD on it and with pf.
>
> When I was using my ERL as primary gateway, I found that my network
> performed better than it did with the dd-wrt based router I was using
> previously.  Everything was more stable, easier to keep track of what
> was going on, and my work VPN was faster to connect and performed
> tremendously.  Anyone talking about a "performance penalty" is missing
> the point.
>
>


-- 
Regards,

--
Rui Ribeiro
Senior Linux Architect and Network Administrator
ISCTE-IUL
https://www.linkedin.com/pub/rui-ribeiro/16/ab8/434

Re: octeon port, ubiquity edgerouter

[jungle Boogie]

On Jul 25, 2017 6:59 PM, "Sean Murphy"  wrote:
>
> >>   People are willing to take an unknown (right now) performance
penalty
> >>   to run openBSD on it and with pf.
>
> When I was using my ERL as primary gateway, I found that my network
> performed better than it did with the dd-wrt based router I was using
> previously.  Everything was more stable, easier to keep track of what
> was going on, and my work VPN was faster to connect and performed
> tremendously.  Anyone talking about a "performance penalty" is missing
> the point.

I absolutely DO NOT want blobs in or around openbsd whatsoever, ever.

Im saying I'm presently surprised to see so many folks running openbsd on
this arch and enjoying it. I certainly enjoy running it and the frequent
updates from the team, I can't say either one of those would happen if we
were still using ubiquity's option.

To make this clear, I love openbsd and will forever be grateful for the
project, the individuals and the 20+ years for the labor of love put into
the project.

Keep openbsd blob free!

Re: octeon port, ubiquity edgerouter

[Sean Murphy]

>>   People are willing to take an unknown (right now) performance penalty
>>   to run openBSD on it and with pf.

When I was using my ERL as primary gateway, I found that my network
performed better than it did with the dd-wrt based router I was using
previously.  Everything was more stable, easier to keep track of what
was going on, and my work VPN was faster to connect and performed
tremendously.  Anyone talking about a "performance penalty" is missing
the point.

Re: octeon port, ubiquity edgerouter

[Theo de Raadt]

> I wonder how fast the NIC's will be - using this CPU and still no hardware
> acceleration.
>
>   Yeah, I'm wondering that too. It's pretty cool this platform is
>   becoming more popular to run openBSD on.
>
>   People are willing to take an unknown (right now) performance penalty
>   to run openBSD on it and with pf.

Wow.

So there is a series of self-education problems hiding behind this
conversation.

There is a completely proprietary HW-assist platform that the
vendor has as a blob.  You want us to use that?  You want a blob?
You think it will be reverse engineered?  Keep dreaming.

Or let's go back to using the blob.  What else does it do?  Thought
about that?  Nope, I think that went WHOOSH overhead.

And even if the HW was figured out.  Does it work with the way PF
manages every packet from arrival to delivery?  Or is it a switch-style
cut-through approach, without good inspection/management inflection
points.

Probably something designed for PERFORMANCE, and acting to the detriment
of any attempt to smart filter/route packets.

But still, the statement stands that this is a 'performance penalty'?

How do you figure that??

None of the other architectures have the benefit of such a blob.
They do it all in software.

When we run on amd64, we don't have such a blob.  So we operate with
a 'performance penalty' defacto?

Where do you guys keep coming from??  I mean I keep seeing people who
just don't spend an OUNCE OF EFFORT at actually learning how things
are put together, and then cheerily pat each other on the back on
mailing lists with hope and glee, and cheering on about changing a fan?

You really do deserve each other, and to large degree I think perhaps
on that platform perhaps you should stick with the blob-enhanced
vendor-locked Linux.

Re: octeon port, ubiquity edgerouter

[jungle Boogie]

On 25 July 2017 at 15:20, Doggie  wrote:
> W dniu 2017-07-25 o 19:39, Peter J. Philipp pisze:
>>
>> Actually I bought the silent fans.  So I don't have to write any code,
>> too bad the foxconn fans are a misdesign.  I'll maintenance this router
>> next week for the new fans.  I'm putting it into production at home
>> tomorrow though.
>
>
> Thanks for all the details, Peter, and good luck during next steps of your
> project.
>
> I wonder how fast the NIC's will be - using this CPU and still no hardware
> acceleration.
>

Yeah, I'm wondering that too. It's pretty cool this platform is
becoming more popular to run openBSD on.
People are willing to take an unknown (right now) performance penalty
to run openBSD on it and with pf.

Sounds like ubiquity should just sell it with openBSD loaded on it
support the project. ;)

Re: octeon port, ubiquity edgerouter

[Doggie]

W dniu 2017-07-25 o 19:39, Peter J. Philipp pisze:

Actually I bought the silent fans.  So I don't have to write any code,
too bad the foxconn fans are a misdesign.  I'll maintenance this router
next week for the new fans.  I'm putting it into production at home
tomorrow though.


Thanks for all the details, Peter, and good luck during next steps of 
your project.


I wonder how fast the NIC's will be - using this CPU and still no 
hardware acceleration.


If you ever want to replace the fans again, I have been having very good 
experience with Noctua devices (http://noctua.at/en/products/fan). The 
folks at the company do know what "silence" means.


--
Cheers,
Pawel Waga

Re: octeon port, ubiquity edgerouter

[Peter J. Philipp]

Actually I bought the silent fans.  So I don't have to write any code,
too bad the foxconn fans are a misdesign.  I'll maintenance this router
next week for the new fans.  I'm putting it into production at home
tomorrow though.

Cheers,

-peter


On 07/25/17 18:38, Peter J. Philipp wrote:
> On Tue, Jul 25, 2017 at 10:58:13AM +0200, Peter J. Philipp wrote:
>> Hi, I got the ER-8.  First impression is that it's in good condition, but the
>> fans are a little noisy, hoping it won't be a pain.  cnmac0 starts on eth4
>> instead of eth0 but that's no problem as long as I remember the order.
> I've had this ER-8 a little over a half day and the only gripe I have is
> the fan noise.  I googled a little about a solution to hardware hack this
> to put less noisy fans in there:
>
> https://community.ubnt.com/t5/EdgeMAX-Stories/Replacing-fans-in-EdgeRouter/cnc-p/1192519#M590
>
> But I'm wondering if there is a more elegant solution.  Is there any 
> capability
> for sensors and fan speed control in the Edgerouter?  Anyone know datasheets
> of this functionality out there somewhere?  I'm willing to try to write a
> driver as a first project, as I can't see these fans going off like that for
> 24/7 in my apartment (even if it's in the hallway).
>
> Regards,
> -peter

Re: octeon port, ubiquity edgerouter

[Peter J. Philipp]

On Tue, Jul 25, 2017 at 10:58:13AM +0200, Peter J. Philipp wrote:
> Hi, I got the ER-8.  First impression is that it's in good condition, but the
> fans are a little noisy, hoping it won't be a pain.  cnmac0 starts on eth4
> instead of eth0 but that's no problem as long as I remember the order.

I've had this ER-8 a little over a half day and the only gripe I have is
the fan noise.  I googled a little about a solution to hardware hack this
to put less noisy fans in there:

https://community.ubnt.com/t5/EdgeMAX-Stories/Replacing-fans-in-EdgeRouter/cnc-p/1192519#M590

But I'm wondering if there is a more elegant solution.  Is there any capability
for sensors and fan speed control in the Edgerouter?  Anyone know datasheets
of this functionality out there somewhere?  I'm willing to try to write a
driver as a first project, as I can't see these fans going off like that for
24/7 in my apartment (even if it's in the hallway).

Regards,
-peter

Re: octeon port, ubiquity edgerouter

[Sean Murphy]

Holger,

That hardware acceleration is proprietary to Ubiquiti's EdgeOS, which
is a fork of Vyatta, if I remember correctly, and not implemented in
the OpenBSD port.

On Tue, Jul 25, 2017 at 6:39 AM, Holger Glaess  wrote:
> hi
>
> what about the hardware functions of the edgerouter
>
>
> description
> https://help.ubnt.com/hc/en-us/articles/115006567467-EdgeRouter-Hardware-Offloading-Explained
>
>
> holger
>
>
>
>> On Mon, Jul 24, 2017 at 07:21:36PM +0200, Peter J. Philipp wrote:
>>> > Now it would be very interesting to see dmesg coming from 8-port ER.
>>
>> Hi, I got the ER-8.  First impression is that it's in good condition, but
>> the
>> fans are a little noisy, hoping it won't be a pain.  cnmac0 starts on eth4
>> instead of eth0 but that's no problem as long as I remember the order.
>>
>> The lanner console cable worked on it with speed 115200.  I've planned on
>> taking this router into production tomorrow.
>>
>>> According to DHL the ER-8 will be delivered here tomorrow.  I'm going to
>>> try
>>> to get a dmesg on list if it's requested.  Thanks to all that made this
>>> hardware possible.  The guy that sent this to me has not included a
>>> console
>>> cable so I have only 1 Lanner FW rollover cable here, hoping it will
>>> work for
>>> this task.  The Lanner rollover cable is cisco compatible it said on
>>> their
>>> support website, so it should work.  Otherwise we'll have to wait about
>>> a day
>>> until I get the rollover cable that I purchased on Amazon yesterday.
>>
>> dmesg follows, thanks to visa@!!!
>>
>> Copyright (c) 1982, 1986, 1989, 1991, 1993
>>   The Regents of the University of California.  All rights reserved.
>> Copyright (c) 1995-2017 OpenBSD. All rights reserved.
>> https://www.OpenBSD.org
>>
>> OpenBSD 6.1-current (GENERIC.MP) #0: Sat Jul 22 21:28:07 UTC 2017
>> visa@octeon:/usr/src/sys/arch/octeon/compile/GENERIC.MP
>> real mem = 2147483648 (2048MB)
>> avail mem = 2113355776 (2015MB)
>> mainbus0 at root
>> cpu0 at mainbus0: CN61xx CPU rev 0.1 800 MHz, Software FP emulation
>> cpu0: cache L1-I 512KB D 8KB 64 way, L2 1024KB 8 way
>> cpu1 at mainbus0: CN61xx CPU rev 0.1 800 MHz, Software FP emulation
>> cpu1: cache L1-I 512KB D 8KB 64 way, L2 1024KB 8 way
>> clock0 at mainbus0: int 5
>> iobus0 at mainbus0
>> simplebus0 at iobus0: "soc"
>> octciu0 at simplebus0
>> cn30xxsmi0 at simplebus0
>> cn30xxsmi1 at simplebus0
>> com0 at simplebus0: ns16550a, 64 byte fifo
>> com0: console
>> com1 at simplebus0: ns16550a, 64 byte fifo
>> octmmc0 at simplebus0
>> sdmmc0 at octmmc0: 8-bit, mmc high-speed
>> octuctl0 at iobus0 base 0x118006f00 irq 56
>> ehci0 at octuctl0
>> usb0 at ehci0: USB revision 2.0
>> uhub0 at usb0 configuration 1 interface 0 "Octeon EHCI root hub" rev
>> 2.00/1.00 addr 1
>> ohci0 at octuctl0, version 1.0
>> usb1 at ohci0: USB revision 1.0
>> uhub1 at usb1 configuration 1 interface 0 "Octeon OHCI root hub" rev
>> 1.00/1.00 addr 1
>> octrng0 at iobus0 base 0x14000 irq 0
>> cn30xxgmx0 at iobus0 base 0x118000800
>> cnmac0 at cn30xxgmx0: SGMII, address 24:a4:3c:06:9f:12
>> ukphy0 at cnmac0 phy 4: Generic IEEE 802.3u media interface, rev. 3: OUI
>> 0x180361, model 0x0004
>> cnmac1 at cn30xxgmx0: SGMII, address 24:a4:3c:06:9f:13
>> ukphy1 at cnmac1 phy 5: Generic IEEE 802.3u media interface, rev. 3: OUI
>> 0x180361, model 0x0004
>> cnmac2 at cn30xxgmx0: SGMII, address 24:a4:3c:06:9f:14
>> ukphy2 at cnmac2 phy 6: Generic IEEE 802.3u media interface, rev. 3: OUI
>> 0x180361, model 0x0004
>> cnmac3 at cn30xxgmx0: SGMII, address 24:a4:3c:06:9f:15
>> ukphy3 at cnmac3 phy 7: Generic IEEE 802.3u media interface, rev. 3: OUI
>> 0x180361, model 0x0004
>> cn30xxgmx1 at iobus0 base 0x118001000
>> cnmac4 at cn30xxgmx1: SGMII, address 24:a4:3c:06:9f:16
>> ukphy4 at cnmac4 phy 0: Generic IEEE 802.3u media interface, rev. 3: OUI
>> 0x180361, model 0x0004
>> cnmac5 at cn30xxgmx1: SGMII, address 24:a4:3c:06:9f:17
>> ukphy5 at cnmac5 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI
>> 0x180361, model 0x0004
>> cnmac6 at cn30xxgmx1: SGMII, address 24:a4:3c:06:9f:18
>> ukphy6 at cnmac6 phy 2: Generic IEEE 802.3u media interface, rev. 3: OUI
>> 0x180361, model 0x0004
>> cnmac7 at cn30xxgmx1: SGMII, address 24:a4:3c:06:9f:19
>> ukphy7 at cnmac7 phy 3: Generic IEEE 802.3u media interface, rev. 3: OUI
>> 0x180361, model 0x0004
>> /dev/ksyms: Symbol table not valid.
>> umass0 at uhub0 port 1 configuration 1 interface 0 "SanDisk Ultra USB 3.0"
>> rev 2.10/1.00 addr 2
>> umass0: using SCSI over Bulk-Only
>> scsibus0 at umass0: 2 targets, initiator 0
>> sd0 at scsibus0 targ 1 lun 0:  SCSI4
>> 0/direct removable serial.07815591241023103380
>> sd0: 118464MB, 512 bytes/sector, 242614272 sectors
>> scsibus1 at sdmmc0: 2 targets, initiator 0
>> sd1 at scsibus1 targ 1 lun 0:  SCSI2 0/direct
>> removable
>> sd1: 3776MB, 512 bytes/sector, 7733248 sectors
>> vscsi0 at root
>> scsibus2 at vscsi0: 256 

Re: octeon port, ubiquity edgerouter

[Holger Glaess]

hi

what about the hardware functions of the edgerouter


description
https://help.ubnt.com/hc/en-us/articles/115006567467-EdgeRouter-Hardware-Offloading-Explained


holger



> On Mon, Jul 24, 2017 at 07:21:36PM +0200, Peter J. Philipp wrote:
>> > Now it would be very interesting to see dmesg coming from 8-port ER.
>
> Hi, I got the ER-8.  First impression is that it's in good condition, but
> the
> fans are a little noisy, hoping it won't be a pain.  cnmac0 starts on eth4
> instead of eth0 but that's no problem as long as I remember the order.
>
> The lanner console cable worked on it with speed 115200.  I've planned on
> taking this router into production tomorrow.
>
>> According to DHL the ER-8 will be delivered here tomorrow.  I'm going to
>> try
>> to get a dmesg on list if it's requested.  Thanks to all that made this
>> hardware possible.  The guy that sent this to me has not included a
>> console
>> cable so I have only 1 Lanner FW rollover cable here, hoping it will
>> work for
>> this task.  The Lanner rollover cable is cisco compatible it said on
>> their
>> support website, so it should work.  Otherwise we'll have to wait about
>> a day
>> until I get the rollover cable that I purchased on Amazon yesterday.
>
> dmesg follows, thanks to visa@!!!
>
> Copyright (c) 1982, 1986, 1989, 1991, 1993
>   The Regents of the University of California.  All rights reserved.
> Copyright (c) 1995-2017 OpenBSD. All rights reserved.
> https://www.OpenBSD.org
>
> OpenBSD 6.1-current (GENERIC.MP) #0: Sat Jul 22 21:28:07 UTC 2017
> visa@octeon:/usr/src/sys/arch/octeon/compile/GENERIC.MP
> real mem = 2147483648 (2048MB)
> avail mem = 2113355776 (2015MB)
> mainbus0 at root
> cpu0 at mainbus0: CN61xx CPU rev 0.1 800 MHz, Software FP emulation
> cpu0: cache L1-I 512KB D 8KB 64 way, L2 1024KB 8 way
> cpu1 at mainbus0: CN61xx CPU rev 0.1 800 MHz, Software FP emulation
> cpu1: cache L1-I 512KB D 8KB 64 way, L2 1024KB 8 way
> clock0 at mainbus0: int 5
> iobus0 at mainbus0
> simplebus0 at iobus0: "soc"
> octciu0 at simplebus0
> cn30xxsmi0 at simplebus0
> cn30xxsmi1 at simplebus0
> com0 at simplebus0: ns16550a, 64 byte fifo
> com0: console
> com1 at simplebus0: ns16550a, 64 byte fifo
> octmmc0 at simplebus0
> sdmmc0 at octmmc0: 8-bit, mmc high-speed
> octuctl0 at iobus0 base 0x118006f00 irq 56
> ehci0 at octuctl0
> usb0 at ehci0: USB revision 2.0
> uhub0 at usb0 configuration 1 interface 0 "Octeon EHCI root hub" rev
> 2.00/1.00 addr 1
> ohci0 at octuctl0, version 1.0
> usb1 at ohci0: USB revision 1.0
> uhub1 at usb1 configuration 1 interface 0 "Octeon OHCI root hub" rev
> 1.00/1.00 addr 1
> octrng0 at iobus0 base 0x14000 irq 0
> cn30xxgmx0 at iobus0 base 0x118000800
> cnmac0 at cn30xxgmx0: SGMII, address 24:a4:3c:06:9f:12
> ukphy0 at cnmac0 phy 4: Generic IEEE 802.3u media interface, rev. 3: OUI
> 0x180361, model 0x0004
> cnmac1 at cn30xxgmx0: SGMII, address 24:a4:3c:06:9f:13
> ukphy1 at cnmac1 phy 5: Generic IEEE 802.3u media interface, rev. 3: OUI
> 0x180361, model 0x0004
> cnmac2 at cn30xxgmx0: SGMII, address 24:a4:3c:06:9f:14
> ukphy2 at cnmac2 phy 6: Generic IEEE 802.3u media interface, rev. 3: OUI
> 0x180361, model 0x0004
> cnmac3 at cn30xxgmx0: SGMII, address 24:a4:3c:06:9f:15
> ukphy3 at cnmac3 phy 7: Generic IEEE 802.3u media interface, rev. 3: OUI
> 0x180361, model 0x0004
> cn30xxgmx1 at iobus0 base 0x118001000
> cnmac4 at cn30xxgmx1: SGMII, address 24:a4:3c:06:9f:16
> ukphy4 at cnmac4 phy 0: Generic IEEE 802.3u media interface, rev. 3: OUI
> 0x180361, model 0x0004
> cnmac5 at cn30xxgmx1: SGMII, address 24:a4:3c:06:9f:17
> ukphy5 at cnmac5 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI
> 0x180361, model 0x0004
> cnmac6 at cn30xxgmx1: SGMII, address 24:a4:3c:06:9f:18
> ukphy6 at cnmac6 phy 2: Generic IEEE 802.3u media interface, rev. 3: OUI
> 0x180361, model 0x0004
> cnmac7 at cn30xxgmx1: SGMII, address 24:a4:3c:06:9f:19
> ukphy7 at cnmac7 phy 3: Generic IEEE 802.3u media interface, rev. 3: OUI
> 0x180361, model 0x0004
> /dev/ksyms: Symbol table not valid.
> umass0 at uhub0 port 1 configuration 1 interface 0 "SanDisk Ultra USB 3.0"
> rev 2.10/1.00 addr 2
> umass0: using SCSI over Bulk-Only
> scsibus0 at umass0: 2 targets, initiator 0
> sd0 at scsibus0 targ 1 lun 0:  SCSI4
> 0/direct removable serial.07815591241023103380
> sd0: 118464MB, 512 bytes/sector, 242614272 sectors
> scsibus1 at sdmmc0: 2 targets, initiator 0
> sd1 at scsibus1 targ 1 lun 0:  SCSI2 0/direct
> removable
> sd1: 3776MB, 512 bytes/sector, 7733248 sectors
> vscsi0 at root
> scsibus2 at vscsi0: 256 targets
> softraid0 at root
> scsibus3 at softraid0: 256 targets
> boot device: sd0
> root on sd0a (08e1253cf19e0676.a) swap on sd0b dump on sd0b
> WARNING: No TOD clock, believing file system.
> WARNING: CHECK AND RESET THE DATE!
> cpu1 launched
> 
>
> I have decided to install OpenBSD on an external USB stick which takes up
> the
> only port.  This leaves 

Re: octeon port, ubiquity edgerouter

[Peter J. Philipp]

On Mon, Jul 24, 2017 at 07:21:36PM +0200, Peter J. Philipp wrote:
> > Now it would be very interesting to see dmesg coming from 8-port ER.

Hi, I got the ER-8.  First impression is that it's in good condition, but the
fans are a little noisy, hoping it won't be a pain.  cnmac0 starts on eth4
instead of eth0 but that's no problem as long as I remember the order.

The lanner console cable worked on it with speed 115200.  I've planned on 
taking this router into production tomorrow.

> According to DHL the ER-8 will be delivered here tomorrow.  I'm going to try
> to get a dmesg on list if it's requested.  Thanks to all that made this
> hardware possible.  The guy that sent this to me has not included a console
> cable so I have only 1 Lanner FW rollover cable here, hoping it will work for
> this task.  The Lanner rollover cable is cisco compatible it said on their
> support website, so it should work.  Otherwise we'll have to wait about a day
> until I get the rollover cable that I purchased on Amazon yesterday.

dmesg follows, thanks to visa@!!!

Copyright (c) 1982, 1986, 1989, 1991, 1993
The Regents of the University of California.  All rights reserved.
Copyright (c) 1995-2017 OpenBSD. All rights reserved.  https://www.OpenBSD.org

OpenBSD 6.1-current (GENERIC.MP) #0: Sat Jul 22 21:28:07 UTC 2017
visa@octeon:/usr/src/sys/arch/octeon/compile/GENERIC.MP
real mem = 2147483648 (2048MB)
avail mem = 2113355776 (2015MB)
mainbus0 at root
cpu0 at mainbus0: CN61xx CPU rev 0.1 800 MHz, Software FP emulation
cpu0: cache L1-I 512KB D 8KB 64 way, L2 1024KB 8 way
cpu1 at mainbus0: CN61xx CPU rev 0.1 800 MHz, Software FP emulation
cpu1: cache L1-I 512KB D 8KB 64 way, L2 1024KB 8 way
clock0 at mainbus0: int 5
iobus0 at mainbus0
simplebus0 at iobus0: "soc"
octciu0 at simplebus0
cn30xxsmi0 at simplebus0
cn30xxsmi1 at simplebus0
com0 at simplebus0: ns16550a, 64 byte fifo
com0: console
com1 at simplebus0: ns16550a, 64 byte fifo
octmmc0 at simplebus0
sdmmc0 at octmmc0: 8-bit, mmc high-speed
octuctl0 at iobus0 base 0x118006f00 irq 56
ehci0 at octuctl0
usb0 at ehci0: USB revision 2.0
uhub0 at usb0 configuration 1 interface 0 "Octeon EHCI root hub" rev 2.00/1.00 
addr 1
ohci0 at octuctl0, version 1.0
usb1 at ohci0: USB revision 1.0
uhub1 at usb1 configuration 1 interface 0 "Octeon OHCI root hub" rev 1.00/1.00 
addr 1
octrng0 at iobus0 base 0x14000 irq 0
cn30xxgmx0 at iobus0 base 0x118000800
cnmac0 at cn30xxgmx0: SGMII, address 24:a4:3c:06:9f:12
ukphy0 at cnmac0 phy 4: Generic IEEE 802.3u media interface, rev. 3: OUI 
0x180361, model 0x0004
cnmac1 at cn30xxgmx0: SGMII, address 24:a4:3c:06:9f:13
ukphy1 at cnmac1 phy 5: Generic IEEE 802.3u media interface, rev. 3: OUI 
0x180361, model 0x0004
cnmac2 at cn30xxgmx0: SGMII, address 24:a4:3c:06:9f:14
ukphy2 at cnmac2 phy 6: Generic IEEE 802.3u media interface, rev. 3: OUI 
0x180361, model 0x0004
cnmac3 at cn30xxgmx0: SGMII, address 24:a4:3c:06:9f:15
ukphy3 at cnmac3 phy 7: Generic IEEE 802.3u media interface, rev. 3: OUI 
0x180361, model 0x0004
cn30xxgmx1 at iobus0 base 0x118001000
cnmac4 at cn30xxgmx1: SGMII, address 24:a4:3c:06:9f:16
ukphy4 at cnmac4 phy 0: Generic IEEE 802.3u media interface, rev. 3: OUI 
0x180361, model 0x0004
cnmac5 at cn30xxgmx1: SGMII, address 24:a4:3c:06:9f:17
ukphy5 at cnmac5 phy 1: Generic IEEE 802.3u media interface, rev. 3: OUI 
0x180361, model 0x0004
cnmac6 at cn30xxgmx1: SGMII, address 24:a4:3c:06:9f:18
ukphy6 at cnmac6 phy 2: Generic IEEE 802.3u media interface, rev. 3: OUI 
0x180361, model 0x0004
cnmac7 at cn30xxgmx1: SGMII, address 24:a4:3c:06:9f:19
ukphy7 at cnmac7 phy 3: Generic IEEE 802.3u media interface, rev. 3: OUI 
0x180361, model 0x0004
/dev/ksyms: Symbol table not valid.
umass0 at uhub0 port 1 configuration 1 interface 0 "SanDisk Ultra USB 3.0" rev 
2.10/1.00 addr 2
umass0: using SCSI over Bulk-Only
scsibus0 at umass0: 2 targets, initiator 0
sd0 at scsibus0 targ 1 lun 0:  SCSI4 0/direct 
removable serial.07815591241023103380
sd0: 118464MB, 512 bytes/sector, 242614272 sectors
scsibus1 at sdmmc0: 2 targets, initiator 0
sd1 at scsibus1 targ 1 lun 0:  SCSI2 0/direct removable
sd1: 3776MB, 512 bytes/sector, 7733248 sectors
vscsi0 at root
scsibus2 at vscsi0: 256 targets
softraid0 at root
scsibus3 at softraid0: 256 targets
boot device: sd0
root on sd0a (08e1253cf19e0676.a) swap on sd0b dump on sd0b
WARNING: No TOD clock, believing file system.
WARNING: CHECK AND RESET THE DATE!
cpu1 launched


I have decided to install OpenBSD on an external USB stick which takes up the
only port.  This leaves little room for a USB-based RTC unless I also get a
USB hub.  I'll leave sd1 as is in case I ever want to explore the ubiquiti OS 
(edgeOS?).

With best regards,
-peter

Re: octeon port, ubiquity edgerouter

[Daniel Gracia]

I have and spare ERPRO-8 (almost the same dual-core MIPS, 1GHz vs 800MHz,
two SFP ports) that could be included on this tests.

Regards,


2017-07-24 19:21 GMT+02:00 Peter J. Philipp :

> On Mon, Jul 24, 2017 at 07:11:32PM +0200, Doggie wrote:
> > W dniu 2017-07-24 o 14:18, Sean Murphy pisze:
> > > Whoops, you're right.  I did mention that it was an ERL in my original
> > > email, but I didn't follow the original link.  Sorry for the noise.
> >
> > All I can say is that I share the same good experience with ERL :)
> >
> > Now it would be very interesting to see dmesg coming from 8-port ER.
> >
> > --
> > Cheers,
> > Pawel Waga
>
> Hi,
>
> According to DHL the ER-8 will be delivered here tomorrow.  I'm going to
> try
> to get a dmesg on list if it's requested.  Thanks to all that made this
> hardware possible.  The guy that sent this to me has not included a console
> cable so I have only 1 Lanner FW rollover cable here, hoping it will work
> for
> this task.  The Lanner rollover cable is cisco compatible it said on their
> support website, so it should work.  Otherwise we'll have to wait about a
> day
> until I get the rollover cable that I purchased on Amazon yesterday.
>
> Cheers,
> -peter
>
>

Re: octeon port, ubiquity edgerouter

[Peter J. Philipp]

On Mon, Jul 24, 2017 at 07:11:32PM +0200, Doggie wrote:
> W dniu 2017-07-24 o 14:18, Sean Murphy pisze:
> > Whoops, you're right.  I did mention that it was an ERL in my original
> > email, but I didn't follow the original link.  Sorry for the noise.
> 
> All I can say is that I share the same good experience with ERL :)
> 
> Now it would be very interesting to see dmesg coming from 8-port ER.
> 
> -- 
> Cheers,
> Pawel Waga

Hi,

According to DHL the ER-8 will be delivered here tomorrow.  I'm going to try
to get a dmesg on list if it's requested.  Thanks to all that made this
hardware possible.  The guy that sent this to me has not included a console
cable so I have only 1 Lanner FW rollover cable here, hoping it will work for
this task.  The Lanner rollover cable is cisco compatible it said on their
support website, so it should work.  Otherwise we'll have to wait about a day
until I get the rollover cable that I purchased on Amazon yesterday.

Cheers,
-peter

Re: octeon port, ubiquity edgerouter

[Doggie]

W dniu 2017-07-24 o 14:18, Sean Murphy pisze:

Whoops, you're right.  I did mention that it was an ERL in my original
email, but I didn't follow the original link.  Sorry for the noise.


All I can say is that I share the same good experience with ERL :)

Now it would be very interesting to see dmesg coming from 8-port ER.

--
Cheers,
Pawel Waga

Re: octeon port, ubiquity edgerouter

[Sean Murphy]

On Sat, Jul 22, 2017 at 12:26 PM, Doggie  wrote:

> Judging by your dmesg, Sean, you are describing EdgeRouter Lite
> (https://www.ubnt.com/edgemax/edgerouter-lite/), while Peter was asking
> about EdgeRouter (https://www.ubnt.com/edgemax/edgerouter/).
>
> BTW, it's really great to see now we have not 2, but 4 models of Ubiquiti
> routers supported! (https://www.openbsd.org/octeon.html)
>
> --
> Cheers,
> Pawel Waga

Whoops, you're right.  I did mention that it was an ERL in my original
email, but I didn't follow the original link.  Sorry for the noise.

Re: usb RTC, was Re: octeon port, ubiquity edgerouter

[Tinker]

It (the DS3231) is on the I2C bus. Is that good or bad?

On 2017-07-23 06:50, Rupert Gallagher wrote:

Dirty cheap.
https://www.adafruit.com/product/3013
Sent from ProtonMail Mobile

On Sat, Jul 22, 2017 at 8:33 PM, gwes  wrote:

On 07/22/17 12:10, Theo de Raadt wrote: > > I'd really like if someone 
could find a USB RTC clock, which is a viable > affordable product 
which we can then create good support for. I've searched > and found a 
few prototypes and 'licence key' products, but nothing readily > 
available which we could support & encourage as a solution for the RTC 
> problem. > What kind of packaging, fit & finish, and price would be acceptable? For example: A commodity microcontroller on a tiny PCB, a Dallas Semi RTC on another tiny commodity PCB and a lithium coin cell in a 4cm x 6cm x 2cm commodity box could be professionally assembled and sold in unit quantities in a month for $50. Accuracy limit is the 32Khz crystal. Temperature compensation to match the standard quartz curves in the ucode. Burn-in and trimming to a few PPM would add maybe $5. The same parts on a single PCB in a slightly smaller box might take three months, an expected sale quantity of 50, and sell for $30. USB stick size, etc. - I'm sure you can extrapolate from there. Geoff Steckel

Re: usb RTC, was Re: octeon port, ubiquity edgerouter

[Rui Ribeiro]

I have bought already a couple of DS3231 at aliexpress, battery included
and they cost around 1USD

On 23 July 2017 at 07:50, Rupert Gallagher  wrote:

> Dirty cheap.
> https://www.adafruit.com/product/3013
> Sent from ProtonMail Mobile
>
> On Sat, Jul 22, 2017 at 8:33 PM, gwes  wrote:
>
> > On 07/22/17 12:10, Theo de Raadt wrote: > > I'd really like if someone
> could find a USB RTC clock, which is a viable > affordable product which we
> can then create good support for. I've searched > and found a few
> prototypes and 'licence key' products, but nothing readily > available
> which we could support & encourage as a solution for the RTC > problem. >
> What kind of packaging, fit & finish, and price would be acceptable? For
> example: A commodity microcontroller on a tiny PCB, a Dallas Semi RTC on
> another tiny commodity PCB and a lithium coin cell in a 4cm x 6cm x 2cm
> commodity box could be professionally assembled and sold in unit quantities
> in a month for $50. Accuracy limit is the 32Khz crystal. Temperature
> compensation to match the standard quartz curves in the ucode. Burn-in and
> trimming to a few PPM would add maybe $5. The same parts on a single PCB in
> a slightly smaller box might take three months, an expected sale quantity
> of 50, and sell for $30. USB stick size, etc. - I'm sure you can
> extrapolate from there. Geoff Steckel
>



-- 
Regards,

--
Rui Ribeiro
Senior Linux Architect and Network Administrator
ISCTE-IUL
https://www.linkedin.com/pub/rui-ribeiro/16/ab8/434

Re: usb RTC, was Re: octeon port, ubiquity edgerouter

[Rupert Gallagher]

Dirty cheap.
https://www.adafruit.com/product/3013
Sent from ProtonMail Mobile

On Sat, Jul 22, 2017 at 8:33 PM, gwes  wrote:

> On 07/22/17 12:10, Theo de Raadt wrote: > > I'd really like if someone could 
> find a USB RTC clock, which is a viable > affordable product which we can 
> then create good support for. I've searched > and found a few prototypes and 
> 'licence key' products, but nothing readily > available which we could 
> support & encourage as a solution for the RTC > problem. > What kind of 
> packaging, fit & finish, and price would be acceptable? For example: A 
> commodity microcontroller on a tiny PCB, a Dallas Semi RTC on another tiny 
> commodity PCB and a lithium coin cell in a 4cm x 6cm x 2cm commodity box 
> could be professionally assembled and sold in unit quantities in a month for 
> $50. Accuracy limit is the 32Khz crystal. Temperature compensation to match 
> the standard quartz curves in the ucode. Burn-in and trimming to a few PPM 
> would add maybe $5. The same parts on a single PCB in a slightly smaller box 
> might take three months, an expected sale quantity of 50, and sell for $30. 
> USB stick size, etc. - I'm sure you can extrapolate from there. Geoff Steckel

usb RTC, was Re: octeon port, ubiquity edgerouter

[gwes]

On 07/22/17 12:10, Theo de Raadt wrote:


I'd really like if someone could find a USB RTC clock, which is a viable
affordable product which we can then create good support for.  I've searched
and found a few prototypes and 'licence key' products, but nothing readily
available which we could support & encourage as a solution for the RTC
problem.


What kind of packaging, fit & finish, and price would be acceptable?

For example:
A commodity microcontroller on a tiny PCB, a Dallas Semi RTC on
another tiny commodity PCB and a lithium coin cell in a
4cm x 6cm x 2cm commodity box could be professionally assembled
and sold in unit quantities in a month for $50.

Accuracy limit is the 32Khz crystal. Temperature compensation
to match the standard quartz curves in the ucode. Burn-in
and trimming to a few PPM would add maybe $5.

The same parts on a single PCB in a slightly smaller box might take
three months, an expected sale quantity of 50, and sell for $30.

USB stick size, etc. - I'm sure you can extrapolate from there.

Geoff Steckel

Re: octeon port, ubiquity edgerouter

[Doggie]

W dniu 2017-07-22 o 17:55, Sean Murphy pisze:

On Sat, Jul 22, 2017 at 5:46 AM, Peter J. Philipp  wrote:

Hi,

Someone has offered me a deal on a somewhat used Ubiquiti Edgerouter,
https://www.ubnt.com/edgemax/edgerouter/  <-- this one.

Is it supported by OpenBSD/octeon and if not what needs to be done to make it
work?  Has anyone experience with this hardware?

Regards,
-peter



Hi Peter,

This is a solid machine, if you can get it, do so.  OpenBSD 6.1 works
very well on this hardware, I have used mine variously as a gateway
router with PF, DHCP server, DNS server with unbound, and local name
server with nsd.  Currently it's acting as local name server while
standing as backup router/nameserver/dhcp if needed.  You will have to
have valid time servers as the ERL doesn't have an internal clock.
Have fun!

Here's a dmesg:

[...]

Judging by your dmesg, Sean, you are describing EdgeRouter Lite 
(https://www.ubnt.com/edgemax/edgerouter-lite/), while Peter was asking 
about EdgeRouter (https://www.ubnt.com/edgemax/edgerouter/).


BTW, it's really great to see now we have not 2, but 4 models of 
Ubiquiti routers supported! (https://www.openbsd.org/octeon.html)


--
Cheers,
Pawel Waga

Re: octeon port, ubiquity edgerouter

[Theo de Raadt]

> > This is a solid machine, if you can get it, do so.  OpenBSD 6.1 works
> > very well on this hardware, I have used mine variously as a gateway
> > router with PF, DHCP server, DNS server with unbound, and local name
> > server with nsd.  Currently it's acting as local name server while
> > standing as backup router/nameserver/dhcp if needed.  You will have to
> > have valid time servers as the ERL doesn't have an internal clock.
> > Have fun!

I'd really like if someone could find a USB RTC clock, which is a viable
affordable product which we can then create good support for.  I've searched
and found a few prototypes and 'licence key' products, but nothing readily
available which we could support & encourage as a solution for the RTC
problem.

Re: octeon port, ubiquity edgerouter

[Peter J. Philipp]

On Sat, Jul 22, 2017 at 11:55:17AM -0400, Sean Murphy wrote:
> Hi Peter,
> 
> This is a solid machine, if you can get it, do so.  OpenBSD 6.1 works
> very well on this hardware, I have used mine variously as a gateway
> router with PF, DHCP server, DNS server with unbound, and local name
> server with nsd.  Currently it's acting as local name server while
> standing as backup router/nameserver/dhcp if needed.  You will have to
> have valid time servers as the ERL doesn't have an internal clock.
> Have fun!
> 
> Here's a dmesg:

Thanks!  I decided to buy this, after the words of confidence from everyone
who replied.

Thanks,
-peter

Re: octeon port, ubiquity edgerouter

[Sean Murphy]

On Sat, Jul 22, 2017 at 5:46 AM, Peter J. Philipp  wrote:
> Hi,
>
> Someone has offered me a deal on a somewhat used Ubiquiti Edgerouter,
> https://www.ubnt.com/edgemax/edgerouter/  <-- this one.
>
> Is it supported by OpenBSD/octeon and if not what needs to be done to make it
> work?  Has anyone experience with this hardware?
>
> Regards,
> -peter
>

Hi Peter,

This is a solid machine, if you can get it, do so.  OpenBSD 6.1 works
very well on this hardware, I have used mine variously as a gateway
router with PF, DHCP server, DNS server with unbound, and local name
server with nsd.  Currently it's acting as local name server while
standing as backup router/nameserver/dhcp if needed.  You will have to
have valid time servers as the ERL doesn't have an internal clock.
Have fun!

Here's a dmesg:

Copyright (c) 1982, 1986, 1989, 1991, 1993
The Regents of the University of California.  All rights reserved.
Copyright (c) 1995-2017 OpenBSD. All rights reserved.  https://www.OpenBSD.org

OpenBSD 6.1 (GENERIC) #0: Mon Apr  3 07:47:02 UTC 2017
visa@octeon:/usr/src/sys/arch/octeon/compile/GENERIC
real mem = 536870912 (512MB)
avail mem = 524255232 (499MB)
warning: no entropy supplied by boot loader
mainbus0 at root
cpu0 at mainbus0: CN50xx CPU rev 0.1 500 MHz, Software FP emulation
cpu0: cache L1-I 32KB 4 way D 8KB 64 way, L2 128KB 8 way
clock0 at mainbus0: int 5
iobus0 at mainbus0
dwctwo0 at iobus0 base 0x118006800 irq 56
usb0 at dwctwo0: USB revision 2.0
uhub0 at usb0 configuration 1 interface 0 "Octeon DWC2 root hub" rev
2.00/1.00 addr 1
octrng0 at iobus0 base 0x14000 irq 0
cn30xxgmx0 at iobus0 base 0x118000800
cnmac0 at cn30xxgmx0: RGMII, address 44:d9:e7:40:b5:c8
atphy0 at cnmac0 phy 7: AR8035 10/100/1000 PHY, rev. 2
cnmac1 at cn30xxgmx0: RGMII, address 44:d9:e7:40:b5:c9
atphy1 at cnmac1 phy 6: AR8035 10/100/1000 PHY, rev. 2
cnmac2 at cn30xxgmx0: RGMII, address 44:d9:e7:40:b5:ca
atphy2 at cnmac2 phy 5: AR8035 10/100/1000 PHY, rev. 2
uartbus0 at mainbus0
com0 at uartbus0 base 0x118000800 irq 34: ns16550a, 64 byte fifo
com0: console
com1 at uartbus0 base 0x118000c00 irq 35: ns16550a, 64 byte fifo
/dev/ksyms: Symbol table not valid.
umass0 at uhub0 port 1 configuration 1 interface 0 "Lexar USB Flash
Drive" rev 2.10/11.00 addr 2
umass0: using SCSI over Bulk-Only
scsibus0 at umass0: 2 targets, initiator 0
sd0 at scsibus0 targ 1 lun 0:  SCSI4
0/direct removable serial.05dca83aZB0L2W63LA4P
sd0: 30526MB, 512 bytes/sector, 62517248 sectors
vscsi0 at root
scsibus1 at vscsi0: 256 targets
softraid0 at root
scsibus2 at softraid0: 256 targets
boot device: sd0
root on sd0a (fb74a192b03ee90f.a) swap on sd0b dump on sd0b
WARNING: No TOD clock, believing file system.
WARNING: CHECK AND RESET THE DATE!

Re: octeon port, ubiquity edgerouter

[Visa Hankala]

On Sat, Jul 22, 2017 at 11:46:02AM +0200, Peter J. Philipp wrote:
> Someone has offered me a deal on a somewhat used Ubiquiti Edgerouter,
> https://www.ubnt.com/edgemax/edgerouter/  <-- this one.
> 
> Is it supported by OpenBSD/octeon and if not what needs to be done to make it
> work?

The hardware works with OpenBSD 6.1.

Re: octeon port, ubiquity edgerouter

[Florian Ermisch]

Hi,

if noone chimes in then maybe 
you can get a dmesg or lshw 
output from the linux-based 
EdgeOS to get some more 
details on the hardware.
I would guess it's quite a bit 
beefier than the ERL3 and for
embedded platforms this can 
mean more differences than 
just more cores and more RAM.

Regards, Florian 

Am 22. Juli 2017 11:46:02 MESZ schrieb "Peter J. Philipp" :
>Hi,
>
>Someone has offered me a deal on a somewhat used Ubiquiti Edgerouter,
>https://www.ubnt.com/edgemax/edgerouter/  <-- this one.
>
>Is it supported by OpenBSD/octeon and if not what needs to be done to
>make it
>work?  Has anyone experience with this hardware?
>
>Regards,
>-peter

octeon port, ubiquity edgerouter

[Peter J. Philipp]

Hi,

Someone has offered me a deal on a somewhat used Ubiquiti Edgerouter,
https://www.ubnt.com/edgemax/edgerouter/  <-- this one.

Is it supported by OpenBSD/octeon and if not what needs to be done to make it
work?  Has anyone experience with this hardware?

Regards,
-peter