WAN side DHCP problems



  • Starting with the 1/11 build of 2.4, I'm seeing the WAN interface fail with some DHCP errors in the gateway log:

    Jan 13 17:46:43 dpinger send_interval 500ms loss_interval 2000ms time_period 60000ms report_interval 0ms data_len 0 alert_interval 1000ms latency_alarm 500ms loss_alarm 20% dest_addr 97.87.56.1 bind_addr 97.87.56.29 identifier "WAN_DHCP "
    Jan 13 17:46:40 dpinger send_interval 500ms loss_interval 2000ms time_period 60000ms report_interval 0ms data_len 0 alert_interval 1000ms latency_alarm 500ms loss_alarm 20% dest_addr 97.87.56.1 bind_addr 97.87.56.29 identifier "WAN_DHCP "
    Jan 13 17:45:28 dpinger WAN_DHCP 97.87.56.1: sendto error: 65
    Jan 13 17:45:27 dpinger WAN_DHCP 97.87.56.1: sendto error: 65
    Jan 13 17:45:27 dpinger WAN_DHCP 97.87.56.1: sendto error: 65
    Jan 13 17:45:26 dpinger WAN_DHCP 97.87.56.1: sendto error: 65
    Jan 13 17:45:26 dpinger WAN_DHCP 97.87.56.1: sendto error: 65
    Jan 13 17:45:25 dpinger WAN_DHCP 97.87.56.1: sendto error: 65
    Jan 13 17:45:25 dpinger WAN_DHCP 97.87.56.1: sendto error: 65
    Jan 13 17:45:24 dpinger WAN_DHCP 97.87.56.1: sendto error: 65
    Jan 13 17:45:24 dpinger WAN_DHCP 97.87.56.1: sendto error: 65

    I'm currently running this release:

    Version 2.4.0-BETA (arm)
    built on Thu Jan 12 21:50:19 CST 2017
    FreeBSD 11.0-RELEASE-p6

    I can't tell if this is a problem with the SG-1000, the pfSense software or the cable modem.  Any thoughts on where to look next?



  • Just updated to today's release…

    2.4.0.b.20170113.1514

    We'll see if that makes a difference.



  • So it happened again overnight and I ran through some debugging steps.

    ebug Log
    14 Jan 2017
    No WAN IP

    1. Disconnect ethernet from FW, wait 1 minute, plug in again.  Still no
    WAN IP.

    2. Attempt to manually configure the WAN interface:

    Enter an option: 2

    Available interfaces:

    1 - WAN (cpsw0 - dhcp, dhcp6)
    2 - LAN (cpsw1 - static)

    Enter the number of the interface you wish to configure: 1

    Configure IPv4 address WAN interface via DHCP? (y/n) y

    Configure IPv6 address WAN interface via DHCP6? (y/n) y

    Do you want to revert to HTTP as the webConfigurator protocol? (y/n) n

    Please wait while the changes are saved to WAN…

    This didn't work either.

    3. Disconnect ethernet from FW, unplug cable modem, plug CM in, plug
    ethernet in.

    This worked.  So there's something happening between the SG-1000's WAN interface and the cable modem that puts the SG-1000 WAN interface into some kind of unrecoverable state vis a vis the CM ethernet.

    Next step will be to replace the ethernet cable between the SG-1000 and the CM because why the heck not.  :-)



  • You might want to check this: https://forum.pfsense.org/index.php?topic=123350.msg682769#msg682769
    What does the interface's error counter look like?



  • Here's what's in there now:

    [2.4.0-BETA][admin@pfSense.localdomain]/root: sysctl -a | grep cpswss.0.stats
    dev.cpswss.0.stats.GoodRxFrames: 2503184
    dev.cpswss.0.stats.BroadcastRxFrames: 72685
    dev.cpswss.0.stats.MulticastRxFrames: 192657
    dev.cpswss.0.stats.PauseRxFrames: 0
    dev.cpswss.0.stats.RxCrcErrors: 0
    dev.cpswss.0.stats.RxAlignErrors: 0
    dev.cpswss.0.stats.OversizeRxFrames: 0
    dev.cpswss.0.stats.RxJabbers: 0
    dev.cpswss.0.stats.ShortRxFrames: 0
    dev.cpswss.0.stats.RxFragments: 0
    dev.cpswss.0.stats.RxOctets: 1418691720
    dev.cpswss.0.stats.GoodTxFrames: 2258951
    dev.cpswss.0.stats.BroadcastTxFrames: 28808
    dev.cpswss.0.stats.MulticastTxFrames: 34129
    dev.cpswss.0.stats.PauseTxFrames: 0
    dev.cpswss.0.stats.DeferredTxFrames: 0
    dev.cpswss.0.stats.CollisionsTxFrames: 0
    dev.cpswss.0.stats.SingleCollisionTxFrames: 0
    dev.cpswss.0.stats.MultipleCollisionTxFrames: 0
    dev.cpswss.0.stats.ExcessiveCollisions: 0
    dev.cpswss.0.stats.LateCollisions: 0
    dev.cpswss.0.stats.TxUnderrun: 0
    dev.cpswss.0.stats.CarrierSenseErrors: 0
    dev.cpswss.0.stats.TxOctets: 1375106659
    dev.cpswss.0.stats.RxTx64OctetFrames: 279355
    dev.cpswss.0.stats.RxTx65to127OctetFrames: 1784092
    dev.cpswss.0.stats.RxTx128to255OctetFrames: 717179
    dev.cpswss.0.stats.RxTx256to511OctetFrames: 209088
    dev.cpswss.0.stats.RxTx512to1024OctetFrames: 168236
    dev.cpswss.0.stats.RxTx1024upOctetFrames: 1604212
    dev.cpswss.0.stats.NetOctets: 2793799289
    dev.cpswss.0.stats.RxStartOfFrameOverruns: 0
    dev.cpswss.0.stats.RxMiddleOfFrameOverruns: 0
    dev.cpswss.0.stats.RxDmaOverruns: 0

    I'll run it again if it fails.



  • The errors from this morning's failure were the same as the ones from yesterday.

    Jan 14 07:14:20 dpinger WAN_DHCP6 fe80::201:5cff:fe76:6046%cpsw0: Alarm latency 0us stddev 0us loss 100%
    Jan 14 07:14:17 dpinger send_interval 500ms loss_interval 2000ms time_period 60000ms report_interval 0ms data_len 0 alert_interval 1000ms latency_alarm 500ms loss_alarm 20% dest_addr fe80::201:5cff:fe76:6046%cpsw0 bind_addr fe80::6a9e:19ff:fe87:e800%cpsw0 identifier "WAN_DHCP6 "
    Jan 14 07:14:17 dpinger send_interval 500ms loss_interval 2000ms time_period 60000ms report_interval 0ms data_len 0 alert_interval 1000ms latency_alarm 500ms loss_alarm 20% dest_addr 96.42.26.1 bind_addr 96.42.26.125 identifier "WAN_DHCP "
    Jan 13 23:43:49 dpinger WAN_DHCP 97.87.56.1: sendto error: 65
    Jan 13 23:43:48 dpinger WAN_DHCP 97.87.56.1: sendto error: 65
    Jan 13 23:43:48 dpinger WAN_DHCP 97.87.56.1: sendto error: 65
    Jan 13 23:43:47 dpinger WAN_DHCP 97.87.56.1: sendto error: 65
    Jan 13 23:43:47 dpinger WAN_DHCP 97.87.56.1: sendto error: 65



  • As a Charter customer also, I can tell you its charter.  I have the same problem (error) and have to change the MAC ID on the WAN address when this happens. (Spend several hours on phone with charter, THEY WONT HELP.)  After changing the MAC ID a cycle to the cable modem and immediately get an IP.  Had this same issue with other brands of routers also.  Nearest I can tell from a anonymous Charter tech is that they are secretly denying an IP based on data load they don't like on your network.


Log in to reply