@rodymcamp:

interesting, i am having the same issue, where did you edit the file to fix?

i had 192.168.1.1 as a dns server.

now i use 8.8.8.8 and my domainname

Hmmmm…  I didn't see those links or maybe just wasn't paying attention.

@jimp:

The code that is in place is correct for most setups, perhaps there is something else unique/incorrect about your configuration contributing to the detection failure, but we had some fallout from this while testing the -RELEASE images.

So the code is back to how it was before, and it is confirmed working on several very large CARP+DHCP Failover setups. If it does not work for you on 2.1-RELEASE, I'd take a closer look at your configuration first.

Okay. I don't see how the original code could be correct, since the loop variable to
check for "a defined vip" (according to the commentary) isn't actually used for
searching, and I pointed out that your fix was not correct either.
But I understand you don't want to break things just before release. My later
version seems to work correctly for me, so I'll just work with a local patch then.
I suggest to have a look at this again in 2.1-stable .

Cheers,
Markus

PS: for illustration (original):

                                foreach ($a_vip as $vipent) {                                         if($int == $real_dhcpif) {                                                 /* this is the interface! */                                                 if(is_numeric($vipent['advskew']) && ($vipent['advskew'] < "20"))                                                         $skew = 0;                                         }                                 }

can be transformed into:

          if($int == $real_dhcpif) {                       foreach ($a_vip as $vipent) {                                     /* this is the interface! */                                     if(is_numeric($vipent['advskew']) && ($vipent['advskew'] < "20"))                                             $skew = 0;                       }           }

and this just doesn't look correct to me.

Ah that's good to hear - somehow anyways :-
But it's interesting and a bit disturbing to see another issue arise which is more or less depending on multi-cores and/or threads. Hopefully that won't be the start of a trend.

Greets

@stephenw10:

So your problem is that it's not working?

Looks like the modem is configured correctly but it trying to connect to something that's not answering. Are you sure the APN details are correct?

Steve

The settings works fine when I use it with the windows software. I think it has to do with missing APN details rather? I think it is out of the forum's hands? I live in the Philippines, if there is any Philippine PFsense Usersn out, I need local network Knowledge.

THANK YOU SIR!

Exactly what I needed to do - I'm always tickled when someone actually posts their own solution instead of saying "I fixed it" - I've added a few links to your note - there are lots of other people with similar issues, but some of them don't seem to have found answers as pretty.

Cheers!

Here's one solution…

http://forum.pfsense.org/index.php/topic,57866.msg309347.html#msg309347

FYI- pull requests are automatically made into patches by github.

You can just feed https://github.com/pfsense/pfsense/pull/799.patch into the system patches package to test it.

Ahh, I totally see it now. I removed the bad reply so no one would follow bad advice.

Thank you guys!

Yeah with apinger fixes that are on 2.1 it should behave better.

@wallabybob:

Thats what I thought at first but a second look showed the routing table entry I queried within the pfSense netstat -rn output/

I don't think I have ever seen such an entry on a pfSense system. I wonder if this is some weirdness related to use of DHCP relay. I wonder what dhclient reports in the logs. What sort of software runs in the DHCP relay?

A system.log fragment. I don't see anything bad. Is it a way to increase verbosity of dhcp client logs?

