I keep loosing connectivity on my wan after a few days
-
I am also getting the same "xl0 watchdog timeout" repeated messages with RC2 (not sure about prev) this is happening on 3 different boxes. I wander if this has any effect beyond minor annoyance? Is there any risk of packet loss occuring or media disconnects? Thanks!
-
I've been having the same problems, always on the same interface.
Sep 25 00:27:01 php: : Hotplug event detected for sk0 but ignoring since interface is not set for DHCP Sep 25 00:27:00 kernel: sk0: link state changed to UP Sep 25 00:09:35 php: : Hotplug event detected for sk0 but ignoring since interface is not set for DHCP Sep 25 00:09:32 kernel: sk0: link state changed to DOWN Sep 25 00:09:32 kernel: sk0: watchdog timeoutSep 24 19:22:11 php: : FTP proxy disabled for interface opt1 - ignoring. Sep 24 19:22:11 kernel: sk1: link state changed to UP Sep 24 19:13:55 php: : Hotplug event detected for sk1 but ignoring since interface is not set for DHCP Sep 24 19:13:51 kernel: sk1: link state changed to DOWN Sep 24 19:13:51 kernel: sk1: watchdog timeoutI happens occasionally at random times, sometimes up to twice a day. Its usually not down for more than an hour of so.
Any clues as to what causes this?
edit: Im using 3com gigabit adaptors:
$ dmesg | grep -i 3com skc0: <3Com 3C940 Gigabit Ethernet> port 0x1000-0x10ff mem 0x40000000-0x40003fff irq 16 at device 4.0 on pci2 skc0: 3Com Gigabit NIC (3C2000) rev. (0x1) skc1: <3Com 3C940 Gigabit Ethernet> port 0x1400-0x14ff mem 0x40100000-0x40103fff irq 18 at device 9.0 on pci2 skc1: 3Com Gigabit NIC (3C2000) rev. (0x1) skc2: <3Com 3C940 Gigabit Ethernet> port 0x1800-0x18ff mem 0x40200000-0x40203fff irq 21 at device 10.0 on pci2 skc2: 3Com Gigabit NIC (3C2000) rev. (0x1)and im using 1.0-SNAPSHOT-09-14-06 built on Thu Sep 14 21:19:15 UTC 2006 after an update of RC2, which i installed from scratch using the LiveCD.
-
i´m about to give pfsense another try, just wondering if this problem still persists or not.
/F
-
Im still having these problems, but there have been 4 snapshots since the one i am running, so it may have been resolved.
Im going to update tomorrow morning (in about 12 hours) and try it out again….
Ill keep posting here...
-
I've been having the same problems, always on the same interface.
... Sep 25 00:27:01 php: : Hotplug event detected for sk0 but ignoring since interface is not set for DHCP ...This is a physical disconnect/connect event on your NIC.
Isolate it (remova/change/inverse with LAN) to check this card, or, more likely, change the cable.
Check also 'the other side' of the cable. -
I've been having the same problems, always on the same interface.
... Sep 25 00:27:01 php: : Hotplug event detected for sk0 but ignoring since interface is not set for DHCP ...This is a physical disconnect/connect event on your NIC.
Isolate it (remova/change/inverse with LAN) to check this card, or, more likely, change the cable.
Check also 'the other side' of the cable.Nope. I've changed the NIC (both are brand new), the cable, even the switch port that its on.
Im going to update to the latest snapshot, and see what gives.
-
A long shot : the NIC, device name sk0, has FreeBSD driver troubles ?
Try another brand - another chipset NIC aren't expensive ;)
Imoh, it can only be the cable or the NIC. -
A long shot : the NIC, device name sk0, has FreeBSD driver troubles ?
Try another brand - another chipset NIC aren't expensive ;)
Imoh, it can only be the cable or the NIC.Alright, ill try replacing the NICs with different one. What strikes me as weird is that all three nics in the box that im using are of the same make and model (bought at the same time). SK1 and SK2 have no problems.
-
Ok.
Some more questions persists.
Is it the third card, recognized when booting (indifferent from which one, sk0, sk1 & sk2 - or on what PCI slot it is) that poses a problem ? dmesg says what ?
(I try to detemine here system resources limits like IRQ share on a BIOS level, card level OS level - because even some PCI implementations have a fixed number of possible IRQS's to chose / OS drivers can have limits…)
Make the system with works with 2 cards - try all combinations....Still sure that it isn't the other side ?
Try also to loop sk1 to sk2 - open WAN Firewall on sk0 (give it a static IP !), open port SSH an login - check also like this.Youl'll manage.
-
Hi all !
Is this solved in 1.0.1 ?
I upgraded to this version but with 1.0 I was reinstalling the machine often !
I can't even have lan access to it …I installed one pfSense in Africa and I'm out of that country and I think it happened there.
[]'s
-
Hi all !
Is this solved in 1.0.1 ?
I upgraded to this version but with 1.0 I was reinstalling the machine often !
I can't even have lan access to it …I installed one pfSense in Africa and I'm out of that country and I think it happened there.
[]'s
Who knows… You are the only person with this problem.
-
How can I debug this ?
Is there some file with logs besides web interface ? -
No idea, honestly. It should "just work".
-
Anyway, I think there is some bug when ISP gives you connection without an ip.
But ok, thanks. -
Uhm, that would not be a bug? If the ISP does not hand out an IP then there is nothing pfSense can do.
-
But it won't give access to web interface of firewall and the other services in DMZ !
This is the bug.This leads to a firewall reset. Nothing more.
-
sounds like hardware issues to me. Why should not receiving a dhcp lease on request cause a reset?
-
No. You didn't understand:
The reset in console is what I must do because the reboot won't work, access to web interface won't work, access to hosts behind DMZ won't work, …
The firewall becomes dead when wan connection goes up but don't receives ip from the ISP.
[]'s
-
I agree with Holger. Sounds like hardware issues.
-
If you lose the WAN IP and use natreflection to access the DMZ it won't work anymore as you lost the IP that gets reflected. You maybe even lose DNS to resolve the WAN IP first if it is a dyndns account. That makes sense. I'm still thinking something with your WAN is wrong or maybe even with your ISP.
