Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

SCSI_NETWORK_WIFI_CMD_SCAN_RESULTS ignores transfer size #173

Closed
th-otto opened this issue Jul 24, 2024 · 8 comments
Closed

SCSI_NETWORK_WIFI_CMD_SCAN_RESULTS ignores transfer size #173

th-otto opened this issue Jul 24, 2024 · 8 comments
Labels
bug Something isn't working

Comments

@th-otto
Copy link
Contributor

th-otto commented Jul 24, 2024

In

int size = sizeof(struct wifi_network_entry) * nets;
, the size of the returned data is only checked against the size of the internal data buffer. But that ignores the size of the initiators specified transfer size in bytes 3/4 of the CDB.

I don't know if this can cause trouble, since at most 10 wifi_network_entries are returned (using 2 + 10 * 74 bytes), but IMHO this should be fixed.

BTW, is there any way to increase that number of entries (WIFI_NETWORK_LIST_ENTRY_COUNT)?

@erichelgeson
Copy link
Contributor

erichelgeson commented Jul 24, 2024

Agree, should truncate the response if the host asks for a specific len.

WIFI_NETWORK_LIST_ENTRY_COUNT is 10 currently and it was just a nice round number to not take up too much RAM, as we are limited on the Pico. I suppose in apartments or the like there could be a lot more than 10 around you.

If you'd like to PR the fix, we'd love to have it!

@erichelgeson erichelgeson added the bug Something isn't working label Jul 24, 2024
@th-otto
Copy link
Contributor Author

th-otto commented Jul 24, 2024

I understand the limitation, but the problem is that even "at home", their may be entries from your neighbours that you are not interested in (unless you know their passwords ;)

I guess its too late to change the interface, so the burden of storing/filtering the entries can be put to the host application instead?

@erichelgeson
Copy link
Contributor

Just brainstorming.. since SCSI_NETWORK_WIFI_CMD_SCAN_RESULTS is the only place that wifi_network_list is used - instead of storing it in the wifi_network_list we can write entries directly to scsiDev.data (as is done in many places.. for better or worse) to save memory. This could be done in a compatible/non-breaking change to the existing mac wifi-da.

@jcs
Copy link
Contributor

jcs commented Jul 24, 2024

I think the intention was to sort by RSSI so that closer/stronger networks would appear first in the list, making it less likely that the one you care about is far down the list. But I guess I never wrote that.

@th-otto
Copy link
Contributor Author

th-otto commented Jul 24, 2024

instead of storing it in the wifi_network_list we can write entries directly to scsiDev.data

But is that safe? What if some other command is sent, while the scan is in progress (possibly from some other application).

@erichelgeson
Copy link
Contributor

erichelgeson commented Jul 24, 2024

But is that safe? What if some other command is sent, while the scan is in progress (possibly from some other application).

Edit: whoops I was mistaken, you're right, we cant do this.

@th-otto
Copy link
Contributor Author

th-otto commented Jul 24, 2024

PR just opened. I've no way to test it, but checked that it compiles atleast.

@erichelgeson
Copy link
Contributor

cherry-picked and merged.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working
Projects
None yet
Development

No branches or pull requests

3 participants