PFSense 1.2.3 Install to Hard Drive Isn't Playing Nice. (Bugs¿)



  • I have been trying to edit the config file through VIM on a test deployment server of PFSense 1.2.3 which is so far working well, Except for our WAN Interface.

    <wan><if>em0</if>
    <mtu><ipaddr>206.75.246.68</ipaddr>
    <subnet>29</subnet>
    <gateway>206.75.246.65</gateway>
    <blockpriv>on</blockpriv>
    <blockbogons>on</blockbogons>
    <disableftpproxy><dhcphostname><media>100baseTX</media>
    <mediaopt>full-duplex</mediaopt>
    <bandwidth>100</bandwidth>
    <bandwidthtype>Mb</bandwidthtype>
    <spoofmac>That is what I have edited the config file to and reloaded it, And it reboots and shows Interface as Full Duplex but then the internet doesnt work, IE Everything pretty much times out, but oddly enough I can ping hosts just fine. (For example, Google.)

    I am wondering if there is a better way to do this - But I am contemplating modifying the cisco counters to be auto negotiate to avoid having to adjust anything….

    WAN interface (em0)  
    Status up  
    MAC address 00:30:48:23:95:0d  
    IP address 206.75.246.68    
    Subnet mask 255.255.255.248  
    Gateway 206.75.246.65  
    ISP DNS servers 10.8.20.30
    10.8.20.80

    Media 100baseTX <half-duplex> 
    In/out packets 30394/22350 (26.34 MB/17.74 MB)  
    In/out errors 0/3178  
    Collisions 4140

    (That's after a fresh reboot, but the collisions add up fast!)

    Can anyone offer a solution to the full duplex problem? It doesn't seem to be taking properly in this new version, although it goes to full, the errors and collisions stop but no net connectivity (At least not an explainable net connectivity.)</half-duplex></spoofmac></dhcphostname></disableftpproxy></mtu></wan>



  • Oddly enough, I troubleshooted this issue further and came to the conclusion that it was not because of a duplex setting mismatch or an incorrect configuration on my part.

    For whatever reason, I may have uncovered a bug, After running PFSense 1.2.3 as a LiveCD and setting up the unit properly, I am able to get 30MB Traffic, But, upon installing it to the hard drive, all network traffic ceases to be, as in, Dropped packets, dropped connections galore. Can ping but no data comes through…

    This only happens after I select SMP Multiprocessor Kernel after a LiveCD setup and -> Subsequent Installation.

    Can someone help verify this problem, Does anyone have a True Dual Processor computer, what we used was a Dual Xeon (Pentium 4 Era) with 2GB ECC DDR Ram



  • I'm running the live cd right now, it's working fine! Shrugs This is really weird! (I've duplicated problem through two installations on two platforms now.) My next attempt is to see if these machines work properly selecting the Uniprocessor Kernel as the 'To Hard-Drive' Installation method VIA livecd.


  • Rebel Alliance Developer Netgate

    You might try to disable Hardware Checksum Offloading (under Advanced), but it sounds like your hardware may not be too happy with the SMP kernel.

    Do you have Hyperthreading enabled in your BIOS? Can you try to turn it off?



  • I just checked BIOS. These Supermicro Motherboards have so much control, so many options.

    The Hyperthreading was turned off, But the option "Fast String Operations" was enabled. Not sure what it means, No web description other than the fact "It Enables Fast String Operations!"

    Every other setting seems okay. To further this error message, when specifying the new PFSense Gateway (1.2.3) after a live CD install, even sometimes the live installs aren't working. It seems to be a problematic situation.

    Is there any other form of Deployment than the Live CD? Can you for example, Install to disk without a livecd config… Has anyone had these problems before?

    It's really weird, it will allow you to Ping to IP or DNS Names but no Traffic goes through the WAN, Besides that, Like you can't goto a webpage, It will time out, Or sometimes partially load. I can receive emails but Port 80 Traffic keeps getting blocked... Or disregarded.



  • Tell me if I am going crazy:

    In the Supermicro Advanced BIOS Area there was a PCI/PCIX Configuration Area.

    Each specific Setting was as follows:

    PCI - Was set to forced 133MHZ

    PCIX - Was set to forced 133MHZ

    There were various settings but I changed them both to AUTO insted, And when it booted I noticed the PCI Speed in the Flash Summary Screen was 33mhz and PCIX speed was 66mhz.

    If some prior IT Staff set this to 133MHZ, Could this have been the problem? If it were, Why isn't the hardware Dead by now? I know the chipsets can support 133mhz PCI but maybe the network cards integrated cannot?

    I'm trying a new install now to see if this was the issue, Tell me your thoughts though! I personally believe this could have been the problem from the get go.



  • @Cide:

    If some prior IT Staff set this to 133MHZ, Could this have been the problem? If it were, Why isn't the hardware Dead by now? I know the chipsets can support 133mhz PCI but maybe the network cards integrated cannot?

    Trying to make a PCI device work way above its rated speed won't necessarily kill it - it may just have trouble keeping up and consequently do "unexpected stuff".

    Standard PCI bus has a bus clock speed of 33MHz. Attempting to run it at 133MHz is highly likely to cause a variety of problems, depending on the devices plugged into the bus. If I recall correctly, PCI-X is rated for 133MHz operation for a significantly reduced number of devices, maybe only one. And thats only if the device itself is 133MHz capable.

    I don't know the history of the system. Maybe you added some network cards. This would be sufficient to require the relevant buses to slow down. The BIOS settings apparently wouldn't allow that.



  • Okay, So Instead of Booting to LIVECD, I initiated a Manual install of 1.2.3 Release from the start (Press "I")

    I was able to install PFSense as I have been, and upon initial startup and configuration, any computers attached to the new Gateway are able to gain Outbound internet access for about a few minutes before PFSense reverts to not giving outbound internet. Inbound LAN Still works but nothing as far as WAN seems to work, this time, and as before PING Functions strangely, You are able to ping sometimes, other times not, SMTP Mail works, etc. But no "Real Internet"

    After a quick reboot of the server, The internet again works for all speakable purposes, and the Upstream bandwidth sits nicely at 30MBit, But, After a few minutes PFSense stops working and something happens to WAN Traffic, I don't know what is happening and I am baffled as to why there isn't much written about this, How could I be the only one experiancing this right now! It seems PFSense is autolearning some network parimeters or something, and afterwards stops functioning, As far as Troubleshooting, It says some stuff in the filter log about Rule 55 Being Blocked with a [bad hdr length 0 - too short <20)

    This is a new install with no additional rules setup or changed, no packages up that would shape the traffic or anything I can think of.
    I am desperate for some help, This is bugging me, Could it just be an incompatibility with this type of server hardware?



  • It keeps dropping out as I've said above, But I just disabled Hardware Checksum Offloading.

    It came back from its "Locked up State" of Dropout, but we'll see if it persists as working.

    In the Advanced Config Area it has an Option for NIC Polling, But says to refer to a list on PFSense homepage, I cannot find that list, Can anyone help me out? I'd like to know if my Eternet Cards support it, They Are Intel Desktop Pro 100 and 1000.
    Is there any benefit to this for a 30MB Load or is it specifically for high load situation?



  • If I recall correctly, there is a known FreeBSD bug in the Intel 100Mbps ethernet driver where the driver incorrectly concludes that at least one member of the family is capable of hardware checksumming. Its possible you have the device for which the driver makes that incorrect conclusion.

    Polling can get you much increased throughput in situations of high interrupt load from the NICs (e.g. high traffic rates with short packets). So, if your CPU is very busy AND you have high interrupt rates from the NICs then it would probably be worth turning on polling to see if it helps.



  • Regardless of hardware checksumming on or off, It seems the dropout connectivity has reared is ugly head with Hardware Checksum Offloading disabled, after it was working for me for awhile. All I did was change the WAN interface link from 100 Half Duplex to 100 Full Duplex… Shrugs

    I am beginning to feel that this box is not cooperating or compatible with FreeBSD In the sense that we need it to be, I am thinking of giving up and trying other hardware, any last thoughts? I really apprecaiate the help so far but I don't think I can single this issue out so well if it keeps happening without any explanation of origin


Log in to reply