Sep 10 13:36:13 gw dhclient[33448]: DHCPREQUEST on em0 to 255.255.255.255 port 67 Sep 10 13:36:20 gw dhclient[33448]: DHCPREQUEST on em0 to 255.255.255.255 port 67 Sep 10 13:36:22 gw apinger: ALARM: WAN(192.168.52.1)  *** down *** Sep 10 13:36:29 gw dhclient[33448]: DHCPDISCOVER on em0 to 255.255.255.255 port 67 interval 5 Sep 10 13:36:32 gw check_reload_status: Reloading filter Sep 10 13:36:34 gw dhclient[33448]: DHCPDISCOVER on em0 to 255.255.255.255 port 67 interval 10 Sep 10 13:36:36 gw dhclient[33448]: DHCPOFFER from 192.168.52.1 Sep 10 13:36:36 gw dhclient: ARPSEND Sep 10 13:36:38 gw dhclient: ARPCHECK Sep 10 13:36:38 gw dhclient[33448]: DHCPREQUEST on em0 to 255.255.255.255 port 67 Sep 10 13:36:38 gw dhclient[33448]: DHCPACK from 192.168.52.1 Sep 10 13:36:38 gw dhclient: BOUND Sep 10 13:36:38 gw dhclient: Deleting old routes Sep 10 13:36:38 gw dhclient: Starting add_new_address() Sep 10 13:36:38 gw dhclient: ifconfig em0 inet 192.168.52.233 netmask 255.255.255.0 broadcast 192.168.52.255 Sep 10 13:36:38 gw dhclient: New IP Address (em0): 192.168.52.233 Sep 10 13:36:38 gw dhclient: New Subnet Mask (em0): 255.255.255.0 Sep 10 13:36:38 gw dhclient: New Broadcast Address (em0): 192.168.52.255 Sep 10 13:36:38 gw dhclient: New Routers (em0): 192.168.52.1 Sep 10 13:36:38 gw dhclient: Adding new routes to interface: em0 Sep 10 13:36:38 gw dhclient: /sbin/route add default 192.168.52.1 Sep 10 13:36:38 gw dhclient: Creating resolv.conf Sep 10 13:36:38 gw dhclient[33448]: bound to 192.168.52.233 -- renewal in 3600 seconds. Sep 10 13:36:38 gw check_reload_status: rc.newwanip starting em0 Sep 10 13:36:42 gw php: : rc.newwanip: Informational is starting em0. Sep 10 13:36:42 gw php: : rc.newwanip: on (IP address: 192.168.52.233) (interface: wan) (real interface: em0). Sep 10 13:36:42 gw php: : ROUTING: setting default route to 192.168.52.1

DHCP relay is D-link DGS-3420. It is running for several months in this configuration and no strange effects have been observed yet.
Finaly i've tried to attach that instance directly into 192.168.39.0/24 segment (no relay between dhcp server and pfsense client) – the strange entry still exists but dns connections work (because of the same broadcast domain).
I think it could be some kind of pfsense- or freebsd-specific script that adds this route for some reason but couldn't catch it yet(

Your diagram is somewhat helpful but suggests to me that 192.168.39.0/24 is on a different broadcast medium (distinct LAN segment) than 192.168.52.0/24

Yes, different vlans. And I've tried tcpdump on em0 – sure, different vlans and no cross-broadcast traffic between them

@doktornotor:

Afraid it's not even LAN but something "in front" of WAN.

It's in front of WAN, yes. It's my internal DNS+DHCP server. And the instance of pfsense i'm having an issue whith is a gate into a kind of isolated subnetwork 192.168.210.0/24 (which contains a demo-stand that can be moved out of the office and displayed somewhere else)

You realize that these are realtime graphs? The persistent ones are provided in Status - RRD graphs - Traffic tab. Cannot see anything unusable about it.

@kejianshi:

Have you been able to diagnose why your openvpn crashes all the time?  Thats strange behavior.  Not at all something happening for me here.

Its a combination of using the firewalls in CARP clusters, having OSPF running and having a full cross mesh OpenVPN connections between three sites.

The single biggest reason for OpenVPN to dump due to a fatal error is because of not being able to bring up the ovpn tunnel interface or not being able to inject the route in the kernel's routing table.

the next thing I am working on it to make the start script resilient to such problems and try to recover from them, fix the issue and restart the openvpn service. Probably not going to be able to finish it since I am already 2 weeks behind in delivering this overall solution to a client.

That would be nice wouldn't it?

@ssheikh:

Your DMZ destined traffic does not match that rule because that traffic does not traverse through any members of the gateway group. When you explicitly specify a gateway for a rule, your firewall's routing table is ignored.

Learned something new today.  Thanks for the reply!

no change.

thanks though.
rody

@doktornotor:

@rodymcamp:

I am not using ipv6 at all on my network.

env ip6addrctl_enable="yes" ip6addrctl_policy="prefer_ipv4" /etc/rc.d/ip6addrctl start

and try again.

I ran a packet capture on the pfsense box and the box issuing the DHCP request, both identical.
yes, my first stop was the log and that shows its making an offer, so then I ran a packet cap at both ends.

Cool…  I'm glad that works.