dhcpcd-discuss

Hi,

I forgot to attach your patch on my environment so that I can know if any
mistake.

Thanks and Best Regards,
Koichi Okamoto

> -----Original Message-----
> From: Okamoto, Koichi
> Sent: Thursday, July 28, 2016 8:37 PM
> To: 'Roy Marples'; 'dhcpcd-discuss@xxxxxxxxxxxx'
> Subject: RE: [dhcpcd-discuss] [dhcpcd-6.9.2] share these resources leak
> issues patch
> 
> Hello Roy san,
> 
> I tried your patch. Unfortunately I cannot use this patch so far.
> Because "dhcpcd -n eth0" causes dhcpcd to handle all existing network
> interface even if I only allow both eth0 and wlan0 for dhcpcd in dhcpcd.conf:
>   allowinterfaces wlan0,eth0
> As the result, that confuses our system.
> 
> In addition, I needed to ask my designers to modify their code again if I
> would decide to use this patch as well as I would take the time to check
> whether all specifications could keep current stable behaviors.
> 
> I remember I also choose the way to use a pair of "dhcpcd -n" and "dhcpcd
> -k"
> on my first integration. The above mentioned is one reason and I seemed to
> meet more issues.
> 
> Hence, I would like to know your opinion for my modification although it's
> not clean. My fundamental testing results on both IPv4 and IPv6 environment
> are OK so far. If you don't have any problem for this modification, I'll
> use it so that we can use latest dhcpcd version with both our reasonable
> cost and yours maybe.
> 
> Best Regards,
> Koichi Okamoto
> 
> > -----Original Message-----
> > From: Okamoto, Koichi
> > Sent: Thursday, July 28, 2016 10:04 AM
> > To: 'Roy Marples'; dhcpcd-discuss@xxxxxxxxxxxx
> > Subject: RE: [dhcpcd-discuss] [dhcpcd-6.9.2] share these resources
> > leak issues patch
> >
> > Hello Roy san,
> >
> > Thank you for your advice, test and solution with patch!
> >
> > > I could not replicate this at all, at least, not on NetBSD. Which OS
> > > are you using?
> >
> > We use Linux 3.10.26.
> >
> > LINK_UP may be one of condition when dhcpcd start with master mode and
> > then "dhcpcd --exit <interface node name>. Second dhcpcd starts also
> > under LINK_UP condtion. (It means that my step1 and my step2 under
> > LINK_UP being
> > kept.)
> >
> > I am wondering if there is a mismatch between dhcpcd status and OS status.
> >
> > > Also, I dislike the way you want to start dhcpcd .... it's not clean!
> >
> > Me too. However I could not find out the solution when I studied to
> > integrate dhcpcd on our system. This way has being able to work as our
> > expectation on dhcpcd-6.9.2.
> >
> > > So I made this patch to add an --inactive option:
> > > http://roy.marples.name/projects/dhcpcd/info/6e2698370eaa3aad
> > >
> > > So you can do this:
> >
> > I try this patch and tell you the results soon.
> >
> > Your informations are very helpful for me!
> >
> > Thanks and Best Regards,
> > Koichi Okamoto
> >
> > > -----Original Message-----
> > > From: Roy Marples [mailto:roy@xxxxxxxxxxxx]
> > > Sent: Thursday, July 28, 2016 1:53 AM
> > > To: Okamoto, Koichi; dhcpcd-discuss@xxxxxxxxxxxx
> > > Subject: Re: [dhcpcd-discuss] [dhcpcd-6.9.2] share these resources
> > > leak issues patch
> > >
> > > Hi
> > >
> > > On 27/07/2016 13:18, Okamoto, Koichi wrote:
> > > > I am trying to update dhcpcd-6.11.1 from 6.9.2 so that I can use
> > > 6.11.2 short term
> > > > when you will release dhcpcd-6.11.2.
> > > >
> > > > However I met one issue which always remained in waiting for
> > > > carrier
> > > condition.
> > > >
> > > > The attached patch
> > > (0001-Candidated-modification-way-to-meet-our-operation.patch)
> > > > can resolve this issue.
> > > >
> > > > If possible, could you give me your advice whether it is
> > > > reasonable
> > > modification?
> > > >
> > > > I try to explain what I would like to do with some assumption.
> > > >
> > > > [Background]
> > > > As the cause of issue may be not appropriate our operation, we
> > > > have to
> > > control
> > > > dhcpcd functionality with master mode which always stays in one
> > > process during
> > > > CPU on.
> > > >
> > > > In addition, we have to choose network interface one by one with
> > > master mode.
> > > > (Network interface are changed according to our system condition)
> > > >
> > > > To realize the above on dhcpcd-6.9.2, the following way is adopted:
> > > >
> > > > 1. First start up time
> > > >    $ dhcpcd -M -b <network node name, e.g) eth0>
> > > >    $ dhcpcd --exit <same as the above network node name, e.g) eth0>
> > > >    Please note that we need only daemonised dhcpcd one process
> > > > without
> > > DHCP function
> > > >
> > > > 2. When DHCP function is needed
> > > >    $ dhcpcd -M -b <network node name, e.g) eth0>
> > > >
> > > >
> > > > 3. When DHCP function isn't needed
> > > >    $ dhcpcd --exit <same as the above no.2 network node name, e.g)
> > > > eth0>
> > > >
> > > > Repeat No.2 and No.3 accordingly. When CPU turns off, "$ dhcpcd
> > > --exit" performs.
> > >
> > > I could not replicate this at all, at least, not on NetBSD. Which OS
> > > are you using?
> > >
> > > Also, I dislike the way you want to start dhcpcd .... it's not clean!
> > > So I made this patch to add an --inactive option:
> > > http://roy.marples.name/projects/dhcpcd/info/6e2698370eaa3aad
> > >
> > > So you can do this:
> > > # Start dhcpcd in master mode, but waiting for our instruction # to
> > > start each interface.
> > > dhcpcd -M -b --inactive
> > >
> > > # Start iwn0
> > > dhcpcd -n iwn0
> > >
> > > # Wait some time
> > > # We could use dhcpcd-online(8) instead sleep 10
> > >
> > > # Release all addresses from iwn0
> > > dhcpcd -k iwn0
> > >
> > > # Restart
> > > dhcpcd -n iwn0
> > >
> > > Hope this helps!
> > >
> > > Roy

Attachment: 0001-Add-inactive-command-option.patch
Description: 0001-Add-inactive-command-option.patch