ddclient-support — Support for ddclient

Re: [Ddclient-support] wrong ip address picked up from firewall/router

[Mike S. <v....@sc...>]

On 21/07/13 04:32, Kurt Bussche wrote:
> Is No-IP still supported by DDClient?  I see no mention of us on the below link even though we use the identical protocol as Dyn.
>
> http://sourceforge.net/apps/trac/ddclient/wiki/Protocols
>
> I need to check the code and see if our external IP detection is still in there, which would solve your issue.

It is (I tried it a while back), but I want to keep the name => address 
mapping as up-to-date as possible. I don't mind hitting my own router 
every minute; external sites just might object, and even if not, it 
seems to me a mite antisocial.

My nasty hack seems to work - it got tested a day or two back. Maybe a 
check for all "impossible" WAN addresses could usefully be incorporated 
in get_ip() as a back-stop to problems elsewhere.

[Ddclient-support] dyndns checkip

[Seb <sp...@gm...>]

Hi,

I had the following to update my dyndns info:

╭───── [ sudo cat /etc/ddclient.conf ]
│ # Configuration file for ddclient generated by debconf
│ #
│ # /etc/ddclient.conf
│ 
│ daemon=28d
│ protocol=dyndns2
│ use=web, web=checkip.dyndns.com, web-skip='IP Address'
│ server=members.dyndns.org
│ syslog=yes
│ login=login
│ password='password'
│ myserver.dyndns.org
╰─────

However, it seems to have stopped working in the last couple of months.
I'm not sure the 'use' and 'server' directives are really needed.  Any
tips?

Thanks,

-- 
Seb

Re: [Ddclient-support] wrong ip address picked up from firewall/router

[Mike S. <v....@sc...>]

On 21/07/13 04:32, Kurt Bussche wrote:
> Is No-IP still supported by DDClient?  I see no mention of us on the below link even though we use the identical protocol as Dyn.
>
Must be - I'm using it :-)

'ddclient --help' offers:

The 'No-IP Compatible' protocol is used to make dynamic dns updates
over an http request.  Details of the protocol are outlined at:
http://www.no-ip.com/integrate/

Configuration variables applicable to the 'noip' protocol are:
   protocol=noip                    ##
   server=fqdn.of.service       ## defaults to dynupdate.no-ip.com
   login=service-login          ## login name and password  registered 
with the service
   password=service-password    ##
   fully.qualified.host         ## the host registered with the service.

Example ddclient.conf file entries:
   ## single host update
   protocol=noip,                                        \
   login=use...@do...,                                \
   password=noip-password                           \
   myhost.no-ip.biz


I hope support will continue - I've just switched to using no-ip from 
dyndns, who've started making life expensive.


