From: "Carl Gehr" Received: from mxout3.mailhop.org ([63.208.196.167] verified) by 2rosenthals.com (CommuniGate Pro SMTP 5.0.9) with ESMTP id 414668 for os2-wireless_users@2rosenthals.com; Sat, 07 Oct 2006 12:55:57 -0400 Received: from mxin1.mailhop.org ([63.208.196.175]) by mxout3.mailhop.org with esmtp (Exim 4.51) id 1GWFSd-000C8S-Rc for os2-wireless_users@2rosenthals.com; Sat, 07 Oct 2006 12:55:51 -0400 Received: from mail-out1.fuse.net ([216.68.8.174] helo=smtp1.fuse.net) by mxin1.mailhop.org with esmtp (Exim 4.51) id 1GWFSd-000Jhf-J7 for os2-wireless_users@2rosenthals.com; Sat, 07 Oct 2006 12:55:39 -0400 Received: from gx4.fuse.net ([208.102.7.45]) by smtp1.fuse.net (InterMail vM.6.01.06.01 201-2131-130-101-20060113) with ESMTP id <20061007165530.CCWA13111.smtp1.fuse.net@gx4.fuse.net> for ; Sat, 7 Oct 2006 12:55:30 -0400 Received: from localhost ([208.102.7.45]) by gx4.fuse.net (InterMail vG.1.02.00.02 201-2136-104-102-20041210) with ESMTP id <20061007165529.WPJZ11137.gx4.fuse.net@localhost> for ; Sat, 7 Oct 2006 12:55:29 -0400 To: "OS/2 Wireless Users Mailing List" Date: Sat, 07 Oct 2006 12:55:27 -0400 (EDT) Reply-To: "Carl Gehr" Priority: Normal X-Mailer: PMMail 2.20.2382 for OS/2 Warp 4.5 In-Reply-To: MIME-Version: 1.0 Content-Type: text/plain; charset="iso-8859-1" Content-Transfer-Encoding: 7bit Subject: Re: [OS2Wireless]Re: T23 internal cards success Message-Id: <20061007165529.WPJZ11137.gx4.fuse.net@localhost> X-Mail-Handler: MailHop by DynDNS X-Spam-Score: -2.5 (--) On Sat, 7 Oct 2006 10:04:34 -0500, Al Heath wrote: > >> It's probably a timing thing, >> where we kill off the one instance but need to insert a do nothing loop >>(or a few of them) to wait long enough before we try to start it up >> again. The problem is probably more noticeable with the faster >machines... > >There is a Rexx SysSleep function as well as several compiled executables >that call the DosSleep control program function. Those would probably work >better than a "do nothing loop" if you want the cpu cycles free for other >uses Good info to know, but I'm not sure this is really a timing problem. I think it is more a glitch in the DHCPMon that it will not recognize that the original DHCP client is now pointing somewhere else. It does eventually change the 'Monitor Interface' setting to LAN1 from LAN0. [I'm not certain if this is timing or requires a kill/restart of the monitor. Timing, I believe.] Thanks, Carl