> > > > does your script work if "someplace" contains spaces? can > > > > /etc/network/interfaces deal with that syntax? a quick look > > > > at your diff makes me think that it won't. > > > > > > The problem here is that ifupdown does not allow spaces in interface > > > names. If one needs to connect to SSIDs containing spaces, one could > > > either use its BSSID or a mapping script. > > > > > > One could argue a mapping script should always be used, but I like the > > > simplicity of having wpasupplicant just working after installing it. > > > > but only "just works" for you. :-) > > No, "just works" as in functional upon installation for anyone. On my
sure. but as written, the mechanism only supports simple SSID names. that's all i meant. (my home SSID has spaces in it.) > > one solution is to do something like that done by "iwgetid --scheme", > > which compresses out all non-alphanumerics from the SSID, so that > > it can be used for purposes such as this. i suspect this could > > be done quite simply in your script by a small sed or tr command. > > My first question is what characters are actually allowed in an > interface name? Would it be safe to assume it is limited to [A-Za-z0-0]? i don't know. a quick look at the parser would say for sure. > Simply removing not allowed characters would be trivial, but it would be > even better transcoding them in some way. Any ideas on a working one > liner? i actually think that simpler is better. my ssid is "The Quick Brown Fox". it's easier for me to say "oh yeah, ifupdown doesn't like that, it needs "TheQuickBrownFox" instead", rather than having to remember how the space characters should be transcoded. > > another, possibly more complete solution, would be for > > wpa_supplicant to allow configuring an "id" string along with the > > network when it is described in wpa_supplicant.conf. this > > identity (which could default to the SSID) would be passed to the > > wpa_cli as an argument along with the connect/disconnect event. > > the identity string, since it would be specified by the user in > > the wpa_supplicant config, is guaranteed to be useful in a simple > > ifup management script such as yours. (i.e., the id i specified > > in my wpa_supplicant.conf file whould match a mapping name in > > /etc/network/interfaces. it would be the key that links the two > > config files.) > > Such changes to wpa_supplicant.conf can't really be motivated when it is > simple enough to archive the same result without them, I think. but putting a simple identifier into wpa_supplicant would solve the problem completely, and wouldn't require every implementor to come up up with a new mapping scheme. from the traffic on the hostap list, it sounds like the event monitoring api was added without a lot of discussion (one person just sent a patch, which was accepted). seems that a small addition might be accepted as well. (by the way, i'll be on vacation for a while, so won't be able to respond promptly to the conversation for some time...) paul =--------------------- paul fox, [EMAIL PROTECTED] -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
