Re: [PATCH] connman.service: use @sbindir@ instead of hardcoding @prefix@/sbin
On Wed, 2015-03-18 at 16:30 +0100, Andreas Oberritter wrote: Applied, thanks! Patrik ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
Re: [PATCH] connman.service.in: start before remote fs mounts
On Wed, 2015-03-18 at 16:25 +0100, Andreas Oberritter wrote: Otherwise NFS mounts may fail on boot. Applied, thanks! I removed the signed-off-by as it's not used in this project. Patrik ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
Re: [PATCH] device/inet: Create read-only devices instead of ignoring completely
Hi Andreas, On ke, 2015-03-18 at 16:27 +0100, Andreas Oberritter wrote: Booting an nfsroot with connman requires passing -I eth0 to ignore the interface. This isn't very nice, for at least the following reasons: * A User interface based on connman is led to believe that there's no network interface and thus connman seems to be offline when it's not. * The DHCP lease obtained by the kernel won't get renewed. * DNS servers won't get obtained from DHCP, thus requiring a workaround to copy /proc/net/pnp to /etc/resolv.conf and passing -r to connmand. Therefore change behaviour to restrict interfaces passed with -I to read-only ioctls. I have seen this NFS thing being asked before and one workaround has been to use the -I option to ignore the NFS link. This is kind of wrong as then the link is not managed and used by ConnMan any more. I just wonder if we could tweak device.c:cleanup_devices() function to skip the NFS link instead of this patch that changes lot of things in the code. The cleanup_devices() is cleaning the links when ConnMan starts so that connmand has a known initial state. Perhaps we could skip the cleaning of NFS link if ConnMan notices that there is such a link. This would be less invasive than having these read checks all over the place. Cheers, Jukka ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
Re: Architechture/Block diagram of Connman ??
Hi, On Wed, 2015-03-18 at 08:56 +, Lamsoge, Abhijit wrote: Apart from the documentation available in Connman sources - Do we also have a block/architectural high level diagram of connman, both Daemon and Client ? So far nobody has had the energy to put such a document together. The best clue here is to look at the data structures starting from struct connman_service and checking which other connman data structs are referenced + see what structs the plugins are handling. Cheers, Patrik ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
Re: [PATCH] device: Don’t report EALREADY if enabling device succeeds with ifup
On Wed, 2015-03-18 at 17:06 +, Philip Withnall wrote: Whew, right. I am unlikely to find time to work on this until one or three weeks from now, but I have put it on my backlog to look at as soon as I can after then. Sorry! No problem. Thanks for taking time to report the issue and solving it at least in one way - it works that way too actually. The only issue I have is that there is a bigger risk of someone forgetting what errors devices should or should not return, thus the proposed more generic task of figuring out what response is appropriate from the technology API. Doing it quickly makes me believe that -EALREADY should be treated as success (= 0), but the details matter. I'll look into this a bit. Cheers, Patrik ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
RE: connman connection policy
Hello All,
Thank you for the support.
I am able to set it running by supplying required passphrase.
Great feeling :)
Regards,
Ram
-Original Message-
From: Jukka Rissanen [mailto:jukka.rissa...@linux.intel.com]
Sent: Wednesday, March 18, 2015 6:54 PM
To: connman@connman.net
Cc: Kallumari Nagaraja Rao, RammohanX
Subject: Re: connman connection policy
Hi Ram,
On ke, 2015-03-18 at 13:12 +, Kallumari Nagaraja Rao, RammohanX
wrote:
Hello Jukka,
Is the Agent request input happens via a dictionary ?
Yes, the passphrase is sent as a dictionary element. See doc/agent-api.txt
document for details (there are some examples at the end of the document).
I was able to register a agent handler getting RequestInput from the
ConnMan.
However I am unable to send out the passphrase out.
static DBusHandlerResult request_passkey_message(DBusConnection *conn,
DBusMessage *msg) {
DBusMessage *reply;
DBusError derr, error;
const char *device;
char passkey[17] = micromax;
const char *psk = micromax;
reply = dbus_message_new_method_return(msg);
if (!reply)
return DBUS_HANDLER_RESULT_NEED_MEMORY;
dbus_error_init(derr);
if (!dbus_message_get_args(msg, derr, DBUS_TYPE_OBJECT_PATH, device,
DBUS_TYPE_INVALID)) {
fprintf(stderr, %s, derr.message);
dbus_error_free(derr);
return error_message(conn, msg, net.connman.Error.Rejected,
Wrong signature);
}
if (device)
printf(Device: %s\n, device);
//memset(passkey, 0, sizeof(passkey));
printf(Passkey sent over: %s\n, psk);
dbus_message_append_args(reply, DBUS_TYPE_STRING, psk,
DBUS_TYPE_INVALID);
dbus_connection_send(conn, reply, NULL);
printf(reply success\n);
dbus_message_unref(reply);
return DBUS_HANDLER_RESULT_HANDLED;
}
I guess the passkey is currently sent out as a string the ConnMan may not
be able to accept it.
Not sure how to convert the input into a dictionary append my passphrase
into it.
I am sure you can search the web for examples how to send a dictionary in dbus
from C-program.
I am able to print the service properly.
Please help me on this. Thanks.
Regards,
Ram
Jukka
___
connman mailing list
connman@connman.net
https://lists.connman.net/mailman/listinfo/connman
Re: [PATCH] device/inet: Create read-only devices instead of ignoring completely
Hi Marcel, On 18.03.2015 23:14, Marcel Holtmann wrote: Hi Andreas, first of all: Whenever you boot from NFS and change your network device address, the system is going to freeze. This goal of this patch is to be able to run ConnMan in an nfsroot (during development) with as little difference to a local boot as possible. There may be additional wireless devices attached which need to get configured by ConnMan and a user interface should be able to query online states and parameters from ConnMan, even though no big changes are allowed to the interface carrying the connection to the NFS server. Booting an nfsroot with connman requires passing -I eth0 to ignore the interface. This isn't very nice, for at least the following reasons: * A User interface based on connman is led to believe that there's no network interface and thus connman seems to be offline when it's not. * The DHCP lease obtained by the kernel won't get renewed. * DNS servers won't get obtained from DHCP, thus requiring a workaround to copy /proc/net/pnp to /etc/resolv.conf and passing -r to connmand. this sentence makes no sense to me. I do not even know what /proc/net/pnp actually is. When passing ip=dhcp to the kernel, which is common for nfsroot setups, Linux generates a resolv.conf at /proc/net/pnp, just as a reference, without anybody using the nameservers listed in it. So what you get is a network device configured with DHCP but no working nameserver setup. And even if you fix it manually, you have to change ConnMan's behaviour (compared to a boot from local storage) by passing -r to it to disable the DNS proxy or otherwise it will overwrite resolv.conf again, without being able to actually resolve anything (because of -I eth0). you learn something new every day. I did not know about /proc/net/pnp. And honestly that naming is horrible and non intuitive at all. However this makes this really simple. I think that ConnMan needs to learn on how to deal with /proc/net/pnp and if that is present honor its information. Can you post and example of that file here. I never boot over NFS so that might be reason I never have seen that file in my life. #PROTO: DHCP domain example.com nameserver 192.168.1.1 bootserver 192.168.1.2 See pnp_seq_show() in net/ipv4/ipconfig.c of Linux. I get the feeling that once we handle the presence of this file properly as an external config (meaning immutable service), then this will all start working nicely. No need to hack read-only into the whole codebase. ConnMan already has the concept of immutable services. This would solve part of the problem, the DNS functionality. Still (typically) eth0 wouldn't show up in a ConnMan user interface and DHCP leases wouldn't get renewed. We need ConnMan to do DHCP. Parsing /proc/net/pnp wouldn't yield any information that ConnMan couldn't obtain from DHCP itself. In case of manual configuration, there's no way to specify a nameserver on the kernel cmdline. I'll try what Jukka suggested, as it would be less invasive than my first approach. Regards, Andreas ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
Re: [PATCH] device/inet: Create read-only devices instead of ignoring completely
Hi Jukka, On 19.03.2015 09:02, Jukka Rissanen wrote: Hi Andreas, On ke, 2015-03-18 at 16:27 +0100, Andreas Oberritter wrote: Booting an nfsroot with connman requires passing -I eth0 to ignore the interface. This isn't very nice, for at least the following reasons: * A User interface based on connman is led to believe that there's no network interface and thus connman seems to be offline when it's not. * The DHCP lease obtained by the kernel won't get renewed. * DNS servers won't get obtained from DHCP, thus requiring a workaround to copy /proc/net/pnp to /etc/resolv.conf and passing -r to connmand. Therefore change behaviour to restrict interfaces passed with -I to read-only ioctls. I have seen this NFS thing being asked before and one workaround has been to use the -I option to ignore the NFS link. This is kind of wrong as then the link is not managed and used by ConnMan any more. I just wonder if we could tweak device.c:cleanup_devices() function to skip the NFS link instead of this patch that changes lot of things in the code. The cleanup_devices() is cleaning the links when ConnMan starts so that connmand has a known initial state. Perhaps we could skip the cleaning of NFS link if ConnMan notices that there is such a link. This would be less invasive than having these read checks all over the place. I'll try this and report back. Do you think I should add a new command-line option to pass the interface to ConnMan? Identifying the interface used for NFS requires parsing /proc/cmdline and, in case of static addresses, knowledge about the interfaces' IP address. Until now I preferred to let the shell do it. Thanks, Andreas ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
Re: [PATCH] device/inet: Create read-only devices instead of ignoring completely
Hi Andreas, first of all: Whenever you boot from NFS and change your network device address, the system is going to freeze. This goal of this patch is to be able to run ConnMan in an nfsroot (during development) with as little difference to a local boot as possible. There may be additional wireless devices attached which need to get configured by ConnMan and a user interface should be able to query online states and parameters from ConnMan, even though no big changes are allowed to the interface carrying the connection to the NFS server. Booting an nfsroot with connman requires passing -I eth0 to ignore the interface. This isn't very nice, for at least the following reasons: * A User interface based on connman is led to believe that there's no network interface and thus connman seems to be offline when it's not. * The DHCP lease obtained by the kernel won't get renewed. * DNS servers won't get obtained from DHCP, thus requiring a workaround to copy /proc/net/pnp to /etc/resolv.conf and passing -r to connmand. this sentence makes no sense to me. I do not even know what /proc/net/pnp actually is. When passing ip=dhcp to the kernel, which is common for nfsroot setups, Linux generates a resolv.conf at /proc/net/pnp, just as a reference, without anybody using the nameservers listed in it. So what you get is a network device configured with DHCP but no working nameserver setup. And even if you fix it manually, you have to change ConnMan's behaviour (compared to a boot from local storage) by passing -r to it to disable the DNS proxy or otherwise it will overwrite resolv.conf again, without being able to actually resolve anything (because of -I eth0). you learn something new every day. I did not know about /proc/net/pnp. And honestly that naming is horrible and non intuitive at all. However this makes this really simple. I think that ConnMan needs to learn on how to deal with /proc/net/pnp and if that is present honor its information. Can you post and example of that file here. I never boot over NFS so that might be reason I never have seen that file in my life. #PROTO: DHCP domain example.com nameserver 192.168.1.1 bootserver 192.168.1.2 See pnp_seq_show() in net/ipv4/ipconfig.c of Linux. some kernel people should not design interfaces. At least add the ifindex or ifname into this so people can figure out which interface it belongs to. That should be patches in the upstream kernel. #IFINDEX: 2 That is what I would expect to be added to really know which interface is handled by the kernel. Who is taking charge of adding this extra information to the kernel? I get the feeling that once we handle the presence of this file properly as an external config (meaning immutable service), then this will all start working nicely. No need to hack read-only into the whole codebase. ConnMan already has the concept of immutable services. This would solve part of the problem, the DNS functionality. Still (typically) eth0 wouldn't show up in a ConnMan user interface and DHCP leases wouldn't get renewed. We need ConnMan to do DHCP. Parsing /proc/net/pnp wouldn't yield any information that ConnMan couldn't obtain from DHCP itself. The kernel does not do DHCP renewals? That is odd now. How do we get the state of the current lease then? In case of manual configuration, there's no way to specify a nameserver on the kernel cmdline. I think I read there is a possibility to put DNS servers in the cmdline. Then again, turning this into an immutable service from a ConnMan point of view just makes sense. Regards Marcel ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
Re: Architechture/Block diagram of Connman ??
Hi Patrik, Apart from the documentation available in Connman sources - Do we also have a block/architectural high level diagram of connman, both Daemon and Client ? So far nobody has had the energy to put such a document together. The best clue here is to look at the data structures starting from struct connman_service and checking which other connman data structs are referenced + see what structs the plugins are handling. or you search the Internet for the various talks I gave about ConnMan. They always include the architecture diagrams. Regards Marcel ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
Re: [PATCH] device/inet: Create read-only devices instead of ignoring completely
On Thu, 2015-03-19 at 15:20 +0200, Jukka Rissanen wrote: Do you think I should add a new command-line option to pass the interface to ConnMan? Identifying the interface used for NFS requires parsing /proc/cmdline and, in case of static addresses, knowledge about the interfaces' IP address. Until now I preferred to let the shell do it. Sure, we can try adding new command line option for that. Although best thing would be to detect NFS link usage at run time inside ConnMan, but I agree it is easier to done in the shell. I prefer implementing kernel command line option parsing and using any interface, IP and configuration method information to create an immutable service out of it. Should not be too hard to do. The additional trick is not to take the interface down, neither at startup where ConnMan clears up any previous configuration, nor release anything DHCP related at shutdown. Cheers, Patrik ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
Re: [PATCH] device/inet: Create read-only devices instead of ignoring completely
Hi Andreas, On to, 2015-03-19 at 12:18 +0100, Andreas Oberritter wrote: Hi Jukka, On 19.03.2015 09:02, Jukka Rissanen wrote: Hi Andreas, On ke, 2015-03-18 at 16:27 +0100, Andreas Oberritter wrote: Booting an nfsroot with connman requires passing -I eth0 to ignore the interface. This isn't very nice, for at least the following reasons: * A User interface based on connman is led to believe that there's no network interface and thus connman seems to be offline when it's not. * The DHCP lease obtained by the kernel won't get renewed. * DNS servers won't get obtained from DHCP, thus requiring a workaround to copy /proc/net/pnp to /etc/resolv.conf and passing -r to connmand. Therefore change behaviour to restrict interfaces passed with -I to read-only ioctls. I have seen this NFS thing being asked before and one workaround has been to use the -I option to ignore the NFS link. This is kind of wrong as then the link is not managed and used by ConnMan any more. I just wonder if we could tweak device.c:cleanup_devices() function to skip the NFS link instead of this patch that changes lot of things in the code. The cleanup_devices() is cleaning the links when ConnMan starts so that connmand has a known initial state. Perhaps we could skip the cleaning of NFS link if ConnMan notices that there is such a link. This would be less invasive than having these read checks all over the place. I'll try this and report back. Do you think I should add a new command-line option to pass the interface to ConnMan? Identifying the interface used for NFS requires parsing /proc/cmdline and, in case of static addresses, knowledge about the interfaces' IP address. Until now I preferred to let the shell do it. Sure, we can try adding new command line option for that. Although best thing would be to detect NFS link usage at run time inside ConnMan, but I agree it is easier to done in the shell. Cheers, Jukka ___ connman mailing list connman@connman.net https://lists.connman.net/mailman/listinfo/connman
