Problems between iphone and dhcp?

Gertjan

@edpbettinelli said in Problems between iphone and dhcp?:

I don't know the details of how iPhones manage dhcp

Look in the pfSense log for details.
Look at the dhcp leases file (the file the DHCP uses to store all the leases it gave away to devices)
On the apple.com site, the 'dev' part, there are tools to be downloaded to can detail much more a what can be seen in the apple phone GUI.
Is this iOS 14.6 ?

This is the lease duration as the DHCP server registered my "192.168.2.222" iPhone lease :

lease 192.168.2.222 {
  starts 4 2022/03/17 15:52:06;
  ends 4 2022/03/17 21:52:06;
......

This doesn't mean the DHCP client on the iPhone side will respect this delay.

So, in theory, my iPhone will renew the lease after 3 hours.
But most probably I will walk out of the Wifi covered zone, walk back into it, so the DHCP client will kick in again, and most probably ask a new lease, etc etc.

Btw ; I've read here that there are VLANs in play.
There is another factor, not mentioned because we can't see, smell or hear it :what about the AP used ? These devices are not all equal. What about the equality of the radio waves ? Other radio devices near by ? Is there a micro wave close by that blast out of orbit the frequency range from 0 to 5 Ghz ??

I've been using iStuff from day one, on good AP's and plain crap ones. Very rare that I even suspected that the Apple stuff was doing things wrong. And if so, an Apple update took care of things.
Right know, I"m using iOS 14.x 6 ? (as since this morning) : no issues known to me.

edpbettinelli

@gertjan
I'm trying to create a small factory to be able to test without impacting the company. Soon the wifi bubble created by 60 old AP extreme will be replaced with 50 AP Aruba. I will try factory testing using both an Aruba AP and an old extreme to evaluate any differences. Maybe so I'll have a little clearer ideas. A thousand thanks
Luca

stephenw10

Yeah, the iphones could still be requesting a very short lease time. Check the logs to see what they are actually being given.

Steve

edpbettinelli

@stephenw10
Hi guys update..
i have implemented a small lab with a switch an ap and the same pfsense 2440 model with the same rules. After going through all the operations (dhcp restart, reservation, resolver restart) that could give me the problem, my iphone never lost a ping.
At the level of the production FW I noticed that there was a problem on the pfsense ntp in the release of the lease time and after fixing this thing the problem seems to have changed, the disconnection from pfsense is much shorter and above all it affects only some phones apparently random.
Occurred on multiple simultaneous voip calls only a couple of people lost the ping and consequently the call with pfsense. I am a little confused.
I was able with packet capture to take a snapshot of when the problem occurs. attached
error_fonia2.cap error_fonia.cap

johnpoz

@edpbettinelli ok a quick look at those - and 2 things jump out at me as odd.

You keep trying to talk to this

;; QUESTION SECTION:
;35.231.241.80.in-addr.arpa.    IN      PTR

;; ANSWER SECTION:
35.231.241.80.in-addr.arpa. 38400 IN    PTR     mx1.ot-mail.it.

on port 443, sending lots of syn - but never see a syn,ack back

Other thing this is odd - is why I assume pfsense 10.135.0.1 keeps arping for 10.135.0.146 - but never sees a response. But when .146 arps for .1 - you get a response.

So you can see here - you get a ping request, but no response - .1 arping for .146... But then after .146 arps for 1 and gets a response your pings get replies..

I also see bunch of dns queries to 8888 and 1111 but never see any responses.. Are you blocking dns to them?

edpbettinelli

@johnpoz said in Problems between iphone and dhcp?:

So you can see here - you get a ping request, but no response - .1 arping for .146... But then after .146 arps for 1 and gets a response your pings get replies..

This is the picture of my problem.
ot-mail (ip 80.241.231.35). is the company's mail server and 8.8.8.8 and 1.1.1.1 the dns assigned by dhcp are obviously not blocked. at that moment pfsense does not respond to the iphone, then as you can see without doing anything the connectivity restores the ping replies arrive the dns replies etc .

johnpoz

@edpbettinelli said in Problems between iphone and dhcp?:

the dns assigned by dhcp are obviously not blocked

They are not getting any answers..

In neither of your sniffs do I see any dns answers.. Maybe its asking something else.. But there are no answers to dns in either of your sniffs.

And why is .146 not answering any arps?

edpbettinelli

@johnpoz At this moment I don't know how to give you an answer. I'd like to say that I stopped packet capture before connectivity resumed. I will try to do other tests in the lab even if I haven't verified the problem yet. In production it is now risky to test now. However, at a company not in production I will try again to make some captures.
Thank you very much for helping

johnpoz

@edpbettinelli here is the thing - the really odd thing is why .146 is not answering the arps.. But pfsense for sure could not answer a ping, if he doesn't have the mac address of .146 in his arp table.. If he had the mac in his arp table, he shouldn't need to arp for it..

I would really look to why not answering those arps..

edpbettinelli

@johnpoz I forced the situation and I think I can provide you with the correct capture. After the block comes the replies as well. I confirm that the previous capture was aborted before reconnection.completo-packetcapture.cap

stephenw10

Hmm, it looks like something is blocking that ARP traffic maybe.

Where was that pcap taken?

You can see pfSense ARPing for the iphone and it never replies.
Then later you can see the iphone ARPing for pfSense and pfSense replies but the iphone just keeps ARPing for it as though it never sees the replies.

Then the iphone sends an ARP announcement and that is seemingly enough for pfSense to populate it's ARP table and respond to pings.

Still something odd there though because after the pings restart the iphone still ARPs for pfSense one last time. Yet at that point it must have the pfSense MAC address already.

Steve

johnpoz

@edpbettinelli

Still not understanding why .146 is not answering arps!

He makes announcements - but doesn't answer when asked.. This is going to be very problematic!

Look in pfsense arp table for this .146 by default arp should be cached for 20 minutes.. But also when asked a client should answer.. So either phone is not getting them? Or is and just not answering?

stephenw10

Seems like something is blocking it since the iphone also appears not to see the ARP replies from pfSense.

johnpoz

@stephenw10 but those are being answered - so pfsense saw the arp, and answered them.

edpbettinelli

@stephenw10 I launched the packet capture on voice vlan with host address 10.135.0.146 in promiscuous mode

Gertjan

Suggestions : some hardware checks :

Take the iPhone out for lunch, and connect somewhere else using Wifi.
Change the cable between the pfSense LAN NIC and the AP.
Change the AP.
Exchange the LAN and WAN NIC.

More difficult : Does your AP have a survey mode ? Can it tell you whatever other wifi networks exist in the neighbourhood ? I mean : radio signals can get get drown in the noise if there are a radio transmitters nearby. These could be other wifi signals, or worse.
pfSense can arp what it want, but what if the arp request never reaches the iPhone ?
(hey apple, can we have a packet capture app for the iPhone ?? :) )
Or, the AP has a lot of power to transmit, the signal reaches the iPhone, but the iPhone, with its small wifi signal, never makes it back to the IP - and then it does for a moment, and then the signal gets lost again etc etc

For what it's worth : if the issue is "ARP" then your close to a hardware issue.

Or someone is really using "ebtables**" in an AP to enforce 'client isolation'. That very subject was one of my first posts on this forum.

Not iptables. ebtables, a MAC based "L2" Linux firewall.

stephenw10

@johnpoz Exactly, but the iphone keeps ARPing for pfSense so it looks like it's not seeing those replies. One could assume it may also not be seeing the ARP requests from pfSense, which is why it never replies.

johnpoz

@stephenw10 said in Problems between iphone and dhcp?:

One could assume it may also not be seeing the ARP requests from pfSense, which is why it never replies.

Quite possible - something clearly is wrong here with the arps.. There should be no reason for pfsense to arp that many times for something. Unless its not getting an answer..

And same goes for the phone for sure.

Something wrong with arp is most likely the root of this issue.

edpbettinelli

@gertjan I will try to do these tests in the test environment, thank you for your suggestion. Furthermore, the replacement of the old wifi extreme bubble with the new Aruba APs is expected in the next few days. At this point I stop for a moment with the tests to try again with the new infrastructure to see if the problem persists.
Thanks everyone for the help

stephenw10

Some proxy-arp happening (or not happening) somewhere? Not sure why it would be in a network like that.