Attention Firebox X Series Users - Testing Needed

DimitriRodis

Not yet– Pyun has a couple of paid projects so the progress on this issue is at a bit of a standstill.

I will preface that what I am about to say may be completely rediculous, but my understanding is that the WatchGuard OS is based on Linux. If that's true, then perhaps someone can look at the Linux driver and compare it to the BSD one? Obviously they are structured differently and this may not make sense, but when the WatchGuard box is running the WatchGuard software, the firebox is a very stable unit, so someone knows how to make these realtek chips work!

loki

Not yet – Pyun has a couple of paid projects so the progress on this issue is at a bit of a standstill.

ok thanks for the update.

then perhaps someone can look at the Linux driver and compare it to the BSD one?

I will try a debian install on the X500 some time this weekend.

Think the linux driver might have the same issue with the realtek drivers, its hard to find of the issue was ever fix or people just started using other network cards.
google around for:
"8139c problem oversized ethernet frame"
"realtec 8139c Abnormal interrupt"

http://www.joshua.raleigh.nc.us/docs/linux-2.4.10_html/286454.html
http://article.gmane.org/gmane.linux.drivers.realtek.devel/420

The X500 does have a pci slot, gonna try using a old sun pci quad port 10/100 network card which works in another pc running 1.2.3.rc2 version of pfsense. At least this should prove the X500 motherboard doesnt have issues controlling acpi/dma/interrupts of network cards.

Here is a pic of the sun card
http://www.sun.com/products/networking/ethernet/sunquadfastethernet/images/I1_hw_quadfastether_pci_i.jpg

loki

Debian net install works on the X500, now just need to find a way to overlay all the pfsense extras on the base Debian install :)

Using the same switch/cable/client the debian network driver seems to provide higher throughput.

Debian
iperf -c 192.168.100.2 -p 5010 -t 60


------------------------------------------------------------
[ ID] Interval       Transfer     Bandwidth
[108]  0.0-60.0 sec   602 MBytes  84.1 Mbits/sec

Freebsd7.2/Pfsense 1.2.3rc2

iperf -c 192.168.100.2 -p 5010 -t 60


------------------------------------------------------------
[ ID] Interval       Transfer     Bandwidth
[108]  0.0-60.0 sec   465 MBytes  65.0 Mbits/sec

Wish i knew why this watchdog issue happens to some X500's device more then others.

madas

I'm having exactly the same on my X500 too.

re0: watchdog timeout
re0: watchdog timeout
re0: watchdog timeout
re0: watchdog timeout
re0: watchdog timeout

I get them on all ports, internal, external whether connected to a switch/cable modem etc etc, nothing makes a difference. Its a shame, the Firebox running pfSense is really good except for the watchdog timeouts!

louis-m

i only get the odd occassional timeout on my x500 since i've upgraded. is the updated code in the new embedded version? i'm running embedded 1.2.3-rc2 and fancy moving over to the new embedded but don't wreck what appears to be a stable install.
of the timeouts i get, they are generally when i'm playing about in the web interface. there's no timeouts if i leave it alone

louis-m

spoke too soon. still getting them but no where near as much. does the new nanobsd embedded have the patch installed?

teh

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

gsiener

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

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

Spy Alelo

I know it's been a while, but is there any progress on this? ???

iFloris

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.

Spy Alelo

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?

iFloris

@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?

Spy Alelo

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.

ntsecrets

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? ???

Spy Alelo

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.

computor

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.

Delirius

Hi,

Any news on this topic?

iFloris

Delerius, watchdog timeouts are pretty much a thing of the past in 2.0, when having set the correct tunables.

Delirius

@iFloris:

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.