Peter Memishian wrote:
>  > There are several things related to the link name:
>  > 
>  > a. the door name
>  > 
>  >     used to communicate between the driver and the wpad daemon).
>  > 
>  > b. the network/wpa service instance name
>  > 
>  >     When a wireless link is requested to be connected, a wpa service 
>  > instance will be (temporarily) created and enabled. Its name will be shown 
>  > as the link name. For example, svc:/network/wpa:ath0
>  > 
>  > c. The "-i" option passed to the wpad daemon
>  > 
>  >     When a wireless is requested to be connected, the wpa service 
> (mentioned 
>  > above) will be execute the wpa command, taking the link name as an 
> argument.
>  > 
>  > We think the link name in a and c can be replace with the linkid.
>  >
>  > But as b is visible to the administrators, we don't know how to deal
>  > with it.
> 
> Isn't (c) also visible?  
> 
Maybe I misunderstood. But I thought wpad is only started internally.

>  > For example, when ath0 is connected, the administrator will be able to
>  > see a service network/wpa:ath0 is enabled, although a "dladm rename
>  > ath0 net0" theoretically does not affect the established connection, it
>  > would be strange if the administrator still see the service
>  > network/wpa:ath0.
> 
> Right, that would be strange.
> 
>  > The only option I can think of is to destroy the old service instance and 
>  > recreate the new service instance as part of the rename operation. But 
> this 
>  > will affect the network connections which already established on the 
>  > specific wireless link.
>  > 
>  > What do you think?
> 
> I'm a little confused how this scenario would happen, since links can't
> be renamed when they're open, and wpad holds the link open as part of
> managing it.  So should't the user just get a "link busy" error?
> 

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?

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)

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.

What do you think?
- Cathy



Reply via email to