We have had issues with the beta, though the build I used was the one
with the voucher patch applied, I do not think that patch caused the
problems that I saw... I posted them on the dev mailing list a week or
so back, but here's a recap:
My 1st email:
1. With "Enable per-user bandwidth restriction" enabled, the Captive
Portal Status screen shows "0 bytes" in the Download column at all times
for each user that logs in. The Upload column increments normally as
the user uses the captive portal. With the per-user option unchecked,
the Download column increments as expected.
2. "Enable per-user bandwidth restriction" only appears to work on the
upload setting. In our case, both upload and download were set to 512.
A visit to speedtest.net results in close to 512K uploads, but the
downloads are on the order of 9 Megabit (which is the top end of our
traffic shaping setting).
My 2nd email:
1. Our NMS system was unable to communicate via SNMP (UDP 161) to a few
devices on the inside leg of our Monowall. We have a very simple rule
set, so we are certain that it was not an error in the firewall rules
that caused this issue. This problem only occurred when attempting to
communicate to three switches on the subnet. Our NMS could successfully
communicate to 13 access points and 10 switches via SNMP, but not the
last three. The firewall log showed that the replies from these devices
were being blocked by the Monowall. Traces ran on the NMS itself showed
that no packets were being received. This was a really strange issue.
(Yes, we are running a captive portal, but IP Pass-through is enabled
for anything destined to our NMS IP address.)
2. An application (ping plotter) running continuous traceroutes (ICMP)
through Monowall was having periods of packet loss at hops beyond
Monowall. Initially, I thought we were having packet loss at this hop.
This application graphs the results and these graphs looked as though
packets were being dropped at regular intervals at this third hop beyond
Monowall. (All packets would make it for about 10 seconds, then all
packets would be dropped for about 10 seconds.) Oddly, the firewall log
showed that these icmp packets were being dropped at similar intervals.
3. A captive portal user uses the Cisco VPN client to connect to their
corporate network. This VPN client used UDP 4500 (I believe) to
initiate the connection. Even though no rules existed which would block
this traffic, it was being blocked from going out at the firewall (and
I loaded version 1.231 and all these issues disappeared without any
further configuration changes.
On 4/26/07, Jason [WeatherServer] <Jason at weatherserver dot net> wrote:
> Is there any huge bugs in the beta or is ok to run?
> Weather Alerts, Traffic Alerts, Toronto Fire CAD Alerts
> All to your email, 24/7/365
> *****Visit us today*****