Age | Commit message (Collapse) | Author | Files | Lines |
|
Change-Id: I13526fbf80296a79be15548fc226a308941ac9ec
Signed-off-by: Taesub Kim <taesub.kim@samsung.com>
|
|
Change-Id: I174854914d9fd06a813270b57d1f7bc2bac63c6a
Signed-off-by: Seonah Moon <seonah1.moon@samsung.com>
|
|
Change-Id: I3a133fa6aebd28dea42f7dfd9ecb42d04c45f291
Signed-off-by: Seonah Moon <seonah1.moon@samsung.com>
|
|
- Fixed NTP service's DNS resolving failure in Hive project.
- Do not turn "wlan0" interface down in cleanup_devices().
- Set resource limits "RLIMIT_NOFILE" for a process.
- After appending a file, fflush and fsync all modified in-core data of the file.
Change-Id: I2767b3302d6204d066fe2075027828ff209d0ee0
Signed-off-by: Niraj Kumar Goit <niraj.g@samsung.com>
|
|
desc: with IPv6, current telephony plugin has not proper logic.
set state and activation for cellular service logic is changed.
it also affects normal cellular service connection.
Change-Id: I48f214ceab2f0f7c6e3f8bead185cc8f1fd2a87a
Signed-off-by: Niraj Kumar Goit <niraj.g@samsung.com>
|
|
Change-Id: I2958446c35966d9ed72df0120b80561be7d89f54
Signed-off-by: Taesub Kim <taesub.kim@samsung.com>
|
|
Change-Id: I02fc50820cccc66aed702a97a9928981e73b43cf
Signed-off-by: Taesub Kim <taesub.kim@samsung.com>
|
|
Signed-off-by: hyunuktak <hyunuk.tak@samsung.com>
Change-Id: I84a42375b5c59739e4caca1f726699ea7647ef17
|
|
|
|
|
|
Fixes BMC#25128
|
|
Do not bother setting individual routes for default gateway so
for VPN we set the whole interface as a default gateway route.
|
|
|
|
|
|
|
|
The kernel will ignore host routes which are bogus.
In case of a PtP connection such as PPP for cellular the
gateway address should not be used.
|
|
This is needed so that we can access hosts behind the VPN.
The route might already be setup if VPN server is the same
as nameserver or similar.
|
|
|
|
If the VPN is connected and the underlaying service is
disconnected, then we must also disconnect the VPN if it
is still connected.
|
|
This is needed so that VPN gets default route when moving
services. That can happen if VPN did not had default route
before.
|
|
Before this patch the system created following routes for VPN
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 192.168.10.9 0.0.0.0 UG 0 0 0 vpn0
192.168.2.0 0.0.0.0 255.255.255.0 U 0 0 0 wlan0
192.168.2.1 0.0.0.0 255.255.255.255 UH 0 0 0 vpn0
192.168.2.1 0.0.0.0 255.255.255.255 UH 0 0 0 wlan0
192.168.10.1 192.168.10.9 255.255.255.255 UGH 0 0 0 vpn0
192.168.10.9 0.0.0.0 255.255.255.255 UH 0 0 0 vpn0
Here the route to gateway in wlan0 192.168.2.1 via vpn0 is not
correct and it will prevent connections to 192.168.2.1
The correct routes should be:
Destination Gateway Genmask Flags Metric Ref Use Iface
0.0.0.0 192.168.10.9 0.0.0.0 UG 0 0 0 vpn0
192.168.2.0 0.0.0.0 255.255.255.0 U 0 0 0 wlan0
192.168.2.1 0.0.0.0 255.255.255.255 UH 0 0 0 wlan0
192.168.10.1 192.168.10.9 255.255.255.255 UGH 0 0 0 vpn0
192.168.10.9 0.0.0.0 255.255.255.255 UH 0 0 0 vpn0
Fixes MBC#25035
|
|
This is useful if P-t-P link does not have a default route.
Fixes BMC#25027
|
|
If the new VPN gateway has split routing set, then do not
clear original default route because VPN will not set the
default route. Without this check we would not get any
proper default route set.
|
|
This is done as we might have changed the order of the services
so force update of the service list.
|
|
It is possible that because the rtnl messages arrive
asynchronously, we might end up having two default gateways
that are both active at the same time. If that happens, we try
to downgrade the one that is not yet active.
|
|
|
|
There can be multiple active gateways in the system at the same
time so we must check them all when updating gateway info.
|
|
VPN could be using wrong phy link data if there are multiple
active links.
|
|
These routes are not needed.
|
|
Get the active gateway pointer only after the gateway hash
has been manipulated by add_gateway(). It is possible that
we are accessing stale pointer otherwise.
|
|
When nameserver are removed by __connman_connection_gateway_remove()
then remove only certain type nameserver (IPv4 or IPv6). This is
needed so that we do not loose IPv4 routes if only IPv6 nameservers
are to be removed. This is needed when there are multiple connected
services.
|
|
|
|
This is needed so that gateways are set properly when service
triggers online checks.
|
|
|
|
The fix b68795352dd5a9ac41eab31c765ade0c88329a6e was only partly
working. We must only take the ref when we are saving stuff
to hash (no need to take ref if we are only modifying value
in the hash). This patch reverts the commit b68795
|
|
Service may be refcount two times when add_gateway for both ipv4 and
ipv6, we need to unref the service twice according when we have both
ipv6 and ipv4 gateway
|
|
It should be possible to move down an online service to ready and the one
which goes up might come up online after recomputing its state.
|
|
The reference counting problems were clearly seen with VPN service.
|
|
Fixes BMC#22540
|
|
|
|
|
|
VPN establishment fails on gateway less networks, like for example ppp
based cellular ones. To fix that, a host route to the VPN server is
established.
|
|
The default gateway for ppp connection should be 0.0.0.0 for ipv4
and :: for ipv6. This issue fixed before but removed by the commit
84a739d0082b89efa8cfbf376abe17937e4bc843
|
|
For IPv4 (DHCP, fixed or manual), and for manual IPv6, the gateway handling
code (connection.c) is the one responsible for moving to the READY state.
|
|
|
|
|
|
In the Connection Manager, completion of a valid IP configuration
excites the service state machine to move from the "configuration" to
the "ready" state.
However, the existing implementation of IP configuration completion
explicitly attempts to directly manipulate service state, rather than
hinting at an excitation event.
As a consequence, a late IP configuration completion after the service
state machine has transitioned from "ready" to "online" can lead to an
incorrect transition back to the "ready" state. This causes the
connection count for the technology associated with that service to
increment again, unnecessarily.
This patch avoids this issue by providing a service object interface
that simply hints that an IP configuration is complete for a given IP
type, allowing the service object and its state machine to either hold
fast in the present state, returning an advisory error or advancing,
as before.
All prior invocations of __connman_service_indicate_state outside of
the service module for the CONNMAN_SERVICE_STATE_READY are replaced
with calls to this new interface.
Thanks to Daniel Wagner and Marcel Holtmann for offline IRC discussion
that helped motivate this fix.
* v2: Incorporated feedback from Samuel Ortiz about combining IPv4
and IPv6 states before checking state readiness.
|
|
The state change should be handled by the caller.
|
|
|
|
When exit from ConnMan, __connman_connection_cleanup() is called
before __connman_service_cleanup() which then calls update_order().
__connman_connection_cleanup() sets gateway_hash as NULL, so update_order()
will access NULL hash and causes GLib-CRITICAL abort
|