Connect. Communicate. Collaborate. Securely.

Home » Kerio User Forums » Kerio Control » Problem with Apple devices and DHCP
  •  
ERTW

Messages: 4
Karma: -1
Send a private message to this user
Greetings, everyone.
Some help/insight/suggestions for a work-around to this Apple and Kerio Control 7.4.2 build 5136 issue would be much appreciated:


Apple devices (iPhones, iPads) keep declining IP address leases specifically reserved for them... even though there are no conflicts / no other devices on the LAN using those addresses! (Aside: Every non-Apple device that has ever connected to the LAN has never had a DCHP DECLINE incident... so I'm tempted to put the blame squarely on Apple for this one.)

But regardless of who at Apple screwed this up, I still need to find a work-around. (Much as I'd like to, I can't simply tell the Apple users to dump their junk and get something that works properly.)

I even tried adding several DHCP reservations (by MAC address and by hostname) for each Apple device, with each redundant reservation having a unique IP address. (So if it declines one, it can at least take a known alternate "backup" IP address.) But after the first DHCP DECLINE (that I noticed), Kerio Control fell back to offering a random IP address instead of one of the remaining reservations! (Either this is the fault of Kerio's programmers, or all the other redundant reservations had already been marked DECLINED before I began investigating.)

Furthermore, after enabling the Debug Log and looking at the DHCP messages, it appears that often the Apple devices will decline several of the random IP address offers too, before finally settling down and accepting something.

As a further annoyance, the only way I was able to clean out the declined IP addresses after Apple pissed in the pool was to shut down Kerio control and then manually edit the file Leases.cfg before restarting. (I was not going to wait-out the 86400 seconds that a reservation remains marked "DECLINED"; that's WAY too long! Anyhow, not only does restarting interrupt service for everyone & everything, it also resets the Daily and Weekly data counters! Shame on Kerio's programmers for this defect!)

Then I found this hack: Edit the WinRoute.cfg file and modify the <variable name="DeclineTimeout">86400</variable> entry (within <table name="DHCP"> ) to 0 seconds (instead of the default 86400). That solved the problem of a poisoned DHCP pool; reservations no longer become off-limits after being declined! But now there's a new problem: Apple devices take about 15 ~ 20 minutes to eventually accept their IP address, after flooding the network with a packet-storm of hundreds of DHCP DECLINE, DISCOVER, REQUEST packets (which of course elicit hundreds of DHCP OFFER and ACK replies)!

I have zero pity for the sheep who claim Steve Jobs is God and their iPhone is the Holy Grail, and now complain about the 20-minute connect times on this network. But I do pity the unfortunate people who didn't realize what they got themselves into when they bought their iPhone. And I get irritated at the drop in network performance due to the Apple-instigated DHCP packet storms.


What should I do? What can I do?

I can't move on to a later version of Kerio Control, because as far as I know, 7.4.2 build 5136 was the last one to run under Windows.


Some further info, for the curious:

I have Kerio Control running on an IBM IntelliStation E Pro running Windows XP Pro.

The computer has 3 network interfaces -- its onboard Ethernet, an Ethernet PCI card that was later installed, and a TP-Link N600 USB Wi-Fi adapter.

The PCI card is used as the WAN uplink; it's working fine, no problems.

The TP-Link N600 is configured to act as an "Access Point" using TP-Link's lousy provision software. Although TP-Link's garbage normally tries to activate Windows Internet Connection Sharing (whether you like it or not!), I deleted it's "helper" IcsManager.exe program to prevent this from happening. (I replaced it with a "do nothing" program I made and compiled as IcsManager.exe, so TP-Link's over-assuming software doesn't bark and complain. Problem averted.)

I then used Windows XP's "Network Bridge" feature to bridge the onboard Ethernet interface with the TP-Link N600 USB Wi-Fi interface, and set this bridge to be the "LAN interface" for Kerio Control. (That way, LAN devices can connect by Wi-Fi or wired.)

[Updated on: Fri, 25 August 2017 05:32]

  •  
fishtech

Messages: 627
Karma: 14
Send a private message to this user
Kerio Control 9.x installed here.

All clients are MacOS/iOS. About 50 addresses are reserved. The problem you describe has never been experienced here.

Control has been running for 5 years or so... can't remember what version we started on.

ft..

[Updated on: Thu, 31 August 2017 15:40]

  •  
ERTW

Messages: 4
Karma: -1
Send a private message to this user
This IBM IntelliStation E Pro w. Kerio Control 7.4.2 b5136 and Win XP Pro has been running continuously for 4 years. This problem never became apparent until recently.

It should be noted, however, the "Network Bridge" was a recent change in configuration. Originally the TP Link N600 and the computer's onboard Ethernet interface were on separate subnets. This allowed network software to immediately determine if a LAN client was using Wi-Fi or using wired Ethernet, just by looking at its IP address subnet. But it was an administrative pain because each client required two DHCP reservations (one for each interface).

Then we got some network software that relied on IP broadcasts, which of course could not cross through from one subnet to the other. That forced a change in configuration from two subnets to a single subnet and bridging the two LAN interfaces.

It was shortly after this change that the DHCP problem surfaced. BUT...

...At the same time the IP addressing plan was changed, we also got a huge wave of new users bringing in their own equipment! So I can't say for sure if it was the Win XP Network Bridge and single-subnet that triggered the problem, or if it was the wave of new iPhones and new iPads that are responsible for this issue.

I am still leaning towards criticizing Apple for it though, because none of the non-Apple clients that were still retained seemed to have any problem even after we changed the network to its single-subnet plan. And none of the new users who arrived with Android, Windows 7, and Windows 10 equipment have had any problems. And none of our long-time users (who may or may not be using Apple stuff) reported any problems. (It was only the new users that alerted us they couldn't get access to some network services; it was then that we discovered their devices were not being assigned the proper reserved IP addresses.)
  •  
fleecy

Messages: 18
Karma: 0
Send a private message to this user

Apple has nothing to do with your issue.

Sounds to me like you should consider replacing your Intellistation's hard drive with a blank one (or an SSD) and install the Kerio Control Software appliance on there. Keep the old drive in case you need to go back in time quickly.

Windows XP is clearly ready for retirement in your setup. You'll benefit from Kerio Control's latest improvements (there are many of those) and solve your weird issues at the same time.

My 2 cents
  •  
ERTW

Messages: 4
Karma: -1
Send a private message to this user
I appreciate the response... but if I may politely disagree... there are some specific points of contention. Pardon the long rebuttal:


fleecy wrote on Tue, 26 September 2017 14:08

Apple has nothing to do with your issue.

Apple has everything to do with it! When Apple devices -- and only Apple devices -- are declining an IP address because they think it is "in use" when it really isn't, those Apple devices are clearly making a mistake. Such Apple devices were programmed by Apple employees, which makes Apple (the company) undeniably at fault for not correctly implementing DHCP.

If even one other device that has ever used the network would have done the same thing, I'd say there's possibly some other fault. But it has been over a month now and still the only offenders are exclusively Apple. The network has also been used by hundreds of devices that were invented/developed anywhere from recently to 19 years ago... and still the only offenders are a recent batch of exclusively Apple products!

It doesn't take rocket science... or any science... for even the most amateur of statisticians (ie. general population) to conclude the fault must obviously be in Apple's recent implementation of DHCP. (This fact remains true regardless of how much Apple might be paying you to defend them, or how much commission you make selling Apple products, or how sour those grapes must be if you recently purchased an Apple product and want to convince yourself to feel good about it. No offense.)


fleecy wrote on Tue, 26 September 2017 14:08

Sounds to me like you should consider replacing your Intellistation's hard drive with a blank one (or an SSD) and install the Kerio Control Software appliance on there. Keep the old drive in case you need to go back in time quickly.

That's great... except the IBM IntelliStation is running other software too. If it was converted to a Kerio "software appliance", it would take some rather diligent hacks -- and even redevelopment of some programs -- to achieve the same functionality the system has right now on Win XP. At that point, it's probably easier to procure a whole new separate computer system instead and make that a dedicated Kerio Control appliance. (And then run that in tandem with the existing IBM IntelliStation relegated to only running it's other (non- Kerio Control) tasks.) Which is not exactly easy... nor elegant.

Either way, the amount of time, down-time, labour, and frustration this would all involve, simply to work-around Apple's defects, can not be justified. Not unless Apple is ready to mail some of their paychecks to me, to compensate my labours for working to resolve something of their incompetence!


fleecy wrote on Tue, 26 September 2017 14:08

Windows XP is clearly ready for retirement in your setup. You'll benefit from Kerio Control's latest improvements (there are many of those) and solve your weird issues at the same time.

Credit where credit's due, I do agree with you that there are many improvements. (I read about several in the changelog.) And yes, they would be nice benefits.

But I just can't justify the enormous hassle of scrapping the entire operating system and everything else that's running on it, just because a few individuals at Kerio decided either they no longer want to compile for a Win32 platform, or they decided to replace their past compilers / IDEs for some other ones that simply don't compile to Win32/XP anymore. (Or they're implementing platform-specific libraries now to do tasks that had previously been done without them... and Kerio staff either don't feel like modifying the libraries to be Win32/XP compatible, or they don't have the legal freedom to do so? I don't know, I can only speculate here.)

(Not that WinXP is particularly great or efficient... but in the world of Windows, it is the fastest operating system that can still run reasonably modern codebases. Hence why I won't retire it for a slower and less-efficient (newer) version of Windows; that would be ludicrous. Granted, retiring it for Linux or some UNIX-based OS might bring a windfall of improvements... but I have to weight that against the loss of some software and the time/cost/effort of finding suitable replacements and the tedious reconfiguring/customizing and script programming/reprogramming that follows. What a pain in the @$$!)

(And sorry Kerio, I'm not about to jump an entire ship (and let the old one flounder) just to get one program's new features. Especially when I don't even know for sure whether the new versions of said program will actually tame Apple's defective stuff!)

My 2 cents
  •  
blturner

Messages: 36
Karma: 0
Send a private message to this user
Could it be possible that your Kerio is offering an IP address in a subnet different from the IP address of the firewall/DHCP server? I suspect that the decline error is the only error that a DHCP client can throw and that it would be a good idea to open up to other issues that might be causing it. An IP address offer that does not match the subnet of the gateway is one of those edge cases that different vendors might interpret differently.
Another possibility that I can think of is that the iPhones in question think that they are on a different network that has the same subnet but is actually their home network. For example, if your network is 192.168.1.0 and their house is also that network. Rebooting the phone is a test for this one. But I could be sending you chasing a red herring with that one. And it's not like you could re-number your network. You could perhaps add another wireless card and let the apple devices connect to that.

A possible explanation that probably does not help is that the standards bodies that control the DHCP standard may have changed it years ago and now the Apple devices are following the new standard and not working with old DHCP servers. This could be for better security or faster performance. Other wireless devices will soon start to do the same thing. If that is the case then this is just the beginning of problems.
  •  
blturner

Messages: 36
Karma: 0
Send a private message to this user
To clarify what I said. Could the old IP address of the wireless still be in your configuration somewhere. You could delete and re-add the wireless interface and clear that.
  •  
ERTW

Messages: 4
Karma: -1
Send a private message to this user
blturner wrote on Fri, 06 October 2017 17:41

Another possibility that I can think of is that the iPhones in question think that they are on a different network that has the same subnet but is actually their home network. For example, if your network is 192.168.1.0 and their house is also that network. Rebooting the phone is a test for this one.


That is an interesting point. I spoke to a colleague about this just last week, and he speculated the same thing -- user takes their iPhone from some other premises with an identically-numbered LAN to this one... Kerio Control then offers a vacant IP address (that was not vacant on the other LAN), and so the iPhone declines it.

I would think that when a device jumps from one SSID to another, it should automatically flush its ARP cache too (or whatever it's using to "remember" what other IP addresses are on the same network segment). I believe Windows XP does that (assuming "Media Sense" is left enabled), even for IEEE 802.3 (wired Ethernet) interfaces when the cable is unplugged!

It makes me wonder if maybe iPhones keep individual ARP tables cached, one for each unique SSID to which the phone has recently connected? Then if some other Wi-Fi LAN has the same SSID, this could most definitely be a problem.

...but why would anyone copy our SSID!?



I think this is going to be a tedious and difficult issue to nail down.
Meanwhile the trouble reports keep flooding in...
Previous Topic: Unwanted disconnect VPN Connection
Next Topic: How Can Block Psiphon by Kerio Control?
Goto Forum:
  


Disclaimer:
Kerio discussion forums are intended for open communication between forum members and may contain information and material posted by members which may be useful in learning about Kerio products. The discussion forums are not intended to provide technical support for any specific product. Any information implied or expressed in the discussion forums is that of the posting member. Kerio is in no way responsible for the information posted in the forums, or its accuracy. Kerio employees may participate in the discussions, but their postings do not represent an offical position of the company on any issues raised or discussed. Kerio reserves the right to monitor and maintain the forums to promote free and accurate exchange of information.

Current Time: Tue Nov 21 18:46:08 CET 2017

Total time taken to generate the page: 0.00429 seconds
.:: Contact :: Home ::.
Powered by: FUDforum 3.0.4.