Looks like the is_macaddr() function we use to validate was changed a while back and started considering a mac valid if it didn't have :'s between each part. I'm committing a fix, it should be back to rejecting invalid MACs when it gets picked up in snapshots.

thanx so i wait for an update of this pkg

i waited more than 20mins. I know wan needs some time. But no boot. It stalls at the same message all time. I'll test with newer iso.

I did try the second slice after I failed to boot the first time.  I would not be surprised since I had a bad CF card from Hacom before and they sent me out the same kind. What lines give it away that it's the CF card?

Brilliant. Thanks.

Thats correct - just reinstall the package. There was also a double syncing of the package happening caused by an extra dependancy which was not needed.

confirmed: On an old P4 it was quite ok with webgiu, but net-performance was great with an 100MB/10MB bandwith. Only slowdown came from the PCI-only netcards (one 3com 100MB, one dlink 1GB). Now with an Atom D525 and 2 intel PCIe netcards netflow is somewhat better compared to before, but webgui is extraordinary! With alix webgui is sometimes as slow as a sleeping rabbit, netflow is great. I have about 50 to 70 MB downloadrate with squid and squidguard enabled.

Not all CF cards are created equal. Disappointingly, not even all 2GB CF cards from the same range from the same manufacturer are created equal!  ::) However I just use the 1GB image and that always fits.  ;D Steve

Hmmm…I am sitting in front of this machine where syslog is installed and I have connection to the pfsense. Could it be possible, that pfsense wants to send syslog traffic to the syslog server, but pfsense isn't fully booted up ? So that the syslog wants to send traffic before the connection to the syslog server is established !? But why is it just happening on my second pfsense and not on the first. Strange....perhaps this will be solved, if do do a complete new installation. Thanks

this is the log I unplugged the cable and waited for about 15 seconds the connection did come back this time but I will insert the log anyway Mar 2 16:30:08 apinger: Starting Alarm Pinger, apinger(31624) Mar 2 16:30:08 check_reload_status: reloading filter Mar 2 16:30:06 apinger: Exiting on signal 15. Mar 2 16:30:06 check_reload_status: reloading filter Mar 2 16:30:06 php: : ROUTING: change default route to 192.168.20.1 Mar 2 16:30:06 dnsmasq[57845]: using nameserver 203.144.207.49#53 Mar 2 16:30:06 dnsmasq[57845]: using nameserver 203.144.207.29#53 Mar 2 16:30:06 dnsmasq[57845]: reading /etc/resolv.conf Mar 2 16:30:05 apinger: alarm canceled: GW_WAN(192.168.20.1) *** down *** Mar 2 16:30:04 php: : rc.newwanip: on (IP address: 192.168.20.106) (interface: wan) (real interface: ste0). Mar 2 16:30:04 php: : rc.newwanip: Informational is starting ste0. Mar 2 16:30:04 dhclient[16079]: bound to 192.168.20.106 – renewal in 43200 seconds. Mar 2 16:30:04 check_reload_status: rc.newwanip starting ste0 Mar 2 16:30:04 dhclient: Creating resolv.conf Mar 2 16:30:04 dhclient: /sbin/route add default 192.168.20.1 Mar 2 16:30:04 dhclient: Adding new routes to interface: ste0 Mar 2 16:30:04 dhclient: New Routers (ste0): 192.168.20.1 Mar 2 16:30:04 dhclient: New Broadcast Address (ste0): 192.168.20.255 Mar 2 16:30:04 dhclient: New Subnet Mask (ste0): 255.255.255.0 Mar 2 16:30:04 dhclient: New IP Address (ste0): 192.168.20.106 Mar 2 16:30:04 dhclient: ifconfig ste0 inet 192.168.20.106 netmask 255.255.255.0 broadcast 192.168.20.255 Mar 2 16:30:04 dhclient: Starting add_new_address() Mar 2 16:30:04 dhclient: REBOOT Mar 2 16:30:04 dhclient[16079]: DHCPACK from 192.168.20.1 Mar 2 16:30:04 dhclient[16079]: DHCPREQUEST on ste0 to 255.255.255.255 port 67 Mar 2 16:30:03 dhclient: PREINIT Mar 2 16:30:02 php: : HOTPLUG: Configuring interface wan Mar 2 16:30:02 php: : DEVD Ethernet attached event for wan Mar 2 16:30:02 check_reload_status: Linkup starting ste0 Mar 2 16:30:02 kernel: ste0: link state changed to UP Mar 2 16:29:45 kernel: arpresolve: can't allocate llinfo for 192.168.20.1 Mar 2 16:29:45 php: : Could not find gateway for interface(wan). Mar 2 16:29:45 php: : ERROR! PPTP enabled but could not resolve the $pptpdtarget Mar 2 16:29:44 kernel: arpresolve: can't allocate llinfo for 192.168.20.1 Mar 2 16:29:44 kernel: arpresolve: can't allocate llinfo for 192.168.20.1 Mar 2 16:29:43 check_reload_status: reloading filter Mar 2 16:29:42 kernel: arpresolve: can't allocate llinfo for 192.168.20.1 Mar 2 16:29:41 kernel: arpresolve: can't allocate llinfo for 192.168.20.1 Mar 2 16:29:40 kernel: arpresolve: can't allocate llinfo for 192.168.20.1 Mar 2 16:29:38 kernel: arpresolve: can't allocate llinfo for 192.168.20.1 Mar 2 16:29:38 kernel: arpresolve: can't allocate llinfo for 192.168.20.1 Mar 2 16:29:37 kernel: arpresolve: can't allocate llinfo for 192.168.20.1 Mar 2 16:29:37 kernel: arpresolve: can't allocate llinfo for 192.168.20.1 Mar 2 16:29:37 kernel: arpresolve: can't allocate llinfo for 192.168.20.1 Mar 2 16:29:36 kernel: arpresolve: can't allocate llinfo for 192.168.20.1 Mar 2 16:29:36 kernel: arpresolve: can't allocate llinfo for 192.168.20.1 Mar 2 16:29:36 kernel: arpresolve: can't allocate llinfo for 192.168.20.1 Mar 2 16:29:35 kernel: arpresolve: can't allocate llinfo for 192.168.20.1 Mar 2 16:29:34 kernel: arpresolve: can't allocate llinfo for 192.168.20.1 Mar 2 16:29:34 kernel: arpresolve: can't allocate llinfo for 192.168.20.1 Mar 2 16:29:33 apinger: ALARM: GW_WAN(192.168.20.1) *** down *** Mar 2 16:29:25 dhclient[12176]: exiting. Mar 2 16:29:25 dhclient[12176]: exiting. Mar 2 16:29:25 dhclient[12176]: connection closed Mar 2 16:29:25 dhclient[12176]: connection closed Mar 2 16:29:25 php: : DEVD Ethernet detached event for wan Mar 2 16:29:24 kernel: ste0: link state changed to DOWN Mar 2 16:29:24 check_reload_status: Linkup starting ste0 I will try later tonight when no real users are on the link and wait for 30 min before reconnecting

