|
|
With genmac the nic is always attached so the is no reason not toTo be sure it would just make sense to perform any peer related action on the end of the processing for each event, but that should be the case/no problem. Of course it would be required to either launch the script asynchronously (not wait for script end) or better start a peer comand within another session from the otherwise synchronous executed script. Letting XWLAN wait for 20 secs would hang PM...
restart peer after making the change over between wifi and wired. The
only hitch is a peer start or stop takes quite a bit of time, 10-30
seconds, so it would be better to run the script detached. Will this
cause a problem with xwlan settings?
The way I would restart peer is via: 'login name /p:password [/L]' This way one is logged in and ready to access shares. The /LSure, Ithat was not the provlem, but XWLAN should only offer to stop or launch it if it is absolutely clear that (a) NetBIOS is bound to the WLAN nic and (b) the peer service (so to say IBMLAN.INI) is definitely using this protocol on the WLAN adapter. _This_ is the problem that cannot be solved bullet-proof. I very much hope that any protocol manager replacement that may come up in the future, can exactly be queried for all nic and protocol binding related issues.
parameter
is only needed when one is logging into a NetBIOS server network (eg, WINS [ugh]), not usually a SOHO environment.
Yup. But IMHO the XWLAN GUI should only offer a repective GUI page if the above stated prerequisites are met.OTOH I could well think of enhancing XWLAN with some of the things your script does, just like starting/stopping peer. The bad part on this is that there is no way to safely determine if a NetBIOS compatible protocol stack is bound to the Wifi nic. In any way I would appreciate if we can proceed on that further, please send pm if you are interested in that.
If peer isn't available, wouldn't a call to a peer function return an
error that could be parsed?
I agree, if I were to put this script into 'production' I would add aThat's what I meant. If you want to stick to Win* ini files, I can send you a procedure for reading keys out of it (oh - will have to dig my hardfile for this one).
lot of feature like this to make it more user friendly. In fact this
is a very good reason to change it to a REXX script where one could
setup a handy config program/file.
Fixed for the upcoming version.1) When the radio is turned off the SSID does not appear to be passedWill check that. The SSID should be empty only when (dis)connectiing from/to a hotspot.
to the script (I get a NULL string). So I used the profile name as a
test instead of the SSID as indicted in the sample script.
Thanks
Yes, true. The default for this setting would still be "ask the user". And nobody can help for people not reading help pages - and even power user ask questions they could easily answer themselves.As long as folks understand that only one LAN can be active at any2) I had to disable the TCP/IP setup in the 'Home' profile and do theJust thought about to add a property to suppress this warning in favour either for the wireless or cabled interface. Think this should help you to make your script even shorter.
setup in the script because I got a popup error message about using
duplicate fixed IP addresses for both lan0 and lan1. The 'Travel' DHCP
setup was ok, no configuration statements are needed in the script
except for ensuring that the wired LAN is deleted.
given time when using the same IP address
In gereral this is still true, although I must admit that I found a bug in 2.02 for the situation I told above. Within the standalone version, go to the script properties page and press the browse button. Then the widget will tell no card is available... Seems to be a problem with file handles - in the standalone version the driver handle is zero (for the first file opened this handle is valid in a PM process), and when the call to WtkDirDlg returns, on every following call to the driver this handle turns to be invalid - so the status "card not available". Even though WtkDirDlg is "my" code (me being the author of Workplace Shell Toolkit), I wasn't able to find out the problem source. I assume for any reason file handle zero is closed accidentally. As the Widget is running in the xCenter context, the driver handle is not zero, so the problem does not show up. I still wonder which part of xCenter is harmed then by WtkDirDlg ... so far no strange behaviour showed up.3) The wifi is sometimes stubborn about connecting to a profile, evenMay also be a driver issue... I sometimes even get a "no driver available", while the hardware _is_ available and was working before, and that both from genprism and genmac drivers (and the mini pci card csnnot be removed, right ?)
if the AP is only a few feet away. I'm not sure if this is a xwlan
script problem or related to interference from local networks.
That thought crossed my mind also.
also fixed for the next version.I also found a bug that for "radio on" (or was it "radio off") no (dis)connect script event is generated. Will have to go after that...
|
: ,
,
. |