Messages

Both of those are MIPS, which is at best a Tier 3 arch for FreeBSD.  I don't speak for OPNsense but it's unlikely that much development effort would be allocated to making a MIPS build.

While not quite as tiny as the products you mention, a PCEngines APU2 with mPCIe Wi-Fi card and antenna seems doable.

'restart' only works if, as it says, dnsmasq_enable="YES" appears in the /etc/rc.conf file.  If it doesn't, you must acknowledge/override this with 'onerestart' instead:

Code Select Expand

% service dnsmasq onerestart

This is not particular to dnsmasq.  It applies to most packages.

Trying to do a clean install of 17.7.5 amd64 via USB memory stick on an OPNsense Quad Core Gen3 rack appliance (4GB RAM, 2GB CF), and it fails around 77%:

Code Select Expand

Execution of the command

/usr/local/bin/cpdup -vvv -I -o /usr/share /mnt/usr/share

FAILED with a return code of 1.

< View Log >  < Mail Log >  < Retry >  < Cancel >  < Skip >


Searching the forums I found:
[WONTFIX] Boot media for 15.1.9 : error 1 at installation.
https://forum.opnsense.org/index.php?topic=307.0

Is this the same cpdup / memory exhaustion problem, and is there anything I can do to salvage this unit?  As it has aborted mid-install it no longer boots from the CF.  It was running 17.1.4 just fine prior to this.


UPDATE / SOLVED!
Choosing MBR instead of GPT got it working.

Not much help, but I've had poor luck with FreeBSD, the external APU2C4 USB3 ports, and USB3 memory sticks unless I set that kern.cam.boot_delay variable to something non-zero.  I believe OPNsense sets this automatically now, so if that hasn't solved it for you maybe try:
a)  find/borrow a USB2 memory stick,
b)  try again to find that USB2 internal port adapter cable,
c)  transplant the m.2 drive to another host computer and write the image there, then move the m.2 drive back

FreeBSD 11.0 (which the current OPNsense is built on) has support for the NIC LEDs (/dev/led/igb[0-2]); that's in the generic kernel.  See 'man led' for what characters you can write to them.

I don't think the LEDs you're interested in have built-in support, as of FreeBSD 11.0 anyway.

See this forum thread for homemade drivers:  APU2 LED/switch driver for FreeBSD?
http://www.pcengines.info/forums/?page=post&id=F5BBF3CB-CFFF-4B03-B377-2E61055008EB

Once you've got either of the drivers mentioned in that thread working, you will have to figure out how/where to tweak OPNsense to do something useful with it.

Yeah, the "spanning-tree portfast" is OK if the node at the other end is a leaf (e.g. a single server), not a branch (e.g. a switch with multiple endpoints beyond).  Not knowing anything about your OPNsense configuration, it would be safer not to consider it a leaf, and remove the "spanning-tree portfast" for now.

One other trick on the 3750 side is after you have finished configuring the physical ports and virtual port-channel, to "shutdown" then "no shutdown" the physical ports to make IOS really notice your changes.

Something like:

Code Select Expand

configure terminal
interface range GigabitEthernet 2/0/46-47
shutdown
{ wait a few seconds }
no shutdown
exit
exit

Or reboot the whole switch.

mimugmail has probably solved it... as you don't mention any VLANs, why are you trunk'ing?  Or, until you permit any VLANs, what are you trunking?

That aside, I have two differences in my 3750E / 3850 GigabitEthernet interface configs when aggregating to FreeBSD servers:

Code Select Expand

channel-protocol lacp
channel-group 12 mode active

Maybe the defaults for your IOS version don't require this anymore, but unless I force LACP and force ACTIVE, it doesn't work for me.

Let me throw my 2 cents at your question about comparing OPNsense to commercial offerings.  Where I work I have replaced some fairly expensive big-name gear with OPNsense.  Overall, the result has been great.  Not perfect, but neither was the big-name stuff either.  My opinions, not global truths:

Pro:

• Cost.  If you've got a pool of money for wading in, this won't matter to you.  It mattered to us and we're able to do other stuff with the money we're not spending on big-name products.
• Simplicity of licensing.  I like to be license-compliant, but I really really hate having to navigate big-name license schemes full of self-invented buzzwords.
  
