Mailing List os2-wireless_users@2rosenthals.com Archived Message #2126

From:	"Christian Langanke" <os2-wireless_users@2rosenthals.com>	Full Headers Undecoded message
Subject:	Re: [OS2Wireless]Re: xwlan 2.14
Date:	Thu, 29 Jun 2006 20:47:17 +0200
To:	OS/2 Wireless Users Mailing List <os2-wireless_users@2rosenthals.com>

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

Subscribe: Feed, Digest, Index.
Unsubscribe
Mail to ListMaster