Attention Firebox X Series Users - Testing Needed
-
I am planning to install debian on my x500 and use it as a "LAMP" server.
How was the net install conducted? Did you manage to get a keyboard to work as I'm having no luck following diagrams on another topic.
Cheers,
Andy
-
Wondering if there's any progress/updates here? I've got two different Firebox x700s that both display the watchdog timeouts on re0 (my LAN port). I was originally running 1.2.3 RC2 and upgraded to the latest firmware in the 1.2.X snapshots.
loki - care to elaborate on how you prepped your firebox for a netboot install of debian?
-
loki - care to elaborate on how you prepped your firebox for a netboot install of debian?
install a base debian from a net install cd on a normal pc. edited /etc/fstab and set the serial port for console access, pop the drive back into the firebox.
Overall wasnt very happy with the older firebox hardware, the network cards just dont seem to have great support with bsd.
I am now running the following jetway with 2g of mem and 1.2.3rc2, pretty happy with it.
xxxx://www.newegg.com/Product/Product.aspx?Item=N82E16856107059
-
I know it's been a while, but is there any progress on this? ???
-
I've been getting the same errors as everyone in this thread, using two fireboxes, an x500 as transparent firewall and an x700 as router/firewall. Like Spy Alelo, I'm also curious to see if there has been any progress on this and if there is perhaps something new that we can test/patch.
-
Call me crazy, but I removed the crypto card to test a mini PCI WiFi card, and have not had a single timeout while messing with the GUI. I removed the WiFi card anyway, since it wasnt supported, and still no timeouts. I have not upgraded the firmware, still using 1.2.3 release nor changed any settings.
Again, it may have been a fluke, but I will keep testing. The only thing that may make any sense, is that the crypto card was in some way being used for SSL on the WebGUI (for which I do have SSL enabled), and there may be some compatibility issue between it and the Realtek interfaces. I mean, seriously, I download over 60GB of data a month using torrents, not a single issue. Also use a VoIP phone non-stop sustaining a VPN connection while using a web based ticketing system 5 days a week, 8 hours a day and never get a single drop or a timeout. It only happens when I access the WebGUI within the first two minutes. And not a single timeout after removing the card? Can anyone else experiment and confirm this?
-
@Spy Alelo, did you ever find out if it indeed was the crypto card that was causing the timeouts?
@Spy:
Call me crazy, but I removed the crypto card to test a mini PCI WiFi card, and have not had a single timeout while messing with the GUI. I removed the WiFi card anyway, since it wasnt supported, and still no timeouts. I have not upgraded the firmware, still using 1.2.3 release nor changed any settings.
Again, it may have been a fluke, but I will keep testing. The only thing that may make any sense, is that the crypto card was in some way being used for SSL on the WebGUI (for which I do have SSL enabled), and there may be some compatibility issue between it and the Realtek interfaces. I mean, seriously, I download over 60GB of data a month using torrents, not a single issue. Also use a VoIP phone non-stop sustaining a VPN connection while using a web based ticketing system 5 days a week, 8 hours a day and never get a single drop or a timeout. It only happens when I access the WebGUI within the first two minutes. And not a single timeout after removing the card? Can anyone else experiment and confirm this?
-
It did timeout, eventually. I found an easy way to make it timeout, and that is to just download some MP3s from my local webserver using its external DNS name over HTTP. That only happens locally, since from the internet, that issue is not present.
It just doesnt make sense, if you ask me.
-
I'm still having the same issue on my x500, although its not as bad as it used to be, but who knows. Its easy to reproduce, just have any traffic going through it and start hitting the web interface, usually listing the states will do it. I know it was worse when HTTPS was enabled. I've tried checking off disable hardware checksum, I've run the ifconfig re0 -tso, I've played with the ACPI settings in the device.hints but to no avail. I'm on 1.2.3-release now. One option I've seen is to disable ACPI in the BIOS but that involves the weird connector and finding a pci video card (man I threw a way a whole box of those a while back) so I havent done it.
It hasn't ever done it on its own, it only happens for me when I hit the web interface, so maybe its not such a problem, but it is annoying when you are trying to debug something and the whole thing locks out. Has anyone made any progress on this? ???
-
I am still having the same issue with 2.x. The horrible timeouts are with the 2.x versions of pfSense, for which we are turning TSO off and has a major improvement after that, but the timeouts will still be there with some major hits on the webgui just like in 1.2.3-release.
I don't know if this will ever be fixed, since a lot of the BSD developers think of Realtek NICs as crap and refuse to do anything about it, they just recommend to use Intel or something else. Which we obviously can't do.
-
Anyone else tried this?
I have two X500's as firewalls/VPN gateways and was having the timeout problem (one was worse than the other – different HW revisions?)
None of the options on System > Advanced > Networking did anything for me, but setting TCP Offload Engine (not the BCE one) in Systems > Advanced > Tunables to 0 (disabled) has allowed them both to run without issue for over a month now. Even the cat /dev/random over SSH doesn't make it hiccup.The snapshot I'm running is almost a month old now, but if the current builds still do this out of the box, it may be worth a shot.
-
Hi,
Any news on this topic?
-
Delerius, watchdog timeouts are pretty much a thing of the past in 2.0, when having set the correct tunables.
-
Delerius, watchdog timeouts are pretty much a thing of the past in 2.0, when having set the correct tunables.
I'm running pfsense 2.0 RC1
Also I have disabled net.inet.tcp.tso in tunables.
I still get watchdog timeouts when I'm connected as a client to the firebox configured as OpenVPN-server. -
I'm running pfsense 2.0 RC1
Also I have disabled net.inet.tcp.tso in tunables.
I still get watchdog timeouts when I'm connected as a client to the firebox configured as OpenVPN-server.That is likely related to what your MTU is set to. The Realtek nics are quite sensitive to incorrect mtu sizes.
What the correct mtu settings might be, is unfortunately something that you'll have to find out by trial and error. -
I'm running pfsense 2.0 RC1
Also I have disabled net.inet.tcp.tso in tunables.
I still get watchdog timeouts when I'm connected as a client to the firebox configured as OpenVPN-server.That is likely related to what your MTU is set to. The Realtek nics are quite sensitive to incorrect mtu sizes.
What the correct mtu settings might be, is unfortunately something that you'll have to find out by trial and error.I've read about other MTU-sizes than default 1500 can cause watchdog timeouts on the realtek nics.
I can see in the log from the OpenVPN-client that it sets different MTU-sizes for the tunnel/link.
I've tried to set it manually with link-mtu and tun-mtu in the client-config, but I don't seem to get it working.
Also is there a way to set the MTU-size in pfsense for a OpenVPN-connection/tunnel?
My knowledge on this is not good, so any help would be appreciated. -
This is what I can see when running windows OpenVPN client with default settings:
Fri Mar 11 16:07:57 2011 Control Channel MTU parms [ L:1560 D:140 EF:40 EB:0 ET:0 EL:0 ]
Fri Mar 11 16:07:57 2011 Data Channel MTU parms [ L:1560 D:1450 EF:60 EB:135 ET:0 EL:0 AF:3/1 ]I have tried to set link-mtu to 1500 or tun-mtu to 1500
-
Am I the only one with this problem? I figure I must replace my firebox with something else until this is resolved.
-
You might have better luck with lower-than-1500 mtu settings.