• HW / SW independence.  We bought hardware from applianceshop.eu, but really anything that runs FreeBSD is a candidate for OPNsense.

Con:

• Popularity.  Put out a job ad for big-name knowledgable tech person, lots of responses.  Job ad for OPNsense or FreeBSD knowledgable tech person, fewer responses.
• Manpower.  The OPNsense team and community certainly test and fix and code, but their resources are smaller than big-names.  I should mention that OPNsense does offer paid support options!
• GUI vs CLI.  I am grateful for how easy the GUI made some tasks, and occasionally irritated at having to wander around the GUI trying to find my way back to some screen I remember seeing last month.  The Search helps, but only if you're bang on with your keywords.

Nesting sure keeps the Rules simpler.  Is there any (significant) performance impact that you're aware of?

In one OPNsense 17.1.4 install I have some firewall rules that reference a Host alias which is populated with IP addresses, e.g. 192.168.5.8, 192.168.99.54, etc.

Now I have a need to apply these same rules to a network, e.g. 10.35.0.0/16.

I can of course create a new Network alias and create copies of all the relevant firewall rules, changing these copies to reference my new Network alias.

My question is whether that is the best way to do it?  Is there a performance impact from having more rules?  If instead I moved all the Hosts into the Network alias, is there a performance impact from having hosts in a network alias?  Do I lose or gain some functionality either way?

[3]

"[Solved] Error mounting 19 trying installing OPNsense on APU2C4"
http://www.pcengines.info/forums/?page=post&id=D7DD920F-77ED-4156-9638-D4C5ADB63102

Short answer:
1)  Drop to the loader prompt from the FreeBSD/OPNsense ASCII boot logo menu (menu option 3)
2)  type:  set kern.cam.boot_delay="10000"
3)  type:  boot

@Alphabet Soup, would you mind contacting Deciso about this? I have the A10 here, it looks ok from my end.

The A10 now does not output anything on the serial console and does not seem to boot at all.  Power light and NIC lights work, but otherwise dead.  Looks like this was a hardware problem, and this A10 is headed for the trash.

Not an OPNsense problem, sorry for the noise.

Can you check your System: Administration settings? Serial console should be first, second one off?

Yes, that's what it shows.  /etc/ttys looks unchanged, /boot.config is still "-S115200 -D", and at the tail of /boot/loader.conf:

Code Select Expand

# dynamically generated settings follow
comconsole_speed="115200"
#boot_multicons
boot_serial="YES"
console="comconsole"

Also, when I gracefully reboot the A10, the serial console comes to life starting with:

Code Select Expand