It would be cool to have a new icon on the Floating Rules Tab that shows that the rule is set to Queue instead of the green arrow that makes it appear that the rule is set to PASS.  Block and Reject are the same icon but different color, maybe the Pass and Queue can be the same icon but different color as well.  I'll put my vote in for black enabled and grey for disabled.  ;D

@wallabybob: wildgoose: are you running off a solid state drive (e.g. a flash card or ssd)? I just wanted to mention here that we had 2 routers running a recent build of BETA5 working flawless for a couple of weeks.  I have switched from a normal platter-based 2.5" hard drive to a Transend 2.5" solid state 8gb IDE drive (SLC) and have installed RC1 fresh onto both of them.  Both of them are now exhibiting this behavior.  I do believe this problem could be linked to SSDs.  Anything I can do to help/fix?  Start a new thread and not hijack this one? ;)

Yes, CARP VIP for FTP and also on VMWare for testing 2.0. john @cmb: should only see that if multicast traffic is getting looped back to you. Are you using CARP IPs? Are you running in VMware by chance?

I pushed some fixes that you can get from next snapshot.

@jimp: Is your GUI running HTTP or HTTPS? That's usually what makes IE break. HTTPS using 8080.

It seems the new version of the OpenVPN client config defaulted to enable Compression where none was configured before. Unchecking that brought the VPN up immediately.

Yes, that is the only post I saw. But nothing on how to get to identify it during install. Anyways, RC1 latest Feb 28th version identifies the Realtek RTL8111E chip perfectly. I could get just the single NIC to work by creating 2 simple VLANs. VLAN 10 for WAN and VLAN 20 for LAN. I have  Netgear GS108T managed switch where I created similar VLAN to separate the data packets. Its working ok for now. Till I get my second NIC delivered I will keep this setup and get to understand pfSense.