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