Netgate Discussion Forum
    • Categories
    • Recent
    • Tags
    • Popular
    • Users
    • Search
    • Register
    • Login

    WAN side DHCP problems

    Scheduled Pinned Locked Moved
    2.4 Development Snapshots
    3
    7
    2.2k
    Loading More Posts
    • Oldest to Newest
    • Newest to Oldest
    • Most Votes
    Reply
    • Reply as topic
    Log in to reply
    This topic has been deleted. Only users with topic management privileges can see it.
    • P
      Phil.Scarr
      last edited by

      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?

      1 Reply Last reply Reply Quote 0
      • P
        Phil.Scarr
        last edited by

        Just updated to today's release…

        2.4.0.b.20170113.1514

        We'll see if that makes a difference.

        1 Reply Last reply Reply Quote 0
        • P
          Phil.Scarr
          last edited by

          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.  :-)

          1 Reply Last reply Reply Quote 0
          • A
            athurdent
            last edited by

            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?

            1 Reply Last reply Reply Quote 0
            • P
              Phil.Scarr
              last edited by

              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.

              1 Reply Last reply Reply Quote 0
              • P
                Phil.Scarr
                last edited by

                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

                1 Reply Last reply Reply Quote 0
                • A
                  adam12
                  last edited by

                  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.

                  1 Reply Last reply Reply Quote 0
                  • First post
                    Last post