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

    WAN interface keeps dropping after upgrade to 1.2.1

    Scheduled Pinned Locked Moved General pfSense Questions
    43 Posts 6 Posters 21.5k Views
    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.
    • C
      CoccoBill
      last edited by

      Currently seems to be 298 Ierrs out of 12635041 Ipkts since the last reboot (so this period doesn't include dhcp problems), this sounds a bit high?

      Update: Had another connection drop, no additional Ierrs and nothing in the logs.

      1 Reply Last reply Reply Quote 0
      • W
        wallabybob
        last edited by

        I presume your first hop from the pfsense box to the ISP is to a modem of some sort. If so, your error count is probably OK.

        Suggestion: Next time pfSense attempts to renew its DHCP lease make sure there is no other traffic on the WAN link no FTPs, no web browsing etc. Then do a

        tcpdump -i fxp0

        for as long as it takes to see a few DHCP renewal requests go to the ISP. This will show ALL traffic on that hop. You're looking to see if there is any response at all. Check the interface counters before and after to see if there were any received packets or any errors. Perhaps you are getting a DHCP response that is not accepted by dhclient but is accepted by some other systems (e.g. Windows). If you see a consistent response try again with the command

        tcpdump -p -i fxp0

        Do you see a different pattern?

        If you can, capture the traces and post them here.

        1 Reply Last reply Reply Quote 0
        • C
          CoccoBill
          last edited by

          Ok I'll try to do a trace of all the trafiic. And no modems involved, just direct ethernet connection (fibre-optic).

          1 Reply Last reply Reply Quote 0
          • W
            wallabybob
            last edited by

            My gut feel, based on reported characteristics of fibre links, is that about 300 errors in about 12,000,000 packets is a "high" error rate. I doubt your system has been up long enough for the packet counter to wrap :-)

            1 Reply Last reply Reply Quote 0
            • C
              CoccoBill
              last edited by

              Ok I did the trace and still no response. After that I downgraded to 1.2 and now for the first time in a week the connection has been up for 16 hours straight, the renewals work again. I would say there's something funny with 1.2.1 and my setup, but unfortunately I don't have the time nor energy to look into it further at the moment.

              Thanks for your help!

              1 Reply Last reply Reply Quote 0
              • R
                rigius
                last edited by

                Apparently I'm having the same problem after upgrading from 1.2.RELEASE to 1.2.2.

                The affected interface is rl1 (WAN2), which gets its external IP address from a Zyxel P-660R-D1 working in half-bridge mode.

                Here is the relevant log:

                
