Marcel: 
> >> I do not even know what any of these information mean. What are they
> >> good for. What value are they providing. What would the user interface
> >> do with this information?
> > 
> > The idea here is to provide a list of the clients that are tethered.
> > Some additional information about each one is useful to have. We're not
> > removing anyone at will, though.
> > 
> > (Even I would prefer to have live information on the leases, it is not
> > fun to dig through a stale udhcp server lease file to find that headless
> > box when away from home.)
> 
> but with the current patch, not even that was possible. Let me put it this 
> way, lets figure out what we really want to show in the UI before adding 
> crazy stuff like MAC addresses left and right. I am totally fine exposing 
> some of the Tethering details to the UI, but we need to be careful here that 
> it makes actual sense.
The requests are:
1. MAC address of the remote devices
2. technology type of the remote devices
3. ip address, hostname, netmask
4. the count of the remote devices

The current issue is that whether this informations are reasonable and
how could we get that?
In my opinions, 1),2),4) are reasonable, and when we get 1) we can
easily get 3) from dhcp server.


To MAC address, we can get that from bridge easily, however, the issue
is that bridge can't know when the device get disconnected from bridge,
bridge can only monitor the traffic of the bridge. We also can't count
on the interface's removing from the bridge to get to know when it
disconnected to bridge, since when wifi clients connect to bridge
through AP, only one interface will be added to bridge. So from bridge
we can't get the accurate information of 4), besides, we also need to
add patches to add dev type to bridge in kernel.

The other way is to get the 1),2),4) from each subsystem(BlueZ,
nl80211/WPA_s, USB). it is workable.
nl80211 knows when client get connected or disconnected and what the MAC
address of the remote devices.
I think the same with BlueZ side.
We also can get that from USB side.
And the technology type is can get from each subsystem.


of course, if bridge can get to know when remote device disconnect from
bridge, bridge is the easiest and most direct way. :)



_______________________________________________
connman mailing list
connman@connman.net
http://lists.connman.net/listinfo/connman

Reply via email to