(BTW is top/bottom preferred for this list please? Or don't people mind?)



> http://sourceforge.net/apps/trac/ddclient/wiki/Protocols
>
> I need to check the code and see if our external IP detection is still in there, which would solve your issue.
>
>
> On Jul 20, 2013, at 12:18 AM, Mike Scott <v....@sc...> wrote:
>
>>
>> Hi; I've recently started using ddclient (3.8.1). I'm fetching the WAN
>> ip address from my router, a netgear dg834g.
>>
>> It's been running for a couple of weeks or so, but I noticed a hiccup
>> today: the system log contained:
>>
>> Jul 19 14:42:41 data ddclient[71264]: SUCCESS:  updating
>> XXXXXXXXXX.dnsd.info: good: IP address set to 192.168.1.254
>> Jul 19 14:42:43 data ddclient[71264]: SUCCESS:  updating
>> XXXXXXXXXX.no-ip.info: good: IP address set to 192.168.1.254

(snip)

Re: [Ddclient-support] wrong ip address picked up from firewall/router

[Kurt B. <ku...@no...>]

Is No-IP still supported by DDClient?  I see no mention of us on the below link even though we use the identical protocol as Dyn.

http://sourceforge.net/apps/trac/ddclient/wiki/Protocols

I need to check the code and see if our external IP detection is still in there, which would solve your issue.


On Jul 20, 2013, at 12:18 AM, Mike Scott <v....@sc...> wrote:

> 
> Hi; I've recently started using ddclient (3.8.1). I'm fetching the WAN 
> ip address from my router, a netgear dg834g.
> 
> It's been running for a couple of weeks or so, but I noticed a hiccup 
> today: the system log contained:
> 
> Jul 19 14:42:41 data ddclient[71264]: SUCCESS:  updating 
> XXXXXXXXXX.dnsd.info: good: IP address set to 192.168.1.254
> Jul 19 14:42:43 data ddclient[71264]: SUCCESS:  updating 
> XXXXXXXXXX.no-ip.info: good: IP address set to 192.168.1.254
> 
> showing the domain name being pointed at the router's private LAN 
> address. This I'm guessing is down to a timing glitch - it seems the 
> lease on that address expired, and a new address was allocated by the 
> dhcp server. A minute later, ddclient picks up a proper WAN ip address.
> 
> Both LAN and WAN addresses are normally on the netgear's status page; 
> presumably while the dhcp negotiation is in progress, the layout changes 
> just a bit and fools ddclient.
> 
> 
> I've put a nasty hack in for the moment into the end of subroutine 
> get_ip that checks for my local LAN addresses and returns undef if so 
> set. At least it stops needless updates to clearly wrong values. It 
> might be better if ddclient recognised this situation and checked more 
> often until a valid address was found, as well as maybe parsing the 
> status page a bit more accurately.
> 
> 
> 
> # Mike's patch 29 Jul 2013.
> # LAN address confused with WAN if fw is in middle of update.
> # Should add full list, but hey.......
>         if( define($ip,'') =~ /^192\.168\./ ) {
>                 warning("fw returned local ip address -- ignored %s.", 
> $ip);
>                 $ip = undef;
>         }
> #########
> 
>     debug("get_ip: using %s, %s reports %s", $use, $arg, define($ip, 
> "<undefined>"));
>     return $ip;
> }
> 
> 
> Unfortunately, there's no easy way to test this
> 
> 
> ------------------------------------------------------------------------------
> See everything from the browser to the database with AppDynamics
> Get end-to-end visibility with application monitoring from AppDynamics
> Isolate bottlenecks and diagnose root cause in seconds.
> Start your free trial of AppDynamics Pro today!
> http://pubads.g.doubleclick.net/gampad/clk?id=48808831&iu=/4140/ostg.clktrk
> _______________________________________________
> Ddclient-support mailing list
> Ddc...@li...
> https://lists.sourceforge.net/lists/listinfo/ddclient-support

[Ddclient-support] wrong ip address picked up from firewall/router

[Mike S. <v....@sc...>]

Hi; I've recently started using ddclient (3.8.1). I'm fetching the WAN 
ip address from my router, a netgear dg834g.

It's been running for a couple of weeks or so, but I noticed a hiccup 
today: the system log contained:

Jul 19 14:42:41 data ddclient[71264]: SUCCESS:  updating 
XXXXXXXXXX.dnsd.info: good: IP address set to 192.168.1.254
Jul 19 14:42:43 data ddclient[71264]: SUCCESS:  updating 
XXXXXXXXXX.no-ip.info: good: IP address set to 192.168.1.254

showing the domain name being pointed at the router's private LAN 
address. This I'm guessing is down to a timing glitch - it seems the 
lease on that address expired, and a new address was allocated by the 
dhcp server. A minute later, ddclient picks up a proper WAN ip address.

Both LAN and WAN addresses are normally on the netgear's status page; 
presumably while the dhcp negotiation is in progress, the layout changes 
just a bit and fools ddclient.


I've put a nasty hack in for the moment into the end of subroutine 
get_ip that checks for my local LAN addresses and returns undef if so 
set. At least it stops needless updates to clearly wrong values. It 
might be better if ddclient recognised this situation and checked more 
often until a valid address was found, as well as maybe parsing the 
status page a bit more accurately.



# Mike's patch 29 Jul 2013.
# LAN address confused with WAN if fw is in middle of update.
# Should add full list, but hey.......
         if( define($ip,'') =~ /^192\.168\./ ) {
                 warning("fw returned local ip address -- ignored %s.", 
$ip);
                 $ip = undef;
         }
#########

     debug("get_ip: using %s, %s reports %s", $use, $arg, define($ip, 
"<undefined>"));
     return $ip;
}


Unfortunately, there's no easy way to test this

Re: [Ddclient-support] Ticket 14 (allow reusing the use option) fix proposed patch

[wimpunk <wi...@us...>]

On 07/01/13 01:47, Rodrigo Araujo wrote:
> Hello.
> 
> Attached is my proposed solution for fixing the following issue:
> 
> http://sourceforge.net/apps/trac/ddclient/ticket/14
> 

Patch has been applied in [r153].  Thanks for the nice work.

wimpunk.

Re: [Ddclient-support] Ticket 14 (allow reusing the use option) fix proposed patch