Jan 15 14:40:02 	dhclient[307]: SENDING DIRECT
Jan 15 14:40:02 	dhclient[307]: DHCPREQUEST on rl1 to 192.168.1.1 port 67
Jan 15 14:39:33 	dhclient[307]: SENDING DIRECT
Jan 15 14:39:33 	dhclient[307]: DHCPREQUEST on rl1 to 192.168.1.1 port 67
Jan 15 14:39:20 	dhclient[307]: SENDING DIRECT
Jan 15 14:39:20 	dhclient[307]: DHCPREQUEST on rl1 to 192.168.1.1 port 67
Jan 15 14:39:12 	dhclient[307]: SENDING DIRECT
Jan 15 14:39:12 	dhclient[307]: DHCPREQUEST on rl1 to 192.168.1.1 port 67
Jan 15 14:39:04 	dhclient[307]: SENDING DIRECT
Jan 15 14:39:04 	dhclient[307]: DHCPREQUEST on rl1 to 192.168.1.1 port 67
Jan 15 14:39:01 	dhclient[307]: SENDING DIRECT
Jan 15 14:39:01 	dhclient[307]: DHCPREQUEST on rl1 to 192.168.1.1 port 67
Jan 15 14:38:58 	dhclient[307]: SENDING DIRECT
Jan 15 14:38:58 	dhclient[307]: DHCPREQUEST on rl1 to 192.168.1.1 port 67
Jan 15 14:38:56 	dhclient[307]: SENDING DIRECT
Jan 15 14:38:56 	dhclient[307]: DHCPREQUEST on rl1 to 192.168.1.1 port 67
Jan 15 14:11:12 	dnsmasq[848]: reading /var/dhcpd/var/db/dhcpd.leases
Jan 15 14:08:56 	dhclient[307]: bound to [EXTERNAL_IPADDRESS] -- renewal in 1800 seconds.
Jan 15 14:08:56 	dhclient[307]: DHCPACK from 192.168.1.1
Jan 15 14:08:56 	dhclient[307]: DHCPREQUEST on rl1 to 255.255.255.255 port 67
Jan 15 14:08:16 	dnsmasq[848]: reading /var/dhcpd/var/db/dhcpd.leases
Jan 15 14:05:58 	dnsmasq[848]: reading /var/dhcpd/var/db/dhcpd.leases
Jan 15 14:03:57 	dnsmasq[848]: reading /var/dhcpd/var/db/dhcpd.leases
Jan 15 14:02:06 	dnsmasq[848]: reading /var/dhcpd/var/db/dhcpd.leases
Jan 15 14:01:11 	dhclient[307]: SENDING DIRECT
Jan 15 14:01:11 	dhclient[307]: DHCPREQUEST on rl1 to 192.168.1.1 port 67
Jan 15 13:59:33 	dnsmasq[848]: reading /var/dhcpd/var/db/dhcpd.leases
Jan 15 13:57:37 	dhclient[307]: SENDING DIRECT
Jan 15 13:57:37 	dhclient[307]: DHCPREQUEST on rl1 to 192.168.1.1 port 67
Jan 15 13:56:13 	dnsmasq[848]: reading /var/dhcpd/var/db/dhcpd.leases
Jan 15 13:53:07 	dhclient[307]: SENDING DIRECT
Jan 15 13:53:07 	dhclient[307]: DHCPREQUEST on rl1 to 192.168.1.1 port 67
Jan 15 13:51:14 	dhclient[307]: SENDING DIRECT
[...]
                1 Reply Last reply Reply Quote 0
                • C
                  CoccoBill
                  last edited by

                  Looks familiar, is it fixed with a reboot and starts again when your dhcp lease expires? Which network card does the interface have?

                  1 Reply Last reply Reply Quote 0
                  • R
                    rigius
                    last edited by

                    The firewall is a Linitx FX5620 (Fabiatech) with one GB RTL8110S network card and five RTL8100C. It used to appear on the pfsense recommended hardware list. I'm having the problem on one of the RTL8100C ports.

                    The connection has been cut only four or five times since the upgrade. It may take place when the dhcp lease expires, but not every time. It seems to restablish itself after some time (not yet sure of how much time neither). And yes, a reboot "fixes" temporarily the problem.

                    After rebooting the ADSL router and the pfsense box, the connection has been stable for the last 20 hours or so. Here goes a commented log:

                    
[...]
Jan 16 06:49:29 pfsense dhclient[307]: DHCPREQUEST on rl1 to 255.255.255.255 port 67
Jan 16 06:49:29 pfsense dhclient[307]: DHCPACK from 192.168.1.1
Jan 16 06:49:29 pfsense dhclient[307]: bound to EXTERNAL_IPADDRESS -- renewal in 1800 seconds.  #(gets address)
Jan 16 07:19:29 pfsense dhclient[307]: DHCPREQUEST on rl1 to 192.168.1.1 port 67                            #(at the end of the lease, asks for renewal)
Jan 16 07:19:29 pfsense dhclient[307]: SENDING DIRECT
Jan 16 07:19:30 pfsense dhclient[307]: DHCPREQUEST on rl1 to 192.168.1.1 port 67                            #(it doesn't get it and keeps asking)
Jan 16 07:19:30 pfsense dhclient[307]: SENDING DIRECT
Jan 16 07:19:32 pfsense dhclient[307]: DHCPREQUEST on rl1 to 192.168.1.1 port 67
Jan 16 07:19:32 pfsense dhclient[307]: SENDING DIRECT
Jan 16 07:19:34 pfsense dhclient[307]: DHCPREQUEST on rl1 to 192.168.1.1 port 67
Jan 16 07:19:34 pfsense dhclient[307]: SENDING DIRECT
Jan 16 07:19:36 pfsense dhclient[307]: DHCPREQUEST on rl1 to 192.168.1.1 port 67
[...]
Jan 16 07:47:43 pfsense dhclient[307]: DHCPREQUEST on rl1 to 255.255.255.255 port 67
Jan 16 07:47:43 pfsense dhclient[307]: DHCPACK from 192.168.1.1
Jan 16 07:47:43 pfsense dhclient[307]: bound to EXTERNAL_IPADDRESS -- renewal in 1800 seconds.  #(finally it gets a new lease, after about 24 minutes)
Jan 16 08:17:43 pfsense dhclient[307]: DHCPREQUEST on rl1 to 192.168.1.1 port 67                            #(and the cycle starts again)
Jan 16 08:17:43 pfsense dhclient[307]: SENDING DIRECT
Jan 16 08:17:45 pfsense dhclient[307]: DHCPREQUEST on rl1 to 192.168.1.1 port 67
Jan 16 08:17:45 pfsense dhclient[307]: SENDING DIRECT
[...]

                    Could the DHCP renewal problem be provoked by the fact that dhclient is sending the renewal requests directly to the address of the DHCP server instead of the broadcast address? Is there a way to ask dhclient to avoid sending "direct" renewal requests?

                    1 Reply Last reply Reply Quote 0
                    • R
                      rigius
                      last edited by

                      The OPT1 (rl1) connection is falling more or less once every day and now I'm also getting this messages:

                      
