> Maybe I misunderstood. But I thought wpad is only started internally.
The options still seem to be documented in wpad(1M), so it seems a least a little bit exposed. (Maybe the administrator can optionally start it by hand? The manpage is unclear.) > Okay. I missed that part of code. So there is still a small window between > someone requests to connect a wireless link and wpad holds the link. If the > rename request comes in between, the wpad will fail, and do_connect() > function will detect the link is not connected and return TIMEOUT. Is that > right? Yes -- but I think that situation is extremely unlikely, and goes against the design center of the vanity naming feature, since it suggests that someone is trying to rename links regularly on a running system. > If my understanding is correct. I will make the following changes: > > a. Change the door name to be based on the linkid. (today the driver use the > dev_info_t to derive the door name) Why wouldn't it use the link name? Since it can't change, it doesn't seem like a problem to use the link name, and it's less obscure and easier for people to interact with. (e.g., the link tied to a door named "foo0" is obvious; the link tied to door "12" is not.) > b. Change the wpa to get the linkid of a specific wireless link and store > that linkid locally. Therefore, it does not need to do linkname-to-linkid > mapping all the time to do other operations like scan(), setkey() etc. As above, I don't yet understand why the linkid needs to be used here. -- meem
