@stephenw10: I get stuck beacons but it never actually causes a problem. You can try setting hw.ath.bstuck to a higher value, I use 8. Steve I have it set to 8.  I usually have several successful resets after stuck beacons before it gets the card into an inconsistent state.  I went through numerous iterations of settings and tweaks but I still end up having to restart 2-3x a week. My AP is in an environment with very little other activity (no other Wifi, bluetooth, microwave, etc.) which, as I understand it, lends itself to the overshooting problem that causes the stuck beacon resets.  You have less likelihood of going from a very low noise floor to a high one and interpolating to an out of range value if you're in an environment with one or more other radios within range.  When my neighbor turns on their wifi printer (acts as an AP in ad-hoc mode) it normally causes my wifi to go down.  Sometimes Wii controllers (bluetooth) will cause it to go down too. I've never successfully logged it happening.  As soon as it happens hostapd goes into an infinite loop trying to reset the HW and floods the log.  By the time I'm able to either kill hostapd or restart it has filled and rolled over my system log.  I have noticed (as I mention above) that it can/will successfully reset sometimes though. If I understood BSD better (I'm of a Linux background) then I might try to fix the code that causes this.

I have seen desktop NICs that can do this but not all of them.  So I think it comes down to hardware support then drivers that can use it.

I figured out the wireless problem.  It turns out that the automatic channel feature is not working.  I was getting tons of stuck beacons and it would eventually stop working.  The solution was to look at the channels used and force a channel (in this case channel 3 was open).  802.11b was working fine because it wasn't being used by my neighbors. Thanks everyone for the help.  My general setup is working.  Now I'm working on setting up packages and firewall rules, NAT, etc.

ok, my mistake everything fine after squid -z and reboot disk usage 0% thanks

Hi Steve, Strange that it doesn't work. It's currently the only rule I have under the wireless interface. Cheers

it just ran after installing to hard drive.

@cmb: @dannjr: Actually I think theres a issue between the FreeBSD 4.4 on the 2Wire and the FreeBSD 8 No, has nothing whatsoever to do with what you're running, it blocks the replies necessary for traceroute to function on the public IPs, and does so for everyone regardless of OS. The reason the last hop works is because it actually replies, it doesn't send back the TTL expired message that the 2wire drops, which is what traceroute times on intermediate hops. All you're doing by dropping the TTL to 1 is ensuring the traceroute never traverses the modem. The modem's internal IP responds with TTL expired, it's just when something upstream of it responds, it blocks it. You'll see it in your firewall log on the modem. Reverse DNS lookups have no relation to traceroute. Thanks for that answer.. I looked in the 2wire logs before but didn't notice it right away cause it only writes one small line about it.. As for setting TTL to 1 in the long run that will work out with our resident goof here so we're not waisting additional time.. It's just gonna advirt a ping TTL of 254 and that could be insain since 90% of all ATT is about a TTL of 116 New meaning.. I think its time for me to see IF I CAN do a work around with TOS We use to lie in Windows for the TOS to 92 which bypassed some of the ISP info with TOS 254 and some other settings would be would be proper.. Best explanation for TOS I can think of is here http://www.dslnuts.com/discussion/index.php/topic,1878.msg9712.html#msg9712 Anything is possible till they catch it.. and that depends on if it can work.. In any event If nothing else no matter how many routes we setup with the2wire in front it can't respond to the Traceroute because someone at AT&T thinks its a security risk.. There's allot of things I like about the 2wire when they left it be.. But now I guess they want to make sure QoS for the TV and the phones don't get put in the same layer.. I tested that with our Satilite dich(directv) and did a speedtest while using the DVR to download and it cut the download speed by 5Mb.. Since directv has its own way of doing things.. Even though I set it up to have a static IP for the 2wire it was also getting an assigned IP (DHCP) from the 2wire as well.. I decided to put the Directv behind the pfSense and its still working well without the second IP.. Latency threw the 2wire threw the Pfsense has an average 18ms So I cant complain about the speed.. I'm also using STATIC IP's threw the 2wire not what some people think are sticky IPs.. It was just getting the MAC tables to take.. Which I've cleared out of the 2wire several times and they're listed re-immediately So other then this trace issue all is well.. All that's really left is to get a hold of ATT to set our rDNS records which is a pain and dont even mention that to Teir 1 they'll ask what email client your using. You have to ask for the Static IP dept after several transfers you might get through SO after all this we need to get a few thousand people together and bust ATT on trace routes….. cmb Thank you for that Quick reply and info… I can't say what I'm thinking about the AT&T engineers right now!