Jan 20 12:38:45 	kernel: arpresolve: can't allocate route for OPT1_EXTERNAL_IPADDRESS
Jan 20 12:38:45 	kernel: arplookup OPT1_EXTERNAL_IPADDRESS failed: host is not on local network

                      They seem to be related to the load balancing monitor IP address of the OPT1 interface (wich, to make a long story short, is OPT1_EXTERNAL_IPADDRESS).

                      I'm beginning to get into trouble at work, so I think that I will have to downgrade to 1.2 very soon. Has anyone done a successful downgrade from 1.2.2 to 1.2 with the firmware update option?

                      1 Reply Last reply Reply Quote 0
                      • W
                        wallabybob
                        last edited by

                        Could the DHCP renewal problem be provoked by the fact that dhclient is sending the renewal requests directly to the address of the DHCP server instead of the broadcast address?

                        That's the way it is supposed to work: when you ask for lease renewal you ask the party that granted the lease.

                        Is there a way to ask dhclient to avoid sending "direct" renewal requests?

                        I suggest you lookup the FreeBSD man pages: go to http://www.freebsd.org/cgi/man.cgi and type dhclient in the Man page or Keyword Search box and click Submit.

                        1 Reply Last reply Reply Quote 0
                        • R
                          rigius
                          last edited by

                          @wallabybob:

                          Could the DHCP renewal problem be provoked by the fact that dhclient is sending the renewal requests directly to the address of the DHCP server instead of the broadcast address?

                          That's the way it is supposed to work: when you ask for lease renewal you ask the party that granted the lease.

                          Yes. You are right. After looking more carefully at the logs, I have found that:

                          -DHCLIENT is not able to get its lease extended at renewal time.

                          -DHCLIENT is getting its lease extended at rebinding time.

                          So everything seems normal.

                          Is there a way to ask dhclient to avoid sending "direct" renewal requests?

                          I suggest you lookup the FreeBSD man pages: go to http://www.freebsd.org/cgi/man.cgi and type dhclient in the Man page or Keyword Search box and click Submit.

                          This page has also helped me understand the process: http://www.tcpipguide.com/free/t_DHCPLeaseRenewalandRebindingProcesses.htm

                          But I'm still getting this connection drops every day or so…

                          1 Reply Last reply Reply Quote 0
                          • W
                            wallabybob
                            last edited by

                            So everything seems normal.

                            Except that the lease extension requests are apparently ignored.

                            Are the lease extension requests getting out on the wire? (May be hard to test without specialised equipment.)

                            If so, why aren't they provoking a response? (Your ISP will probably have to help with than one.)

                            Are there any link status change reports on rl1 at these times? (Does pulling out the rl1 cable generate a link status change on rl1 report?)

                            1 Reply Last reply Reply Quote 0
                            • R
                              rigius
                              last edited by

                              @wallabybob:

                              So everything seems normal.

                              Except that the lease extension requests are apparently ignored.

                              Yes.

                              Are the lease extension requests getting out on the wire? (May be hard to test without specialised equipment.)

                              I don't know. I will try to get an answer.

                              If so, why aren't they provoking a response? (Your ISP will probably have to help with than one.)

                              We own the modem (Zyxel P660R-D1 in half bridge mode), so the ISP won't help. I will send the question to Zyxel.

                              Are there any link status change reports on rl1 at these times?

                              I don't know. I'm waiting for the next connection drop.

                              (Does pulling out the rl1 cable generate a link status change on rl1 report?)

                              Yes.

                              1 Reply Last reply Reply Quote 0
                              • R
                                rigius
                                last edited by

                                @rigius:

                                Are there any link status change reports on rl1 at these times?

                                I don't know. I'm waiting for the next connection drop.

                                Ok. I have just had another connection drop. This is interesting:

                                Here are the last four DHCP leases. There is something "bizarre" ont the last one: the renew time seems to be wrong. Taking into account the previous leases, it should be around 52,5 (rebinding time) minutes from the previous one but instead of that, it's exactly one hour later (lease time):

                                
