9:46 a.m.
Hi all,
I'm new to connman. I'm writing here to ask for informations about
proposing modifications to connman.
I made changes to connman for a project I'm working on, which required
to send a fixed hostname in connman dhcp requests during network
interface configuration (regardless of the actual system hostname).
My system hostname may change since its startup, so I added a
configuration option to put into main.conf to have a fixed hostname into
dhcp requests.
Can such a modification be of any interest? I would be more than happy
to send a patch so you can evaluate it.
I also want to ask whether I can eventually send the git formatted-patch
directly to this ML or I have to follow some other procedure.
Thanks in advance
marco
4:51 a.m.
Hi Marco,
On 11/06/2017 03:46 PM, Marco Gigante wrote:
Hi all,
I'm new to connman. I'm writing here to ask for informations about
proposing modifications to connman.
Welcome!
I made changes to connman for a project I'm working on, which
required
to send a fixed hostname in connman dhcp requests during network
interface configuration (regardless of the actual system hostname).
My system hostname may change since its startup, so I added a
configuration option to put into main.conf to have a fixed hostname into
dhcp requests.
It's a while since since I touched that code. So my knowledge is a bit
rusty. I suspect you know the details better than me. So bear with me :)
So I checked what we currently do. If I am not completely mistaken we
extract the hostname and domain name at ConnMan startup time in the
loopback plugin. There is no tracking if the hostname changes over time.
And then we have some code for "org.freedesktop.hostname1"
(src/machine.c) in place. Which just extracts the machine type. This
code is able to track hostname changes provided
org.freedesktop.hostname1 is doing its job.
I rather like to avoid adding the hostname setting into connman config
file. It would be better to extract this from the main source.
So I suggest to extend the src/machine.c code instead. Provided this
works. Probably loopback.c should only used as fallback if
org.freedesktop.hostname1 is not working.
Can such a modification be of any interest? I would be more than
happy
to send a patch so you can evaluate it.
Yes, of course. Having some patches (even though they might just be a
prove of concept) are usually much better to understand and to discuss.
I also want to ask whether I can eventually send the git
formatted-patch
directly to this ML or I have to follow some other procedure.
Yes, 'git send-email' is the preferred contribution way on this mailing
list. Same procedures and etiquette as on LKML :)
Thanks,
Daniel
4:13 a.m.
On 12/11/2017 10:51, Daniel Wagner wrote:
Hi Marco,
Hi Daniel,
sorry for the late reply.
On 11/06/2017 03:46 PM, Marco Gigante wrote:
> Hi all,
> I'm new to connman. I'm writing here to ask for informations about
> proposing modifications to connman.
Welcome!
> I made changes to connman for a project I'm working on, which required
> to send a fixed hostname in connman dhcp requests during network
> interface configuration (regardless of the actual system hostname).
> My system hostname may change since its startup, so I added a
> configuration option to put into main.conf to have a fixed hostname into
> dhcp requests.
It's a while since since I touched that code. So my knowledge is a bit
rusty. I suspect you know the details better than me. So bear with me :)
So I checked what we currently do. If I am not completely mistaken we
extract the hostname and domain name at ConnMan startup time in the
loopback plugin. There is no tracking if the hostname changes over time.
It looks so to me too, as far as I can understand from a more in dept
check I did by following your description.
My connman knowledge is pretty poor, I just made changes to suite the
project needs I'm working on.
And then we have some code for "org.freedesktop.hostname1"
(src/machine.c) in place. Which just extracts the machine type. This
code is able to track hostname changes provided
org.freedesktop.hostname1 is doing its job.
I rather like to avoid adding the hostname setting into connman config
file. It would be better to extract this from the main source.
So I suggest to extend the src/machine.c code instead. Provided this
works. Probably loopback.c should only used as fallback if
org.freedesktop.hostname1 is not working.
Thanks for the references. Not sure I will be able to allocate some
bandwidth to add hostname tracking in the following days. Should I'll be
able to have some patches, I'll send them for sure.
> Can such a modification be of any interest? I would be more than happy
> to send a patch so you can evaluate it.
Yes, of course. Having some patches (even though they might just be a
prove of concept) are usually much better to understand and to discuss.
Going to send the patch.
My need was to set the hostname to a well known value. My system boots
with, lets say, 'host-factory' hostname and during its running time the
hostname may become 'host-id', where id is a host identifier locally
defined. Also the end-user can manually change the hostname from system
gui and restart the network, hence connman.
The problem is that the dhcp request can contain either 'host-factory'
or 'host-id' depending upon who runs first between connman dhcp client
and id negotiator component or end-user actions.
The dhcp server in my network assigns IP addresses depending upon host
type, inferred by client hostname.
> I also want to ask whether I can eventually send the git formatted-patch
> directly to this ML or I have to follow some other procedure.
Yes, 'git send-email' is the preferred contribution way on this
mailing list. Same procedures and etiquette as on LKML :)
I just realized, while up-merging my changes from connman v1.33 to
latest v1.35, that 'VendorClassID' config option has been added, and I
guess it could be used for my needs in some way.
Anyhow, patch already done :-) The code should follow LKML etiquette.
Thanks,
Daniel
Thank you
marco
3:02 p.m.
Hi Marco
On 11/17/2017 10:13 AM, Marco Gigante wrote:
> Yes, of course. Having some patches (even though they might just
be a
> prove of concept) are usually much better to understand and to discuss.
Going to send the patch.
I looked at the patch and basically is the thing I would like to avoid.
Adding random option is not going to scale.
My need was to set the hostname to a well known value. My system
boots
with, lets say, 'host-factory' hostname and during its running time the
hostname may become 'host-id', where id is a host identifier locally
defined.
Right, that is something very generic so far.
Also the end-user can manually change the hostname from system
gui and restart the network, hence connman.
That is your approach to solve the problem. If your GUI apps updates the
hostname, ConnMan could see the change and should the right thing... If
I am not completely mistaken ConnMan would send a new DHCPREQUEST with
the new hostname to update the DNS server.
I really would like to avoid to have two places where you configure the
hostname.
The problem is that the dhcp request can contain either
'host-factory'
or 'host-id' depending upon who runs first between connman dhcp client
and id negotiator component or end-user actions.
Hmm, somehow this sounds a bit racy :)
After a bit of pondering I think we should try the monitor approach
first and see if this works or not.
Thanks,
Daniel
10:43 a.m.
Hi Daniel
On 26/11/2017 21:02, Daniel Wagner wrote:
> My need was to set the hostname to a well known value. My system
> boots with, lets say, 'host-factory' hostname and during its running
> time the hostname may become 'host-id', where id is a host identifier
> locally defined.
Right, that is something very generic so far.
Sorry, not sure whether I created confusion or not. I meant "My need was
to set the hostname to a well known value" _in the dhcp requests_.
> Also the end-user can manually change the hostname from system gui
> and restart the network, hence connman.
That is your approach to solve the problem. If your GUI apps updates
the hostname, ConnMan could see the change and should the right
thing... If I am not completely mistaken ConnMan would send a new
DHCPREQUEST with the new hostname to update the DNS server.
I really would like to avoid to have two places where you configure
the hostname.
The sack of adding new option is to send a fixed hostname in dhcp
requests, regardless the actual system hostname (which may change).
I understand this can be confusing or unwanted (on the network side you
see a different hostname than the system one), but depending upon the
policy one wants to implement, the config gives the option to set one or
the other behavior.
Here is a usage example, just to better clarify why I went with the
config option way:
ForcedHostname not defined -> connman retrieves the actual system
hostname for the dhcp requests (current behavior)
ForcedHostname = "myhost" -> connman sends 'myhost' as hostname in
the
dhcp requests. This permits also to send empty hostname, which is not
possible with current implementation.
Maybe the config option could have a better name...
> The problem is that the dhcp request can contain either
> 'host-factory' or 'host-id' depending upon who runs first between
> connman dhcp client and id negotiator component or end-user actions.
Hmm, somehow this sounds a bit racy :)
Indeed. That's why I wanted to have the chance to fix it.
After a bit of pondering I think we should try the monitor approach
first and see if this works or not.
Thanks,
Daniel
Thank you
--
marco
1067
days inactive
1089
days old
4 comments
2 participants
participants (2)
-
Daniel Wagner -
Marco Gigante