Re: OpenBSD/octeon on EdgeRouter PoE - my experience
W dniu 2017-04-25 o 18:47, Daniel Gracia pisze: EdgeRouter PoE octeon has 3 Ethernet hardware ports (it is the very same platform for PoE and Lite). In the case of the PoE unit: * Two first ports are connected to a PHY device (so you can connect an actual UTP/FTP cable). * Third port is connected to an embedded hardware switch rather than a PHY (so you get no cable for your cnmac2). So the OpenBSD kernel output seems reasonable as long as you suppose that nobody has taken the job of writting the driver to enable the embedded switch. Managing PoE is closely related (as this kind of hardware level configuration should require its very own driver). Regards! Sorry for delayed response and thanks for yours. In this case, can someone please let me know if there are any plans for making this switch supported in OpenBSD in the nearest future? I'm pretty excited about these little devices so now I'm thinking about buying EdgeRouter Lite where, as I understand, all 3 ports would be available. And 3 ports is the minimum amount required for my own purposes. -- Cheers, Pawel Waga
Re: OpenBSD/octeon on EdgeRouter PoE - my experience
W dniu 2017-04-25 o 03:14, Doggie pisze:
And here is a couple of suggestions after my thorough reading of
"INSTALL.octeon" doc and experiments performed afterwards:
- replacing all occurrences of "rootdev=sd0" with "rootdev=/dev/sd0",
which fixes the issue with boot process stopping in the middle and
asking for "root device:"
- replacing all occurrences of "$loadaddr" with "${loadaddr}" - just a
cosmetic change
- putting an information that a kernel meant to be used, should actually
be copied to MSDOS partition, so that U-Boot can load it upon boot, e.g.
by doing this:
mount /dev/sd0i /mnt && cp /bsd /mnt/bsd && umount /mnt
Apart from the above, I'd like to suggest more explicit information that
a switch in PoE is not supported at the moment - in this section of
"INSTALL.octeon" doc:
"Ubiquiti Networks EdgeRouter Lite / PoE
onboard serial port, Ethernet and USB controller are supported."
as this could be a deal-breaker for some ports hungry folks :)
--
Cheers,
Pawel Waga
Re: OpenBSD/octeon on EdgeRouter PoE - my experience
W dniu 2017-04-30 o 21:25, Daniel Gracia pisze: I'd bet there are quite more important issues related to the Octean platform than the switch issue, so I won't expect any progress soon. About the Lite, you'd get your three working ports. Regards! Thanks again, Daniel! -- Cheers, Pawel Waga
Re: OpenBSD/octeon on EdgeRouter PoE - my experience
W dniu 2017-05-01 o 02:21, Adam Steen pisze: I have been running an EdgeRouter Lite, using all three ports, for about a year, rock solid! Cheers Adam Thanks for the confirmation, Adam, really appreciate it. -- Cheers, Pawel Waga
Re: OpenBSD/octeon on EdgeRouter PoE - my experience
W dniu 2017-05-02 o 00:01, etie...@magickarpet.org pisze: I also own one of these nice devices, and replaced the usb thumbdrive that was present for my own, to keep the original filesystem intact, just in case. But I had to try a few USB drives, and I suspect the only ones that could be booted on were USB2, and not USB3. That said, I haven't verified this thoroughly. Cheers, I based my USB flashdrive research on this thread: https://community.ubnt.com/t5/EdgeMAX/List-of-Compatible-USB-drives/td-p/1185011# (especially post #5) and eventually chose Transcend JetFlash 710 32GB USB 3.1 Gen 1 - works like a charm in my EdgeRouter PoE. -- Cheers, Pawel Waga
OpenBSD/octeon and "OpenBSD/patches/6.0/common/002_perl.patch.sig"
Hello, In patch "OpenBSD/patches/6.0/common/002_perl.patch.sig" I've found references to two paths that appear to not exist in OpenBSD/octeon: * /usr/libdata/perl5/octeon-openbsd/5.20.3/IO * /usr/libdata/perl5/octeon-openbsd/5.20.3/IO/Socket Instead, there are: * /usr/libdata/perl5/mips64-openbsd/5.20.3/IO * /usr/libdata/perl5/mips64-openbsd/5.20.3/IO/Socket The following change seems to resolve this issue, at least on octeon and i386: -/usr/libdata/perl5/`machine`-openbsd/5.20.3/IO +/usr/libdata/perl5/`arch -s`-openbsd/5.20.3/IO -/usr/libdata/perl5/`machine`-openbsd/5.20.3/IO/Socket +/usr/libdata/perl5/`arch -s`-openbsd/5.20.3/IO/Socket -- Cheers, Pawel Waga
Re: OpenBSD/octeon and "OpenBSD/patches/6.0/common/002_perl.patch.sig"
W dniu 2017-05-05 o 00:18, Theo de Raadt pisze: Strange noone else noticed this for so many months. My pleasure :) Anyways, it is not that important. I won't reroll a 6.0 errata for something so minor. We'll keep an eye out for next time. That is fine with me. Thanks, Theo. -- Cheers, Pawel Waga
Re: octeon port, ubiquity edgerouter
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
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
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
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
OpenBSD/octeon on EdgeRouter PoE - my experience
Hello,
OpenBSD has been my system of choice for router / firewall / access
point purposes since 2003 (v3.3). And naturally it's been doing great :)
Up until this year though, I would always use rather old i386 hardware
(15-20 years old PC's are still in operation), equipped with a bunch of
slow NIC's, while still dreaming about something neat, efficient, small,
silent and low-energy. Then, all of a sudden, a few months ago I
discovered Ubiquiti Networks' EdgeRouter PoE, followed by OpenBSD/octeon
port. Didn't need much time to decide to buy it, remove its original USB
flashdrive, deploy OpenBSD to a new one and finally give it a try. 6.0
Release is now installed, patched and configured with all the needed
packages. Below I include dmesg outputs ("sysctl hw.sensors" produces no
information):
Copyright (c) 1982, 1986, 1989, 1991, 1993
The Regents of the University of California. All rights reserved.
Copyright (c) 1995-2016 OpenBSD. All rights reserved.
http://www.OpenBSD.org
OpenBSD 6.0 (GENERIC) #10: Fri Jul 29 04:45:17 UTC 2016
visa@octeon:/usr/src/sys/arch/octeon/compile/GENERIC
real mem = 536870912 (512MB)
avail mem = 524386304 (500MB)
warning: no entropy supplied by boot loader
mainbus0 at root
cpu0 at mainbus0: Cavium OCTEON 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 "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 **:**:**:**:**:**
atphy0 at cnmac0 phy 7: AR8035 10/100/1000 PHY, rev. 2
cnmac1 at cn30xxgmx0: RGMII, address **:**:**:**:**:**
atphy1 at cnmac1 phy 6: AR8035 10/100/1000 PHY, rev. 2
cnmac2 at cn30xxgmx0: RGMII, address **:**:**:**:**:**
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 "JetFlash Mass
Storage Device" 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.
sd0: 30128MB, 512 bytes/sector, 61702144 sectors
vscsi0 at root
scsibus1 at vscsi0: 256 targets
softraid0 at root
scsibus2 at softraid0: 256 targets
boot device: sd0
root on sd0a (.a) swap on sd0b dump on sd0b
WARNING: No TOD clock, believing file system.
WARNING: CHECK AND RESET THE DATE!
Copyright (c) 1982, 1986, 1989, 1991, 1993
The Regents of the University of California. All rights reserved.
Copyright (c) 1995-2016 OpenBSD. All rights reserved.
http://www.OpenBSD.org
OpenBSD 6.0 (GENERIC.MP) #0: Thu Apr 6 00:45:05 CEST 2017
root@:/usr/src/sys/arch/octeon/compile/GENERIC.MP
real mem = 536870912 (512MB)
avail mem = 524353536 (500MB)
warning: no entropy supplied by boot loader
mainbus0 at root
cpu0 at mainbus0: Cavium OCTEON CPU rev 0.1 500 MHz, Software FP emulation
cpu0: cache L1-I 32KB 4 way D 8KB 64 way, L2 128KB 8 way
cpu1 at mainbus0: Cavium OCTEON CPU rev 0.1 500 MHz, Software FP emulation
cpu1: 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 "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 **:**:**:**:**:**
atphy0 at cnmac0 phy 7: AR8035 10/100/1000 PHY, rev. 2
cnmac1 at cn30xxgmx0: RGMII, address **:**:**:**:**:**
atphy1 at cnmac1 phy 6: AR8035 10/100/1000 PHY, rev. 2
cnmac2 at cn30xxgmx0: RGMII, address **:**:**:**:**:**
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 "JetFlash Mass
Storage Device" 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.
sd0: 30128MB, 512 bytes/sector, 61702144 sectors
vscsi0 at root
scsibus1 at vscsi0: 256 targets
softraid0 at root
scsibus2 at softraid0: 256 targets
boot device: sd0
root on sd0a (.a) swap on sd0b dump on sd0b
WARNING: No TOD clock, believing file system.
WARNING: CHECK AND RESET THE DATE!
cpu1 launched
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 (RAMDISK) #
