Unable to re-issue static IP to awakening client without pfsense reboot
-
What is meant by "If this IP address is in use when this client requests a lease, it will instead receive one from the general pool." is ISC dhcpd's behavior in not assigning IPs that are actively in use somewhere else. As far as I'm aware, that means something other than the host requesting the lease is already using that IP, it suggests you have an IP conflict somewhere.
On the link recovery, is it going into a constant state of link down/up there? Seems to do that at least once but not sure if it's more than that.
-
@cmb:
On the link recovery, is it going into a constant state of link down/up there? Seems to do that at least once but not sure if it's more than that.
Earlier reply says @Pennyless:
The following pattern repeats without ending about every 7 seconds.
Network connection is established for about 2 seconds then lost for 5, over and over.which strongly suggests to me its more than once.
-
Ah yeah I didn't see that. The problem at one point in the past was the Intel drivers cycle link when you add an interface to a bridge, which then causes the interface to be added back to the bridge, which cycles link, which causes the interface to be added to the bridge, and repeats the process over and over endlessly. Though the OP makes no mention of which version, 2.0 and 2.0.1 release versions shouldn't exhibit this behavior. We ran into that scenario on a customer's system pre-2.0 release and fixed it prior to release.
-
@cmb:
Ah yeah I didn't see that. The problem at one point in the past was the Intel drivers cycle link when you add an interface to a bridge, which then causes the interface to be added back to the bridge, which cycles link, which causes the interface to be added to the bridge, and repeats the process over and over endlessly. Though the OP makes no mention of which version, 2.0 and 2.0.1 release versions shouldn't exhibit this behavior. We ran into that scenario on a customer's system pre-2.0 release and fixed it prior to release.
Thank you
Version 2.0.1
Intel Pro 16.8 drivers
This behavior accurately discribes the issue.
Is there anything that I can do to resolve this cycling, short of rebooting pfSense every time a client is awakened? -
Is there anything that I can do to resolve this cycling, short of rebooting pfSense every time a client is awakened?
Are you able to try my suggestion in reply 5?
-
Thank you, not yet.
But it's underway.
Take a couple of days. -
Is there anything that I can do to resolve this cycling, short of rebooting pfSense every time a client is awakened?
Are you able to try my suggestion in reply 5?
As you recommended, a switch was placed between the pfSense nic and a Server.
This test was accomplished with 1 to 5 dis-similar servers, individually and concurrently.
In each case all servers operated correctly with no "nic linkup cycling" whatsoever.
Every configuration we could think of performed correctly.
Each client device was cycled from a cold shutdown to a stable connection numerous times with static IP assignment, dynamic IP assignment, and "statically mapped" dynamic assignment.
We were completely unable to reproduce the "cycling" with an intermediate switch in place.However immediately upon removal of the recommended switch, the exact same previous behavior returned.
We need these servers connected directly to the pfSense bridge nics without intermediate switches.
That should be a perfectly acceptable configuration because on a cold startup everything does exactly what it is suppose to do and no "cycling" occurs. So it does work without a switch. Just not on a restart of any of the client devices.Do you have any ideas how to stop this "cycling" upon reconnect?
Thank you!
-
We need these servers connected directly to the pfSense bridge nics without intermediate switches.
Why? If readers know a bit more about your requirements they might be better able to suggest a solution.
Do you have any ideas how to stop this "cycling" upon reconnect?
1. Unfortunately you have already rejected what seemed to me (in my ignorance of the nuances of your requirements) a quite workable solution.
2. The log reports @Pennyless:
08:52:36 php: : rc.newwanip: Informational is starting em13.
08:52:36 php: : rc.newwanip: on (IP address: ) (interface: opt24) (real interface: em13).
08:52:36 php: : rc.newwanip: Failed to update opt24 IP, restarting…The section of /etc/rc.newwanip that reports this reads:```
if($curwanip == "0.0.0.0" || !is_ipaddr($curwanip)) {
log_error("rc.newwanip: Failed to update {$interface} IP, restarting...");
send_event("interface reconfigure {$interface}");
exit;
}> 08:52:31 php: : Hotplug event detected for opt24 but ignoring since interface is configured with static IP () which might imply the interface has an "empty" IP address. At this point I'm thinking its not a good use of my volunteer time to pursue this any further especially when I have a couple of still unresolved pfSense issues of my own. 3\. Wait for another reader to come up with a solution. 4\. File a pfSense bug report on [http://redmine.pfsense.org](http://redmine.pfsense.org) 5\. Offer a bounty to have it fixed 6\. Purchase pfSense support etc. -
Disabling the link up actions entirely may suffice for your scenario, check the source where wallabybob gave you some pointers.
-
OK, understood.
Thank you both again for your time.I apologize for not making our requirements clear.
We simply needed to connect a static IP server directly to a bridged subnet within our pfSense box, shut the server down in the evening, and wake it up in the AM…without restarting pfSense.
-
For anyone else having trouble with this particular cycling nic issue, this problem has been previously documented.
It was marked as resolved 2 months ago by Chris Buechler.
Just as this thread indicates;http://redmine.pfsense.org/issues/1572
The only solution in my particular case was setting the "Speed and Duplex to nothing other than "default"."
All cycling vanished.v2.0.1