[wimpunk <wi...@us...>]

On 07/01/13 01:57, Rodrigo Araujo wrote:
> For some reason, the attachment with the patch seems to have vanished in
> the message I received as reply (but I can confirm I did not forget to
> attach it).
> 
> wimpunk, can you confirm you have received it? If necessary to send by
> other means, please let me know.
> 
> Best regards.
> 

Sorry, attachments are cut by mailing list.  As trac has been closed,
maybe you could open a new ticket [1] referring to the trac issue and
attaching the patch to the new ticket.

[1] https://sourceforge.net/p/ddclient/discussion/create_topic

Regards,

wimpunk.

Re: [Ddclient-support] Ticket 14 (allow reusing the use option) fix proposed patch

[Rodrigo A. <ro...@eu...>]

For some reason, the attachment with the patch seems to have vanished in
the message I received as reply (but I can confirm I did not forget to
attach it).

wimpunk, can you confirm you have received it? If necessary to send by
other means, please let me know.

Best regards.

-- 
Rodrigo Araújo <ro...@eu...>
Administrador de Sistemas
Eurotux Informática, S.A. | www.eurotux.com
Tel: (+351) 253680300 - Suporte: (+351) 253680301 Fax: (+351) 253680319

[Ddclient-support] Ticket 14 (allow reusing the use option) fix proposed patch

[Rodrigo A. <ro...@eu...>]

Hello.

Attached is my proposed solution for fixing the following issue:

http://sourceforge.net/apps/trac/ddclient/ticket/14

Basically, in the subrouting update_nics, instead of using only the
'use' value as key to the %iplist hash when checking to avoid repeating
the same command, I use several option values related to the host being
processed and that may (or may not) be related to the -use option being
processed for the host.

Initially I used a much more simple approach by using only 2 keys - $use
and opt($use, $h) - and that would work for most cases, but when you
have options like -use=cisco or -use=cisco-asa that accept arguments
from -fw and -if, that wouldn't be enough. I decided to use all keys
instead: it's not pretty but it does the job, as it doesn't really
matter if all the options aren't used by the method or aren't defined at
all (it will use '' as value in that case). Only disadvantages is there
might be some miliseconds of overhead (but hardly noticeable as perl
hashes are very efficient) and you might have to keep in mind to update
this "key chain" (let's call it that) should you add more arguments
related to "-use" methods in the future.

Probably could be reworked to use another subroutine to do the dirty
job, but if you ask me this is enough for my usage cenarios where I have
multiple providers, each with different IP addresses, and I must
sometimes use the same -use argument for each, such as -use=if,if=eth0
for one and -use=if,if=eth1 for another, or -use=cmd method invoking a
different cmd for each one and playing with curl (like cmd="curl -sS
--interface eth2http://checkip.dyndns.org/", cmd-skip="Current IP
Address: ", \ ...) - with this patch, it works like a charm and should
be easy for you to figure more uses out of it, but should you need more
elaborate examples please let me know.

Other change I did is in the get_ip function to make the $arg variable
value be retrieved related to the $h (host), as the opt subroutine
handles that well already (and thus I removed a line in update_nics that
redefined $opt{$use} as local, seemed more logical to me to do it like
this). I also took advantage of the opt subroutine handling the $h
(host) argument and retrieving the global variable if necessary to do
minor cleanups in the update_nics sub. Seems good to me, but please confirm.

The attached patch was made against the trunk svn version, but also
applies well to version 3.8.1 (at least the one that comes with Fedora
17, where I tested).

Can you check if it's worthy (and doesn't break anything) to include on
the upcoming 3.8.2 version? If this is not the place to submit the
patch, then I'm sorry and please tell me where is the correct place (I
couldn't figure out where to do it in trac).

Best regards, and keep up the excelent work :)

-- 
Rodrigo Araújo <ro...@eu...>
Administrador de Sistemas
Eurotux Informática, S.A. | www.eurotux.com
Tel: (+351) 253680300 - Suporte: (+351) 253680301 Fax: (+351) 253680319

[Ddclient-support] Using ddclient to update Hurricane Electric tunnelbroker

[wimpunk <wi...@us...>]

Hi all,

Somewhat by accident I saw a message on identica [1] about 'configuring
ddclient on #RPi for Hurricane Electric'.  As I'm using Hurricane
Electric as tunnelbroker and using ddclient to update my dynamic dns
provider, I wanted to know how he did it.

