Project

General

Profile

Actions

Bug #8152

closed

No DHCP on WAN with cable modem

Added by Andras Gaal over 6 years ago. Updated over 6 years ago.

Status:
Not a Bug
Priority:
Normal
Assignee:
-
Category:
-
Target version:
-
Start date:
12/01/2017
Due date:
% Done:

0%

Estimated time:
Plus Target Version:
Release Notes:
Affected Version:
2.4.x
Affected Architecture:

Description

My cable modem (SagemCom FAST3686v2 - in bridge mode) when rebooting, first assigns an IP address in the 192.168.100.x range. Once boot is completed, it cycles the link on the WAN port (link goes down for ~5 secs) and a public IP can be picked up on the WAN interface.

Up until pfSense 2.4.3 I was able to get a public IP. Ever since updating to 2.4 I am not getting an IP after the link cycle (WAN shows 0.0.0.0). Same happens with a brand new, default install of 2.4 so I don't believe it's a config issue. This generates headaches when there's a modem restart (power outage or ISP initiated reboot), as pfSense will not pick up an IP and loose internet access.
Directly connecting a Windows computer to the modem shows the following process:
  1. reboot modem
  2. computer gets first 192.168.100.x IP
  3. boot is completed, WAN link is cycled
  4. computer picks up public IP
As a workaround I have discovered that if I prevent pfSense from picking up the 192.168.100.x IP, it will pickup the public IP:
  1. disconnect modem-pfsense WAN cable
  2. power cycle the modem
  3. wait till boot is completed
  4. reconnect cable
  5. pfSense gets the public IP

Discussion: https://forum.pfsense.org/index.php?topic=139693.0

DHCP client logs:

Nov 9 19:56:42    dhclient    21222    hn1 link state up -> down
Nov 9 19:56:46    dhclient    21222    DHCPREQUEST on hn1 to 192.168.100.1 port 67
Nov 9 19:56:47    dhclient    21222    DHCPREQUEST on hn1 to 192.168.100.1 port 67
Nov 9 19:56:47    dhclient    21222    hn1 link state down -> up
Nov 9 19:56:47    dhclient    21222    DHCPREQUEST on hn1 to 255.255.255.255 port 67
Nov 9 19:56:47    dhclient    21222    DHCPNAK from 10.229.0.1
Nov 9 19:56:47    dhclient    21222    DHCPDISCOVER on hn1 to 255.255.255.255 port 67 interval 1
Nov 9 19:56:47    dhclient    21222    DHCPOFFER from 10.229.0.1
Nov 9 19:56:47    dhclient        ARPSEND
Nov 9 19:56:49    dhclient        ARPCHECK
Nov 9 19:56:49    dhclient    21222    DHCPREQUEST on hn1 to 255.255.255.255 port 67
Nov 9 19:56:51    dhclient    21222    DHCPREQUEST on hn1 to 255.255.255.255 port 67
Nov 9 19:56:56    dhclient    21222    DHCPREQUEST on hn1 to 255.255.255.255 port 67
Nov 9 19:56:56    dhclient    84434    connection closed
Nov 9 19:56:56    dhclient    84434    exiting.
Nov 9 19:56:59    dhclient    60445    DHCPREQUEST on hn1 to 255.255.255.255 port 67
Nov 9 19:57:01    dhclient    60445    DHCPREQUEST on hn1 to 255.255.255.255 port 67
Nov 9 19:57:05    dhclient    60445    DHCPREQUEST on hn1 to 255.255.255.255 port 67
Nov 9 19:57:09    dhclient    60445    DHCPREQUEST on hn1 to 255.255.255.255 port 67
Nov 9 19:57:15    dhclient    60445    DHCPDISCOVER on hn1 to 255.255.255.255 port 67 interval 2
Nov 9 19:57:17    dhclient    60445    DHCPDISCOVER on hn1 to 255.255.255.255 port 67 interval 2
Nov 9 19:57:19    dhclient    60445    DHCPDISCOVER on hn1 to 255.255.255.255 port 67 interval 5
Nov 9 19:57:24    dhclient    60445    DHCPDISCOVER on hn1 to 255.255.255.255 port 67 interval 8
Nov 9 19:57:28    dhclient    61193    connection closed
Nov 9 19:57:28    dhclient    61193    exiting.
Actions #1

Updated by Jim Pingle over 6 years ago

  • Status changed from New to Not a Bug

I have a similar modem and it works fine here.

With modems that behave in that way you should go to Interfaces > WAN and set "Reject Leases From" to 192.168.100.1, then save/apply and try again.

Though mine still works without that, it's easier to have it reject. It's also possible something else in your environment is changing, since that appears to be virtualized, things like Hyper-V support in the base OS may change behavior that is unrelated to pfSense in some other way.

Continue to discuss this on the forum, however, it's too early to call any one particular aspect of this a bug without identifying more specifically what might be at work there in your specific environment.

Actions

Also available in: Atom PDF