#cat /var/db/dhclient.leases.rl1
[...]
lease {
  interface "rl1";
  fixed-address rl1_EXTERNAL_IP;
  option subnet-mask 255.255.255.0;
  option routers rl1_EXTERNAL_IP;
  option domain-name-servers 80.10.246.130,81.253.149.10;
  option host-name "dhcppc0";
  option dhcp-lease-time 3600;
  option dhcp-message-type 5;
  option dhcp-server-identifier 192.168.1.1;
  option dhcp-renewal-time 1800;
  option dhcp-rebinding-time 3150;
  renew 3 2009/1/21 11:58:06;
  rebind 3 2009/1/21 12:20:36;
  expire 3 2009/1/21 12:28:06;
}
lease {
  interface "rl1";
  fixed-address rl1_EXTERNAL_IP;
  option subnet-mask 255.255.255.0;
  option routers rl1_EXTERNAL_IP;
  option domain-name-servers 80.10.246.130,81.253.149.10;
  option host-name "dhcppc0";
  option dhcp-lease-time 3600;
  option dhcp-message-type 5;
  option dhcp-server-identifier 192.168.1.1;
  option dhcp-renewal-time 1800;
  option dhcp-rebinding-time 3150;
  renew 3 2009/1/21 12:52:31;
  rebind 3 2009/1/21 13:15:01;
  expire 3 2009/1/21 13:22:31;
}
lease {
  interface "rl1";
  fixed-address rl1_EXTERNAL_IP;
  option subnet-mask 255.255.255.0;
  option routers rl1_EXTERNAL_IP;
  option domain-name-servers 80.10.246.130,81.253.149.10;
  option host-name "dhcppc0";
  option dhcp-lease-time 3600;
  option dhcp-message-type 5;
  option dhcp-server-identifier 192.168.1.1;
  option dhcp-renewal-time 1800;
  option dhcp-rebinding-time 3150;
  renew 3 2009/1/21 13:47:14;
  rebind 3 2009/1/21 14:09:44;
  expire 3 2009/1/21 14:17:14;
}
lease {
  interface "rl1";
  fixed-address rl1_EXTERNAL_IP;
  option subnet-mask 255.255.255.0;
  option routers rl1_EXTERNAL_IP;
  option domain-name-servers 80.10.246.130,81.253.149.10;
  option host-name "dhcppc0";
  option dhcp-lease-time 3600;
  option dhcp-message-type 5;
  option dhcp-server-identifier 192.168.1.1;
  option dhcp-renewal-time 1800;
  option dhcp-rebinding-time 3150;
  renew 3 2009/1/21 14:47:23;
  rebind 3 2009/1/21 15:09:53;
  expire 3 2009/1/21 15:17:23;
}

                                And this is what shows the system log (arplookup problem at 15:17:15, the end of the last DHCP lease):

                                
