Planning Address Conflict Detection RFC-5227
by Christian Spielberger
Hello,
We are planning to add Address Conflict Detection RFC-5227 into connman. It will
be my task to implement the main aspects of this RFC in the next 2-3 weeks.
Now I will start by cloning the project to github. Then looking where and how
to place the ACD code. If you have any hints, please let me know!
The goal would be definitely to bring it upstream.
regards,
Christian Spielberger
https://github.com/cspiel1
www.commend.com
2 years
ConnMan sometimes shutting down, sometimes not restarting
by Craig McQueen
I'm using ConnMan in an ARM embedded Linux system (based on BeagleBone Black).
For a long time, with systems using Linux kernel 3.14.x and 4.4.x, it has been working very well. Recently, I have done some work to upgrade to Linux kernel 4.9.x. With this kernel, ConnMan sometimes terminates and restarts shortly after start-up, something that I don't think it did before.
At least, I think the change is related to the kernel upgrade. The system has also had other upgrades to other components, but the kernel update seems like the most likely cause.
Examining recent system logs, I see this message appears shortly before a ConnMan restart:
Jan 29 17:25:34 wt000043 daemon.err connmand[19746]: Inconsistent IP pool management (start not found)
Shortly after that message, ConnMan shuts down. Usually it restarts, and everything is fine. But occasionally, ConnMan never restarts, and the system has no network connectivity.
What might be a cause for this error? I see in the source code, function __connman_ippool_deladdr() contains:
info = lookup_info(index, start);
if (!info) {
/* In theory this should never happen */
connman_error("Inconsistent IP pool management (start not found)");
return;
}
--
Craig McQueen
2 years, 1 month
[PATCH 0/1] Configure flag for disabling stats file generation
by Chris Novakovic
In August 2016, Feng Wang posted a patch that allowed the generation of
interface statistics files to be disabled at compile-time. It was never merged,
but I rediscovered it recently and realised it'd be useful to have a way to stop
those files from being generated on embedded systems, where file systems are
often on flash storage (putting writes at a premium) and the interface stats
themselves might not even be needed.
This is Feng's patch from 2016, cleaned up and updated for the current master
branch.
Chris Novakovic (1):
build: Add --disable-stats option
Makefile.am | 4 ++++
configure.ac | 5 +++++
src/stats.c | 36 ++++++++++++++++++++++++++++++++++++
3 files changed, 45 insertions(+)
--
2.14.1
2 years, 1 month
connman does not see any wifi carriers after cycling hardware rfkill button
by KARBOWSKI Piotr
Hi,
It appears that the momment I double tap fn+print screen (rfkill) hotkey
(so, block followed by unblock), connman looses wifi support until
restart. If I try to force scan via `scan wifi`, I get:
connmanctl> scan wifi
Error /net/connman/technology/wifi: No carrier
I can confirm that `rfkill` reports all as unblocked.
Any suggestion how can I make connman recovery after such event?
-- Piotr.
2 years, 1 month
Ofono LTE modems and connman services
by Jonas Bonn
The following issue is causing us some grief and I really need some
guidance on how to approach this. This is being sent to both the ofono
and connman mailing lists because it's not really clear to me who's
doing the right/wrong thing here...
The connman ofono plugin does the following:
i) It powers up (enables) the modem
ii) If cellular tech is enabled, it brings the modem online
For an LTE-modem, this second step results in a default bearer being
attached and thereby the modem is 'connected'. The third connman step,
setting the ofono context to Active, is not required for LTE; the
context becomes 'Active=true' right away.
The above effectively means that it's not possible to have an LTE modem
that does not auto-connect (in connman terms).
Now the APN that ofono sets on the LTE context is 'automatic'; that was
selected because connman _requires_ some APN or else it ignores the
context altogther.
If the modem roams away from LTE connectivity and wants to fallback to
UMTS/GSM, it needs another context with a valid APN. So now the modem
has two 'internet' contexts ('automatic' and APN) which connman presents
as two distinct services.
These two services, as far as I can tell, end up competing with each
other when connecting and a mess ensues... if the lower numbered context
is the 3G context, connman goes into an endless loop attempting to set
it Active and continuously failing when the tech switches to LTE.
The question is, what are the expectations here:
i) What does it mean for connman to see two 'internet' contexts since
it sets up two services for them?
ii) How is a modem supposed to roam between LTE and UMTS/GSM networks
when one requires an APN and the other does not.
iii) Not auto-connecting an LTE modem means not bringing it online; what
implications does this have for connman?
The above is currently a bit of a confusing mess and both ofono and
connman get themselves tied in a knot when the modem switches between
LTE and non-LTE techs. Any guidance on how to approach this would be
appreciated.
Thanks,
Jonas
2 years, 1 month
Default Gateway
by Vasiu Alexandru
Hi,
I have *2 PCs *with the following set-up:
- both have 2 interfaces: eth0 and eth1
*PC 1: *
- Not connected to network
- Has a *DHCP* Server with gives private IPs from 192.168.2.0/24
- Is connected to *PC 2 *through eth0 (eth0 PC 1 to eth0 PC 2)
*PC 2:*
- eth0 has IP from *DHCP* Server from *PC 1*
- eth1 has IP from an intern network (also private, 10. ...)
If I run "ip route show" on PC 2, it shows *2 default gateways* (one for
eth0 and one for eth1) on *Ubuntu* and on a distribution with *connman*, it
shows just *one default gateway *(eth 1).
Questions:
1. Which is the normal behavior?
2. If both interfaces have different IPs from the same network there
should be only one default gateway or one for each interface (with the same
value)?
Thank you,
Alexandru Vasiu
NI
2 years, 1 month
[PATCH] supplicant: fixed return value of ssid getter
by Vasyl Vavrychuk
Previously for network without SSID g_supplicant_network_get_ssid
returned pointer to empty string. Then some naive users of it treated
such value as a valid SSID.
This fixes "Network SSID is not set" for hidden networks.
---
gsupplicant/supplicant.c | 2 +-
1 file changed, 1 insertion(+), 1 deletion(-)
diff --git a/gsupplicant/supplicant.c b/gsupplicant/supplicant.c
index 5246c80b..ec2f4307 100644
--- a/gsupplicant/supplicant.c
+++ b/gsupplicant/supplicant.c
@@ -1189,7 +1189,7 @@ const char *g_supplicant_network_get_security(GSupplicantNetwork *network)
const void *g_supplicant_network_get_ssid(GSupplicantNetwork *network,
unsigned int *ssid_len)
{
- if (!network) {
+ if (!network || !network->ssid_len) {
*ssid_len = 0;
return NULL;
}
--
2.11.0
2 years, 1 month
[PATCH] fixed noisy warning on every connect
by Vasyl Vavrychuk
On every connect I get 'Skipping disconnect of ..., network is connecting'.
This is happening because __connman_network_connect sets connecting
flag before __connman_device_disconnect. The last function then prints
warning due to this connecting flag.
Changed order of assigning connecting and __connman_device_disconnect
fixes this. Connman logic is not effected due to the way how flags
connected and associating are handled in __connman_network_connect
and __connman_network_disconnect.
---
src/network.c | 4 ++--
1 file changed, 2 insertions(+), 2 deletions(-)
diff --git a/src/network.c b/src/network.c
index 8c5979f7..4757d0d7 100644
--- a/src/network.c
+++ b/src/network.c
@@ -1468,10 +1468,10 @@ int __connman_network_connect(struct connman_network *network)
if (!network->device)
return -ENODEV;
- network->connecting = true;
-
__connman_device_disconnect(network->device);
+ network->connecting = true;
+
err = network->driver->connect(network);
if (err < 0) {
if (err == -EINPROGRESS)
--
2.11.0
2 years, 1 month
Issue with service reporting on a 4G modem
by Bassem BOUBAKER
Hello community,
I'm having connman version 1.31 along side with ofono running on my board.
When I activate a context on my 4G modem using ofono, connman creates two services: one is cellular and the other is ethernet.
*AR Wired ethernet_XX_cable
*AO XXX cellular_XXX_context1
In this case, the ideal state is that connman reports only one cellular technology related to the modem.
When digging into the logs, I feels like a new ethernet device is enumerated and connman creates the appropriate service for it.
Knowing that my modem net interface is using "cdc_ether" driver, does anyone have an idea about what could be the issue here?
Regards,
Bassem
2 years, 1 month
