From: "Christian Langanke" <os2-wireless_users@2rosenthals.com>
Message-ID: <44A42035.7040607@clanganke.de>
Date: Thu, 29 Jun 2006 20:47:17 +0200
User-Agent: Thunderbird 1.5 (OS/2/20060113)
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-196198@2rosenthals.com>
In-Reply-To: <list-196198@2rosenthals.com>
Content-Type: text/plain; charset=ISO-8859-1; format=flowed
Content-Transfer-Encoding: 7bit

Michael Warmuth wrote:
> Interesting solution! Haven't thought about this myself. So I tried it
> out (loop back interface as lan2, other subnet, TCPBEUI only bound to
> this interface, ipgate on) with the following result:
>
> Using lan0 (wired) it does work (domain logon, TCPBEUI access to
> shares). Using lan1 (WLAN) it does not work completely (NO domain logon,
> but TCBEUI access to shares).
>
> (Have I told you already, that I still cannot figure out how this
> TCPBEUI implementation works?)
>
> So I switched back to the "two interfaces configured in the same subnet
> configuration".
>   
Pitty! I really think that this switch should be transparent to TCPBEUI, 
as the NetBEUI client should not be aware at all of the underlying 
TCP/IP stuff. But OTOH you never know what the TCPBEUI stack does in 
order to make the protocol conversion work...

This theoretically could be examined with an IP trace. But this is quite 
a time consuming effort, and I don't have a WARP server... and I don't 
think it makes sense that I only review traces sent by mail to me - this 
would cost too much time I am afraid. If you can, however, recreate that 
scenario as well with two clients, then I could do this (taken that I 
find the time so set all that File&Print client stuff up for testing).

I must say though that I have merely no experience with TCP over 
NetBIOS, so in order to be really able to read the trace, one would also 
ned an interpretation of the SMB data (LAN Manager protocol), and that 
could be done oly with a real network sniffer supporting this 
protocol... Otherwise most of reading the IP trace would be just guessing.
> But I really think that this is the correct
> sequence: Because it is possible to start a process then which strikes
> when the interface is fully configured by XWLAN. But it's a bit hard to
> code to step back in time when xwlan.cmd is started after configuring
> the interface. ;-)
I doubt that the xwlan script should be run before the WLAN interface is 
configured. The purpose of the script is to run additional commands 
depending on the _configured_ WLAN interface, for this the WLAN 
interface must already be configured. The only thing that I could think 
of is to redesign the script interface and add two more events. SO it 
would not only be

CONNECT (run after WLAN is configured)
DISCONNECT (run before WLAN is unconfigured)

but as well

CONNECTPENDING (run before WLAN is configured)
DISCONECTCOMPLETED (run after WLAN is unconfigured)

I would not so so before there is a serious used case for that, because 
I would not want to make the whole thing too complex.

bye, Christian

-------------------------------------------------

Christian Langanke
COS2E & CWSE
Team OS/2 Ruhr e.V.
cla@clanganke.de