Running 1.8.1b540 with SNMP and no troubles here.  Uptime of up to 30 days, and monitoring with cacti, and no issues noted.

Might be fun to nose around the exec.php when it crashes to see what is happening.

Note that some of the Jetway boards will not work on 1.34 and you will need 1.8b to see the onboard nic.  The Jetway NF96U-525 will work with 1.34.  I have used it several times.  And when you get the addon card, get the Intel based one, as it has less load on the CPU.

Study up on RADIUS.  It is more than just authentication, and if properly configured it tracks all the things you were asking for.  I know because we needed it for WISPr compliance. 

So, if this is the same as the server I did a few weeks back, it will only run on the beta, and not on the release.  pfSense uses a newer version of FreeBSD for the base, so it has the drivers.

It is a nice box, and has good performance, but you will need to run the beta.

I can not see any way to do this without massive customization.  You my try pfSense...

Andrew found it.  You need <media> defined if you want to use <mediaopt> in the config.

Code:

         <wan>
             <if>em1</if>
             <media>100BaseTX</media>
             <mediaopt>full-duplex</mediaopt>
             <spoofmac/>
             <ipaddr>206.xxx.xxx.18</ipaddr>
             <subnet>28</subnet>
             <gateway>206.xxx.xxx.17</gateway>
         </wan>

I have an appliance with 6 gigabit-ports and search for an option to trunk 2 or 3 port for one interface. Since many of today's appliances have more ports than needed, trunking would be a very useful feature.

Back to the first question, this is not as easy as you think...

If you have LAC on two interfaces, now what?  It has to go somewhere, and that means LAC on two other interfaces.  Now to use that you have to push 2 gig (less overhead) on two different virtual interfaces.  (Total 4 gig of traffic)  How fast do you think your system buss is in that appliance?  There is a reason for Layer 3 Switches...  It is because full routing and firewall functions take system power, and to "route" 2-10 gig traffic, you really need switching fabric over a powerful backplane.

So, until we have a new bus standard (by which time 10g nics will be standard) this will not really be possible.

Do these work with 1.34 or do they require the beta version to recognize the LAN ports?

Well, m0n0wall is open source, so anything is modifiable...  However, you might just want to set up captive portal with a RADIUS backend to collect the data and approve access.

Sounds like a WINS issue.  Are you running WINS on the SBS server?  Is WINS defined in the DHCP server on both m0n0walls?  If you have connectivity, but not resolution, it is a naming issue.  Setting up WINS properly can help a lot with this.

How do you know the source port?  It is usually random, and so it is usually "Any" in firewall rules.

[System -> Advanced]

First, look under System -> Advanced and find "Disable webGUI anti-lockout rule" and check it.  Note that if you do not have a way back in after you do this, you will be locked out yourself.

This is a term question, not a technicle question.  "FullNAT" is not an IEEE defined standard.  We do, however, support server NAT and 1 to 1 NAT, and one of those may be what you need.

I am running 1.8.1b540 in semi-production.  (Production, but not user facing)  And it is suffering the usual "Cisco can't do autonegiotiation" issue...  So I hard set it in the config file.

Code:

    <interfaces>
        <lan>
            <if>em0</if>
            <ipaddr>192.168.50.1</ipaddr>
            <subnet>24</subnet>
            <media/>
            <mediaopt/>
        </lan>
        <wan>
            <if>em1</if>
            <media/>
            <mediaopt>full-duplex</mediaopt>
            <spoofmac/>
            <ipaddr>206.xxx.xxx.18</ipaddr>
            <subnet>28</subnet>
            <gateway>206.xxx.xxx.17</gateway>
        </wan>
    </interfaces>

But in the GUI and in the CLI it is back to half-duplex...

Code:

em1: flags=8843<UP,BROADCAST,RUNNING,SIMPLEX,MULTICAST> metric 0 mtu 1500
    options=4219b<RXCSUM,TXCSUM,VLAN_MTU,VLAN_HWTAGGING,VLAN_HWCSUM,TSO4,WOL_MAGIC,VLAN_HWTSO>
    ether 00:25:90:67:79:f9
    inet 206.xxx.xxx.18 netmask 0xfffffff0 broadcast 206.xxx.xxx.31
    inet6 xxxx::xxx:xxxx:xxxx:xxxx%em1 prefixlen 64 scopeid 0x2
    nd6 options=41<PERFORMNUD,NO_RADR>
    media: Ethernet autoselect (100baseTX <half-duplex>)
    status: active

Is this a known bug, user error, or new surprise?

There may be, but none of that would work in m0n0wall.  What exactly are you trying to do?  (Not that "software defined networking" has lost almost all meaning, and doesn't help much any more in describing what you need.)