search

sysprog21 / vwifi

A virtual wireless device driver for Linux
MIT License
203 stars 39 forks source link

Use hash table to store AP information #11

Closed dungru closed 2 years ago

dungru commented 2 years ago
  1. Use strspn and strcspn to parsing the parameter.
  2. Store the AP information into hash table which is ap_info_hash
jserv commented 2 years ago

I would invite @lekoOwO for reviewing.

lekoOwO commented 2 years ago

What's the pro of storing AP info?

The main purpose of generating bssid from hash(ssid) is to make it stateless, so we do not need to store it. If we're going to store it into a hash table, the bssid can be generated from a random number instead of hash(ssid).

dungru commented 2 years ago

What's the pro of storing AP info?

The main purpose of generating bssid from hash(ssid) is to make it stateless, so we do not need to store it. If we're going to store it into a hash table, the bssid can be generated from a random number instead of hash(ssid).

Actually, if you don't change SSID, the murmurhash result will always same. The AP info always get update when module_param has changed and trigger STA scan. The hash table provides a more efficient way to get AP info with O(1). On the other hand, this table could extend other AP information fields (i.e. security type) not just store the bssid. The original method iterate every SSID string, it cost O(n).

lekoOwO commented 2 years ago

What's the pro of storing AP info? The main purpose of generating bssid from hash(ssid) is to make it stateless, so we do not need to store it. If we're going to store it into a hash table, the bssid can be generated from a random number instead of hash(ssid).

Actually, if you don't change SSID, the murmurhash result will always same. The AP info always get update when module_param has changed and trigger STA scan. The hash table provides a more efficient way to get AP info with O(1). On the other hand, this table could extend other AP information fields (i.e. security type) not just store the bssid. The original method iterate every SSID string, it cost O(n).

I see.

Then we'd need a limit for stored AP Infos. Also the bssid can now be generated randomly instead of hashing ssid.

It might help understanding the code if we comment that the field in AP info is extendable.

dungru commented 2 years ago

What's the pro of storing AP info? The main purpose of generating bssid from hash(ssid) is to make it stateless, so we do not need to store it. If we're going to store it into a hash table, the bssid can be generated from a random number instead of hash(ssid).

Actually, if you don't change SSID, the murmurhash result will always same. The AP info always get update when module_param has changed and trigger STA scan. The hash table provides a more efficient way to get AP info with O(1). On the other hand, this table could extend other AP information fields (i.e. security type) not just store the bssid. The original method iterate every SSID string, it cost O(n).

I see.

Then we'd need a limit for stored AP Infos. Also the bssid can now be generated randomly instead of hashing ssid.

It might help understanding the code if we comment that the field in AP info is extendable.

If we generate the BSSID such as eth_random_addr() in every scan stage for same SSID, how could we make sure same SSID will not mapping to different BSSID. When BSSID is changed during STA which is under following probe/associate/4-way hand shake/port secured staged or even AP and STA are connected. The WPA supplicant will found the SSID and BSSID is not match and abort the state machine.

Correct me if I am wrong.

lekoOwO commented 2 years ago

What's the pro of storing AP info? The main purpose of generating bssid from hash(ssid) is to make it stateless, so we do not need to store it. If we're going to store it into a hash table, the bssid can be generated from a random number instead of hash(ssid).

Actually, if you don't change SSID, the murmurhash result will always same. The AP info always get update when module_param has changed and trigger STA scan. The hash table provides a more efficient way to get AP info with O(1). On the other hand, this table could extend other AP information fields (i.e. security type) not just store the bssid. The original method iterate every SSID string, it cost O(n).

I see. Then we'd need a limit for stored AP Infos. Also the bssid can now be generated randomly instead of hashing ssid. It might help understanding the code if we comment that the field in AP info is extendable.

If we generate the BSSID such as eth_random_addr() in every scan stage for same SSID, how could we make sure same SSID will not mapping to different BSSID. When BSSID is changed during STA which is under following probe/associate/4-way hand shake/port secured staged or even AP and STA are connected. The WPA supplicant will found the SSID and BSSID is not match and abort the state machine.

Correct me if I am wrong.

We should not generate BSSID in every stage since we have a database now 🤔