$ cat /var/log/system.log
[...]
Jan 21 14:17:14 pfsense dhclient[308]: DHCPREQUEST on rl1 to 255.255.255.255 port 67
Jan 21 14:17:14 pfsense dhclient[308]: DHCPACK from 192.168.1.1
Jan 21 14:17:14 pfsense dhclient[308]: bound to rl1_EXTERNAL_IP -- renewal in 1800 seconds.
Jan 21 14:47:14 pfsense dhclient[308]: DHCPREQUEST on rl1 to 192.168.1.1 port 67
Jan 21 14:47:14 pfsense dhclient[308]: SENDING DIRECT
Jan 21 14:47:15 pfsense dhclient[308]: DHCPREQUEST on rl1 to 192.168.1.1 port 67
Jan 21 14:47:15 pfsense dhclient[308]: SENDING DIRECT
[...]
Jan 21 15:09:28 pfsense dhclient[308]: DHCPREQUEST on rl1 to 192.168.1.1 port 67
Jan 21 15:09:28 pfsense dhclient[308]: SENDING DIRECT
Jan 21 15:14:40 pfsense dnsmasq[834]: reading /var/dhcpd/var/db/dhcpd.leases
Jan 21 15:17:15 pfsense kernel: arplookup rl1_EXTERNAL_IP failed: host is not on local network
Jan 21 15:17:15 pfsense kernel: arpresolve: can't allocate route for rl1_EXTERNAL_IP
Jan 21 15:17:15 pfsense dhclient[308]: DHCPDISCOVER on rl1 to 255.255.255.255 port 67 interval 2
Jan 21 15:17:17 pfsense dhclient[308]: DHCPDISCOVER on rl1 to 255.255.255.255 port 67 interval 4
Jan 21 15:17:19 pfsense kernel: arplookup rl1_EXTERNAL_IP failed: host is not on local network
Jan 21 15:17:19 pfsense kernel: arpresolve: can't allocate route for rl1_EXTERNAL_IP
Jan 21 15:17:20 pfsense kernel: arplookup rl1_EXTERNAL_IP failed: host is not on local network
Jan 21 15:17:20 pfsense kernel: arpresolve: can't allocate route for rl1_EXTERNAL_IP
Jan 21 15:17:21 pfsense dhclient[308]: DHCPDISCOVER on rl1 to 255.255.255.255 port 67 interval 5
Jan 21 15:17:21 pfsense dhclient[308]: DHCPOFFER from 192.168.1.1
Jan 21 15:17:21 pfsense kernel: arplookup rl1_EXTERNAL_IP failed: host is not on local network
Jan 21 15:17:21 pfsense kernel: arpresolve: can't allocate route for rl1_EXTERNAL_IP
Jan 21 15:17:21 pfsense kernel: arplookup rl1_EXTERNAL_IP failed: host is not on local network
Jan 21 15:17:21 pfsense kernel: arpresolve: can't allocate route for rl1_EXTERNAL_IP
Jan 21 15:17:23 pfsense dhclient[308]: DHCPREQUEST on rl1 to 255.255.255.255 port 67
Jan 21 15:17:23 pfsense dhclient[308]: DHCPACK from 192.168.1.1
Jan 21 15:17:23 pfsense dhclient[308]: bound to rl1_EXTERNAL_IP -- renewal in 1800 seconds.
Jan 21 15:17:24 pfsense kernel: arplookup rl1_EXTERNAL_IP failed: host is not on local network
Jan 21 15:17:24 pfsense kernel: arpresolve: can't allocate route for rl1_EXTERNAL_IP
Jan 21 15:17:24 pfsense check_reload_status: rc.newwanip starting
Jan 21 15:17:25 pfsense kernel: arplookup rl1_EXTERNAL_IP failed: host is not on local network
Jan 21 15:17:25 pfsense kernel: arpresolve: can't allocate route for rl1_EXTERNAL_IP
Jan 21 15:17:25 pfsense kernel: arplookup rl1_EXTERNAL_IP failed: host is not on local network
Jan 21 15:17:25 pfsense kernel: arpresolve: can't allocate route for rl1_EXTERNAL_IP
Jan 21 15:17:25 pfsense php: : Informational: rc.newwanip is starting .
Jan 21 15:17:25 pfsense php: : rc.newwanip working with (IP address: HIDDEN_IP) (interface: wan) (interface real: rl0).
Jan 21 15:17:27 pfsense kernel: arplookup rl1_EXTERNAL_IP failed: host is not on local network
Jan 21 15:17:27 pfsense kernel: arpresolve: can't allocate route for rl1_EXTERNAL_IP
Jan 21 15:17:28 pfsense kernel: arplookup rl1_EXTERNAL_IP failed: host is not on local network
Jan 21 15:17:28 pfsense kernel: arpresolve: can't allocate route for rl1_EXTERNAL_IP
Jan 21 15:17:29 pfsense kernel: arplookup rl1_EXTERNAL_IP failed: host is not on local network
Jan 21 15:17:29 pfsense kernel: arpresolve: can't allocate route for rl1_EXTERNAL_IP
Jan 21 15:17:31 pfsense kernel: arplookup rl1_EXTERNAL_IP failed: host is not on local network
Jan 21 15:17:31 pfsense kernel: arpresolve: can't allocate route for rl1_EXTERNAL_IP
Jan 21 15:17:33 pfsense kernel: arplookup rl1_EXTERNAL_IP failed: host is not on local network
Jan 21 15:17:33 pfsense kernel: arpresolve: can't allocate route for rl1_EXTERNAL_IP
[...]

                                As usual, the connection on rl1 has been dropped and a reboot is needed to bring everything back to normal!

                                So I think that definitely, the problem has something to do with DHCP.

                                There's another interesting fact: once they have begun, the arplookup/arpresolve problems continue even after rl1 gets a new lease from the DHCP server.

                                …And today this has happened on the 30th address renewal from the last reboot.

                                Any ideas?

                                1 Reply Last reply Reply Quote 0
                                • W
                                  wallabybob
                                  last edited by

                                  The arplookup/arpresolve messages suggest to me that you have lost communication with rl1_EXTERNAL_IP which should be responding to the ARPs. Once that happens you won't get a DHCP response until (possibly) the DHCP broadcast which does not need a mapping from IP address to MAC address. Its strange though that you then apparently get a DHCP response but no ARP response.

                                  When this happens can you ssh into the pfSense box? Can you login on the console? (Perhaps there is a kernel memory leak and when DHCP fails in this way its because there is a little bit of free memory but not enough to always get the DHCP/ARP responses.) If you can login on the console or ssh in there is at least a chance of testing this theory. If you can't login then some cunning will be needed.

                                  If you can login while this is happening, type command

                                  netstat -i -I rl1

                                  a few times and watch what happens to the rl1 error counters.

                                  1 Reply Last reply Reply Quote 0
                                  • R
                                    rigius
                                    last edited by

                                    @wallabybob:

                                    So everything seems normal.

                                    Except that the lease extension requests are apparently ignored.

                                    Are the lease extension requests getting out on the wire? (May be hard to test without specialised equipment.)

                                    The lease extension requests are not getting out: I have connected the pfsense box, the Zyxel modem and a laptop to a small hub. Using Wireshark on the laptop, I have done some monitoring and I don't see the DHCPREQUEST packets from pfsense to the zyxel modem.

                                    1 Reply Last reply Reply Quote 0
                                    • W
                                      wallabybob
                                      last edited by

                                      I don't see the DHCPREQUEST packets from pfsense to the zyxel modem.

                                      That would explain why you don't see responses.

                                      This sounds like a hardware problem or a driver bug. Do you get the same behaviour on other ports?

                                      1 Reply Last reply Reply Quote 0
                                      • jahonixJ
                                        jahonix
                                        last edited by

                                        Do you have a free RTL8100C port on your machine?
                                        I'd suggest using that one (at least temporarily) to see if it's a hardware issue. Sounds pretty much like it.
                                        Using another CAT cable might help as well.

                                        1 Reply Last reply Reply Quote 0
                                        • R
                                          rigius
                                          last edited by

                                          @wallabybob:

                                          I don't see the DHCPREQUEST packets from pfsense to the zyxel modem.

                                          This sounds like a hardware problem or a driver bug. Do you get the same behaviour on other ports?

                                          I think the problem could come from the fact that our two WAN "modems" (on rl0 and rl1) have the same "internal" IP address (192.168.1.1).

                                          I cannot change it on our primary conection (the modem -WIMAX interface / PPPOE- is owned by the ISP and they won't do it) and for the moment I have not been able to change it on the Zyxel P660R neither (half-bridge PPPOA): After changing the internal IP of the P660R, it reverts to the default 192.168.1.1 when I turn half-bridge mode on, and if I turn on half-bridge first, it does the address change when I power cycle the modem!

                                          What puzzles me is that everything has worked fine with the 1.2 version of pfsense for almost a year :-?

                                          Could this be the origin of the problem?

                                          1 Reply Last reply Reply Quote 0
                                          • W
                                            wallabybob
                                            last edited by

                                            Yesterday my rl0 interface got into a state where it either wasn't sending or wasn't receiving. My WAN interface to a Zyxel ADSL modem/router uses rl0.

                                            This is suspiciously like your configuration.

                                            When it was in this state the activity light would flash regularly, seemingly in time with the ping but there was no ping response reported. I could login on the console and I could ssh in over the LAN interface (vr0). I was unable to reactivate rl0 by a ifconfig down/up sequence, nor by reassigning interfaces. There were no errors reported on rl0 EXCEPT over 2000 collisions which is an unexpected event on a full duplex link to a modem. I couldn't work out any other way of recovering than rebooting. The system has now been up over 21 hours with no errors and no collisions reported on rl0.

                                            Perhaps there is an rl driver bug or hardware error in dealing with an "unusual" situation.

                                            Are you sure your 10/100 interfaces are RTL8100C? I think the 8100C should be controlled by the re driver. I suspect that you have a number of 8139 ports.

                                            1 Reply Last reply Reply Quote 0
                                            • First post
                                              Last post
                                            Copyright 2025 Rubicon Communications LLC (Netgate). All rights reserved.