Phil, thanks again. Makes sense. I didn't think of the fact that if packets are switched on the switch, pfsense is not involved. I'll look at the switch then. And as for point 2. –> strange. Where could I look for more details on hosts connected? Take care, 0lek

I am getting something that sounds very much like this.  Next time it happens I will check the same logs to see if the same thing is happening.

The 192.168.100.x that the cable modem is giving out is actually due to the connection on the cable interface being down.  The cable modem (specifically motorolla) will 'unbridge' when the cable connection is down and then give out an IP in the above subnet.  You do not need to do anything usually, once the cable connection comes backup, it will register the pfsense wan interface 'mac address' to the dhcp server on the cable network and update the ip adress to the current wan ip given by the cable companies dhcp forwarder.

I'd leave it on all since thats what mine is set for and working fine like forever.

Interesting stuff. I think a number of us would be interested in that discussion in public, no need to switch to PM. The General Discussion board always open for completely OT topics.

No it would not be a unicast offer, and no it wouldn't be multicast either.. Offers can not be unicast, since the client does not have an IP yet ;) An offer would be to 255.255.255.255 dest port 67..  Now if your working with relays then sure stuff can happen over unicast during the relay.

I had a feeling that was the answer, so I just changed the TLD to .lan and it's all good now.  Thanks!

"I don't know if you understand my problem." Not really.. not able to access a url quite often is dns related.  What is the URL?  Is this some dynamic fqdn pointing to pfsense wan IP??

Yea got the pcap… Its from a DHCP offer malformed packet...where I didnt make the request. Sent on the broadcast (cable modem ISP) that hit my box. Still investigating. Wrote some suricata rules, motitoring and capturing more... F.

boa noite  aconteceu  a mesma  coisa comigo  também  tive  de  fazer  a restauração  do  bkp  para voltar  mas  agora  tudo  funcionado.

Thanks for the response! I do have DHCP leases registered in DNS, will have to check the system log and gateways log - not able to at the moment.  I do know that clearing the DHCP log (which restarts DHCP) stops the incessant reading of /etc/hosts for a while.

Ok, here's an example of what I wrote about earlier and also what I've seen on earlier versions of pfS too. I have edited and only pressed 'save' on the top three entries and all of them picks up the correct IP and shows it in list, two are Loopia and one DYN, doesn't seem to be the issue what type of account it is. [image: 141030-pfsense-dyndns-buggy-behavior-after-new-host_reediting.png] [image: 141030-pfsense-dyndns-buggy-behavior-after-new-host_reediting.png_thumb]

Well for starts the only box that can talk to 127.0.0.1/loopback is that box itself.. So nobody can query that other than the pfsense running tinydns Why do you need to run tinydns to have a few names resolve - the dns forwarder that is built part of pfsense can resolve pretty much any host name you want to any IP you want, just create an over ride in dns forwarder or have it register dhcp clients if you want, etc. Running tinydns to resolve a few names is overkill.

IMHO they have finally fixed a broken setup then.  You should not have reservations for same hostname, mac or IP on in your dhcp server.  MAC to IP should be a unique combination when setting reservations - your run into a possible problem of duplicate. To be honest your wireless network shouldn't even be on the same segment as wired devices for security reasons ;) If you want make your wired interface 192.168.1.42, and 192.168.2.42 on wireless for example.  You could use the same fqdn if you wanted too. Here is the thing with wireless clients - they fairly often never actually release the lease and just disappear off the network - how does the dhcp server know if he should give that IP to wired mac that asks for it when he doesn't know for sure if wireless gave gave it up, etc.