Keep loosing WAN IP Address - dhclient does not seem to do update
-
Yea… my sense box seems pretty happy again.. thank you sir...
-
Good. Others please test. A new snapshot will be uploaded in a couple hours.
-
running great now for around 1 day!
Thanks a lot for the great work!
-
running great now for around 1 day!
Thanks a lot for the great work!
Awesome! Anyone else?
-
Works great ! I think you hit the spot ! ;D
-
Works great ! I think you hit the spot ! ;D
Great! That's 3-4 people that is now fixed. FreeBSD REALLY needs to take a look at their dhclient. It's obvious that it's subpar to ISC's.
Anyone else?
Merry Xmas and happy holidays!
-
Just updated to the latest cvs… No issue for 2 days. I think the right spot was hit ;)
Happy holidays and again - big thanks for the great work!
-
I'm new here; so it could be me; but I'm also experiencing the issue. I have to ifconfig up / down every couple hours. I don't see any logs that are showing me errors - any tips on where to look? I installed from the 12-23 build with squid and snort. I also ran the fetch command from above.
I'm all for suggesting it's user error; any tips are welcome. I had a build from early December running and it was up for a couple weeks without issue.
edit with a tiny bit more info - I've looked at the system.log; and it seems to be corrupted near the end.I'm on my second old clunker hard drive; maybe this one's been around the block too many times as well. There's some weird duplication at the end of the log before it turns into an ASCII mess:
Dec 27 02:44:31 chunder snort[775]: Var 'SMTP_SERVERS' defined, value len = 28 chars
Dec 27 02:44:31 chunder snort[775]: Var 'SMTP_SERVERS' defined, value len = 28 chars
Dec 27 02:44:31 chunder snort[775]: , value = [24.89.123.123,192.168.1.1,]
…skipping...
Dec 27 21:53:26 chunder dhclient: execve (/sb, ...): No such file or directory
Dec 27 21:53:26 chunder dhclient: execve (/sb, ...): No such file or directory
Dec 27 21:53:26 chunder dhclient: Listening on BPF/ed0/00:50:8d:f1:3a:9d
Dec 27 21:53:26 chunder dhclient: Sending on BPF/ed0/00:50:8d:f1:3a:9d
Dec 27 21:53:26 chunder dhclient: Can't bind to dhcp address: Address already in use
Dec 27 21:53:26 chunder dhclient: Can't bind to dhcp address: Address already in use
Dec 27 21:53:26 chunder dhclient: Please make sure there is no other dhcp server
Dec 27 21:53:26 chunder dhclient: Please make sure there is no other dhcp server
Dec 27 21:53:26 chunder dhclient: running and that there's no entry for dhcp or
Dec 27 21:53:26 chunder dhclient: running and that there's no entry for dhcp or
Dec 27 21:53:26 chunder dhclient: bootp in /etc/inetd.conf. Also make sure you
Dec 27 21:53:26 chunder dhclient: bootp in /etc/inetd.conf. Also make sure you
Dec 27 21:53:26 chunder dhclient: are not running HP JetAdmin software, which
Dec 27 21:53:26 chunder dhclient: are not running HP JetAdmin software, which
Dec 27 21:53:26 chunder dhclient: includes a bootp server.
Dec 27 21:53:26 chunder dhclient: includes a bootp server.Does that suggest anything? I'm not aware of any bootp servers running anywhere. Hm.
-
Any chance that you are using dhcp on more than 1 interface? The current dhclient-switch doesn't handle multiple dhcp interfaces correctly atm. We need to improve this a bit to handle these kind of situations.
-
Any chance that you are using dhcp on more than 1 interface? The current dhclient-switch doesn't handle multiple dhcp interfaces correctly atm. We need to improve this a bit to handle these kind of situations.
Bad news. Looks like we are going to have to revert back to the previous code. This newer code breaks our multi-wan dhcp.
-
Just to follow up on my previous information; I see this in the system.log:
Dec 28 08:39:40 chunder dhclient: execve (/usr/local/sbin/dhclient-script, …): No such file or directory Dec 28 08:39:40 chunder dhclient: execve (/usr/local/sbin/dhclient-script, ...): No such file or directory Dec 28 08:39:40 chunder dhclient: /y: not found Dec 28 08:39:40 chunder dhclient: /y: not found
dhclient-script is in /sbin ?
I'm still using the install from 12-23 and I used the fetch from another thread. Maybe I just made a mess…. Maybe I'll copy that over and see what happens; or maybe I'll get a chance to take a better look at it and see what put it there.
-
Investigating this error is riding a dead horse. We have to go back to the previous dhclient due to multi interface dhclient issues with the isc client that can't be worked around. The next snapshot will be back at the "old" openbsd dhclient.
-
Hi !
Does the following code work to workaround temporarily this problem ?
/etc/rc.newwanip
if($curwanip == "0.0.0.0") {
log_error("Failed to update WAN IP, restarting dhclient.");
exec("dhclient fxp0");Thanks in advance.
- 13 days later
-
I don't want to stress anybody but I didn't received any answer and this topic seems to be stopped.
This issue is being solved ?
I'm having this problem too.Thanks in advance.
-
I don't want to stress anybody but I didn't received any answer and this topic seems to be stopped.
This issue is being solved ?
I'm having this problem too.Thanks in advance.
No, work has halted. Sorry.
- 8 days later
-
I have commited some work around code to this bug. Please test a snapshot in about an hour from now and see if it works around the issue.
-
Hi again.
I did the update but I lost my connection at this moment again where it didn't happened with an old pfsense with the same hardware:
php: : Hotplug event detected for vr0 but ignoring since interface is not set for DHCP
Jan 30 10:28:24 php: : Hotplug event detected for vr0 but ignoring since interface is not set for DHCP
Jan 30 10:28:23 check_reload_status: rc.linkup starting
Jan 30 10:28:23 mpd: [pt1] LCP: no reply to 1 echo request(s)
Jan 30 10:28:22 kernel: vr0: link state changed to UP
Jan 30 10:28:19 kernel: vr0: link state changed to DOWN
Jan 30 10:28:19 mpd: [pt0] LCP: no reply to 1 echo request(s)
Jan 30 10:28:08 php: : DEVD Ethernet attached event for fxp0
Jan 30 10:28:08 kernel: vr0: link state changed to UP
Jan 30 10:28:08 check_reload_status: rc.linkup starting
Jan 30 10:28:04 kernel: fxp0: link state changed to UP
Jan 30 10:28:03 php: : Hotplug event detected for vr0 but ignoring since interface is not set for DHCP
Jan 30 10:28:03 php: : Hotplug event detected for vr0 but ignoring since interface is not set for DHCP
Jan 30 10:28:03 php: : DEVD Ethernet detached event for fxp0
Jan 30 10:28:03 check_reload_status: rc.linkup starting
Jan 30 10:28:00 kernel: vr0: link state changed to DOWN
Jan 30 10:27:59 kernel: vr0: link state changed to UP
Jan 30 10:27:58 kernel: fxp0: link state changed to DOWN
Jan 30 10:27:58 php: : Hotplug event detected for vr0 but ignoring since interface is not set for DHCP
Jan 30 10:27:58 check_reload_status: rc.linkup starting
Jan 30 10:27:53 kernel: vr0: link state changed to DOWN
Jan 30 10:21:44 mpd: [pt1] IFACE: Up event
Jan 30 10:21:44 mpd: [pt1] exec: /usr/local/sbin/vpn-linkup ng2 inet 172.16.99.1 172.16.99.97 USERXXX
Jan 30 10:21:44 mpd: [pt1] exec: command returned 256
Jan 30 10:21:44 mpd: [pt1] exec: /sbin/route add 172.16.99.1 -iface lo0
Jan 30 10:21:44 mpd: [pt1] no interface to proxy arp on for 172.16.99.97
Jan 30 10:21:44 mpd: [pt1] exec: /sbin/ifconfig ng2 172.16.99.1 172.16.99.97 netmask 0xffffffff -link0
Jan 30 10:21:44 mpd: [pt1] setting interface ng2 MTU to 1396 bytes
Jan 30 10:21:44 mpd: [pt1] IFACE: Up event
Jan 30 10:21:44 mpd: 172.16.99.1 -> 172.16.99.97
Jan 30 10:21:44 mpd: [pt1] IPCP: LayerUp
Jan 30 10:21:44 mpd: [pt1] IPCP: state change Ack-Sent –> Opened
Jan 30 10:21:44 mpd: IPADDR 172.16.99.1
Jan 30 10:21:44 mpd: [pt1] IPCP: rec'd Configure Ack #13 link 0 (Ack-Sent)
Jan 30 10:21:44 mpd: [pt1] IPCP: state change Req-Sent –> Ack-Sent
Jan 30 10:21:44 mpd: IPADDR 172.16.99.97
Jan 30 10:21:44 mpd: [pt1] IPCP: SendConfigAck #7
Jan 30 10:21:44 mpd: 172.16.99.97 is OK
Jan 30 10:21:44 mpd: IPADDR 172.16.99.97
Jan 30 10:21:44 mpd: [pt1] IPCP: rec'd Configure Request #7 link 0 (Req-Sent)
Jan 30 10:21:44 mpd: [pt1] setting interface ng2 MTU to 1396 bytes
Jan 30 10:21:44 mpd: Decompress using: MPPE, 128 bit, stateless
Jan 30 10:21:44 mpd: Compress using: MPPE, 128 bit, stateless
Jan 30 10:21:44 mpd: [pt1] CCP: LayerUp
Jan 30 10:21:44 mpd: [pt1] CCP: state change Ack-Rcvd –> Opened
Jan 30 10:21:44 mpd: 0x01000040: MPPE, 128 bit, stateless
Jan 30 10:21:44 mpd: MPPC
Jan 30 10:21:44 mpd: [pt1] CCP: SendConfigAck #6
Jan 30 10:21:44 mpd: [pt1] CCP: Checking whether 128 bits are acceptable -> yes
Jan 30 10:21:44 mpd: 0x01000040: MPPE, 128 bit, statelessThanks.
-
Don't know if this help but here it is another log from today.
Don't know if is coincidence but the same vpn user is present in logs trying to connect when this appens:
php: : Hotplug event detected for vr0 but ignoring since interface is not set for DHCP
Jan 31 14:30:26 php: : Hotplug event detected for vr0 but ignoring since interface is not set for DHCP
Jan 31 14:30:26 check_reload_status: rc.linkup starting
Jan 31 14:30:24 kernel: vr0: link state changed to UP
Jan 31 14:30:22 kernel: vr0: link state changed to DOWN
Jan 31 14:30:11 php: : Hotplug event detected for vr0 but ignoring since interface is not set for DHCP
Jan 31 14:30:11 check_reload_status: rc.linkup starting
Jan 31 14:30:10 kernel: vr0: link state changed to UP
Jan 31 14:30:06 php: : Hotplug event detected for vr0 but ignoring since interface is not set for DHCP
Jan 31 14:30:06 php: : Hotplug event detected for vr0 but ignoring since interface is not set for DHCP
Jan 31 14:30:05 check_reload_status: rc.linkup starting
Jan 31 14:30:03 kernel: vr0: link state changed to DOWN
Jan 31 14:30:01 kernel: vr0: link state changed to UP
Jan 31 14:30:00 php: : Hotplug event detected for vr0 but ignoring since interface is not set for DHCP
Jan 31 14:30:00 check_reload_status: rc.linkup starting
Jan 31 14:29:56 kernel: vr0: link state changed to DOWN
Jan 31 14:07:54 mpd: pptp0: killing connection with XXX.XXX.XXX.XXX:4160
Jan 31 14:07:54 mpd: [pt0] device is now in state DOWN
Jan 31 14:07:54 mpd: [pt0] device: CLOSE event in state DOWN
Jan 31 14:07:54 mpd: [pt0] LCP: LayerFinish
Jan 31 14:07:54 mpd: [pt0] LCP: state change Starting –> Initial
Jan 31 14:07:54 mpd: [pt0] LCP: Close event
Jan 31 14:07:54 mpd: [pt0] link: CLOSE event
Jan 31 14:07:54 mpd: [pt0] device is now in state DOWN
Jan 31 14:07:54 mpd: [pt0] pausing 9 seconds before open
Jan 31 14:07:54 mpd: [pt0] device: OPEN event in state DOWN
Jan 31 14:07:54 mpd: [pt0] closing link "pt0"…
Jan 31 14:07:54 mpd: [pt0] bundle: CLOSE event in state OPENED
Jan 31 14:07:54 mpd: [pt0] LCP: LayerDown
Jan 31 14:07:54 mpd: [pt0] CCP: LayerFinish
Jan 31 14:07:54 mpd: [pt0] CCP: state change Starting –> Initial
Jan 31 14:07:54 mpd: [pt0] CCP: Close event
Jan 31 14:07:54 mpd: [pt0] CCP: LayerDown
Jan 31 14:07:54 mpd: [pt0] CCP: state change Opened –> Starting
Jan 31 14:07:54 mpd: [pt0] CCP: Down event
Jan 31 14:07:54 mpd: [pt0] IPCP: state change Closing –> Initial
Jan 31 14:07:54 mpd: [pt0] IPCP: LayerFinish
Jan 31 14:07:54 mpd: [pt0] IPCP: Down event
Jan 31 14:07:54 mpd: [pt0] RADIUS: Down Event
Jan 31 14:07:54 mpd: [pt0] up: 0 links, total bandwidth 9600 bps
Jan 31 14:07:54 mpd: [pt0] setting interface ng1 MTU to 1500 bytes
Jan 31 14:07:54 mpd: [pt0] RADIUS: RadiusSendRequest: RAD_ACCOUNTING_RESPONSE for user userXXX
Jan 31 14:07:54 mpd: [pt0] RADIUS: RadiusAccount: Sending accounting data (Type: 2)
Jan 31 14:07:54 mpd: [pt0] RADIUS: Termination cause: , RADIUS: 10
Jan 31 14:07:54 mpd: [pt0] RADIUS: RadiusAddServer Adding 192.168.99.1
Jan 31 14:07:54 mpd: [pt0] RADIUS: RadiusAccount for: userXXX
Jan 31 14:07:54 mpd: [pt0] LCP: phase shift NETWORK –> DEAD
Jan 31 14:07:54 mpd: [pt0] LCP: state change Opened –> Starting
Jan 31 14:07:54 mpd: [pt0] LCP: Down event
Jan 31 14:07:54 mpd: [pt0] link: DOWN event -
Hi again.
There is another log but the symptom seems the same: the interface vr0 that is connected to a router goes down then it can't goe up again:
php: : Hotplug event detected for vr0 but ignoring since interface is not set for DHCP
Feb 2 11:09:46 check_reload_status: rc.linkup starting
Feb 2 11:09:41 kernel: vr0: link state changed to UP
Feb 2 11:09:41 php: : Hotplug event detected for vr0 but ignoring since interface is not set for DHCP
Feb 2 11:09:41 check_reload_status: rc.linkup starting
Feb 2 11:09:39 kernel: vr0: link state changed to DOWN
Feb 2 11:09:31 php: : Hotplug event detected for vr0 but ignoring since interface is not set for DHCP
Feb 2 11:09:30 check_reload_status: rc.linkup starting
Feb 2 11:09:27 kernel: vr0: link state changed to UP
Feb 2 11:09:20 php: : Hotplug event detected for vr0 but ignoring since interface is not set for DHCP
Feb 2 11:09:20 php: : Hotplug event detected for vr0 but ignoring since interface is not set for DHCP
Feb 2 11:09:20 check_reload_status: rc.linkup starting
Feb 2 11:09:19 kernel: vr0: link state changed to DOWN
Feb 2 11:09:18 kernel: vr0: link state changed to UP
Feb 2 11:09:15 php: : Hotplug event detected for vr0 but ignoring since interface is not set for DHCP
Feb 2 11:09:15 check_reload_status: rc.linkup starting
Feb 2 11:09:13 kernel: vr0: link state changed to DOWN
Feb 2 10:51:31 mpd: pptp0: killing connection with 87.103.50.134:2118
Feb 2 10:51:31 mpd: [pt0] LCP: Down event
Feb 2 10:51:31 mpd: [pt0] link: DOWN event
Feb 2 10:51:31 mpd: [pt0] LCP: phase shift ESTABLISH –> DEAD
Feb 2 10:51:31 mpd: [pt0] LCP: state change Closed –> Initial
Feb 2 10:51:31 mpd: [pt0] LCP: Down event
Feb 2 10:51:31 mpd: [pt0] link: DOWN event
Feb 2 10:51:31 mpd: [pt0] device is now in state DOWN
Feb 2 10:51:31 mpd: [pt0] device: DOWN event in state DOWN
Feb 2 10:51:31 mpd: [pt0] LCP: state change Stopped –> Closed
Feb 2 10:51:31 mpd: [pt0] LCP: Close event
Feb 2 10:51:31 mpd: [pt0] link: CLOSE event
Feb 2 10:51:31 mpd: [pt0] device is now in state DOWN
Feb 2 10:51:31 mpd: [pt0] device: DOWN event in state CLOSING
Feb 2 10:51:31 mpd: [pt0] closing link "pt0"…
Feb 2 10:51:31 mpd: [pt0] bundle: CLOSE event in state OPENED
Feb 2 10:51:31 mpd: [pt0] device is now in state CLOSING
Feb 2 10:51:31 mpd: [pt0] IFACE: Close event
Feb 2 10:51:31 mpd: pptp0: closing connection with 87.103.50.134:2118
Feb 2 10:51:31 mpd: [pt0] IFACE: Close event
Feb 2 10:51:31 mpd: [pt0] IPCP: LayerFinish
Feb 2 10:51:31 mpd: [pt0] IPCP: state change Starting –> Initial
Feb 2 10:51:31 mpd: [pt0] IPCP: Close event
Feb 2 10:51:31 mpd: [pt0] IFACE: Close event
Feb 2 10:51:31 mpd: [pt0] PPTP call terminated
Feb 2 10:51:31 mpd: pptp0-0: killing channel
Feb 2 10:51:31 mpd: pptp0-0: clearing call
Feb 2 10:51:31 mpd: [pt0] device: CLOSE event in state UP
Feb 2 10:51:31 mpd: [pt0] LCP: LayerFinish
Feb 2 10:51:31 mpd: [pt0] LCP: phase shift TERMINATE –> ESTABLISH
Feb 2 10:51:31 mpd: [pt0] LCP: state change Stopping –> Stopped
Feb 2 10:51:31 mpd: [pt0] LCP: SendTerminateAck #138
Feb 2 10:51:31 mpd: [pt0] LCP: rec'd Terminate Request #10 link 0 (Stopping) -
Is that interface marked for DHCP? It thinks that it is not.
-
No, it's not.
No dhcp in vr0.
The dhcp on router is deactivated too.Thanks in advance.
-
Then I am confused… What is vr0?
-
The vr0 is the network interface of the firewall of our second link to workstations. It is connected to a router.
-
The vr0 is the network interface of the firewall of our second link to workstations. It is connected to a router.
This makes the situation even more puzzling. Why would it think that you are unplugging or plugging in vr0?!
-
Check your gmail account freax … I am working on this issue now and need your help. I cannot guarantee when I'll have time or interest to work on it again so right now is your chance to get it solved!
-
Please test the latest snapshot if you are still having problems and post the logs. I have added some debugging information.
-
im using snapshot 02-02 and it still dosn´t work:
Feb 3 00:46:20 dhclient[275]: exiting.
Feb 3 00:46:20 dhclient[275]: exiting.
Feb 3 00:46:20 dhclient[275]: short write: wanted 21 got 0 bytes
Feb 3 00:46:20 dhclient[275]: short write: wanted 21 got 0 bytes
Feb 3 00:46:20 dhclient[275]: DHCPACK from 90.224.168.1
Feb 3 00:46:20 dhclient[275]: DHCPREQUEST on rl0 to 255.255.255.255 port 67 -
Hi again.
I'm at 180 km from the firewall so I will test it monday.
Thanks.
-
I've been experiencing this problem lately and it still has not been resolved for myself either.
ISP: ZoomInternet
I'm not sure my exact snapshot, but it was most recently updated on Jan29.
Any info that I can provide to help get this resolved I am more than willing to give.
-
I've been experiencing this problem lately and it still has not been resolved for myself either.
ISP: ZoomInternet
I'm not sure my exact snapshot, but it was most recently updated on Jan29.
Any info that I can provide to help get this resolved I am more than willing to give.
Please update to a recent snapshot like I asked everyone else to do.
-
Anyone have an update? Or is the problem finally fixed with recent snapshots?
-
do you mean snapshot 02-02 ?? if you do, the problem is not fixed =(
still ending up with "short write: wanted 21 got 0 bytes" -
Yes, the updated snapshot as of a day or so.
Please provide the entire log file.. As much detail as possible. You can X out IP addresses but I need to see the chain of events from before and after this happens.
Also, for the record, who uses PPPOE and who has just a regular DHCP WAN?
-
I've updated but still now it didn't stop. Maybe I can turn off then on the router.
I have 2 links:
- fxp0 that is our pppoe wan that is used for servers and DMZ;
- vr0 which is in opt1 that serves our worksations; This is connected to a router trought a diffrent ip.
I think I had 2 different problems:
- pppoe (fxp0) went down from time to time and I think it was solved with some latest update. This was the worst because sometimes we dind't have vpn at weekends. I think it's solved.
- now I still have the last problem which the workstations don't have internet with some dhcp problem. There isn't dhcp activated neither on router or firewall.
[]'s
Yes, the updated snapshot as of a day or so.
Please provide the entire log file.. As much detail as possible. You can X out IP addresses but I need to see the chain of events from before and after this happens.
Also, for the record, who uses PPPOE and who has just a regular DHCP WAN?
-
I have made some more changes for debugging. Please test todays snapshot.
Thanks!
-
Confirm me that its the pfSense-Full-Update-1.0.1-SNAPSHOT-02-02-2007.tgz dated from today please.
-
No, todays date is the 6th. Images are still building. Check back in an hour.
-
It's from http://snapshots.pfsense.com/FreeBSD6/RELENG_1/updates/ ? Right ?
There isn't any from today. -
It's there now. Thanks.
-
http://snapshots.pfsense.com/FreeBSD6/RELENG_1/updates/pfSense-Full-Update-1.0.1-SNAPSHOT-02-06-2007.tgz