Some browsers can be pretty bad about caching those things. The initial error indicated your /tmp slice was full. If it was on NanoBSD that's not terribly hard to do since it's a RAM disk.

Quite a stupid mistake!  But indeed, it's working now! Thanks a lot!

@Wasca: I've got my problem sorted but it was a little strange. I was connecting to the SIP server (Switchvox server) via an OPENVPN tunnel. The tunnel was using UDP. I changed it to a TCP tunnel and now I can make inbound and out bound calls over the tunnel. After doing some packet capture it looked like my UDP SIP/SDP Invite packets being sent by my SIP phone was getting dropped some where so they were never hitting back at the Switchvox PBX while the tunnel was using UDP. As soon as I switched the tunnel to TCP all was good. I vaguely remember reading something about SIP and UDP in PFsense being a problem, can anyone enlighten me? No such problems. Sometimes you have to change NAT settings depending on your provider and your specific circumstances but that's not relevant in this scenario. The only way changing it from TCP to UDP would make any difference is if the tunnel wasn't functional at all over UDP (something blocking it somewhere most commonly why) and worked with TCP.

Do you have a big problem with arp spoofing then? What sort of network are you using this in? @http://en.wikipedia.org/wiki/Network_switch#Configuration_options: Managed switches — These switches have one or more methods to modify the operation of the switch You can connect to the switch configure it for your network. Typically you might use VLANs or QoS options. Some such switched have: MAC filtering and other types of "port security" features which prevent MAC flooding In order to prevent an arp spoofing attack you need to stop a malicious client machine sending out arp packets announcing that the gateway IP has changed MAC address. Or at least prevent those packets reaching your other clients. The only way to do this is at layer 2, typically the switch. You set the switch to filter and arp announcements for the gateway IP other than the correct MAC which you have set. I'm still not sure what you mean by MAC Vulnerability. Do you have a link to the Mikrotik forum explaining it? It sounds like possibly you are referring to a paid access captive portal arrangement. Clients spoof their MAC address in order to get access that someone alse has paid for. Is that it? Steve

@cmb: that's never been permitted. can either very carefully manually edit the config with viconfig and make sure you don't orphan any references, or backup the config and do the same edit and restore it. Hi cmb, thanks for feedback. I found out that if I rename the interface under INTERFACES from eg. OPT2 to WAN3 then the gateway in ROUTING is called WAN3. This is working if the interface is in DHCP or Static mode. When it is in PPPoE the name is "OPT2_GW".

Since it's not in production yet, I just boot it when I'm tinkering with it, then shut it back down.  However, this error seems to have gone away since I fixed my fstab entries the other night (pfSense was originally booting off /dev/d1s1a because it was installed from USB stick, but after removing the stick, it moved to /dev/d0s1a because of the way my BIOS handles USB devices as hard drives).  Not sure if that was the underlying cause, or just coincidental.  Now OpenNTP goes through its thing in like 5-10 seconds. Also, at one point I had the box running with a USB NIC too, but switched over to the onboard and had left the configuration the same between the two.  I finally unplugged the USB NIC the night I did the fstab thing, until I'm ready to use it again… so I'm wondering if maybe OpenNTP was trying to route over the (not-connected) USB NIC. Anyways, it seems to be behaving for the time being :P

@cmb: get a packet capture of the ICMP that apinger generates and check the timestamps. I've never seen it be anything other than accurate. OK today we had a power outage and the both pfSense servers were restarted, and now it shows the right latency. I didn't change anything. That was weird, a windows-like solution :D

@podilarius: I am not sure why Endian would work and pfSense not. Have you left advanced setting alone and tried just standard MTUs? If you have installed any packages, remove them and restart. You want to get to where it is working and then make one change at a time so that you will know what is causing the problem. Actually I have tried no MTU settings, MTU settings on the LAN / WAN and I have installed no packages.  I am a firm believer in starting from scratch but out of the box in my scenario doesn't work.

That means the system clock went backwards for some reason. Isn't related to anything other than generating RRD data. System clock should sync via NTP periodically and that should get the data being collected properly again, though the system clock in some systems will drift significantly which may not be easy to work around (BIOS update or disabling ACPI in BIOS most commonly fix significant time drift if that's the case). Generally the quality RRD graph is the best place to look for connectivity problems in the past, but depending on when your system clock went nuts,you may not have that data.