haiku/src/servers/net/Settings.h

68 lines
1.6 KiB
C
Raw Normal View History

/*
* Copyright 2006-2013, Haiku, Inc. All Rights Reserved.
* Distributed under the terms of the MIT License.
*
* Authors:
* Axel Dörfler, axeld@pinc-software.de
*/
#ifndef SETTINGS_H
#define SETTINGS_H
#include <Message.h>
#include <Messenger.h>
#include <Path.h>
class Settings {
public:
Settings();
~Settings();
status_t GetNextInterface(uint32& cookie,
BMessage& interface);
* Remove the BNetworkDevice::AddPersistentNetwork() again and instead introduce BNetworkRoster::{Count|GetNext|Add|Remove}PersistentNetwork() as it fits better (thanks Philippe for the heads up). * Implement the backend for these functions in the net_server and also move conversion of the wireless_network based format into the settings based format there. * Implement removal of a network from the settings and make adding a new network with the same name replace the old one instead of just adding multiple ones. Might need to change this in the future depending on how we want to handle multiple networks with the same name (i.e. distinguish based on BSSID or similar). * Fix apparent oversight that caused configured networks _not_ to be used in the auto join attempt. * Remove auto joining open networks. I've been bitten by that more than once now because we happen to have an open network in the neighbourhood that I now accidentally used to transfer quite a bit of (unencrypted) stuff before noticing... In the future, one will instead have to explicitly join an open network once and store that config. Note that the driver will actually still auto-associate with open networks due to how things are set up currently. Note also that the auto join will fire join requests whenever there's a disassociation event, so you might see spurious join dialogs when the wpa_supplicant actually just re-establishes the connection. * Make join requests async again. Instead of waiting for a synchronous reply of the wpa_supplicant we instead return success when the request has been sent. While the API call might still be made synchronous again in the future, the net_server should really not block on an external application. In the case of the wpa_supplicant we would otherwise deadlock when using the new *PersistentNetwork() API after a successful join, and in other cases we might just unacceptably delay other calls. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@42816 a95241bf-73f2-0310-859d-f6bbb57e9c96
2011-10-09 23:56:19 +04:00
int32 CountNetworks() const;
status_t GetNextNetwork(uint32& cookie,
* Remove the BNetworkDevice::AddPersistentNetwork() again and instead introduce BNetworkRoster::{Count|GetNext|Add|Remove}PersistentNetwork() as it fits better (thanks Philippe for the heads up). * Implement the backend for these functions in the net_server and also move conversion of the wireless_network based format into the settings based format there. * Implement removal of a network from the settings and make adding a new network with the same name replace the old one instead of just adding multiple ones. Might need to change this in the future depending on how we want to handle multiple networks with the same name (i.e. distinguish based on BSSID or similar). * Fix apparent oversight that caused configured networks _not_ to be used in the auto join attempt. * Remove auto joining open networks. I've been bitten by that more than once now because we happen to have an open network in the neighbourhood that I now accidentally used to transfer quite a bit of (unencrypted) stuff before noticing... In the future, one will instead have to explicitly join an open network once and store that config. Note that the driver will actually still auto-associate with open networks due to how things are set up currently. Note also that the auto join will fire join requests whenever there's a disassociation event, so you might see spurious join dialogs when the wpa_supplicant actually just re-establishes the connection. * Make join requests async again. Instead of waiting for a synchronous reply of the wpa_supplicant we instead return success when the request has been sent. While the API call might still be made synchronous again in the future, the net_server should really not block on an external application. In the case of the wpa_supplicant we would otherwise deadlock when using the new *PersistentNetwork() API after a successful join, and in other cases we might just unacceptably delay other calls. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@42816 a95241bf-73f2-0310-859d-f6bbb57e9c96
2011-10-09 23:56:19 +04:00
BMessage& network) const;
status_t AddNetwork(const BMessage& network);
* Remove the BNetworkDevice::AddPersistentNetwork() again and instead introduce BNetworkRoster::{Count|GetNext|Add|Remove}PersistentNetwork() as it fits better (thanks Philippe for the heads up). * Implement the backend for these functions in the net_server and also move conversion of the wireless_network based format into the settings based format there. * Implement removal of a network from the settings and make adding a new network with the same name replace the old one instead of just adding multiple ones. Might need to change this in the future depending on how we want to handle multiple networks with the same name (i.e. distinguish based on BSSID or similar). * Fix apparent oversight that caused configured networks _not_ to be used in the auto join attempt. * Remove auto joining open networks. I've been bitten by that more than once now because we happen to have an open network in the neighbourhood that I now accidentally used to transfer quite a bit of (unencrypted) stuff before noticing... In the future, one will instead have to explicitly join an open network once and store that config. Note that the driver will actually still auto-associate with open networks due to how things are set up currently. Note also that the auto join will fire join requests whenever there's a disassociation event, so you might see spurious join dialogs when the wpa_supplicant actually just re-establishes the connection. * Make join requests async again. Instead of waiting for a synchronous reply of the wpa_supplicant we instead return success when the request has been sent. While the API call might still be made synchronous again in the future, the net_server should really not block on an external application. In the case of the wpa_supplicant we would otherwise deadlock when using the new *PersistentNetwork() API after a successful join, and in other cases we might just unacceptably delay other calls. git-svn-id: file:///srv/svn/repos/haiku/haiku/trunk@42816 a95241bf-73f2-0310-859d-f6bbb57e9c96
2011-10-09 23:56:19 +04:00
status_t RemoveNetwork(const char* name);
status_t GetNextService(uint32& cookie,
BMessage& service);
const BMessage& Services() const;
status_t StartMonitoring(const BMessenger& target);
status_t StopMonitoring(const BMessenger& target);
status_t Update(BMessage* message);
private:
status_t _Load(const char* name = NULL,
uint32* _type = NULL);
status_t _Save(const char* name = NULL);
BPath _Path(BPath& parent, const char* name);
status_t _GetPath(const char* name, BPath& path);
status_t _StartWatching(const char* name,
const BMessenger& target);
bool _IsWatching(const BMessenger& target) const
{ return fListener == target; }
bool _IsWatching() const
{ return fListener.IsValid(); }
private:
BMessenger fListener;
BMessage fInterfaces;
BMessage fNetworks;
BMessage fServices;
};
static const uint32 kMsgInterfaceSettingsUpdated = 'SUif';
static const uint32 kMsgServiceSettingsUpdated = 'SUsv';
#endif // SETTINGS_H