DHCP on WAN suddenly started failing
-
I hate to dredge this 2 month old thread up, but I'm having what I believe to be a similar or identical issue here; also on a cable modem for WAN, but I'm with Time Warner.
What's interesting is that when the behavior is happening, I can watch the blinkenlights and the interface is flapping on both pfSense and the modem – the modem is NOT rebooting during this, I just get a constantly flapping WAN interface / modem ethernet.
Thinking maybe it was somehow hardware related (unlikely as the hardware is Soekris with Intel / em NICs), I tried moving the modem from em0 to em3. The link stopped flapping on em3… until I reconfigured pfSense to use em3 as the WAN, at which point it started flapping again.
Rebooting made it all work correctly on em3, and then I was able to move the connection back to em0 and re-set that as the WAN, and it runs fine on that interface again. I'm not sure what the reboot was doing that I wasn't able to do by clicking "renew lease" in the GUI (IIRC, that had no effect).
I have everything that pfSense was outputting on a syslog server if the logs would be helpful. I don't have any of the stuff from /tmp because of the reboot (and this is an embedded install).
I was thinking about trying 2.1RC, but I don't see the point if this is still in 2.1 as well.
-
@bradenmcg:
I just get a constantly flapping WAN interface / modem ethernet.
What is that causes to consider the interface is "flapping"? The interface indicator lights blinking? A recurring sequence of events in the system log?
What is the system log reporting during the time you consider the interface is "flapping"?
-
I am running pfsense 2.0.3 and I have problem with it.
my conf is : isp–> modem--> pfsense--> lan
and my pfsense lost connection with modem gateway.
and suddenly drops all dhcp leases on lan. restart does not solve dhcp issues. -
and my pfsense lost connection with modem gateway.
and suddenly drops all dhcp leases on lan.What do you observe that you describe as "drops all DHCP leases on LAN"? Lose access to Internet? All LAN systems suddenly and almost simultaneously attempt to renew DHCP leases and all fail to get a response?
restart does not solve dhcp issues.
Restart of what: modem? pfSense box? DHCP server on pfSense LAN interface?
Please post an extract of pfSense system log from a few events before "lost connection with modem gateway" to a few minutes later.
-
I am running pfsense 2.0.3 and I have problem with it.
It looks as if you started a new topic for this issue: http://forum.pfsense.org/index.php/topic,64107
Lets keep the discussion there. -
@bradenmcg:
I just get a constantly flapping WAN interface / modem ethernet.
What is that causes to consider the interface is "flapping"? The interface indicator lights blinking? A recurring sequence of events in the system log?
What is the system log reporting during the time you consider the interface is "flapping"?
Sorry for the super delayed reply to this, I have been busy. :)
By "flapping" I mean both log indications from pfSense showing interface up / interface down, as well as physical link lights on both the hardware and the cable modem it is connecting to turning off (indicating no link).
It just happened to me again today when the modem lost signal on the coax. Pfsense would show the interface as "up" and then "no carrier" in Status -> Interfaces (if I kept refreshing the page). I can also SSH to the box and keep repeating an "ifconfig em0" (which is the link attached to the modem) and it alternates between "status: no carrier" and "status: active".
[2.0.3-RELEASE][admin@pf.bhm.ds]/root(9): ifconfig em0 em0: flags=8843 <up,broadcast,running,simplex,multicast>metric 0 mtu 1500 options=4209b <rxcsum,txcsum,vlan_mtu,vlan_hwtagging,vlan_hwcsum,wol_magic,vlan_hwtso>ether 00:00:24:cf:ef:70 inet6 fe80::200:24ff:fecf:ef70%em0 prefixlen 64 scopeid 0x1 inet [public IP] netmask 0xffffe000 broadcast 255.255.255.255 nd6 options=43 <performnud,accept_rtadv>media: Ethernet autoselect (1000baseT <full-duplex>) status: active [2.0.3-RELEASE][admin@pf.bhm.ds]/root(10): ifconfig em0 em0: flags=8843 <up,broadcast,running,simplex,multicast>metric 0 mtu 1500 options=4209b <rxcsum,txcsum,vlan_mtu,vlan_hwtagging,vlan_hwcsum,wol_magic,vlan_hwtso>ether 00:00:24:cf:ef:70 inet6 fe80::200:24ff:fecf:ef70%em0 prefixlen 64 scopeid 0x1 inet [public ip] netmask 0xffffe000 broadcast 255.255.255.255 nd6 options=43 <performnud,accept_rtadv>media: Ethernet autoselect status: no carrier</performnud,accept_rtadv></rxcsum,txcsum,vlan_mtu,vlan_hwtagging,vlan_hwcsum,wol_magic,vlan_hwtso></up,broadcast,running,simplex,multicast></full-duplex></performnud,accept_rtadv></rxcsum,txcsum,vlan_mtu,vlan_hwtagging,vlan_hwcsum,wol_magic,vlan_hwtso></up,broadcast,running,simplex,multicast>
This appears to be logged in syslog with a tag of "DEVD Ethernet {detached,attached} event on [interfacename]" – this is nice, but it would be better if the interface name in BSD-speak was also included, since searching for "em0" doesn't turn up squat about the link state. "wan (em0)" would be far more helpful than just "wan." According to syslog (this unit dumps to a server), it seems to detach 2 seconds after it has gone to attached state, and then 3 seconds later it goes back to attached. This will repeat forever until I take action.
I've found that hard-setting the interface to 1000/full clears everything up, or I can reboot pfSense and it will be OK again (still at auto) for some indeterminate period of time until there is a link status change. It seems like when the modem is without signal on coax for long enough, it either self-reboots (causing Eth to drop) or it simply drops and re-ups the Eth port.
I hate hardcoding equipment, especially when I can't also hardcode the same on the other side (can't change anything on the modem). I hope that the modem is smart enough to go to 1000/full, but I could be causing a duplex mis-match by hardcoding and I have no way to know since the modem doesn't provide any Ethernet link status beyond a light that indicates speed (blue = 1000, orange = 100 or 10). I know that a 10/100 link with auto on one side and 100/full on the other is generally supposed to operate at 100/half, but I don't know what gigabit is supposed to do under similar auto-mismatches.
I'm wondering if this is some sort of "green ethernet" "feature" in the em driver or the chip itself, or possibly a very strange incompatibility between the chip and this Motorola modem? I don't have any trouble with systems on older Soekris hardware (with the same modem) which didn't use Intel Gigabit chips. I also have other systems on the net6501 but with different WAN devices (Ubee modem in one location and DSL in another) and haven't heard complaints.
-
Do you have gateway monitoring enabled on the WAN link? (Edit the appropriate gateway from the System -> Routing, Gateways tab and look at the Disable Gateway Monitoring attribute.)
-
Yes, gateway monitoring is enabled per the defaults for a dynamic WAN connection.
-
Can you put a switch between the pfSense WAN interface and the modem? This should have the effect of leaving carrier to the modem permanently on (as long as as the switch has power) and should stop each end confusing the other by dropping carrier.
-
I could insert a switch between them, yes… but why should I have to? I know the switch works around the problem, as does hardcoding the interface on pfSense, but this is a bug somewhere, either in the modem's ethernet controller or the em driver in FreeBSD.
I don't have another system handy to see if the behavior persists with other drivers, and every NIC in this Soekris box is Intel/em. I have tried more than one of this Soekris box (in case it was a problem with the board or controller itself) but the problem has persisted across the devices.
-
Actually, I went back and put in a switch for the heck of it… and the interface continues flapping as described previously. The only way I can get it to stop now is to hardcode the interface to 1000/full, or rebooting pfSense fixes the problem until it decides to start up again. Presumably having the switch between the modem and pfSense should extend the time before it starts flapping though.
I've even tried disabling the interface for a while and then re-enabling it to see if downing/re-upping would reset the hardware, but no help.
Again, I don't know if this is necessarily a pfSense bug and seems more likely to be a FreeBSD (driver?) bug... but I'm not directly using FreeBSD. ;)
[edit]
Ok, played around with it some more. It seems like there is something strange going on with the "autoselect" option. When I have the interface set to "Autoselect," it will flap the link at layer 1 (LED turns on and off) indefinitely. If I set the interface to 1000/full, it stays up.
If I change the interface to "Default / no preference", it seems to take on the settings it was at previously – if I had been at 1000/full and I set to Default/No Pref and Save+Apply, the link stays hardcoded at 1000/full (with unknown effects since the device on the other side can't be hardcoded).
However, if I set the link to autoselect, save+apply and allow it to flap, and while that is happening change it back to "default/no preference," and then save+apply that setting... the link stays at autoselect but it doesn't flap anymore. o_O
There is something Not Right (TM) with autoselect mediaopt on em(4) in 2.0.3 release at least. >_<
-
Uhm… frankly this sounds like faulty cable or the modem being garbage, rather than any driver bug.
-
Please post an extract of pfSense system log from a few events before "lost connection with modem gateway" to a few minutes later.
There have been a number of different reports of this sort of problem but (as far as I know) the problem has not been identified. It seems to be quite difficult to reproduce. Could you turn off gateway monitoring for a few days to see if that makes a difference? Also please post the output of pfSense shell command```
wc -c -l /tmp/rules.debug -
Uhm… frankly this sounds like faulty cable or the modem being garbage, rather than any driver bug.
I would agree with you except the problem persists when I put a switch between the pfSense box and the modem, and the problem manifests on the pfSense box itself and not the modem in that case. (The link on pfSense is flapping and the modem doesn't change state at all if I have the switch between them.) It seems like when there ISN'T a switch between them, the entire process starts if the modem reboots or loses RF signal, which causes it to drop its Ethernet interface after some period of time. Once that link has dropped and reconnected, pfSense goes off the rails.
wallabybob:
That shouldn't be a problem, I think I'm able to reproduce it fairly easily now just by setting the link directly to autoselect then unplugging the NIC and plugging it back in. That seems to start the flapping anew (or at least it was last night).wc -c -l /tmp/rules.debug 222 12310 /tmp/rules.debug
I have some stale log events from last night in my syslog server, or I can attempt to recreate again tonight and post fresh log details.
-
@bradenmcg:
I would agree with you except the problem persists when I put a switch between the pfSense box and the modem, and the problem manifests on the pfSense box itself and not the modem in that case. (The link on pfSense is flapping and the modem doesn't change state at all if I have the switch between them.)
Well, then it's probably time to consider the pfsense box HW itself is faulty.
-
@bradenmcg:
I would agree with you except the problem persists when I put a switch between the pfSense box and the modem, and the problem manifests on the pfSense box itself and not the modem in that case. (The link on pfSense is flapping and the modem doesn't change state at all if I have the switch between them.)
Well, then it's probably time to consider the pfsense box HW itself is faulty.
It is a Soekris net6501. It's been replaced once already due to this because I thought it was bad HW, and it does it on the new box as well (I doubt I got two bad units in a row). The same behavior happens on multiple ports on the unit too, each a separate ethernet controller (albeit all using the em driver). If I change my definition of WAN to be em4 instead of em0 and move the ethernet connection to the modem there, it is fine until Layer 1 gets dropped for whatever reason, and then the flapping starts again.
If it's not the driver, I wonder if gateway monitoring could be the cause, since I don't believe LAN would get monitored by default (and I've never had this problem with the LAN port connected to a gigabit HP switch).
-
I didn't want to paste the entire log (500+ lines for about a minute or two of flapping), so I put it on pastebin.
http://pastebin.com/CJ4rN1yV
Unfortunately, system.log doesn't seem to make a note of the time that any changes were actually enacted by a user, and I didn't look at a seconds-accurate clock to know when I "fixed" the interface.
This was all started by simply going to Interfaces > (WAN interface), then clicking "Advanced" under the "Speed and duplex" heading, and changing it to "autoselect", then clicking "Save" at the bottom of the page, and then "Apply" at the top.
The link was allowed to flap up and down for a minute or two, and then somewhere around 23:06 I reversed the above process, resetting "speed and duplex" back to "Default (no preference, typically autoselect)". The final DHCP / link up / etc should all be due to that change, and it has remained stable since then.
Gateway Monitoring was DISABLED during this test, by checking "Disable Gateway Monitoring" under System: Gateways: Edit gateway.
My LAN interface apparently has GW monitoring enabled by default, and it is set as "autoselect" for speed/duplex, and has never exhibited this flapping behavior (to my knowledge at least). Then again, the switch doesn't get restarted often… but I just reset it last night and didn't have any problems on the LAN side.
If there is more info that would be helpful I can reproduce again and gather whatever's needed.
-
@bradenmcg:
My LAN interface apparently has GW monitoring enabled by default,
What GUI setting leads you to that conclusion?
What do you have set as DNS Server and Use gateway on System -> General Setup?
Your log shows (I have deleted some entries :
Aug 7 23:05:36 pf check_reload_status: Linkup starting em0
Aug 7 23:05:36 pf kernel: em0: link state changed to DOWN
Aug 7 23:05:36 pf dhclient[30956]: My address (76.189.121.xxx) was deleted, dhclient exiting
Aug 7 23:05:39 pf php: : DEVD Ethernet detached event for wan
Aug 7 23:05:40 pf check_reload_status: Linkup starting em0
Aug 7 23:05:40 pf kernel: em0: link state changed to UP
Aug 7 23:05:40 pf dhclient: PREINIT
Aug 7 23:05:40 pf dhclient[40076]: DHCPREQUEST on em0 to 255.255.255.255 port 67
Aug 7 23:05:40 pf dhclient[40076]: DHCPACK from 142.254.151.133
Aug 7 23:05:40 pf dhclient: REBOOT
Aug 7 23:05:40 pf dhclient: Starting add_new_address()
Aug 7 23:05:40 pf dhclient: ifconfig em0 inet 76.189.121.xxx netmask 255.255.224.0 broadcast 255.255.255.255
Aug 7 23:05:40 pf dhclient: New IP Address (em0): 76.189.121.xxx
Aug 7 23:05:40 pf dhclient: New Subnet Mask (em0): 255.255.224.0
Aug 7 23:05:40 pf dhclient: New Broadcast Address (em0): 255.255.255.255
Aug 7 23:05:40 pf dhclient: New Routers (em0): 76.189.96.1
Aug 7 23:05:40 pf dhclient: Adding new routes to interface: em0
Aug 7 23:05:40 pf dhclient: /sbin/route add default 76.189.96.1
Aug 7 23:05:40 pf dhclient: Creating resolv.conf
Aug 7 23:05:41 pf check_reload_status: rc.newwanip starting em0
Aug 7 23:05:41 pf dhclient[40076]: bound to 76.189.121.xxx – renewal in 21600 seconds.
Aug 7 23:05:41 pf php: /interfaces.php: ROUTING: setting default route to 76.189.96.1
Aug 7 23:05:42 pf php: : DEVD Ethernet attached event for wan
Aug 7 23:05:42 pf php: : HOTPLUG: Configuring interface wan
Aug 7 23:05:42 pf check_reload_status: Linkup starting em0
Aug 7 23:05:42 pf kernel: em0: link state changed to DOWN
Aug 7 23:05:43 pf dnsmasq[35896]: exiting on receipt of SIGTERM
Aug 7 23:05:43 pf php: : rc.newwanip: Informational is starting em0.
Aug 7 23:05:43 pf php: : rc.newwanip: on (IP address: 76.189.121.xxx) (interface: wan) (real interface: em0).
Aug 7 23:05:43 pf php: : The command 'route change -host 76.189.96.1' returned exit code '1', the output was 'route: writing to routing socket: No such process route: writing to routing socket: Invalid argument change host 76.189.96.1: Invalid argument'Notice the link state to DOWN transition at 23:05:42 before the completion of the processing of the preceding linkup - the error returned by route at 23:05:43 appears to be because of an attempt to set a route to a DNS server failing because part of the necessary information has gone missing because the link went down.
The log extract shows a number of instances of link up promptly followed by link down:
Aug 7 23:05:36 pf check_reload_status: Linkup starting em0
Aug 7 23:05:36 pf kernel: em0: link state changed to DOWNAug 7 23:05:40 pf kernel: em0: link state changed to UP
Aug 7 23:05:42 pf check_reload_status: Linkup starting em0
Aug 7 23:05:42 pf kernel: em0: link state changed to DOWNAug 7 23:05:45 pf check_reload_status: Linkup starting em0
Aug 7 23:05:45 pf kernel: em0: link state changed to UPAug 7 23:05:48 pf kernel: em0: link state changed to DOWN
Aug 7 23:05:48 pf check_reload_status: Linkup starting em0
A
Aug 7 23:05:54 pf kernel: em0: link state changed to DOWN
Aug 7 23:05:54 pf check_reload_status: Linkup starting em0Aug 7 23:05:57 pf kernel: em0: link state changed to UP
Aug 7 23:05:57 pf check_reload_status: Linkup starting em0Aug 7 23:06:00 pf check_reload_status: Linkup starting em0
Aug 7 23:06:00 pf kernel: em0: link state changed to DOWNAug 7 23:06:06 pf check_reload_status: Linkup starting em0
Aug 7 23:06:06 pf kernel: em0: link state changed to DOWNAug 7 23:06:09 pf check_reload_status: Linkup starting em0
Aug 7 23:06:09 pf kernel: em0: link state changed to UPAug 7 23:06:11 pf check_reload_status: Linkup starting em0
Aug 7 23:06:11 pf kernel: em0: link state changed to DOWNAug 7 23:06:15 pf check_reload_status: Linkup starting em0
Aug 7 23:06:15 pf kernel: em0: link state changed to UP. I don't know why this is happenning. But with link up running concurrently with link down PERHAPS the link up processing is detecting an unexpected condition (e.g. the WAN interface doesn't have an IP address) and forcing link down to try to reset things
Does it make a difference to disable miniupnpd? The log suggests it isn't happy. I don't know if miniupnpd is doing anything to contribute to this unhappy state of affairs.
-
@bradenmcg:
My LAN interface apparently has GW monitoring enabled by default,
What GUI setting leads you to that conclusion?
I looked at Gateway Monitoring and the LAN interface was in there and configured already, I did not alter it. I thought that only WAN gateways were monitored but I guess all gateways are unless you change them.
What do you have set as DNS Server and Use gateway on System -> General Setup?
DNS servers are all blank, and "use gateway" is WAN. I have "allow DNS server list to be overridden" enabled.
I do have two DNS domain overrides setup on Services > DNS Forwarder that allow me to resolve hostnames from my office (across VPN), but otherwise DNS forwarder is just using Time Warner's DHCP-assigned pair of servers.
Your log shows (I have deleted some entries :
Aug 7 23:05:36 pf check_reload_status: Linkup starting em0
Aug 7 23:05:36 pf kernel: em0: link state changed to DOWN
Aug 7 23:05:36 pf dhclient[30956]: My address (76.189.121.xxx) was deleted, dhclient exiting
Aug 7 23:05:39 pf php: : DEVD Ethernet detached event for wan
Aug 7 23:05:40 pf check_reload_status: Linkup starting em0
Aug 7 23:05:40 pf kernel: em0: link state changed to UP
Aug 7 23:05:40 pf dhclient: PREINIT
Aug 7 23:05:40 pf dhclient[40076]: DHCPREQUEST on em0 to 255.255.255.255 port 67
Aug 7 23:05:40 pf dhclient[40076]: DHCPACK from 142.254.151.133
Aug 7 23:05:40 pf dhclient: REBOOT
Aug 7 23:05:40 pf dhclient: Starting add_new_address()
Aug 7 23:05:40 pf dhclient: ifconfig em0 inet 76.189.121.xxx netmask 255.255.224.0 broadcast 255.255.255.255
Aug 7 23:05:40 pf dhclient: New IP Address (em0): 76.189.121.xxx
Aug 7 23:05:40 pf dhclient: New Subnet Mask (em0): 255.255.224.0
Aug 7 23:05:40 pf dhclient: New Broadcast Address (em0): 255.255.255.255
Aug 7 23:05:40 pf dhclient: New Routers (em0): 76.189.96.1
Aug 7 23:05:40 pf dhclient: Adding new routes to interface: em0
Aug 7 23:05:40 pf dhclient: /sbin/route add default 76.189.96.1
Aug 7 23:05:40 pf dhclient: Creating resolv.conf
Aug 7 23:05:41 pf check_reload_status: rc.newwanip starting em0
Aug 7 23:05:41 pf dhclient[40076]: bound to 76.189.121.xxx – renewal in 21600 seconds.
Aug 7 23:05:41 pf php: /interfaces.php: ROUTING: setting default route to 76.189.96.1
Aug 7 23:05:42 pf php: : DEVD Ethernet attached event for wan
Aug 7 23:05:42 pf php: : HOTPLUG: Configuring interface wan
Aug 7 23:05:42 pf check_reload_status: Linkup starting em0
Aug 7 23:05:42 pf kernel: em0: link state changed to DOWN
Aug 7 23:05:43 pf dnsmasq[35896]: exiting on receipt of SIGTERM
Aug 7 23:05:43 pf php: : rc.newwanip: Informational is starting em0.
Aug 7 23:05:43 pf php: : rc.newwanip: on (IP address: 76.189.121.xxx) (interface: wan) (real interface: em0).
Aug 7 23:05:43 pf php: : The command 'route change -host 76.189.96.1' returned exit code '1', the output was 'route: writing to routing socket: No such process route: writing to routing socket: Invalid argument change host 76.189.96.1: Invalid argument'Notice the link state to DOWN transition at 23:05:42 before the completion of the processing of the preceding linkup - the error returned by route at 23:05:43 appears to be because of an attempt to set a route to a DNS server failing because part of the necessary information has gone missing because the link went down.
The route that it is trying to set is the default route - 76.189.96.1 is the default gateway for the IP I am assigned. TWC is using a fairly large subnet here (/19).
The log extract shows a number of instances of link up promptly followed by link down:
Aug 7 23:05:36 pf check_reload_status: Linkup starting em0
Aug 7 23:05:36 pf kernel: em0: link state changed to DOWNAug 7 23:05:40 pf kernel: em0: link state changed to UP
Aug 7 23:05:42 pf check_reload_status: Linkup starting em0
Aug 7 23:05:42 pf kernel: em0: link state changed to DOWNAug 7 23:05:45 pf check_reload_status: Linkup starting em0
Aug 7 23:05:45 pf kernel: em0: link state changed to UPAug 7 23:05:48 pf kernel: em0: link state changed to DOWN
Aug 7 23:05:48 pf check_reload_status: Linkup starting em0
A
Aug 7 23:05:54 pf kernel: em0: link state changed to DOWN
Aug 7 23:05:54 pf check_reload_status: Linkup starting em0Aug 7 23:05:57 pf kernel: em0: link state changed to UP
Aug 7 23:05:57 pf check_reload_status: Linkup starting em0Aug 7 23:06:00 pf check_reload_status: Linkup starting em0
Aug 7 23:06:00 pf kernel: em0: link state changed to DOWNAug 7 23:06:06 pf check_reload_status: Linkup starting em0
Aug 7 23:06:06 pf kernel: em0: link state changed to DOWNAug 7 23:06:09 pf check_reload_status: Linkup starting em0
Aug 7 23:06:09 pf kernel: em0: link state changed to UPAug 7 23:06:11 pf check_reload_status: Linkup starting em0
Aug 7 23:06:11 pf kernel: em0: link state changed to DOWNAug 7 23:06:15 pf check_reload_status: Linkup starting em0
Aug 7 23:06:15 pf kernel: em0: link state changed to UP. I don't know why this is happening. But with link up running concurrently with link down PERHAPS the link up processing is detecting an unexpected condition (e.g. the WAN interface doesn't have an IP address) and forcing link down to try to reset things
Does it make a difference to disable miniupnpd? The log suggests it isn't happy. I don't know if miniupnpd is doing anything to contribute to this unhappy state of affairs.
To my knowledge miniupnpd doesn't actively do anything with the link, it is just complaining because it wants to know the WAN IP and can't find it. I can try disabling it though and then triggering the bug again to see if the link will still flap.
Should I open a bug for this in Redmine?
-
Sorry to necro this, but I've been searching topics for the last hour, and this is the only topic I was able to find that is exactly, to the tee, what I am experiencing.
Was this ever resolved?
Running 2.0.1 release. This box has been running for over a year. no issues until this
Recently, I was experiencing issues with my cable modem and I made two changes to the WAN interface config:
- I cloned the MAC to another system I was testing with temporarily (and then removed the clone settings when I was done testing)
. . . and
- I manually set the interface to 100Mbps, and then set it to "autoselect" (which I thought was the default)
Since then, any interruption of the WAN carrier causes that interface to flap. For ex, if I unplug the WAN cable, and plug it back in. . flaps indefinitely. If the cable modem times out briefly due to service provider maintenance, and the cable modem resets, interface flaps forever.
Only a reboot of the system resolves it.
Before the above 2 changes, this never happened.
It seems like the OP here fixed by setting the interface back to the actual default setting- "Default (no preference, typically autoselect)". I set mine back to that as well now, but can't test it at the moment since it's production.
The OP asked about opening up a bug report? Is this something resolved in a newer version? Was the underlying cause ever discovered?
Nic uses em driver, IP config is DHCP, and connection to cable modem is gigabit.
-Rich H.