From: "Mark Henigan" <os2-wireless_users@2rosenthals.com>
Message-ID: <44A03B62.90600@sbcglobal.net>
Date: Mon, 26 Jun 2006 12:54:10 -0700
User-Agent: Mozilla/5.0 (OS/2; U; Warp 4.5; en-US; rv:1.7.11) Gecko/20050728
MIME-Version: 1.0
To: OS/2 Wireless Users Mailing List <os2-wireless_users@2rosenthals.com>
Subject: Re: [OS2Wireless]Re: xwlan 2.14
References: <list-191454@2rosenthals.com>
In-Reply-To: <list-191454@2rosenthals.com>
Content-Type: text/plain; charset=us-ascii; format=flowed
Content-Transfer-Encoding: 7bit

Hello Christian, Michael, and list:

Please forgive the top posting.  This is more generally
about the topic below rather than addressing specific
technical points made by either of you.

On the Suntan Special CD, Neil Waldhauer provides a
script to disconnect from a wired LAN and to provide the
changes necessary for XWLAN to operate via the wireless
card.  He also provides a script to do the opposite,
i.e., to disconnect from the wireless card and rejoin
the wired network.  They are quite probably worth a
look.

One "feature" that impressed impressed me was that it
corrected an error in my wired LAN configuration so
that upon reconnecting to the wired LAN, I was finally
able to use the router at work.  That doesn't say much
for my networking skills, but, it gives a positive
view of Neil's.

I also want to echo Michael's praise for XWLAN.  When
I use it correctly, it is excellent with my Cisco 350
PCMCIA card.  Without it, OS/2-eCS would be hobbled.
Thank you, Christian, for your continued support.

Best Regards,

- Mark

Mark Henigan
-- 

Christian Langanke wrote:
> Michael Warmuth wrote:
> 
>> Hi everyone,
>>
>> Before you read the following please keep in mind, that I appreciate the
>> work you guys do in your spare time for the sake of us. It is a great
>> help. And even if XWLAN is not perfect it is a very useful tool for
>> operating a WLAN card.
>>   
> 
> appreciated.
> 
>> Yes, I played around with 2.14 some days ago, just to find out that it
>> has a big design problem: Deleting an interface (e.g. LAN) when it is in
>> the same subnet a the other (e.g. WLAN) is just wrong. Because:
>>
>> +) In my situation (never using both interfaces at the same time) it is
>> necessary to have them configured to make TCPBEUI work. So it should be
>> possible to turn this feature off.
>>   
> 
> I am sorry, but having two interfaces configured to the same subnet is 
> wrong. If you mean that you disable one of either interface, this would 
> be ok. But it is definitely not sufficient to just "not use" one of 
> either interface. The IP stack will not care for if you don't use one of 
> two interfaces - exactly one of two will just always win and the other 
> will never be used.
> 
>> +) Even if it is necessary to delete one of the interfaces it makes the
>> TCP/IP-stack unusable because if it turns off the previously configured
>> interface it does not update the routes - so no interface does work:
>>   
> 
> That is correct and I hope I will be able to fix this route issue.
> 
>> -) Let's say lan0 is LAN, lan1 is WLAN, lan0 is configured
>> -) We turn on WLAN - XWLAN gets configuration for lan1 using DHCP
>> -) Routes are configured for lan0, so the ones for lan1 aren't there
>> -) XWLAN detects the "conflict" and deletes lan0
>> -) The routes for lan0 are still there - nothing does work
>> -) XWLAN "thinks" it has completed it's work
>>
>> The correct behavior would be:
>>
>> 1) XWLAN configures WLAN interface (either statically or with DHCP)
>> 2) XWLAN detects the "conflict"
>> 3) If the LAN interface should be deleted (one of three options: "Delete
>> LAN if", "Delete WLAN if", "Do nothing"): do the following:
>>   
> 
> "Do nothing is definitely not an option.
> 
>> 4) Delete WLAN interface (yes!)
>> 5) Flush all routes and arp table (route flush or route -fh and arp -f)
>> 6) Delete the LAN interface
>> 7) Configure WLAN interface (statically or using DHCP)
>> 7a) (Now the routes should be OK.)
>> 8) Set "hostid" to the address of the newly configured if (WLAN)
>>   
> 
> Hmmm. I did not know that this has to be explicitely set. How would I do 
> that ?
> 
>> 9) Run rfcaddr for TCPBEUI
>>   
> 
> Note that NetBEUI is currently ot handled by XWLAN, so you would have to 
> do that with the script feature.
> 
> I would be interested though to have an exeperienced user telling me 
> what else could be required/make sense for better NetBEUI support.
> 
> If this is not too much in one piece, I could think of integrating some 
> support for it.
> 
>> Off course this does take a longer time (two times waiting for the DHCP
>> lease), but the result is that it does actually work.
>>   
> 
> For testing I implemented something different, at least for the default 
> route. If the WLAN interfaces is to be kept, the default route is saved, 
> deleted, then LAN is deleted, then default route is reset - et voila: 
> the defalt route is attached to the WLAN interface. I intend to cache 
> _all_ routes for the cabled interface and restore them all on the 
> correct interface, so network and hostroutes would also be handled 
> properly. The only drawback is that I cannot do that for the way back 
> (wireless to cabled). Here the setup script is to setup all routes 
> properly again.
> 
>> P.S. All the time I spent to get XWLAN working correctly was more or
>> less useless as my mini-PCI "IBM High Rate ..." still chocks up when
>> sending more than just a few KB (XWLAN shows "No Card"). But this is a
>> driver problem...
>>   
> 
> I am sorry to hear that. Did you post a request to netlabs.org on this ?
> 
> bye, Christian
> 
> -------------------------------------------------
> 
> Christian Langanke
> COS2E & CWSE
> Team OS/2 Ruhr e.V.
> cla@clanganke.de