Actually,  I'm already using ddclient to update my settings. I use
little post-script to update the broker which has been working for a
while now.  My script just do a wget to the URL defined in the
documentation of the tunnelbroker.

The link in the post doesn't point to the correct blogpost, just search
for a blogpost called 'Setting up ddclient on the Raspberry Pi'.  The
post is pretty straight-forward and uses the dyndns2 protocol to get the
job done.

I'm planning to add this information to the ddclient documentation but
maybe there are some people out there who wants to use this information.

[1] http://identi.ca/notice/101319674

regards,

wimpunk.

Re: [Ddclient-support] Fixing warning message ''Use of the default SSL_verify_mode..."

[William M. <wf...@ho...>]

> On 06/03/13 17:02, Lars Noodén wrote:
> > On 6/3/13 5:49 PM, William Makowski wrote:
> >> I reported this back in February on the mailing list and opened a
> >> ticket, https://sourceforge.net/apps/trac/ddclient/ticket/76.  There
> >> is also a temporary patch that I suggested until a more permanent
> >> solution can be completed.
> >>
> >> Bill
> > 
> > Thanks. That's the same version I have, but the patch looks like it
> > turns off verification.  If so, that might not be a good long term
> > solution.  Should there be some certificates from the dynammic services
> > checked instead?
> > 
> > Regards,
> > /Lars
> > 
> 
> That's why I didn't applied the patch. Maybe we could add some kind of
> an unsafe option to make it usable.
> 
Ideally it would be nice if ddclient allowed us to set SSL_verify_mode to SSL_VERIFY_PEER  together with a SSL_ca_file|SSL_ca_path for verification.  Currently from what I understand ddclient defaults to using SSL_VERIFY_NONE because that is how the perl module IO::Socket::SSL works.  The message is coming out because the module developers plan on forcing users to explicitly set a SSL_verify_mode.  Once that happens ddclient probably won't work.
 
My patch is temporary.  It explicitly sets the verify mode to SSL_VERIFY_NONE and should keep ddclient working once the perl module is changed.  Long term though I think this setting should become a configuration option and allow the user to set SSL_VERIFY to PEER or NONE.  NONE, however, does lead to a less secure state.
 
> ------------------------------------------------------------------------------
> Get 100% visibility into Java/.NET code with AppDynamics Lite
> It's a free troubleshooting tool designed for production
> Get down to code-level detail for bottlenecks, with <2% overhead.
> Download for free and get started troubleshooting in minutes.
> http://p.sf.net/sfu/appdyn_d2d_ap2
> _______________________________________________
> Ddclient-support mailing list
> Ddc...@li...
> https://lists.sourceforge.net/lists/listinfo/ddclient-support
 		 	   		  

Re: [Ddclient-support] Fixing warning message ''Use of the default SSL_verify_mode..."

[wimpunk <wi...@us...>]

On 06/03/13 17:02, Lars Noodén wrote:
> On 6/3/13 5:49 PM, William Makowski wrote:
>> I reported this back in February on the mailing list and opened a
>> ticket, https://sourceforge.net/apps/trac/ddclient/ticket/76.  There
>> is also a temporary patch that I suggested until a more permanent
>> solution can be completed.
>>
>> Bill
> 
> Thanks. That's the same version I have, but the patch looks like it
> turns off verification.  If so, that might not be a good long term
> solution.  Should there be some certificates from the dynammic services
> checked instead?
> 
> Regards,
> /Lars
> 

That's why I didn't applied the patch. Maybe we could add some kind of
an unsafe option to make it usable.

wimpunk.

Re: [Ddclient-support] Fixing warning message ''Use of the default SSL_verify_mode..."

[Lars N. <lar...@gm...>]

On 6/3/13 5:49 PM, William Makowski wrote:
> I reported this back in February on the mailing list and opened a
> ticket, https://sourceforge.net/apps/trac/ddclient/ticket/76.  There
> is also a temporary patch that I suggested until a more permanent
> solution can be completed.
> 
> Bill

Thanks. That's the same version I have, but the patch looks like it
turns off verification.  If so, that might not be a good long term
solution.  Should there be some certificates from the dynammic services
checked instead?

Regards,
/Lars

Re: [Ddclient-support] Fixing warning message ''Use of the default SSL_verify_mode..."

[William M. <wf...@ho...>]

I reported this back in February on the mailing list and opened a ticket, https://sourceforge.net/apps/trac/ddclient/ticket/76.  There is also a temporary patch that I suggested until a more permanent solution can be completed.
 
Bill
 
