No DHCP response, pfSense 1.2.3



  • Hello,

    since almost a week I'm struggling to get my pfSense box to provide IP leases via DHCP. I'm new to pfSense, but experienced in Linux (not BSD) and consumer class routers, but still surprised about not beeing able to configure pfSense to enable DHCP. Searching on the web has pointed me to some ideas on how to analyse the issue and tune the settings, however no luck so far in getting pfSense to respond on DHCP requests on the LAN. There's no other DHCP server and I'm not running into the known Vista (pre SP1) problem as I tried with Linux (Maemo), XP and Win7 clients, all known to work. I hope someone can provide help in nailing down the issue and hopefully point me to a solution.

    Here's my Setup:

    • ste3: LAN (port #4 of a D-Link DFE-580TX)

    • rl0: WAN (Realtek on motherboard)

    • tun0: VPN (OpenVPN)

    More details recorded from the console let me assume that the dhcpd is setup correctly to listen on all net-ports and DHCP requests are coming in as they should.

    
    # uname -a
    FreeBSD router.local 7.2-RELEASE-p5 FreeBSD 7.2-RELEASE-p5 #0: Sun Dec  6 22:57:48 EST 2009     sullrich@FreeBSD_7.2_pfSense_1.2.3_snaps.pfsense.org:/usr/obj.pfSense/usr/pfSensesrc/src/sys/pfSense.7  i386
    #
    #
    # ifconfig -a
    ste0: flags=8802 <broadcast,simplex,multicast>metric 0 mtu 1500
            options=8 <vlan_mtu>ether 00:0d:88:c5:f5:b4
            media: Ethernet autoselect (none)
            status: no carrier
    ste1: flags=8802 <broadcast,simplex,multicast>metric 0 mtu 1500
            options=8 <vlan_mtu>ether 00:0d:88:c5:f5:b5
            media: Ethernet autoselect (none)
            status: no carrier
    ste2: flags=8802 <broadcast,simplex,multicast>metric 0 mtu 1500
            options=8 <vlan_mtu>ether 00:0d:88:c5:f5:b6
            media: Ethernet autoselect (none)
            status: no carrier
    ste3: flags=8843 <up,broadcast,running,simplex,multicast>metric 0 mtu 1500
            options=8 <vlan_mtu>ether 00:0d:88:c5:f5:b7
            inet 192.168.1.221 netmask 0xffffff00 broadcast 192.168.1.255
            inet6 fe80::20d:88ff:fec5:f5b7%ste3 prefixlen 64 scopeid 0x4
            media: Ethernet autoselect (100baseTX <full-duplex>)
            status: active
    rl0: flags=8843 <up,broadcast,running,simplex,multicast>metric 0 mtu 1500
            options=8 <vlan_mtu>ether 00:e0:c5:6a:74:a6
            inet6 fe80::2e0:c5ff:fe6a:74a6%rl0 prefixlen 64 scopeid 0x5
            media: Ethernet autoselect (100baseTX <full-duplex>)
            status: active
    lo0: flags=8049 <up,loopback,running,multicast>metric 0 mtu 16384
            inet 127.0.0.1 netmask 0xff000000
            inet6 ::1 prefixlen 128
            inet6 fe80::1%lo0 prefixlen 64 scopeid 0x6
    enc0: flags=0<> metric 0 mtu 1536
    pfsync0: flags=41 <up,running>metric 0 mtu 1460
            pfsync: syncdev: lo0 syncpeer: 224.0.0.240 maxupd: 128
    pflog0: flags=100 <promisc>metric 0 mtu 33204
    ng0: flags=88d1 <up,pointopoint,running,noarp,simplex,multicast>metric 0 mtu 1492
            inet xxx.xxx.xxx.xxx --> 217.0.116.247 netmask 0xffffffff
            inet6 fe80::20d:88ff:fec5:f5b4%ng0 prefixlen 64 scopeid 0xa
    tun0: flags=8051 <up,pointopoint,running,multicast>metric 0 mtu 1500
            inet6 fe80::20d:88ff:fec5:f5b4%tun0 prefixlen 64 scopeid 0xb
            inet 192.168.10.1 --> 192.168.10.2 netmask 0xffffffff
            Opened by PID 377
    #
    #
    # tcpdump -e -i ste3 -l -n -s 1500 port 67 or port 68
    tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
    listening on ste3, link-type EN10MB (Ethernet), capture size 1500 bytes
    21:54:01.965714 ec:9b:5b:d3:83:a6 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 590: 0.0.0.0.68 > 166.255.255.255.67: BOOTP/DHCP, Request from ec:9b:5b:d3:83:a6, length 548
    21:54:04.644946 ec:9b:5b:d3:83:a6 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 590: 0.0.0.0.68 > 166.255.255.255.67: BOOTP/DHCP, Request from ec:9b:5b:d3:83:a6, length 548
    21:54:07.964732 ec:9b:5b:d3:83:a6 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 590: 0.0.0.0.68 > 166.255.255.255.67: BOOTP/DHCP, Request from ec:9b:5b:d3:83:a6, length 548
    21:54:10.964375 ec:9b:5b:d3:83:a6 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 590: 0.0.0.0.68 > 166.255.255.255.67: BOOTP/DHCP, Request from ec:9b:5b:d3:83:a6, length 548
    21:54:13.745063 ec:9b:5b:d3:83:a6 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 590: 0.0.0.0.68 > 36.255.255.255.67: BOOTP/DHCP, Request from ec:9b:5b:d3:83:a6, length 548
    21:54:16.706229 ec:9b:5b:d3:83:a6 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 590: 0.0.0.0.68 > 164.255.255.255.67: BOOTP/DHCP, Request from ec:9b:5b:d3:83:a6, length 548
    21:54:19.962777 ec:9b:5b:d3:83:a6 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 590: 0.0.0.0.68 > 166.255.255.255.67: BOOTP/DHCP, Request from ec:9b:5b:d3:83:a6, length 548
    21:54:22.962395 ec:9b:5b:d3:83:a6 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 590: 0.0.0.0.68 > 166.255.255.255.67: BOOTP/DHCP, Request from ec:9b:5b:d3:83:a6, length 548
    8 packets captured
    114 packets received by filter
    0 packets dropped by kernel
    #
    #
    # ps auxgw | grep dhcpd
    dhcpd   1080  0.0  0.2  3156  2116  ??  Is    7:07PM   0:00.00 /usr/local/sbin/dhcpd -user dhcpd -group _dhcp -chroot /var/dhcpd -c
    #
    #
    # sockstat | grep dhcpd
    dhcpd    dhcpd      1080  3  dgram  -> /var/run/logpriv
    dhcpd    dhcpd      1080  10 udp4   *:67                  *:*
    #
    #
    # netstat -an -p udp
    Active Internet connections (including servers)
    Proto Recv-Q Send-Q  Local Address          Foreign Address        (state)
    udp4       0      0 *.67                   *.*
    udp6       0      0 *.53                   *.*
    udp4       0      0 *.53                   *.*</up,pointopoint,running,multicast></up,pointopoint,running,noarp,simplex,multicast></promisc></up,running></up,loopback,running,multicast></full-duplex></vlan_mtu></up,broadcast,running,simplex,multicast></full-duplex></vlan_mtu></up,broadcast,running,simplex,multicast></vlan_mtu></broadcast,simplex,multicast></vlan_mtu></broadcast,simplex,multicast></vlan_mtu></broadcast,simplex,multicast> 
    

    Here's my system log:

    dhcpd: For info, please visit http://www.isc.org/sw/dhcp/
    dhcpd: All rights reserved.
    dhcpd: Copyright 2004-2008 Internet Systems Consortium.
    dhcpd: Internet Systems Consortium DHCP Server V3.0.7
    pftpx[557]: listening on 127.0.0.1 port 8022
    pftpx[557]: listening on 127.0.0.1 port 8022
    kernel: pflog0: promiscuous mode enabled
    kernel: Trying to mount root from ufs:/dev/ad0s1a
    kernel: ad0: 955MB <transcend 20070831=""> at ata0-master UDMA33
    kernel: ad0: DMA limited to UDMA33, device found non-ATA66 cable
    kernel: IPsec: Initialized Security Association Processing.
    kernel: Timecounters tick every 1.000 msec
    kernel: Timecounter "TSC" frequency 797968474 Hz quality 800
    kernel: vga0: <generic isa="" vga=""> at port 0x3c0-0x3df iomem 0xa0000-0xbffff on isa0
    kernel: sc0: VGA <16 virtual consoles, flags=0x300>
    kernel: sc0: <system console=""> at flags 0x100 on isa0
    kernel: orm0: <isa option="" roms=""> at iomem 0xc0000-0xcbfff,0xcc000-0xcffff pnpid ORM0000 on isa0
    kernel: pmtimer0 on isa0
    kernel: acpi_throttle0: <acpi cpu="" throttling=""> on cpu0
    kernel: cpu0: <acpi cpu=""> on acpi0
    kernel: psm0: model Generic PS/2 mouse, device ID 0
    kernel: psm0: [ITHREAD]
    kernel: psm0: [GIANT-LOCKED]
    kernel: psm0: <ps 2="" mouse=""> irq 12 on atkbdc0
    kernel: atkbd0: [ITHREAD]
    kernel: atkbd0: [GIANT-LOCKED]
    kernel: kbd0 at atkbd0
    kernel: atkbd0: <at keyboard=""> irq 1 on atkbdc0
    kernel: atkbdc0: <keyboard controller="" (i8042)=""> port 0x60,0x64 irq 1 on acpi0
    kernel: sio1: [FILTER]
    kernel: sio1: type 16550A
    kernel: sio1: <16550A-compatible COM port> port 0x2f8-0x2ff irq 3 on acpi0
    kernel: sio0: [FILTER]
    kernel: sio0: type 16550A
    kernel: sio0: <16550A-compatible COM port> port 0x3f8-0x3ff irq 4 flags 0x10 on acpi0
    kernel: speaker0: <pc speaker=""> port 0x61 on acpi0
    kernel: rl0: [ITHREAD]
    kernel: rl0: Ethernet address: 00:e0:c5:6a:74:a6
    kernel: rlphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
    kernel: rlphy0: <realtek internal="" media="" interface=""> PHY 0 on miibus4
    kernel: miibus4: <mii bus=""> on rl0
    kernel: rl0: <realtek 10="" 8139="" 100basetx=""> port 0xe800-0xe8ff mem 0xef000000-0xef0000ff irq 15 at device 9.0 on pci0
    kernel: pci0: <multimedia, audio=""> at device 7.5 (no driver attached)
    kernel: pci0: <bridge> at device 7.4 (no driver attached)
    kernel: uhub0: 2 ports with 2 removable, self powered
    kernel: uhub0: <via 1="" 9="" uhci="" root="" hub,="" class="" 0,="" rev="" 1.00="" 1.00,="" addr=""> on usb0
    kernel: usb0: USB revision 1.0
    kernel: usb0: <via 83c572="" usb="" controller=""> on uhci0
    kernel: uhci0: [ITHREAD]
    kernel: uhci0: [GIANT-LOCKED]
    kernel: uhci0: <via 83c572="" usb="" controller=""> port 0xd400-0xd41f irq 10 at device 7.2 on pci0
    kernel: ata1: [ITHREAD]
    kernel: ata1: <ata 1="" channel=""> on atapci0
    kernel: ata0: [ITHREAD]
    kernel: ata0: <ata 0="" channel=""> on atapci0
    kernel: atapci0: <via 82c686b="" udma100="" controller=""> port 0x1f0-0x1f7,0x3f6,0x170-0x177,0x376,0xd000-0xd00f at device 7.1 on pci0
    kernel: isa0: <isa bus=""> on isab0
    kernel: isab0: <pci-isa bridge=""> at device 7.0 on pci0
    kernel: ste3: [ITHREAD]
    kernel: ste3: Ethernet address: 00:0d:88:c5:f5:b7
    kernel: ste3: WARNING: using obsoleted if_watchdog interface
    kernel: ukphy3: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
    kernel: ukphy3: <generic ieee="" 802.3u="" media="" interface=""> PHY 1 on miibus3
    kernel: miibus3: <mii bus=""> on ste3
    kernel: ste3: <d-link 10="" dl10050="" 100basetx=""> port 0xcc00-0xcc7f irq 15 at device 7.0 on pci2
    kernel: ste2: [ITHREAD]
    kernel: ste2: Ethernet address: 00:0d:88:c5:f5:b6
    kernel: ste2: WARNING: using obsoleted if_watchdog interface
    kernel: ukphy2: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
    kernel: ukphy2: <generic ieee="" 802.3u="" media="" interface=""> PHY 1 on miibus2
    kernel: miibus2: <mii bus=""> on ste2
    kernel: ste2: <d-link 10="" dl10050="" 100basetx=""> port 0xc800-0xc87f irq 11 at device 6.0 on pci2
    kernel: ste1: [ITHREAD]
    kernel: ste1: Ethernet address: 00:0d:88:c5:f5:b5
    kernel: ste1: WARNING: using obsoleted if_watchdog interface
    kernel: ukphy1: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
    kernel: ukphy1: <generic ieee="" 802.3u="" media="" interface=""> PHY 1 on miibus1
    kernel: miibus1: <mii bus=""> on ste1
    kernel: ste1: <d-link 10="" dl10050="" 100basetx=""> port 0xc400-0xc47f irq 10 at device 5.0 on pci2
    kernel: ste0: [ITHREAD]
    kernel: ste0: Ethernet address: 00:0d:88:c5:f5:b4
    kernel: ste0: WARNING: using obsoleted if_watchdog interface
    kernel: ukphy0: 10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, auto
    kernel: ukphy0: <generic ieee="" 802.3u="" media="" interface=""> PHY 1 on miibus0
    kernel: miibus0: <mii bus=""> on ste0
    kernel: ste0: <d-link 10="" dl10050="" 100basetx=""> port 0xc000-0xc07f irq 5 at device 4.0 on pci2
    kernel: pci2: <pci bus=""> on pcib2
    kernel: pcib2: <pci-pci bridge=""> at device 6.0 on pci0
    kernel: vgapci0: <vga-compatible display=""> mem 0xed000000-0xed07ffff,0xe0000000-0xe7ffffff irq 15 at device 0.0 on pci1
    kernel: pci1: <pci bus=""> on pcib1
    kernel: pcib1: <pci-pci bridge=""> at device 1.0 on pci0
    kernel: agp0: aperture size is 256M
    kernel: agp0: <via 82c694x="" (apollo="" pro="" 133a)="" host="" to="" pci="" bridge=""> on hostb0
    kernel: pci0: <acpi pci="" bus=""> on pcib0
    kernel: pcib0: <acpi host-pci="" bridge=""> port 0xcf8-0xcff,0x4000-0x407f,0x4080-0x40ff,0x5000-0x500f,0x6000-0x607f on acpi0
    kernel: acpi_button0: <power button=""> on acpi0
    kernel: acpi_timer0: <24-bit timer at 3.579545MHz> port 0x4008-0x400b on acpi0
    kernel: Timecounter "ACPI-safe" frequency 3579545 Hz quality 850
    kernel: acpi0: Power Button (fixed)
    kernel: acpi0: [ITHREAD]
    kernel: acpi0: <via605 awrdacpi=""> on motherboard
    kernel: padlock0: No ACE support.
    kernel: cryptosoft0: <software crypto=""> on motherboard
    kernel: kbd1 at kbdmux0
    kernel: wlan: mac acl policy registered
    kernel: avail memory = 1028579328 (980 MB)
    kernel: real memory = 1065287680 (1015 MB)
    kernel: VIA Padlock Features=0x3d <rng>kernel: Features=0x380b13d <fpu,de,pse,tsc,msr,cx8,mtrr,pge,cmov,mmx,fxsr,sse>kernel: Origin = "CentaurHauls" Id = 0x695 Stepping = 5
    kernel: CPU: VIA Nehemiah (797.97-MHz 686-class CPU)
    kernel: Timecounter "i8254" frequency 1193182 Hz quality 0
    kernel: sullrich@FreeBSD_7.2_pfSense_1.2.3_snaps.pfsense.org:/usr/obj.pfSense/usr/pfSensesrc/src/sys/pfSense.7
    kernel: FreeBSD 7.2-RELEASE-p5 #0: Sun Dec 6 22:57:48 EST 2009
    kernel: FreeBSD is a registered trademark of The FreeBSD Foundation.
    kernel: The Regents of the University of California. All rights reserved.
    kernel: Copyright (c) 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
    kernel: Copyright (c) 1992-2009 The FreeBSD Project.
    syslogd: kernel boot file is /boot/kernel/kernel</fpu,de,pse,tsc,msr,cx8,mtrr,pge,cmov,mmx,fxsr,sse></rng></software></via605></power></acpi></acpi></via></pci-pci></pci></vga-compatible></pci-pci></pci></d-link></mii></generic></d-link></mii></generic></d-link></mii></generic></d-link></mii></generic></pci-isa></isa></via></ata></ata></via></via></via></bridge></multimedia,></realtek></mii></realtek></pc></keyboard></at></ps></acpi></acpi></isa></system></generic></transcend>
    

    Here's the my DHCP setup:

    Enable DHCP server on LAN interface
    Deny unknown clients [no]
    Subnet 	192.168.1.0
    Subnet mask 	255.255.255.0
    Available range 	192.168.1.0 - 192.168.1.255
    Range	192.168.1.103 to	192.168.1.150
    

    Attached image is the Firewall setup on the LAN port:
    Note the logging in my first, second and last rule.
    … and there is nothing in the firewall log. No packets from LAN logged!?

    … and the DHCP log

    last message repeated 2 times
    dhcpd: 5 bad IP checksums seen in 5 packets
    last message repeated 2 times
    dhcpd: 5 bad IP checksums seen in 5 packets
    last message repeated 2 times
    dhcpd: 5 bad IP checksums seen in 5 packets
    dhcpd: Sending on Socket/fallback/fallback-net
    dhcpd: Sending on BPF/ste3/00:0d:88:c5:f5:b7/192.168.1/24
    dhcpd: Listening on BPF/ste3/00:0d:88:c5:f5:b7/192.168.1/24
    dhcpd: Wrote 0 leases to leases file.
    dhcpd: Wrote 0 new dynamic host decls to leases file.
    dhcpd: Wrote 0 deleted host decls to leases file.
    dhcpd: For info, please visit http://www.isc.org/sw/dhcp/
    dhcpd: All rights reserved.
    dhcpd: Copyright 2004-2008 Internet Systems Consortium.
    dhcpd: Internet Systems Consortium DHCP Server V3.0.7
    dhcpd: Sending on Socket/fallback/fallback-net
    dhcpd: Sending on BPF/ste3/00:0d:88:c5:f5:b7/192.168.1/24
    dhcpd: Listening on BPF/ste3/00:0d:88:c5:f5:b7/192.168.1/24
    dhcpd: Wrote 0 leases to leases file.
    dhcpd: Wrote 0 new dynamic host decls to leases file.
    dhcpd: Wrote 0 deleted host decls to leases file.
    dhcpd: For info, please visit http://www.isc.org/sw/dhcp/
    dhcpd: All rights reserved.
    dhcpd: Copyright 2004-2008 Internet Systems Consortium.
    dhcpd: Internet Systems Consortium DHCP Server V3.0.7
    

    The bad checksum notification made me checking „Disable Hardware Checksum Offloading“ in pfSense „System: Advanced functions“ without success.
    …. and the interface list (LAN is up)

    WAN interface (rl0)
    Status 	up
    PPPoE 	up  
    MAC address 	00:e0:c5:6a:74:a6
    IP address 	xxx.xxx.xxx.xxx  
    Subnet mask 	255.255.255.255
    Gateway 	217.0.116.247
    ISP DNS servers 	217.0.43.97
    217.0.43.113
    Media 	100baseTX <full-duplex>
    In/out packets 	5232/5607 (4.24 MB/707 KB)
    In/out errors 	0/0
    Collisions 	0
    
    LAN interface (ste3)
    Status 	up
    MAC address 	00:0d:88:c5:f5:b7
    IP address 	192.168.1.221  
    Subnet mask 	255.255.255.0
    Media 	100baseTX <full-duplex>
    In/out packets 	27614/6894 (2.44 MB/5.28 MB)
    In/out errors 	0/0
    Collisions 	0
    
    VPNprivate interface (tun0)
    Status 	up
    IP address 	192.168.10.1  
    Subnet mask 	255.255.255.255
    In/out packets 	0/3 (0 bytes/220 bytes)</full-duplex></full-duplex>
    

    Any more information I could provide that would help analysing the issue?

    Thanx for any suggestions,

    Klaus



  • Have you run a packet trace on the DHCP client or the pfSense LAN port to verify that DHCP is correctly configured
    on the client and pfSense is receiving the DHCP requests?

    Without knowing the definition of DHCPports it is difficult to know if your rules are correct.

    I presume Interface IP address is the LAN interface's IP address. If that is the case then your second rule is wrong because a DHCP lease renewal will have its destination IP address the DHCP server address, the LAN IP address.

    The DHCP related rules can all specify the protocol as UDP rather than TCP/UDP.



  • Thanks for the reply.
    Here are my answers to your questions in between your original post:

    Have you run a packet trace on the DHCP client or the pfSense LAN port to verify that DHCP is correctly configured
    on the client and pfSense is receiving the DHCP requests?
    here is a tcpdump copied from my original post (scroll down in first code block):

    tcpdump -e -i ste3 -l -n -s 1500 port 67 or port 68

    tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
    listening on ste3, link-type EN10MB (Ethernet), capture size 1500 bytes
    21:54:01.965714 ec:9b:5b:d3:83:a6 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 590: 0.0.0.0.68 > 166.255.255.255.67: BOOTP/DHCP, Request from ec:9b:5b:d3:83:a6, length 548
    21:54:04.644946 ec:9b:5b:d3:83:a6 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 590: 0.0.0.0.68 > 166.255.255.255.67: BOOTP/DHCP, Request from ec:9b:5b:d3:83:a6, length 548
    21:54:07.964732 ec:9b:5b:d3:83:a6 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 590: 0.0.0.0.68 > 166.255.255.255.67: BOOTP/DHCP, Request from ec:9b:5b:d3:83:a6, length 548
    21:54:10.964375 ec:9b:5b:d3:83:a6 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 590: 0.0.0.0.68 > 166.255.255.255.67: BOOTP/DHCP, Request from ec:9b:5b:d3:83:a6, length 548
    21:54:13.745063 ec:9b:5b:d3:83:a6 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 590: 0.0.0.0.68 > 36.255.255.255.67: BOOTP/DHCP, Request from ec:9b:5b:d3:83:a6, length 548
    21:54:16.706229 ec:9b:5b:d3:83:a6 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 590: 0.0.0.0.68 > 164.255.255.255.67: BOOTP/DHCP, Request from ec:9b:5b:d3:83:a6, length 548
    21:54:19.962777 ec:9b:5b:d3:83:a6 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 590: 0.0.0.0.68 > 166.255.255.255.67: BOOTP/DHCP, Request from ec:9b:5b:d3:83:a6, length 548
    21:54:22.962395 ec:9b:5b:d3:83:a6 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 590: 0.0.0.0.68 > 166.255.255.255.67: BOOTP/DHCP, Request from ec:9b:5b:d3:83:a6, length 548
    8 packets captured
    114 packets received by filter
    0 packets dropped by kernel

    At least DHCP requests are arriving at the LAN port. Is it that what you where looking for?

    Without knowing the definition of DHCPports it is difficult to know if your rules are correct.
    My alias definition of "DHCPports" is: 67, 68, 69, 847, 546, 547, 647, 847

    I presume Interface IP address is the LAN interface's IP address. If that is the case then your second rule is wrong because a DHCP lease renewal will have its destination IP address the DHCP server address, the LAN IP address.
    That was set to the VPN port, now changed to VPN subnet (IP range 192.168.10.0/24).

    The DHCP related rules can all specify the protocol as UDP rather than TCP/UDP.
    I didn't think of that making a difference in the result, as I presumed the rules would apply to both, UDP and TCP (logical OR). I was intending to include TFTP (using TCP?) in my DHCP rules. Anyway changed now to UDP only.

    Any more suggestions?



  • Attached is my new ruleset with the above mentioned changes - unfortunately didn't enable DHCP replies.

    Here are some of my alias definitions for the rules:
    DHCPports 67, 68, 69, 847, 546, 547, 647, 847 ports used for DHCP 
    Gateway 192.168.1.221 This router's IP Adress 
    Router 192.168.1.221 this router = Gateway 
    VPNsubnet 192.168.10.0/24 IP-Range used for the VPN subnet 
    privateLAN 192.168.1.0/24 IP-Range used by the private subnet 
    www 80, 443, 8080, 8443

    • LAN net is the pysical LAN port (ste3)

    • WAN address is the IP-adress of the WAN port (rl0)

    I guess the later doesn't make sense on the purpose of "Let all LAN pass to WAN" - however shouldn't affect the DHCP issue.




  • Sorry I didn't pick up the tcpdump in your earlier post.

    That shows what I suspect is a violation of the DHCP rules. I believe that the initial DHCP request should be sent to the broadcast IP address (255.255.255.255) rather than what appears to be a network specific broadcast address (166.255.255.255, 36.255.255.255, 164.255.255.255 etc).

    It would be interesting to see if a trace on the DHCP client shows the same destination IP address being used. Since you have tried a number of clients and not had any work, I'm inclined to suspect there is something wrong with the LAN interface you are using. Could you try the other NICs on the DLink card or even the motherboard NIC?



  • Many thanks for looking into this again and pointing me to that subnet broadcasting phenomenon.

    I tried again and this is what the XP-Client has sent (as traced by wireshark - filter on udp port 67 or port 68):
    1 0.000000000 0.0.0.0 255.255.255.255 DHCP DHCP Discover - Transaction ID 0x1b7b19c1
    2 3.003655000 0.0.0.0 255.255.255.255 DHCP DHCP Discover - Transaction ID 0x1b7b19c1
    3 11.005107000 0.0.0.0 255.255.255.255 DHCP DHCP Discover - Transaction ID 0x1b7b19c1
    4 26.006680000 0.0.0.0 255.255.255.255 DHCP DHCP Discover - Transaction ID 0x1b7b19c1

    And this is what came in on ste3 on the pfSense box:

    tcpdump -e -i ste3 -l -n -s 1500 port 67 or port 68

    tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
    listening on ste3, link-type EN10MB (Ethernet), capture size 1500 bytes
    16:47:46.941873 00:08:0d:64:59:50 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 343: 0.0.0.0.68 > 36.255.255.255.67: BOOTP/DHCP, Request from 00:08:0d:64:59:50, length 301
    16:47:49.946678 00:08:0d:64:59:50 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 343: 0.0.0.0.68 > 166.255.255.255.67: BOOTP/DHCP, Request from 00:08:0d:64:59:50, length 301
    16:47:57.951224 00:08:0d:64:59:50 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 343: 0.0.0.0.68 > 166.255.255.255.67: BOOTP/DHCP, Request from 00:08:0d:64:59:50, length 301
    16:48:12.958581 00:08:0d:64:59:50 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 343: 0.0.0.0.68 > 164.255.255.255.67: BOOTP/DHCP, Request from 00:08:0d:64:59:50, length 301
    4 packets captured
    314 packets received by filter
    0 packets dropped by kernel

    So I followed your suggestion and reconfigured my router to have LAN on ste0 instead of ste3 (WAN kept same on rl0).
    Tried again, XP-Client sent exactly same packets and here is what was received on ste0 in the pfSense box:

    tcpdump -e -i ste0 -l -n -s 1500 port 67 or port 68

    tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
    listening on ste0, link-type EN10MB (Ethernet), capture size 1500 bytes
    17:23:22.776147 00:08:0d:64:59:50 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 343: 0.0.0.0.68 > 166.255.255.255.67: BOOTP/DHCP, Request from 00:08:0d:64:59:50, length 301
    17:23:25.778858 00:08:0d:64:59:50 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 343: 0.0.0.0.68 > 164.255.255.255.67: BOOTP/DHCP, Request from 00:08:0d:64:59:50, length 301
    17:23:34.780778 00:08:0d:64:59:50 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 343: 0.0.0.0.68 > 166.255.255.255.67: BOOTP/DHCP, Request from 00:08:0d:64:59:50, length 301
    17:23:50.782020 00:08:0d:64:59:50 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 343: 0.0.0.0.68 > 164.255.255.255.67: BOOTP/DHCP, Request from 00:08:0d:64:59:50, length 301
    4 packets captured
    240 packets received by filter
    0 packets dropped by kernel

    Same phenomenon! Ok - we seem to be on the right track and at least two of four ports are affected. There appears to be a bit dropping on the initial bits os the IP-Adress. Why does this happen only on DHCP requests and only in the IP-Adress and no effect on other data? Can dhcpd get set up to handle both, requests broadcasted on a subnet and requests broadcasted to everyone as it should happen?
    I guess the problem might appear only on UDP packets while TCP would cover data loss in the protocol layer by checksum and repeating packets.
    If this is a driver problem caused by card-firmware or the driver then I would not go for a replacement of the same type. Just using this ethernet card for the WAN where DHCP is not needed would not resolve my problem as it would still affect ports I want to use for other subnets and also how hall I confirm, that this card (or the driver) would not cause arbitrary data loss, resulting in a lot of traffic overhead for necessary packet repetitions.
    Any thoughs on this?

    Just to be sure not to have a misconfiguration that we have not seen I'll give it another try with the ethernet port on the motherboard.

    Thanks,
    Klaus



  • After swapping the interfaces to be:

    • rl0: LAN

    • ste0: WAN

    it works.

    IP address    MAC address    Hostname    Start    End 
    192.168.1.150  00:08:0d:64:59:50  MANNS-5200  2010/11/26 21:01:47  2010/11/26 23:01:47

    # tcpdump -e -i rl0 -l -n -s 1500 port 67 or port 68
    tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
    listening on rl0, link-type EN10MB (Ethernet), capture size 1500 bytes
    21:01:34.498808 00:08:0d:64:59:50 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 343: 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:08:0d:64:59:50, length 301
    21:01:35.001738 00:e0:c5:6a:74:a6 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 342: 192.168.1.221.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 300
    21:01:39.003367 00:08:0d:64:59:50 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 343: 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:08:0d:64:59:50, length 301
    21:01:39.004097 00:e0:c5:6a:74:a6 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 342: 192.168.1.221.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 300
    21:01:47.003875 00:08:0d:64:59:50 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 343: 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:08:0d:64:59:50, length 301
    21:01:47.004567 00:e0:c5:6a:74:a6 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 342: 192.168.1.221.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 300
    21:01:47.005113 00:08:0d:64:59:50 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 363: 0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 00:08:0d:64:59:50, length 321
    21:01:47.616267 00:e0:c5:6a:74:a6 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 342: 192.168.1.221.67 > 255.255.255.255.68: BOOTP/DHCP, Reply, length 300
    8 packets captured
    248 packets received by filter
    0 packets dropped by kernel
    
    

    Ok, now we know that the DHCP configuration is allright, however I'm wondering if I will end up with the same issue when getting a replacement card of the same type (D-Link DFE-580TX). I think it would be a safe bet to assume it's not a hardware issue but rather firmware or driver related. Staying with the current working setup is not an option as it would keep me with three non-DHCP capable interfaces for OPT1..OPT3. On top there is the question of how much trust I can keep on that card-firmware-driver combination. Does it cause more traffic and less throughput? How can I test that?

    Is there any way to confirm or exclude a hardware fault (other than testing replacement cards, which I don't have at hand)? Any recommendations on a cheap 4 port ethernet 32bit PCI card the is known to work 100%?

    Thanks again,
    Klaus



  • Some FreeBSD drivers suffer from bit rot - the cards are no longer in sufficient use for them to be tested with drivers in newer releases. Maybe ste is in that category.

    It could be worth looking at the FreeBSD revision history for ste. Maybe this problem has been fixed in a later release.

    Generally 4 port cards are comparatively expensive. I would be inclined to look at getting a VLAN capable card and use a VLAN capable switch as a "port multiplier". I suspect you would be able to get an 8 port VLAN capable switch for a comparable price to a 4 port NIC.



  • Thank you for your excellent support and suggestions. Now I'd better check ste history. I've got this card for about only 15 EUR (= 20 AUD) and I'm afraid there are not many alternatives available with a 32bit PCI interface. The D-Link 570TX is using another chipset but is even older, so even less of a target for driver updates. Anyway I'll follow your suggestion of not only checking the FreeBSD hardware support list but also driver history before deciding for the next. (we might even move this post to hardware related).
    For now I've inserted an old SMC 9332BDT 21140A which provides me with DHCP on LAN and OPT1 and what is even better (although 2 ports less) it gives me a noticeable performance improvement. Unfortunately I have no second PCI slot on the motherboard (old ThinClient), so I still need to look for another 4 port card or consider a VLAN switch (probably more expensive).

    Klaus



  • Some alternative 4 port PCI cards: lan1641 and lan1741 from http://www.soekris.com
    If buying second hand a card with Intel PRO/100 (fxp) NICs would probably be a good choice. I think a number of the major computer suppliers have produced multi-port network cards with Intel chips under their own brand (HP, COMPAQ etc).

    A cheap (US$40) 5 port VLAN capable switch is the RB250G: http://routerboard.com/pricelist.php?showProduct=101

    I have no experience with any of the above products.


Log in to reply