Waiting (max 60 seconds) for system process `vnlru' to stop...done
Waiting (max 60 seconds) for system process `bufdaemon' to stop...done
Waiting (max 60 seconds) for system process `syncer' to stop...
Syncing disks, nodes remaining...1 0 0 done
All buffers synced.
Uptime: 3h26m6s
SeaBIOS (version 1.7.5-20141105_115023-ubuntu)
Found mainboard Deciso Netboard A10
Relocating init from 0x000e76b9 to 0xbf0e5df0 (size 41283)
(snip)

Now running 16.7.9.  No change to this problem.

I upgraded my A10 from 16.7.5 to 16.7.8 remotely last night via SSH CLI.  No errors during the updating but the box never came back after the reboot.  I didn't have a console cable plugged in at that time unfortunately so I don't know if it reported any errors as it tried to boot.

When I arrived on site, I plugged the console cable into the A10 but could not get any response.  Eventually pulled the A10's power plug, then replugged it.  Now output appeared on the serial console.  The usual POST and OPNsense/FreeBSD boot stuff followed, kernel modules loaded, devices enumerated, etc.  Until it got to the point where it was UP'ing my interfaces... the last serial console output was about two of my three used em* interfaces now being UP.  Then silence, no response.  The OS appears to continue to boot as eventually I can ping and SSH and HTTP to the A10, and it seems to be following it's OPNsense configuration.  Looking at /var/log/system.log shows that it just kept right on booting and logging:

Code Select Expand

(snip)
Nov 22 06:34:29 OPNsense kernel: Root mount waiting for: usbus4 usbus2
Nov 22 06:34:29 OPNsense kernel: uhub2: 4 ports with 4 removable, self powered
Nov 22 06:34:29 OPNsense kernel: uhub4: 4 ports with 4 removable, self powered
Nov 22 06:34:29 OPNsense kernel: Trying to mount root from ufs:/dev/mmcsd0s1a [rw,noatime]...
Nov 22 06:34:29 OPNsense kernel: em0: link state changed to UP
Nov 22 06:34:29 OPNsense kernel: em2: link state changed to UP
*****  About here is where the serial console stops outputting.  *****
Nov 22 06:34:29 OPNsense kernel: em3: link state changed to UP
Nov 22 06:34:29 OPNsense kernel: done.
Nov 22 06:34:30 OPNsense kernel:
Nov 22 06:34:30 OPNsense kernel: em0: link state changed to DOWN
Nov 22 06:34:30 OPNsense devd: Executing '/usr/local/opnsense/service/configd_ctl.py interface linkup stop em0'
Nov 22 06:34:30 OPNsense sshlockout[16911]: sshlockout/webConfigurator v3.0 starting up
Nov 22 06:34:30 OPNsense configd.py: [563b1c51-64da-4082-8468-30c6defac169] Linkup stopping em0
Nov 22 06:34:30 OPNsense opnsense: /usr/local/etc/rc.bootup: The command '/sbin/ifconfig 'pppoe0' inet6 -accept_rtadv' returned exit code '1', the output was 'ifconfig: interface pppoe0 does not exist'
Nov 22 06:34:30 OPNsense kernel:
Nov 22 06:34:30 OPNsense kernel: em2: link state changed to DOWN
Nov 22 06:34:30 OPNsense devd: Executing '/usr/local/opnsense/service/configd_ctl.py interface linkup stop em2'
Nov 22 06:34:30 OPNsense configd.py: [09a8de75-38c4-4711-90e3-addbc5b2166b] Linkup stopping em2
Nov 22 06:34:31 OPNsense kernel:
Nov 22 06:34:31 OPNsense kernel: ng0: changing name to 'pppoe0'
Nov 22 06:34:32 OPNsense opnsense: /usr/local/etc/rc.bootup: The command '/sbin/ifconfig 'pppoe1' inet6 -accept_rtadv' returned exit code '1', the output was 'ifconfig: interface pppoe1 does not exist'
Nov 22 06:34:32 OPNsense kernel:
Nov 22 06:34:32 OPNsense kernel: em3: link state changed to DOWN
Nov 22 06:34:32 OPNsense devd: Executing '/usr/local/opnsense/service/configd_ctl.py interface linkup stop em3'
Nov 22 06:34:33 OPNsense configd.py: [9ec92e6b-b17b-4575-8078-0e1e263e8156] Linkup stopping em3
Nov 22 06:34:33 OPNsense kernel:
Nov 22 06:34:33 OPNsense kernel: ng1: changing name to 'pppoe1'
Nov 22 06:34:33 OPNsense kernel: em2: link state changed to UP
Nov 22 06:34:33 OPNsense devd: Executing '/usr/local/opnsense/service/configd_ctl.py interface linkup start em2'
Nov 22 06:34:34 OPNsense configd.py: [19561326-c76a-4047-a362-1c6295b7c439] Linkup starting em2
Nov 22 06:34:34 OPNsense kernel: em0: link state changed to UP
(snip)

I tried rebooting a couple of times, and each time the serial console goes silent and unresponsive after em* UP.  I rechecked for updates, but it reports being up-to-date.

Last time I updated (to 16.7.5) I think I did it via the serial console, so I can sort-of confirm that it worked then.

I can dismiss the first box-dead-after-reboot as a one-time post-upgrade thing, but this serial console issue doesn't want to self-heal so nicely.  Any advice?

Thanks for the explanation.  I was hoping to try a minimal change to see if it affected my setup but, curious as I am to see what building the driver on 16.1 would do, I think straying off into uncharted waters as you describe isn't likely to help me or anybody else.  Guess I'll be updating to 16.7.x when I can and using the package you're providing for everybody.  Thanks again.