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

    No WAN DHCP Discover Request

    Scheduled Pinned Locked Moved 2.0-RC Snapshot Feedback and Problems - RETIRED
    16 Posts 5 Posters 6.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.
    • N
      NOYB
      last edited by

      See below the dhclient fail log entry.

      Also, why the duplicate/double webConfigurator login log entry?

      Last 50 system log entries
      Jan 16 12:26:53 kernel: atkbd0: [GIANT-LOCKED]
      Jan 16 12:26:53 kernel: atkbd0: [ITHREAD]
      Jan 16 12:26:53 kernel: psm0: <ps 2="" mouse="">irq 12 on atkbdc0
      Jan 16 12:26:53 kernel: psm0: [GIANT-LOCKED]
      Jan 16 12:26:53 kernel: psm0: [ITHREAD]
      Jan 16 12:26:53 kernel: psm0: model IntelliMouse, device ID 3
      Jan 16 12:26:53 kernel: uart0: <non-standard ns8250="" class="" uart="" with="" fifos="">port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0
      Jan 16 12:26:53 kernel: uart0: [FILTER]
      Jan 16 12:26:53 kernel: uart1: <non-standard ns8250="" class="" uart="" with="" fifos="">port 0x2f8-0x2ff irq 3 on acpi0
      Jan 16 12:26:53 kernel: uart1: [FILTER]
      Jan 16 12:26:53 kernel: fdc0: <floppy drive="" controller="" (fde)="">port 0x3f0-0x3f5,0x3f7 irq 6 drq 2 on acpi0
      Jan 16 12:26:53 kernel: fdc0: does not respond
      Jan 16 12:26:53 kernel: device_attach: fdc0 attach returned 6
      Jan 16 12:26:53 kernel: ppc0: <parallel port="">port 0x378-0x37f irq 7 on acpi0
      Jan 16 12:26:53 kernel: ppc0: Generic chipset (EPP/NIBBLE) in COMPATIBLE mode
      Jan 16 12:26:53 kernel: ppc0: [ITHREAD]
      Jan 16 12:26:53 kernel: ppbus0: <parallel port="" bus="">on ppc0
      Jan 16 12:26:53 kernel: plip0: <plip network="" interface="">on ppbus0
      Jan 16 12:26:53 kernel: plip0: [ITHREAD]
      Jan 16 12:26:53 kernel: lpt0: <printer>on ppbus0
      Jan 16 12:26:53 kernel: lpt0: [ITHREAD]
      Jan 16 12:26:53 kernel: lpt0: Interrupt-driven port
      Jan 16 12:26:53 kernel: ppi0: <parallel i="" o="">on ppbus0
      Jan 16 12:26:53 kernel: pmtimer0 on isa0
      Jan 16 12:26:53 kernel: orm0: <isa option="" roms="">at iomem 0xc0000-0xcbfff,0xcc000-0xcc7ff,0xcc800-0xccfff pnpid ORM0000 on isa0
      Jan 16 12:26:53 kernel: sc0: <system console="">at flags 0x100 on isa0
      Jan 16 12:26:53 kernel: sc0: VGA <16 virtual consoles, flags=0x300>
      Jan 16 12:26:53 kernel: vga0: <generic isa="" vga="">at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0
      Jan 16 12:26:53 kernel: Timecounter "TSC" frequency 1402394120 Hz quality 800
      Jan 16 12:26:53 kernel: Timecounters tick every 10.000 msec
      Jan 16 12:26:53 kernel: IPsec: Initialized Security Association Processing.
      Jan 16 12:26:53 kernel: ad0: 1023MB <virtual 1="" hd="" 1.="">at ata0-master WDMA2
      Jan 16 12:26:53 kernel: acd0: DVDROM <virtual cd="">at ata1-master PIO4
      Jan 16 12:26:53 kernel: Trying to mount root from ufs:/dev/ad0s1a
      Jan 16 12:26:54 kernel: pflog0: promiscuous mode enabled
      Jan 16 12:26:57 apinger: Starting Alarm Pinger, apinger(18873)
      Jan 16 12:26:57 apinger: No usable targets found, exiting
      Jan 16 12:27:03 dnsmasq[27633]: started, version 2.55 cachesize 10000
      Jan 16 12:27:03 dnsmasq[27633]: compile time options: no-IPv6 GNU-getopt no-DBus I18N DHCP TFTP
      Jan 16 12:27:03 dnsmasq[27633]: no servers found in /etc/resolv.conf, will retry
      Jan 16 12:27:03 dnsmasq[27633]: no servers found in /etc/resolv.conf, will retry
      Jan 16 12:27:03 check_reload_status: updating all dyndns
      Jan 16 12:27:03 dnsmasq[27633]: read /etc/hosts - 2 addresses
      Jan 16 12:27:12 php: : Creating rrd update script
      Jan 16 12:27:15 php: : Resyncing configuration for all packages.
      Jan 16 12:27:18 login: login on ttyv0 as root
      Jan 16 12:27:18 sshlockout[2084]: sshlockout/webConfigurator v3.0 starting up
      Jan 16 12:27:53 dhclient: FAIL
      Jan 16 12:28:03 php: /index.php: Successful webConfigurator login for user 'admin' from 192.168.1.31
      Jan 16 12:28:03 php: /index.php: Successful webConfigurator login for user 'admin' from 192.168.1.31</virtual></virtual></generic></system></isa></parallel></printer></plip></parallel></parallel></floppy></non-standard></non-standard></ps>

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

        That means there was no response, either a config issue in your VPC or some sort of FreeBSD compatibility issue with VPC, hard to say.

        1 Reply Last reply Reply Quote 0
        • N
          NOYB
          last edited by

          @cmb:

          That means there was no response, either a config issue in your VPC or some sort of FreeBSD compatibility issue with VPC, hard to say.

          No not talking about lack of a response from a DHCP server.  But rather there is no DHCP request of any kind being generated by pfSense on the WAN interface.  Also please note this same, very basic, VPC config works perfectly fine with pfSense 1.2.3.  And it also works perfectly fine with CentOS 5.x.

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

            @NOYB:

            And it also works perfectly fine with CentOS 5.x.

            which has 0 relevance. Try FreeBSD 8.1.

            1 Reply Last reply Reply Quote 0
            • N
              NOYB
              last edited by

              @cmb:

              @NOYB:

              And it also works perfectly fine with CentOS 5.x.

              which has 0 relevance. Try FreeBSD 8.1.

              The relevance is that of an additional data point in addition to that of pfSense 1.2.3, demonstrating VPC is working well and stable with multiple OS flavors.  Do you also contend that the fact the same VPC config works fine with pfSense 1.2.3 also has 0 relevance?

              Have you or the team even attempted to reproduce the problem?  And if so was the problem successfully reproduced?  And if so was there any attempt to determine where the issue resides?  (Free BSD compatibility, pfSense compatibility, etc?)

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

                @NOYB:

                Have you or the team even attempted to reproduce the problem?  And if so was the problem successfully reproduced?  And if so was there any attempt to determine where the issue resides?  (Free BSD compatibility, pfSense compatibility, etc?)

                no because I don't have or care to use VPC. I know others do though.

                1 Reply Last reply Reply Quote 0
                • N
                  NOYB
                  last edited by

                  @cmb:

                  @NOYB:

                  Have you or the team even attempted to reproduce the problem?  And if so was the problem successfully reproduced?  And if so was there any attempt to determine where the issue resides?  (Free BSD compatibility, pfSense compatibility, etc?)

                  no because I don't have or care to use VPC. I know others do though.

                  So you really have no idea then whether the issue is with pfSense, VPC config, or FreeBSD, as previously alluded too?

                  1 Reply Last reply Reply Quote 0
                  • V
                    voona
                    last edited by

                    @NOYB:

                    @cmb:

                    @NOYB:

                    Have you or the team even attempted to reproduce the problem?  And if so was the problem successfully reproduced?  And if so was there any attempt to determine where the issue resides?  (Free BSD compatibility, pfSense compatibility, etc?)

                    no because I don't have or care to use VPC. I know others do though.

                    So you really have no idea then whether the issue is with pfSense, VPC config, or FreeBSD, as previously alluded too?

                    LOL!

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

                      @NOYB:

                      So you really have no idea then whether the issue is with pfSense, VPC config, or FreeBSD, as previously alluded too?

                      I know it's not a problem in our code base, if you set something for DHCP it works. Whether it's VPC or FreeBSD 8.1 on VPC I don't know, some experimentation and you should be able to find out.

                      1 Reply Last reply Reply Quote 0
                      • N
                        NOYB
                        last edited by

                        @cmb:

                        I know it's not a problem in our code base, if you set something for DHCP it works. Whether it's VPC or FreeBSD 8.1 on VPC I don't know, some experimentation and you should be able to find out.

                        All the following using the same VPC:

                        FreeBSD 8.1-RELEASE #0: Mon Jul 19.02:55:53 UTC 2010
                        root
                        dhclient de1
                        DHCPDDISCOVER on de1 to 255.255.255.255 port 67 …
                        Wireshark captures Src 0.0.0.0 Dst 255.255.255.255 Protocol DHCP Info DHCP Discover ...

                        Also works with:
                        FreeBSD 7.2
                        pfSense 1.2.3
                        CentOS 5.4 (have not tried 5.5)

                        Does not work with:
                        pfSense 2.0 BETA5
                        option 8 shell
                        dhclient de1
                        DHCPDDISCOVER on de1 to 255.255.255.255 port 67 …
                        Wireshark Captures ICMPv6 Neighbor solicitaion etc. but no DHCP

                        Seems to me dhclient works correclty with everthing except pfSnese 2.0 BETA.

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

                          A while ago I tried a pfSense 2.0 BETA snapshot under virtual box. Virtual box NICs default to some type of AMD NIC. One or both of the NICs wouldn't work (I forget the exact symptom but it was something along the lines of "wouldn't transmit" which bears a resemblance to what you have reported). The problem went away when I changed the emulated NIC type to Intel e1000. I suspected a driver problem but didn't consider it worthwhile to investigate.

                          How about interchanging your LAN and WAN interfaces? Does the system behave any differently?

                          The chipsets recognised by the de driver were used in lots of different types of NICs, a number of them having their own peculiarities. Its possible something in the de driver is broken for a particular NIC but the driver still works for most of the recognised chips.

                          1 Reply Last reply Reply Quote 0
                          • N
                            NOYB
                            last edited by

                            Interchanging the LAN and WAN does not change behavior.

                            As for drivers and chip sets, as mentioned this same config works with both FreeBSD 7.2 and FreeBSD 8.1.
                            pfSense 1.2.3 is on FreeBSD 7.2 and that works too.
                            pfSense 2 BETA5 is on FreeBSD 8.0 or 8.1 and that does not work.

                            So what is it about pfSense 2 BETA5 that is breaking this?

                            1 Reply Last reply Reply Quote 0
                            • N
                              NOYB
                              last edited by

                              Okay, here is something kind of odd and interesting.

                              Going through the Setup Wizard (web), making no changes, and clicking the Reload button at the end, releases a bunch of buffered up DHCP Discover requests.  Also LAN access is gone after this.

                              But a reboot puts it right back to square one.

                              What is going on?

                              P.S. pfSense Version 1.2.3 works fine.

                              1 Reply Last reply Reply Quote 0
                              • _
                                _igor_
                                last edited by

                                Did you change your interface-settings as said by wallabybob?

                                Virtual box NICs default to some type of AMD NIC. One or both of the NICs wouldn't work (I forget the exact symptom but it was something along the lines of "wouldn't transmit" which bears a resemblance to what you have reported). The problem went away when I changed the emulated NIC type to Intel e1000.

                                That should be your next action!

                                Your way to search for that error seems to be ineffective.

                                1 Reply Last reply Reply Quote 0
                                • N
                                  NOYB
                                  last edited by

                                  @_igor_:

                                  Did you change your interface-settings as said by wallabybob?

                                  Virtual box NICs default to some type of AMD NIC. One or both of the NICs wouldn't work (I forget the exact symptom but it was something along the lines of "wouldn't transmit" which bears a resemblance to what you have reported). The problem went away when I changed the emulated NIC type to Intel e1000.

                                  That should be your next action!

                                  Your way to search for that error seems to be ineffective.

                                  Of course I did, had already tried and retried.

                                  Your way of assisting seems to be ineffective.  Otherwise I'm sure the problem would be solved by now.

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