> Date: Mon, 3 Jun 2013 08:06:10 +0200
> From: wi...@us...
> To: ddc...@li...
> Subject: Re: [Ddclient-support] Fixing warning message ''Use of the default SSL_verify_mode..."
> 
> Hi,
> 
> On 06/02/13 12:04, Lars Noodén wrote:
> > I just recently started noticing this warning message when running
> > ddclient 3.8.1:
> >
> 
> Please try the latest svn version.
> 
> >  "Using the default of SSL_verify_mode of SSL_VERIFY_NONE for client
> >  is depreciated! Please set SSL_verify_mode to SSL_VERIFY_PEER
> >  together with SSL_ca_file|SSL_ca_path for verification.
> >  If you really don't want to verify the certificate and keep the
> >  connection open to Man-In-The-Middle attacks please set
> >  SSL_verify_mode explicitly to SSL_VERIFY_NONE in your application."
> > 
> 
> Looks like a SSL message to me.  Which distribution and version of SSL
> are you using?
> 
> > Currently my ddclient.conf is rather spartan:
> > 
> > 	ssl=yes
> > 	protocol=dyndns2
> > 	use=web, web=checkip.dyndns.com,web-skip='IP Address'
> > 	server=members.dyndns.org
> > 	login=zzz
> > 	password='zzz'
> > 	zzz.dyndns-remote.com
> > 
> > I've looked a little in the support list archive and not noticed any
> > solution.  Also, the documentation for ddclient itself is a little sparse.
> >
> 
> I thought I saw this message before but it could be on a linux
> distribution list.  Did you tried the bugreporting system of your
> distribution?
> 
> > What do I need to add/change in ddclient.conf to fix the warning and
> > still use SSL?  And what do I need to download from DynDNS in the way of
> > certs and where do they get stored, if anything?
> > 
> > Regards,
> > /Lars
> > 
> 
> Sorry, I don't have a direct fix.
> 
> Regards,
> 
> wimpunk.
> 
> ------------------------------------------------------------------------------
> Get 100% visibility into Java/.NET code with AppDynamics Lite
> It's a free troubleshooting tool designed for production
> Get down to code-level detail for bottlenecks, with <2% overhead.
> Download for free and get started troubleshooting in minutes.
> http://p.sf.net/sfu/appdyn_d2d_ap2
> _______________________________________________
> Ddclient-support mailing list
> Ddc...@li...
> https://lists.sourceforge.net/lists/listinfo/ddclient-support
 		 	   		  

Re: [Ddclient-support] Fixing warning message ''Use of the default SSL_verify_mode..."

[wimpunk <wi...@us...>]

Hi,

On 06/02/13 12:04, Lars Noodén wrote:
> I just recently started noticing this warning message when running
> ddclient 3.8.1:
>

Please try the latest svn version.

>  "Using the default of SSL_verify_mode of SSL_VERIFY_NONE for client
>  is depreciated! Please set SSL_verify_mode to SSL_VERIFY_PEER
>  together with SSL_ca_file|SSL_ca_path for verification.
>  If you really don't want to verify the certificate and keep the
>  connection open to Man-In-The-Middle attacks please set
>  SSL_verify_mode explicitly to SSL_VERIFY_NONE in your application."
> 

Looks like a SSL message to me.  Which distribution and version of SSL
are you using?

> Currently my ddclient.conf is rather spartan:
> 
> 	ssl=yes
> 	protocol=dyndns2
> 	use=web, web=checkip.dyndns.com,web-skip='IP Address'
> 	server=members.dyndns.org
> 	login=zzz
> 	password='zzz'
> 	zzz.dyndns-remote.com
> 
> I've looked a little in the support list archive and not noticed any
> solution.  Also, the documentation for ddclient itself is a little sparse.
>

I thought I saw this message before but it could be on a linux
distribution list.  Did you tried the bugreporting system of your
distribution?

> What do I need to add/change in ddclient.conf to fix the warning and
> still use SSL?  And what do I need to download from DynDNS in the way of
> certs and where do they get stored, if anything?
> 
> Regards,
> /Lars
> 

Sorry, I don't have a direct fix.

Regards,

wimpunk.

[Ddclient-support] Fixing warning message ''Use of the default SSL_verify_mode..."

[Lars N. <lar...@gm...>]

I just recently started noticing this warning message when running
ddclient 3.8.1:

 "Using the default of SSL_verify_mode of SSL_VERIFY_NONE for client
 is depreciated! Please set SSL_verify_mode to SSL_VERIFY_PEER
 together with SSL_ca_file|SSL_ca_path for verification.
 If you really don't want to verify the certificate and keep the
 connection open to Man-In-The-Middle attacks please set
 SSL_verify_mode explicitly to SSL_VERIFY_NONE in your application."

