Retired > 1.2.1-RC Snapshot Feedback and Problems-RETIRED

How can I be the only one with a broken RC2?

(1/4) > >>

berniem:
I've seen no one else reporting this, so I'm really confused.  At first, I thought it may have been flakey hardware, but I've tried it on 2.5 different platforms and I'm seeing the same thing.  Am I missing something here?

Problem: About every 5-10 boots, the pfSense box mostly ignores clients.  Specifically , clients cannot get new (or renewed) DHCP addresses from pfSense.  Further, even those machines which still have their old DHCP addresses are ignored (or, at least I see to responses back to the clients).  The one exception I see in Wireshark is when a client asks via ARP who has 192.168.1.1, the pfSense responds with the correct information (and the MAC addresses on both ends are correct).  But then, when the client sends out its properly-formed DHCP request, no response comes from the pfSense box.  A reboot (soft reboot or power cycle; doesn't matter which) will clear it up.  I've had it fail with only one "good boot" in between failures, or, more usual, having 5-10 boots between "bad boots".

When it's a "good boot", it will work fine and continue to work without problems.  If it was a "bad boot", it never gets itself working and a reboot is required.

Hardware: the 2.5 motherboards on which I can repro this:
   *) A Jetway J7F5M1G2E with a 3-gigabit-port daughterboard
   *) A Jetway J7F2WE1G5D with the same 3-gigabit-port daughterboard (hence the .5)
   *) A Jetway J7F4xxxxxx-something with an Intel Pro dual NIC.

I'm running the November 19 "official" RC2 build.  It's a pretty vanilla installation - no extra packages installed, and no patches.   The one thing that is common which is out of the "default" is that the installations are installed as a full install and then the /etc/platform file is edited for "embedded".  However, I can say that in at least one of the test passes, I changed that back to "pfSense" and still had the problem (after a few boots).  Dunno if that has any significance, but it's the only thing I could think of that was non-standard.

Anyone care to venture a guess as to where I might look for a clue?  Or is there more information I could supply to help someone else take a guess at what's up?

Thanks.

wallabybob:
Do you see the DHCP requests on the pfSense box? (On the console or ssh session, type

--- Quote ---# tcpdump -i <interface name>
e.g. # tcpdump -i re0

--- End quote ---

Do you see the incoming DHCP requests? If not, you most likely have a physical layer problem.

If you see DHCP requests, check the DHCP server log to see if they have been logged: On the web GUI, status -> System logs -> DHCP tab. If not, check if they are blocked by the firewall (click on Firewall tab next to the DHCP tab) and that the DHCP server is running (in ssh session type

--- Quote ---# ps ax | grep dhcp

--- End quote ---

That should give some more information to work with.

berniem:
Ah!  Excellent suggestions.  It turns out that tcpdump has likely answered the original question, but then also prompts the next question:

I put the pfSense box in the state where it seems to be ignoring (other than ARP) packets from the client.  As soon as I do the tcpdump -i re1 (re1 is the LAN), the DHCP renewal will work immediately.  To me, this implies that maybe the card had not been in promiscuous mode.  So, I get the box to the bad state again and BEFORE doing the tcpdump, I do a ifconfig and I do see the line:
pflag0: flags-100(PROMISC) metric 0 mtu 33204
which, I assume, means that the system thinks the driver/card is already in promiscuous mode.

Is there a different way I can see whether or not the driver/card is -really- in promiscuous mode?

In either case, anyone have a guess as to what could cause these situations?  (IE:  case #1: the driver/card is not in promiscuous mode even though it should be and the ifconfig thinks it is;  or   case #2: the card IS in promiscuous mode but not responding to packets (other than ARP) until tcpdump is started.)

Thanks.

ermal:
What happens after you kill tcpdump?

wallabybob:
You can access the FreeBSD man pages at http://www.freebsd.org/cgi/man.cgi

tcpdump -p
doesn't put the interface into promiscuous mode.

tcpdump -e
displays the link layer headers including source and destination MAC address.

Perhaps you could use these options together to see if promiscuous mode really is a factor in this. If so, check the link layer addresses. I'm thinking that when DHCP doesn't work the packets coming to pfSense don't have the correct link layer (MAC) address and so are discarded until you switch the interface into promiscuous mode by running tcpdump. Perhaps you have another system on the network that is supply the wrong MAC address in response to an ARP query. Checking the MAC addresses in the packets should give you a clue as to whether or not this is happening.

Is your pfSense connected to a hub or a switch? (If a switch, the promiscuous mode shouldn't make a difference unless pfSense is plugged into a "monitor port" which is getting all the traffice for 'monitoring' purposes.) What is the configuration of your local network?

Navigation

[0] Message Index

[#] Next page

Go to full version