The syscall might be interrupted, especially in signal heavy
applications. In that case we need to retry the read until the timeout
runs out. since the timeout is already absolute we don't need to adjust
anything.
When reaching the next node the current key should be set to the next
valid index within that node (0 for forward and NumKeys() - 1 for
backward). This did not cause any harm as BFS uses forward traversal
only.
Return as many dirents as fit into the provided buffer. The readdir()
implementation in libroot tries to get many dirents and caches them to
reduce the amount of syscalls and the associated overhead.
This reduces the syscall count dramatically for use cases where a lot
of directories are enumerated. A "git status" on a Haiku repository for
example goes from over 50k read dir syscalls down to just under 7k.
The performance gain is only around a moderate 5% in that use case
though.
This usually wasn't a problem as the key buffer is generally large
enough to hold a single value. Still on short buffers or very long
it could have silently overrun before.
This replaces waiting a fixed time of 300ms for the device power to
stabilize. In the ideal case this reduces the boot time by 200ms per
connected device (including internal hubs).
This is very similar to what Linux implements and we use the same time
values. An interval of 25ms is used to check for connection state
changes, the stable time is at least 100ms as per the USB specs and the
whole process times out after 1.5 seconds.
Casting the difference of the two off_t values to size_t may truncate
the result. Doing so before the comparison will therefore break it.
Instead cast the size to off_t to get around the signed versus unsigned
integer expression comparison and then cast the result of the comparison
to size_t again. Should fix#9714.
* If we have a configured network, then we always try to connect to it
as soon as the interface has been brought up.
* If we don't have a configured network and are auto configuring, we
use the AutoconfigLooper to also do initial auto joins.
* Before issuing auto joins we need to wait for scan results to come
in, so we watch for corresponding messages.
For now auto joining is a one shot attempt as the infrastructure to
properly tell reasons for scans apart is not yet there.
This ensures that we don't spuriously re-detect a link if we have a
race between starting to watch for link state changes and detecting the
initial link.
The scanning still occurs so that the network list is populated. But if
no SSID has been explicitly configured, we now always set the
IEEE80211_SCAN_NOJOIN flag that prevents automatically joining open
networks at the end of the scan.
The wpa_supplicant (rightfully) supplies the SSID with this request.
However, with the code that is in place it gets ignored and the desired
SSID, as set by IEEE80211_IOC_SSID is used instead. This still works if
the wpa_supplicant is the only client in use and IEEE80211_IOC_SSID
is never used, as then the mlme.im_macaddr is used as the only
identifying element. If we used IEEE80211_IOC_SSID before though, for
example because we joined an open network from the net_server directly,
there will always be a mismatch between the desired SSID and the one
the wpa_supplicant tries to associate with using this MLME request.
No association is then possible. As there is no obvious reason why the
request supplied SSID shouldn't be used, we simply do so.
We need to make sure that the wpa_supplicant knows about our intention
even when joining an open network, as it otherwise might interfere.
Since leaving a network is not synchronous and the wpa_supplicant is
already running in that case anyway, this seems easier and more
reliable.
If the wpa_supplicant is not already running we still join ourselves.
The _ConfigureInterface() method is used as a backend for all
configuration tasks. That includes setting addresses manually or by
DHCP and changing flags, mtu or metric. Therefore we can't join
networks every time it is invoked. Instead we check for an existing
link first and only try to join if there is none yet.
This allows to reuse BMessenger objects for different targets, or to
recheck validity after initial creation. With that one can use the same
BMessenger after launching an application that was previously not found
valid for example.
Any fully empty keyring (no keys and no applications) would fail to add
the empty flat buffer and thus prevent the whole keystore database from
being stored. This could easily happen when you used separate keyrings
but the master keyring was left unused for example.
Adding a flag that tells that there is no data allows us to distinguish
between a case where the stored data is missing due to a problem versus
an actually empty buffer.
We always try to reach the wpa_supplicant first. If it isn't running
we check if this might have been a network we've connected directly
and then just disassociate using an MLME disassociation request.
* Updated to version 2.0 of vendor code.
* Reliability improvements in controlling the underlying devices.
* Implement leaving networks.
* Better timeout handling.
* Usability enhancements like cancel on escape, ok button being the
default and the password field having focus on start.
* Storing of the password using BKeyStore.
Using the original message and storing that into the settings resulted
in a not yet fully understood deadlock. Presumably related to missing
and/or stray replies.
They can be supplied as request type codes to SIOCS80211 are added to
allow overcoming a difference between how Haiku and FreeBSD handle
network drivers.
In FreeBSD a device can be set into the down state but is still fully
configurable using the ioctl interface. The Haiku network stack on the
other hand opens and closes the driver on the transition form up to
down and vice versa. This difference can become problematic with ported
software that depends on the original behaviour.
Therefore IEEE80211_IOC_HAIKU_COMPAT_WLAN_{UP|DOWN} provide a way to
achieve the behaviour of setting and clearing IFF_UP without opening
or closing the driver itself.
The wpa_supplicant will use this in its BSD driver instead of actually
setting the interface down and then failing all other ioctls.
* Replace {Set|Remove}MasterKey() by generic {Set|Remove}UnlockKey()
that works on a keyring.
* Implement {Set|Remove}MasterUnlockKey() on top of that.
* Rename the commands and constants accrodingly.
* Implement setting and removing keyring unlock keys.
* Rename fKeyMessage to fUnlockKey and the KeyMessage() getter to
UnlockKey().
* Keep track of whether the keyring has an unlock key set.
* Store and restore that info separately.
* En- and decryption will depend on unlock key presence later.
* Add functions to set and remove an unlock key and query for it.
* Each keyring is now stored in a proper message which allows it to
contain additional meta data along side the flat data.
* Adding all keyring messages under a common field also allows to add
meta data to the keystore, as the keyrings don't use up random field
names anymore.
* Treat the master keyring as any other keyring and just add it to the
list. This allows to write/read the keystore database without special
casing the master keyring.
As there aren't any more generic meta data containers inside BKey,
there's no real way to distinguish different instances with the same
identifiers. This may be added later, for example the same index system
as used in BMessage could apply.
Before, each permanently granted access flag would overwrite the
previously granted flag, causing the dialog to come up whenever the
operation was changed.
The application access concept is on the keyring level only for now.
Generally it probably would get pretty complicated and therefore harder
to use when application access needs to be granted on a per key basis.
Also add a well defined name ("Master") for the master keyring so it is
easier to understand what this keyring does instead of displaying an
empty string.
* Using Unset() initializes the BKey to default values.
* Also set fCreationTime to 0 for now. It is still unused but needs to
have a stable value for the exact matches when comparing keys.
The application is resolved and then looked up in the keyring. If the
keyring doesn't provide a matching entry, an application access request
is triggered. The mechanism doesn't yet do any actual checksums, but
has provisions for differentiating between new and changed/updated
applications.
This will have to be reworked though, as by using the roster only
BApplications can be resolved, as plain cli apps aren't registered with
the registrar.
* Pass them through a flat buffer that can later be encrypted and
decrypted in a central place.
* Remove the data argument from the constructor as keyrings are
now reading their data on their own.
* Prepare for additional application info storage in the keyring.
The type is relevant and required as it determines the type of the
handed in key. The purpose however isn't actually needed and rather
inconvenient to get by depending on the situation.
* The keyring needs to be made accessible before allowing any
operation.
* Before executing commands the keyring is made accessible if
possible (the command is aborted as needed).
* Accessing a keyring opens up a preliminary key request dialog.
* If the default keyring is accessible and a keyring key for the
requested keyring is found, that key will be used to automatically
make the requested keyring accessible.
* Implement adding/removing passwords and keyrings.
* Implement enumerating passwords and keyrings.
* Implement preliminary accessibility status check for keyrings.
* Move the *Key() functions into a Keyring class.
* Retrieve and select the right keyring for various commands.
* Implement adding/removing/enumerating keyrings.
* Rework the keystore database read/write to work with keyrings.
* Sync BKeyStore::IsKeyringAccessible() with the changed message.
* Remove leftover template code from registrar.
* Add reading/writing a yet unprotected flat BMessage as the storage
backend for the keys.
* Factor out the identifier based lookup logic into _FindKey() and use
that from _AddKey() to detect duplicates.
* Add _FindKey() variant that does the lookup based on given type and
purpose constraints.
* The keystore backend will (at least for the time being) reside in a
separate server. This one can be reached via normal messaging, so use
a BMessenger for sending key messages.
* Move the message constants from RegistrarDefs.h into a new
KeyStoreDefs.h that also contains the server signature.
* Update the message constants to reflect the new situation.
* Add all relevant message constants.
* Implement the messaging to send/retrieve key info.
* Implement _Flatten/_Unflatten for sending flat BKey objects.
* Remove application list from BKey, the key can't only differ by
allowed applications as the identifiers would still collide, so the
comparison isn't needed to uniquely identify the key. The applications
can be enumerated via the BKeyStore instead.
* Modified the API greatly to be based on BKey* instead of BPassword*.
* Added BKeyPurpose and used it instead of BKeyType. It is supposed to
indicate the purpose of a key so that an app can look up keys on a
more granular level. The BKeyType on the other hand actually
identifies the type (i.e. subclass of BKey) so an app knows how to
handle a given key or may only enumerate/use keys it is compatible
with.
* Made everything based on a raw data buffer for now, only BPasswordKey
is implemented yet which stores the (0 terminated) string into that
data buffer.
* Removed the additional data BMessage as I don't yet see where it fits
in. While I could imagine adding meta data to a key may be nice it
might be an interoperability concern when keys are shared by
different apps.
* Moved the app functions to the keystore as per the TODO, but not sure
how to actually implement them.
Michael Lotz