Currently my ddclient.conf is rather spartan:

	ssl=yes
	protocol=dyndns2
	use=web, web=checkip.dyndns.com,web-skip='IP Address'
	server=members.dyndns.org
	login=zzz
	password='zzz'
	zzz.dyndns-remote.com

I've looked a little in the support list archive and not noticed any
solution.  Also, the documentation for ddclient itself is a little sparse.

What do I need to add/change in ddclient.conf to fix the warning and
still use SSL?  And what do I need to download from DynDNS in the way of
certs and where do they get stored, if anything?

Regards,
/Lars

Re: [Ddclient-support] Planning new 3.8.2 release

[Eduardo T. <etr...@gm...>]

> The patch is too big to add, it changes to much functionality.  The

It adds just one thing, a keyword: "usev6" and the code to parse it. It
does not change already existing functionality. In that respect I think
it is a pretty well isolated enhancement.

It doesn't strike me as a big patch either, but it's your call, no problem.

> current changes only has some influences on the ssl usage, the
> documentation and a dynamic dns provider.  Implementing IPv6 would at
> least create a 3.9 version.

Ok, we'll have to wait a bit longer to have official ipv6 support. But
please keep that in your radar!

Friendly, Eduardo.

Re: [Ddclient-support] Planning new 3.8.2 release

[wimpunk <wi...@us...>]

