Dell Optiplex XE with Broadcom BCM5761 NetXtreme and Broadcom BCM57780



  • Hi All,

    After installing the latest beta version, 2.0, dated 29/12/2010, installed on a Dell Optiplex XE, with Dual Integrated Broadcom® BCM5761 NetXtreme® and Broadcom® BCM57780 NetLink® 10/100/1000, pfsense can see the three nics (one PCI D-Link nic) , but they cannot be detected when setting / configuring for the first time. An extra nic car, D-Link is also installed, and works fine. I also noticed, that when a cable is removed from the socket, a message is displayed that bge0 or bge1 is down, when connected, is shows it is up, but it cannot be detected through the installer when configuring the network interface.

    I tried first pfsense 1.2.3, but that didn't detect any nic's at all.

    I need to configure the two nics, bge's correctly. I added the line if_pge_load="YES" to the loader.conf, but the problem is not solved yet.

    Would appreciate your help,

    Thanks,

    Dan



  • I've already get this kind of problem with broadcom integrated nic, the problem is not pfsense itself but freebsd 8.1

    use intel nic :)



  • @dan2010:

    I tried first pfsense 1.2.3, but that didn't detect any nic's at all.

    Possibly your NICs are  "too new" to be supported by the FreeBSD in pfSense 1.2.3.

    @dan2010:

    I need to configure the two nics, bge's correctly. I added the line if_pge_load="YES" to the loader.conf, but the problem is not solved yet.

    Maybe a typo, but if_pge_load="YES" won't cause the bge driver to be loaded. With rare exceptions, pfSense includes all the supported NIC drivers in the kernel, so its generally not necessary to configure special directives to load drivers.

    @dan2010:

    After installing the latest beta version, 2.0, dated 29/12/2010, installed on a Dell Optiplex XE, with Dual Integrated Broadcom® BCM5761 NetXtreme® and Broadcom® BCM57780 NetLink® 10/100/1000, pfsense can see the three nics (one PCI D-Link nic) , but they cannot be detected when setting / configuring for the first time. An extra nic car, D-Link is also installed, and works fine. I also noticed, that when a cable is removed from the socket, a message is displayed that bge0 or bge1 is down, when connected, is shows it is up, but it cannot be detected through the installer when configuring the network interface.

    Just so we know what FreeBSD thinks you have in your system, please provide the output of the shell commands on a pfSense 2.0 install:

    # dmesg; pciconf -l; ifconfig -a
    

    Also, its not clear to me what "setting/configuration" you are referring to: assign interfaces dialog from the console menu? assign interfaces dialog from the console menu with automatic option? web GUI assign interfaces page? Please clarify.



  • Thanks wallabybob for your reply.

    Attached is the file you just asked for.

    I cannot open the web interface yet.

    Just moved the machine, connect bge0 to my standard lan (to be the WAN here) , with DHCP enabled. bge1 for the lan, connected to a router, and will connect a computer to check its connectivity, and OPT is connected to the D-LINK nic, which has NONE setup now.

    I can see the network is UP for bge0 (WAN) and bge1 (LAN), but no connectivity or cannot ping from outside.

    Just did some tests on the WAN.

    I can ping from the pfsense box other boxes on my wan with their ip address. However, when pinging from the Wan to the box using the ip address, and running tcpdump -i bge0, I can see the echo request, but no echo reply from the pfsense box! Is it because it is configured to ignore / drop ICMP Req ?

    Appreciate your help.

    Dan

    myconfig.txt



  • I can ping from the pfsense box other boxes on my wan with their ip address. However, when pinging from the Wan to the box using the ip address, and running tcpdump -i bge0, I can see the echo request, but no echo reply from the pfsense box! Is it because it is configured to ignore / drop ICMP Req ?

    Unless you set rules to allow traffic, pfSense will block pretty much all inbound traffic on your WAN interface.



  • How can I enable reply back on ICMP echo req using the command line ?

    Dan



  • Hi,

    I can see in the system logs :

    Dec 30 22:07:59 pfSense kernel: bge0: <broadcom bcm57780="" a1,="" asic="" rev.="" 0x57780001="">mem 0xfe2f0000-0xfe2fffff irq 19 at device 0.0 on pci5
    Dec 30 22:07:59 pfSense kernel: miibus0: <mii bus="">on bge0
    Dec 30 22:07:59 pfSense kernel: ukphy0: <generic ieee="" 802.3u="" media="" interface="">PHY 1 on miibus0
    Dec 30 22:07:59 pfSense kernel: ukphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto
    Dec 30 22:07:59 pfSense kernel: bge0: [FILTER]
    Dec 30 22:07:59 pfSense kernel: pcib6: <acpi pci-pci="" bridge="">irq 16 at device 28.4 on pci0
    Dec 30 22:07:59 pfSense kernel: pci6: <acpi pci="" bus="">on pcib6
    Dec 30 22:07:59 pfSense kernel: bge1: <broadcom netxtreme="" gigabit="" ethernet="" controller,="" asic="" rev.="" 0x5761100="">mem 0xfe1e0000-0xfe1effff,0xfe1f0000-0xfe1fffff irq 16 at devic
    e 0.0 on pci6
    ec 30 22:07:59 pfSense kernel: miibus1: <mii bus="">on bge1
    Dec 30 22:07:59 pfSense kernel: brgphy0: <bcm5761 10="" 100="" 1000basetx="" phy="">PHY 1 on miibus1
    Dec 30 22:07:59 pfSense kernel: brgphy0:  10baseT, 10baseT-FDX, 100baseTX, 100baseTX-FDX, 1000baseT, 1000baseT-FDX, auto
    Dec 30 22:07:59 pfSense kernel: bge1: [FILTER]</bcm5761></mii></broadcom></acpi></acpi></generic></mii></broadcom>

    The standard Interface, bge0 now works. However, bge1 doesn't work.
    bge1 is the Broadcom NetXtreme Gigabit Ethernet Controller.

    So I setup a machine on bge1 network, as I cannot get a DHCP ip from pfsense, gave it an ip of 192.168.22.22, and the pfsense bge1 192.168.22.1.
    I listened on the bge1 interface, when pinging from 192.168.22.22 to 192.168.22.1:

    22:41:52.946586 IP 192.168.22.22.netbios-ns > 192.168.22.255.netbios-ns: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST
    22:41:53.696292 IP 192.168.22.22.netbios-ns > 192.168.22.255.netbios-ns: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST
    22:41:54.446601 IP 192.168.22.22.netbios-ns > 192.168.22.255.netbios-ns: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST
    22:41:57.452032 IP 192.168.22.22.netbios-ns > 192.168.22.255.netbios-ns: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST
    22:41:58.201741 IP 192.168.22.22.netbios-ns > 192.168.22.255.netbios-ns: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST
    22:41:58.952047 IP 192.168.22.22.netbios-ns > 192.168.22.255.netbios-ns: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST
    22:42:02.610887 IP 192.168.22.22.netbios-dgm > 192.168.22.255.netbios-dgm: NBT UDP PACKET(138)
    22:42:02.612536 IP 192.168.22.22.netbios-ns > 192.168.22.255.netbios-ns: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST
    22:42:03.362246 IP 192.168.22.22.netbios-ns > 192.168.22.255.netbios-ns: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST
    22:42:04.112704 IP 192.168.22.22.netbios-ns > 192.168.22.255.netbios-ns: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST
    22:42:07.115135 IP 192.168.22.22.netbios-ns > 192.168.22.255.netbios-ns: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST
    22:42:07.864693 IP 192.168.22.22.netbios-ns > 192.168.22.255.netbios-ns: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST
    22:42:08.615152 IP 192.168.22.22.netbios-ns > 192.168.22.255.netbios-ns: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST
    22:42:32.031140 IP 0.0.0.0 > IGMP.MCAST.NET: igmp v3 report, 1 group record(s)
    22:42:32.056039 IP 192.168.22.22 > IGMP.MCAST.NET: igmp v3 report, 1 group record(s)
    22:42:32.082290 IP 192.168.22.22.3388 > 239.255.255.250.1900: UDP, length 133
    22:42:32.093840 IP 192.168.22.22 > IGMP.MCAST.NET: igmp v3 report, 1 group record(s)
    22:42:32.929051 IP 192.168.22.22 > IGMP.MCAST.NET: igmp v3 report, 1 group record(s)
    22:42:35.085173 IP 192.168.22.22.3388 > 239.255.255.250.1900: UDP, length 133
    22:42:38.085807 IP 192.168.22.22.3388 > 239.255.255.250.1900: UDP, length 133
    22:42:47.130748 IP 192.168.22.22.netbios-ns > 192.168.22.255.netbios-ns: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST
    22:42:47.881055 IP 192.168.22.22.netbios-ns > 192.168.22.255.netbios-ns: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST
    22:42:48.631364 IP 192.168.22.22.netbios-ns > 192.168.22.255.netbios-ns: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST

    So I can see only UDP Packets. Not sure if that means that the interface is working but misconfigured, or is there another problem ?

    I appreciate your help :-)

    Thanks,

    Dan



  • @dan2010:

    How can I enable reply back on ICMP echo req using the command line ?

    pfSense is a firewall and as such it is intended to be secure from initial installation. Therefore access from the WAN interface is strictly limited.

    For the time being then you would be better off making the pfSense interface closest to your local machines the LAN interface then you should get responses to your pings.

    @dan2010:

    The standard Interface, bge0 now works. However, bge1 doesn't work.
    bge1 is the Broadcom NetXtreme Gigabit Ethernet Controller.

    So I setup a machine on bge1 network, as I cannot get a DHCP ip from pfsense, gave it an ip of 192.168.22.22, and the pfsense bge1 192.168.22.1.
    I listened on the bge1 interface, when pinging from 192.168.22.22 to 192.168.22.1:

    pfSense is a firewall intended to be secure from the initial installation. With rare exceptions stuff doesn't get enabled unless it is specifically enabled. Hence you won't get DHCP service on an interface until you enable it from the web GUI. As described above, for security reasons I expect you initially won't have access to the web GUI from the WAN side so you need to configure your LAN interface with a fixed IP address (even a temporary address) and access the web GUI from the LAN side to configure DHCP, DNS, optional interfaces, name service etc etc.

    I've been using pfSense for a few years now so I'm quite familiar with the configuration process. I'm sure I got started initially by reading at least one clear "getting started" explanation in a document somewhere in the pfSense web site (follow the documentation link from the pfSense home page). Spending a bit of preparation time will quickly pay off.

    @dan2010:

    The standard Interface, bge0 now works. However, bge1 doesn't work.

    This sort of problem report is too vague for anyone to be able to help without asking further questions. If you supply some more information it can significantly reduce the elapsed time to resolve the issue. I think a useful template for problem reporting is to fill in the blanks in the sentence "I did … and I saw ... but I expected to see ...".

    From where you were at last report, I suggest you read at least one "getting started" document in the excellent documentation collection linked to from the pfSense home page and then use your system with IP address 192.168.22.22 to invoke the pfSense web GUI setup wizzard.



  • Hi Wallabybob,

    Thanks for your detailed reply.

    As per your email, my problem is : Interface bge1 is not working on the lan, is it a problem on the BSD side? Can I fix it ? I bought this computer specifically to run PF Sense, so I didn't expect to have this problem with the network card, the second one.

    To checked the problem further, I installed one extra PCI card, D-Link, and changed the config to make the new D-Link card as the LAN nic. IT worked.

    However, still the bge1, which is now the OPT Interface, is not working, not even sending DHCP leases. I have enabled DHCP server on OPT 1, and can see traffic on this interface, as sent on my last email, but I cannot get a DHCP id, nor can I get to the WebConf / Admin module through interface 196.168.22.1.

    I would appreciate if you can help me by pointing me to the right direction to fix this problem, as this computer has two built-in Network cards, bge0 and bge1. And cannot install further network cards except the one I have already installed, the D-Link one.

    Regarding documentation, could you send me a link for the startup guide as I couldn't find one, only installation guides, which I have already completed.

    Thanks,

    Dan,



  • A difficulty I have is that I don't have detailed enough history to understand what issues you faced at what stage of configuration. So lets go with something simple: You are seeing received traffic on OPT1 including DHCP requests, you have DHCP server enabled on OPT1, you have the web GUI operating and you don't see DHCP responses go out over OPT1.

    By default (for security reasons) the OPT interfaces don't have firewall rules allowing traffic. My guess is that the firewall is blocking the DHCP requests received on OPT1. You should look at the DHCP server log (in web GUI: Status -> System Logs, click on DHCP tab) and there should be some notification that the DHCP server startrted on bge1. If not, you probably haven't correctly enabled the DHCP server. If you see incoming DHCP requests in a packet trace then you should see those requests logged. If you don't have DHCP requests logged then you should check the firewall log (Status -> System Logs, click on Firewall tab) to see if the firewall is blocking DHCP traffic.

    It may be that you came to conclusion that bge1 as a LAN interface wasn't working because you were looking for a particular form of "working" before you had advanced sufficiently far through the configuration and setup. It could be worth rebooting and in the console startup selecting option 1 (Assign Interfaces) and then setting bge0 as WAN bge1 as LAN and not selecting any OPT interfaces, swap over the cables to bge1 and re1 and see if LAN now "works". If not, swap over the cables again, reboot and assign interfaces again, bge0 as WAN, re0 as LAN and bge1 as OPT1 to restore your current configuration. Then work through the previous paragraph (if you haven't already).



  • @dan2010:

    Regarding documentation, could you send me a link for the startup guide as I couldn't find one, only installation guides, which I have already completed.

    The main thing that provoked my comment about the documentation is that you apparently were trying to configure pfSense from the WAN interface. The install guide http://doc.pfsense.org/index.php/InstallationGuide strongly hints that the web interface should be accessed from the LAN interface (it says _Now we have rebooted and are presented with the “pfsense console setup” for a second time. At this moment you can unplug your monitor cable and manage this firewall via a browser or you could select option 8 and explore via a Shell.

    Make sure your computers interface is in the 192.168.1.0 subnet, because 'pfSenses' LAN interface is by default 192.168.1.1._ but I accept that the reader needs a certain base knowledge of IP routing to deduce that the initial configuration should be done through the LAN interface) and the referenced link (http://doc.pfsense.org/smiller/Install_Guide.htm) goes on to show the use of the setup wizard from the web GUI.

    My route to the referenced Installation guide: Documentation link from pfSense home page, click on documentation wiki then How-Tos then Installation Guide in the alphabetically ordered list of How-to titles near the bottom of the page..



  • H Wallabybob,

    Thanks again for you comments, suggestions and links.

    I have basic understanding that I won't try to access the webconfig from the WAN Interface. I have setup pfsense on a different machine sometime ago, with no such problems, it was working flawlessly, and that was an exercise I have to go through, deciding whether I should go with CISCO ASA 5XXX Series, or buy a good server, and run an Open Source Firewall, in my case, I found that the best one would be pfsense after reading different reviews.

    The couple of links you sent, I had already went through them, and they were irrelevant to my problem, of a card not working! Which was clear when I searched afterwards, FreeBSD with Broadcom BCM cards.

    To sum up, after doing your suggestions and swapping the WAN with the LAN, and changing the cables, the problems seems to be in the driver. The card is working, but something is wrong with the driver. I found that there is a patch to be applied to the driver, from FreeBSD, but I need to compile against the kernel.
    have a look at: http://forums.freebsd.org/showthread.php?t=6081

    So I still unable to use the second interface, which is swapped now with the OPT1.

    I would appreciate any help on this area of the driver.

    Thanks,

    Dan.



  • @dan2010:

    the problems seems to be in the driver.

    Please elaborate on what you think is the problem with the driver.

    An earlier reply said:
    @dan2010:

    I listened on the bge1 interface, when pinging from 192.168.22.22 to 192.168.22.1:

    22:41:52.946586 IP 192.168.22.22.netbios-ns > 192.168.22.255.netbios-ns: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST
    22:41:53.696292 IP 192.168.22.22.netbios-ns > 192.168.22.255.netbios-ns: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST
    22:41:54.446601 IP 192.168.22.22.netbios-ns > 192.168.22.255.netbios-ns: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST
    22:41:57.452032 IP 192.168.22.22.netbios-ns > 192.168.22.255.netbios-ns: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST
    22:41:58.201741 IP 192.168.22.22.netbios-ns > 192.168.22.255.netbios-ns: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST
    22:41:58.952047 IP 192.168.22.22.netbios-ns > 192.168.22.255.netbios-ns: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST
    22:42:02.610887 IP 192.168.22.22.netbios-dgm > 192.168.22.255.netbios-dgm: NBT UDP PACKET(138)
    22:42:02.612536 IP 192.168.22.22.netbios-ns > 192.168.22.255.netbios-ns: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST
    22:42:03.362246 IP 192.168.22.22.netbios-ns > 192.168.22.255.netbios-ns: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST
    22:42:04.112704 IP 192.168.22.22.netbios-ns > 192.168.22.255.netbios-ns: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST
    22:42:07.115135 IP 192.168.22.22.netbios-ns > 192.168.22.255.netbios-ns: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST
    22:42:07.864693 IP 192.168.22.22.netbios-ns > 192.168.22.255.netbios-ns: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST
    22:42:08.615152 IP 192.168.22.22.netbios-ns > 192.168.22.255.netbios-ns: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST
    22:42:32.031140 IP 0.0.0.0 > IGMP.MCAST.NET: igmp v3 report, 1 group record(s)
    22:42:32.056039 IP 192.168.22.22 > IGMP.MCAST.NET: igmp v3 report, 1 group record(s)
    22:42:32.082290 IP 192.168.22.22.3388 > 239.255.255.250.1900: UDP, length 133
    22:42:32.093840 IP 192.168.22.22 > IGMP.MCAST.NET: igmp v3 report, 1 group record(s)
    22:42:32.929051 IP 192.168.22.22 > IGMP.MCAST.NET: igmp v3 report, 1 group record(s)
    22:42:35.085173 IP 192.168.22.22.3388 > 239.255.255.250.1900: UDP, length 133
    22:42:38.085807 IP 192.168.22.22.3388 > 239.255.255.250.1900: UDP, length 133
    22:42:47.130748 IP 192.168.22.22.netbios-ns > 192.168.22.255.netbios-ns: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST
    22:42:47.881055 IP 192.168.22.22.netbios-ns > 192.168.22.255.netbios-ns: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST
    22:42:48.631364 IP 192.168.22.22.netbios-ns > 192.168.22.255.netbios-ns: NBT UDP PACKET(137): QUERY; REQUEST; BROADCAST

    Why is there is no sign of the ping in that trace?

    Here is what a ping exchange looks like on my pfSense system:

    
    22:45:06.736389 IP 192.168.11.241 > 192.168.11.173: ICMP echo request, id 9237, seq 66, length 64
    22:45:06.736544 IP 192.168.11.173 > 192.168.11.241: ICMP echo reply, id 9237, seq 66, length 64
    
    

Locked