Allright, I've done some more troubleshooting yesterday, and I decided to let the NIC issue rest, since the I211 (igb0) seems to have a proper connection and the I219 is working fine on the LAN side. I'm guessing the I219 simply can't be used for the WAN side or something. I'm still not getting an WAN IP address though. The dhclient keeps sending DHCPDISCOVER's and it eventually ends with a FAIL. I've done a packet inspection on the DHCP port and the options it has are slightly different than what my DrayTek sends when I put it on the LAN side of the pfSense box. I've correctly spoofed its MAC which I know is locked at the ISP side, so that shouldn't be the problem. I've tried to mimic all the other option fields to make the DHCP request identical to what the DrayTek sends, but I'm having trouble with the hostname option field. DrayTek sends this: 19:38:22.863598 XX:XX:XX:XX:XX:XX > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 590: (tos 0x0, ttl 127, id 0, offset 0, flags [none], proto UDP (17), length 576)     0.0.0.0.68 > 255.255.255.255.67: [udp sum ok] BOOTP/DHCP, Request from XX:XX:XX:XX:XX:XX, length 548, xid 0x7b501da0, Flags [none] (0x0000)   Client-Ethernet-Address XX:XX:XX:XX:XX:XX   Vendor-rfc1048 Extensions     Magic Cookie 0x63825363     DHCP-Message Option 53, length 1: Discover     Client-ID Option 61, length 7: ether XX:XX:XX:XX:XX:XX     Requested-IP Option 50, length 4: XXX.XXX.XXX.XXX     MSZ Option 57, length 2: 576     Vendor-Class Option 60, length 9: "Vigor2925"     Parameter-Request Option 55, length 5:       Subnet-Mask, Default-Gateway, Domain-Name-Server, Domain-Name       Option 212 And pfSense sends this: 19:41:30.692195 XX:XX:XX:XX:XX:XX > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 342: (tos 0x10, ttl 128, id 0, offset 0, flags [none], proto UDP (17), length 328)     0.0.0.0.68 > 255.255.255.255.67: [udp sum ok] BOOTP/DHCP, Request from XX:XX:XX:XX:XX:XX, length 300, xid 0x236406cf, Flags [none] (0x0000)   Client-Ethernet-Address XX:XX:XX:XX:XX:XX   Vendor-rfc1048 Extensions     Magic Cookie 0x63825363     DHCP-Message Option 53, length 1: Discover     Client-ID Option 61, length 7: ether XX:XX:XX:XX:XX:XX     Hostname Option 12, length 7: "pfSense"     Parameter-Request Option 55, length 9:       Subnet-Mask, BR, Time-Zone, Classless-Static-Route       Default-Gateway, Domain-Name, Domain-Name-Server, Hostname       Option 119 My DrayTek doesn't send a hostname (Option 12) whereas the pfSense box sends Hostname Option 12, length 7: "pfSense". Could this be it? If so, is there a way to remove the hostname option from the dhclient's requests, without affecting the general hostname setting of the pfSense box?

Should I remove this topic as it seems to be resolved?

You mean like System - General - Localization - Timezone?

@enphor: Welp, I just installed 2.3.3 fresh overwriting the old system and restored the backup .xml. Worked like a charm! Bravo for the backup/restore routine. I have been able to upgrade my Fireboxes without any issues. And any new ones I have built with 2.3.2 I have been able to upgrade to 2.3.3 without any issues.

Yep the Broken BIOS would make sense, but means the Motherboard is stuffed! After alll it was working fine for 9months, and then not. Ver 2.4 you say, I don't see an I386 version. Bit of a bummer. Does anyone know how to search for the \ fault as in backslash, or if it has been mentioned before. I have searched but can't find anything directly? Or is this the same as below with "Forward slash /" ? As in the PC did and now does again Freezes as soon after it continues after the F1 screen. DOC - If everything is configured correctly the kernel will begin to load. For serial console images, systems with VGA output will stop displaying with a "/" on the screen or may stop at a "BTX" message. From that point on all output is sent to COM1 Q2. How do I install pfsense to a HDD then install that HDD into the machine I wish to use pfsense on? As described in the DOCS –https://doc.pfsense.org/index.php/Installation_Troubleshooting#Boot_from_Memstick_or_CD_Fails Thanks

Se Redmine https://redmine.pfsense.org/issues/7343 for progress about this.

I think it could be memory issue, it just fails with power saving modes  and it can be stable under load, when full voltage applied. To check this you need to install memtester package. For 2.4  version it would be: fetch http://pkg.freebsd.org/freebsd:11:x86:64/latest/All/memtester-4.3.0.txz pkg install memtester-4.3.0.txz to run, use memtester (size to test in MB) (loops) memtester 512 10 Memtester for other FreeBSD version can be found here — http://portsmon.freebsd.org/portoverview.py?category=sysutils&portname=memtest For examle 2.3 pfSense based on freebsd 10 needs this package http://pkg.freebsd.org/freebsd:10:x86:64/latest/All/memtester-4.3.0.txz If pfSense also would not hang, then it definitely memory powersavings incompatibility issue.

Seems most people in this thread is refering to the monitoring rather than the traffic graph. My traffic graph is working, but the monitoring section is dead. All metrics show as 0 On snmp it reports 0 on all but memory (mempool).

Hmmm, yeh. It looks like the next time anything does "check for updates" that it overwrites here. Anyone got a better idea?

AWS 1:1 NATs the elastic IP to your interface address.

! interface FastEthernet0/35 switchport access vlan 105 switchport trunk encapsulation dot1q end As has been said, get rid of the trunk config on your edge device (access, untagged) ports. There is zero reason for that to be there.

I use Notepad++.  Thanks guys.

@pmass: even if one pray while rebooting ?  :) Perhaps if you pray for butterflies… :)

Just since this comes up fairly high in the relevant searches on this subject, and never got a resolution: cmb is correct in that you have only to change the track and run the update. When you check for updates it will still show an experimental release number as an available update. Run this update and then reboot. Once it comes back, it will show an update available that will be the release version. This was my experience going from a 2.3.3 pre-release anyway.

well that was simple it worked Thanks

I don't know what the issue was…but I backed up my config.xml, rolled back my VM to a snapshot from a few weeks ago, restored the config.xml, and am able to run the update(s) now.

Well, the only "solution" is to kill as many services as possible (and that includes ntpd, nginx etc.)