1) Time/Date Sept. 09/08
2) Response time
3) Product WT4090
4) OS Version BSP35
5) Clarify Case #1965123 · The WT4090’s running Rev F BSP35 is polling the DHCP server much more often than the WT4090’s running Rev D BSP30. · The DHCP Leases the IP Address on a 3 Day Lease. · The DHCP Server is off site and maintained remotely. The issue still is that the when the WAN Link for the Distribution Centre DHCP Server failed the devices should have continued to operate as there addresses are on a 3 Day lease. However because the BSP35 REV F devices poll the DHCP server so often when they didn’t get an answer the devices fail to operate. How can this be corrected? · There was talk of using Enable IP Management in the Fusion Options Menu. However before we do this we would need to know what this does and how it may or may not help? Thanks,
8 Replies
Alain, Can you send the network traces which show that the WT4090 is performing additional DHCP discoveries/renew requests? If the lease is for three days (72 hours), then at 36 hours (1/2 of the lease time) the handheld should begin requesting renewal of the address. During this time it will continue to use the address it received. However, if the device is roaming on 802.11 the device will attempt to renew renew the IP address to insure it has roamed onto the same network. This behavior was added to Windows CE 5.0 to address a specific issue (See http://support.microsoft.com/kb/936198). From the description this 'fix' from Microsoft may be contributing to the problem you are reporting.
We asked Tesco to provide us some traces.
I want to be sure that we're clear regarding the use of this forum. It is intended to ask questions regarding functionality or a technology. It's to be used to find registry keys that can change the default behavior of a terminal. It is not intended to replace a case or SPR. With that in mind, there are two separate themes in this thread. The first is the behavior of the terminal. When a terminal roams it WILL do a DHCP REQ on the current address. This happens in BSP30 as well as BSP35. The concern that I have is the observation that BSP35 does it more often than BSP30. Traces will help to quantify that functionality and perhaps there are registry keys that can change this behavior so that BSP35 performs the REQ as often as BSP30. The second seems to be a complaint from the customer regarding terminals losing their IP address. This complaint needs to follow the standard process for tracking customer issues (i.e. case opened, problem defined, reproduction steps, etc.)
I asked for traces, but am not sure if the TA can provide some. The issue still is that the when the WANLink for the Distribution Centre DHCP Server failed the devices should havecontinued to operate as there addresses are on a 3 Day lease. However, after a while, when they didn’t get ananswer from the DHCP server the devices fail to operate. With BSP30 it works fine.
Keep in mind that Microsoft owns the TCP/IP portion of the network stack. Fusion only provides the lower layers (along with some support functionality for the upper layers). Before approaching Microsoft it is necessary to quantify the problem. This can be done with a wireless trace and a netlog captured from the terminal in question.
There have been no changes to this functionality between BSP30 and BSP35. I would expect DHCP to occur on each suspend/resume and each roam. I recommend capturing a wireless trace for BSP30 and another for BSP35 to quantify "much more often". Have any changes been done to the infrastructure? Are you comparing BSP30 and BSP35 side by side in two different devices?
Nothing has changed on the Cisco Infrastructure and all testing between BSP30 and BSP35 is taking place on the same device, WT4090.
Well then we'll need two wireless traces, one with BSP30 and another with BSP35 to quantify the difference.