On 05/23/13 15:53, Eduardo Trápani wrote:
>> I'm planning a new release for ddclient 3.8.2. based on the latest
>> version in svn.  I appreciate very hard any feedback on that version.
> 
> Would you consider adding this patch[1]? Here [2] you can find more info
> on the patch and the logic behind it.
> 
> It has been in production all this time and some people have asked me to
> provide the patch (not available anymore through sourceforge), so I
> attached it to the Debian bug.
> 
> Cheers, Eduardo.
> 
> [1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=704467
> [2] http://sourceforge.net/mailarchive/message.php?msg_id=28068392
> 

The patch is too big to add, it changes to much functionality.  The
current changes only has some influences on the ssl usage, the
documentation and a dynamic dns provider.  Implementing IPv6 would at
least create a 3.9 version.

Re: [Ddclient-support] Planning new 3.8.2 release

[Eduardo T. <etr...@gm...>]

> I'm planning a new release for ddclient 3.8.2. based on the latest
> version in svn.  I appreciate very hard any feedback on that version.

Would you consider adding this patch[1]? Here [2] you can find more info
on the patch and the logic behind it.

It has been in production all this time and some people have asked me to
provide the patch (not available anymore through sourceforge), so I
attached it to the Debian bug.

Cheers, Eduardo.

[1] http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=704467
[2] http://sourceforge.net/mailarchive/message.php?msg_id=28068392

[Ddclient-support] Planning new 3.8.2 release

[wimpunk <wi...@us...>]

Hi all,

I'm planning a new release for ddclient 3.8.2. based on the latest
version in svn.  I appreciate very hard any feedback on that version.

Kind regards,

wimpunk.

Re: [Ddclient-support] Not Setting SSL_verify_mode Produces Warning

[wimpunk <wi...@us...>]

William,

Thanks for the patch but I would ratter like it as an option.  Strictly
spoken this is an security so I think people have to able to control the
setting.

Regards,

wimpunk.

On 02/26/13 20:14, William Makowski wrote:
> Ticket #76 https://sourceforge.net/apps/trac/ddclient/ticket/76 has
> been opened to track this issue. I have also attached a proposed
> patch to the ticket(see below).  This appears to work for me, 
> but may require further testing.
> 
> --- o/ddclient-3.8.1/ddclient    2013-02-24 08:17:51.607524001 -0500
> +++ n/ddclient-3.8.1/ddclient    2013-02-26 08:52:37.491332081 -0500
> @@ -1861,6 +1861,7 @@
>              Proto => 'tcp',
>              MultiHomed => 1,
>              Timeout => opt('timeout'),
> +            SSL_verify_mode => SSL_VERIFY_NONE(),
>          );
>          defined $sd or warning("cannot connect to $peer:$port socket: $@ " . IO::Socket::SSL::errstr());
>      } else {
> 
> 
>> From: wf...@ho...
>> To: ddc...@li...
>> Subject: Not Setting SSL_verify_mode Produces Warning
>> Date: Sun, 27 Jan 2013 22:07:14 -0500
>>
>> While using the configuration option of "ssl=yes" in ddclient a warning 
>> message is produced by the latest release of perl module IO::Socket::SSL.
>> This is because the SSL_verify_mode is not explicitly set to 
>> SSL_VERIFY_NONE. 
>>  
>> Warning Message:
>> *******************************************************************
>>  Using the default of SSL_verify_mode of SSL_VERIFY_NONE for client
>>  is depreciated! Please set SSL_verify_mode to SSL_VERIFY_PEER
>>  together with SSL_ca_file|SSL_ca_path for verification.
>>  If you really don't want to verify the certificate and keep the
>>  connection open to Man-In-The-Middle attacks please set
>>  SSL_verify_mode explicitly to SSL_VERIFY_NONE in your application.
>> *******************************************************************
>>  
>> The second paragraph of the method documentation explains that the
>> default will be changing to SSL_VERIFY_PEER (see below). ddclient will
>> need to set the SSL_verify_mode to SSL_VERIFY_NONE.
>>  
>> SSL_verify_mode
>> This option sets the verification mode for the peer certificate. You may
>> combine SSL_VERIFY_PEER (verify_peer), SSL_VERIFY_FAIL_IF_NO_PEER_CERT
>> (fail verification if no peer certificate exists; ignored for clients),
>> SSL_VERIFY_CLIENT_ONCE (verify client once; ignored for clients). See
>> OpenSSL man page for SSL_CTX_set_verify for more information.
>>  
>> The default is SSL_VERIFY_NONE for server (e.g. no check for client
>> certificate). For historical reasons the default for client is currently
>> also SSL_VERIFY_NONE, but this will change to SSL_VERIFY_PEER in the near
>> future. To aid transition a warning is issued if the client is used with
>> the default SSL_VERIFY_NONE, unless SSL_verify_mode was explicitly set
>> by the application.
>  		 	   		  
> ------------------------------------------------------------------------------
> Everyone hates slow websites. So do we.
> Make your web apps faster with AppDynamics
> Download AppDynamics Lite for free today:
> http://p.sf.net/sfu/appdyn_d2d_feb
> _______________________________________________
> Ddclient-support mailing list
> Ddc...@li...
> https://lists.sourceforge.net/lists/listinfo/ddclient-support
> 

Re: [Ddclient-support] Not Setting SSL_verify_mode Produces Warning

[William M. <wf...@ho...>]

Ticket #76 https://sourceforge.net/apps/trac/ddclient/ticket/76 has
been opened to track this issue. I have also attached a proposed
patch to the ticket(see below).  This appears to work for me, 
but may require further testing.

--- o/ddclient-3.8.1/ddclient    2013-02-24 08:17:51.607524001 -0500
+++ n/ddclient-3.8.1/ddclient    2013-02-26 08:52:37.491332081 -0500
@@ -1861,6 +1861,7 @@
             Proto => 'tcp',
             MultiHomed => 1,
             Timeout => opt('timeout'),
+            SSL_verify_mode => SSL_VERIFY_NONE(),
         );
         defined $sd or warning("cannot connect to $peer:$port socket: $@ " . IO::Socket::SSL::errstr());
     } else {


> From: wf...@ho...
> To: ddc...@li...
> Subject: Not Setting SSL_verify_mode Produces Warning
> Date: Sun, 27 Jan 2013 22:07:14 -0500
> 
> While using the configuration option of "ssl=yes" in ddclient a warning 
> message is produced by the latest release of perl module IO::Socket::SSL.
> This is because the SSL_verify_mode is not explicitly set to 
> SSL_VERIFY_NONE. 
>  
> Warning Message:
> *******************************************************************
>  Using the default of SSL_verify_mode of SSL_VERIFY_NONE for client
>  is depreciated! Please set SSL_verify_mode to SSL_VERIFY_PEER
>  together with SSL_ca_file|SSL_ca_path for verification.
>  If you really don't want to verify the certificate and keep the
>  connection open to Man-In-The-Middle attacks please set
>  SSL_verify_mode explicitly to SSL_VERIFY_NONE in your application.
> *******************************************************************
>  
> The second paragraph of the method documentation explains that the
> default will be changing to SSL_VERIFY_PEER (see below). ddclient will
> need to set the SSL_verify_mode to SSL_VERIFY_NONE.
>  
> SSL_verify_mode
> This option sets the verification mode for the peer certificate. You may
> combine SSL_VERIFY_PEER (verify_peer), SSL_VERIFY_FAIL_IF_NO_PEER_CERT
> (fail verification if no peer certificate exists; ignored for clients),
> SSL_VERIFY_CLIENT_ONCE (verify client once; ignored for clients). See
> OpenSSL man page for SSL_CTX_set_verify for more information.
>  
> The default is SSL_VERIFY_NONE for server (e.g. no check for client
> certificate). For historical reasons the default for client is currently
> also SSL_VERIFY_NONE, but this will change to SSL_VERIFY_PEER in the near
> future. To aid transition a warning is issued if the client is used with
> the default SSL_VERIFY_NONE, unless SSL_verify_mode was explicitly set
> by the application.
 		 	   		  

[Ddclient-support] Not Setting SSL_verify_mode Produces Warning

[William M. <wf...@ho...>]

While using the configuration option of "ssl=yes" in ddclient a warning message is produced by the latest release of perl module IO::Socket::SSL.  This is because the SSL_verify_mode is not explicitly set to SSL_VERIFY_NONE. 
 
Warning Message:
*******************************************************************
 Using the default of SSL_verify_mode of SSL_VERIFY_NONE for client
 is depreciated! Please set SSL_verify_mode to SSL_VERIFY_PEER
 together with SSL_ca_file|SSL_ca_path for verification.
 If you really don't want to verify the certificate and keep the
 connection open to Man-In-The-Middle attacks please set
 SSL_verify_mode explicitly to SSL_VERIFY_NONE in your application.
*******************************************************************
 
The second paragraph of the method documentation explains that the default will be changing to SSL_VERIFY_PEER (see below).  ddclient will need to set the SSL_verify_mode to SSL_VERIFY_NONE.
 
SSL_verify_mode
This option sets the verification mode for the peer certificate. You may combine SSL_VERIFY_PEER (verify_peer), SSL_VERIFY_FAIL_IF_NO_PEER_CERT (fail verification if no peer certificate exists; ignored for clients), SSL_VERIFY_CLIENT_ONCE (verify client once; ignored for clients). See OpenSSL man page for SSL_CTX_set_verify for more information.
 
The default is SSL_VERIFY_NONE for server (e.g. no check for client certificate). For historical reasons the default for client is currently also SSL_VERIFY_NONE, but this will change to SSL_VERIFY_PEER in the near future. To aid transition a warning is issued if the client is used with the default SSL_VERIFY_NONE, unless SSL_verify_mode was explicitly set by the application. 		 	   		  

[Ddclient-support] First step done: migrated to the new sf.net

[wimpunk <wi...@us...>]

Hi all,

I just want to let you know ddclient has been migrated to the new 
sourceforge environment.  Next step will be to migrate the trac wiki to 
the new wiki and update the text where needed.
Attention: if you want to check out ddclient using svn, you will have to 
change the url.  You can find the instructions on 
http://sourceforge.net/p/ddclient/code
This mailing list will be the only mailing list used by ddclient. There 
hasn't been very much messages on all the lists so I thought it would be 
a good idea to bring them all together in one list.

Next step will be moving the trac-wiki to the new sf.net wiki.  Stay tuned.

Regards,

wimpunk.

Re: [Ddclient-support] OVH stop working

[Josu L. <jos...@gm...>]

2012/7/21 wimpunk <wi...@us...>:
> Hi,
>
> I don't have any experience with OVH but I have some comments on the result:
> * it's a stupid idea to put the cache from ddclient in /tmp/. It will be
> erased after every reboot. You get an error like yours when ddclient doesn't
> find any cache file. Change it to something like
> /var/cache/ddclient/ddclient.cache but don't forget to create directory with
> the rights of the user running ddclient. You could change it to
> $HOME/.cache/ddclient/ddclient.cache if you run it as a normal desktop user.
> But again, create the directory needed.
> * The error "bad file descriptor" means it didn't correctly connected to
> www.ovh.com port 443.  Try if you can do a telnet to that host and port.
> There could be problem with the certificate, but I don't know how to check
> it running perl.
> * You could try to disable ssl, that could work to, although it is less
> secure.
>
> Regards,
>
> wimpunk.
>

Thanks!

I change the ssl to "no" and it works:

Jul 22 00:08:57 htpc ddclient[13082]: SUCCESS:  updating
sub.domain.com: good: IP address set to xxx.xxx.229.126

I got the cache on the /tmp because it is configured this way by
default on Debian.

Thanks for your help.

Best regards.

-- 
Josu Lazkano