From: Johan B. <lis...@ce...> - 2012-11-05 15:15:42
|
Hi, I also experienced this problem, but unfortunately spend more than 2 hours on it. :-) The issue is not specifiying port 0. I think this is a good way of using a port that is free. The issue is this: ... my $listen_address; if ( !($local) ) { $listen_address = $::config_parms{'ipaddress_xpl'}; $listen_address = $::config_parms{'xpl_address'} unless $listen_address; } if ($main::OS_win || $::Info{'OS_name'} eq 'cygwin') { $listen_address = $::Info{IPAddress_local} unless $listen_address; } else { # can't get *nix to bind to a specific address; defaults to # kernel assigned default IP $listen_address = '0.0.0.0'; ... I don't know why "0.0.0.0" is used, but this is not working. If I simply use the IP address that is configured on my PC, and also specified with the "ipaddress_xpl" configuration in mh.private.ini, everything works as expected. I don't know why this is in the code, but I think it should be changed as this is not working for Ubuntu 12.04.1 LTS Best regards, Johan. Quoting Andy McCallum <myi...@st...>: > Grrrrrrr. I just ran into the problem discussed below (and wasted 2 hours.) > > On a new build Ubuntu 12.04.1 system this auto port selection "feature" > does not work. Considering the code change in xPL_Items.pl to use this > feature adds negligible (read as "no") extra functionality to MH should > we revert back to the code that works for all systems? > > ===>MichaelS: As the change author, would you mind reverting this part > of your code revision? > > Many thanks, > Andy. > > PS. This is particularly embarrassing since I am trying to convert a > colleague to MH and it is his installation I am trying to get working > with xPL. > > > On 14/05/12 23:57, Michael Stovenour wrote: >> I recently made the change to use port 0 so this is my fault. I am running >> Windows 7 w/ Perl 5.12 and Debian Linux 5 w/ Perl 5.10. Both seem to work >> fine for me. I'll do some research to see why it might be failing on your >> system. The worst case is that I can restore the previous logic that picked >> a base port and incremented by one on failure. >> >> This is how the inet stack "should" work >> http://www.perlmonks.org/?node_id=579654. Specifying LocalPort => 0 isn't a >> Perl trick it is part of the BSD Sockets implementation from many years ago. >> I've been doing this for a long time in C. >> >> Sincerely, >> Michael >> >> -----Original Message----- >> From: Lieven Hollevoet [mailto:li...@li...] >> Sent: Tuesday, May 08, 2012 3:03 PM >> To: The main list for the MisterHouse home automation program >> Subject: Re: [mh] XPL problem >> >> Hello Richard, >> >> I doubt that Misterhouse will be able to receive messages on port 0. And if >> this is indeed the case, it would result in the behavior you describe. >> >> Now why MH tries to listen on port 0: I have no idea. You should get a >> report in your MH logfile at startup telling you at what port it is supposed >> to be listening on (' - creating xpl listen on udp 49352' when I restart my >> MH setup). Do you see the same port that is reported by the hub displayed >> there? >> >> Kind regards, >> Lieven. >> >> >> >> Op 7-mei-2012, om 22:41 heeft Richard Williams het volgende geschreven: >> >>> Hi Lieven , >>> >>> Thanks for your reply. >>> >>> My broadcast address is 10.255.255.255 (mask = 255.0.0.0). I have the >> firewall turned it off. >>> I tried starting xpl-hub first in verbose mode and got this. >>> >>> $ xpl-hub -v -i eth0 >>> Listening on 10.255.255.255:3865 >>> Sending on 10.255.255.255 >>> Adding client: 10.0.0.9:0 "mhouse-mh.misterhouse" >>> Adding client: 10.0.0.9:40860 "bnz-ownet.claudia" >>> >>> Misterhouse sends a hbeat packet at the start and then in 5 minute >> intervals. Does this mean that it is connected? >>> I notice that the client port for Misterhouse is 0 whereas the other >> clients have a high port number. My understanding is that port 0 is >> reserved. Could this be the problem? >>> Richard >>> >>> On 8 May 2012 05:42, Lieven Hollevoet <li...@li...> wrote: >>> Hello Richard, >>> >>> I have a comparable setup as you have, only I'm using a hardware OneWire >> to ethernet device (hollie-utilmon). >>> The only two differences in MH configuration: >>> * I configure the complete name of the sensor, without using a wildcard in >> the name as you do >>> * I configure the xpl-broadcast address to be my local subnet broadcast >> address (192.168.1.255). I don't know what your netmask is, is >> 10.255.255.255 your local broadcast address, or should it be 10.0.0.255? >>> If you run the hub in verbose mode, do you actually see Misterhouse >> connecting to it (first startup the hub with --verbose and then >> Misterhouse). It could be that Misterhouse is able to send messages but not >> receive any because it did not find the hub. A reason for this might be the >> broadcast address that is not setup correctly. >>> Kind regards, >>> Lieven. >>> >>> Op 7-mei-2012, om 11:45 heeft Richard Williams het volgende geschreven: >>> >>>> Hi there, >>>> >>>> I'm trying to get my 1-wire devices working with XPL after giving up a >> while ago. I got them working with owfs i.e. Owfs_DS18S20() but not with XPL >> which I gather is the suggested way of doing it. >>>> I have mr setup thus: >>>> ipaddress_xpl_broadcast = 10.255.255.255 >>>> ipaddress_xpl = 10.0.0.9 >>>> xpl_nohub = 1 >>>> debug=xpl >>>> >>>> I have some table items matching my sensors. >>>> XPL_SENSOR, bnz-ownet.*:10.B5ED38010800, air_temp, , temp >>>> XPL_SENSOR, bnz-ownet.*:10.438939010800, freezer_temp, , temp >>>> >>>> I have xpl-hub running and xpl-logger logging events such as >>>> 10.0.0.9:40447 [xpl-stat/hbeat.app: mhouse-mh.misterhouse -> * >> 5/0/10.0.0.9] >>>> 10.0.0.9:40447 [xpl-stat/hbeat.app: bnz-ownet.claudia -> * >> 5/59241/10.0.0.9] >>>> 10.0.0.9:40447 [xpl-stat/hbeat.app: bnz-listener.claudia -> * >> 5/42363/10.0.0.9] >>>> 10.0.0.9:40447 [xpl-trig/sensor.basic: bnz-ownet.claudia -> * >> 10.438939010800/temp/-19.3125] >>>> 10.0.0.9:40447 [xpl-stat/sensor.basic: bnz-ownet.claudia -> * >> 10.B5ED38010800/temp/11.4375] >>>> So it appears that both mr and 1-wire are sending updates over XPL OK. >> But I get nothing when I try to read the state $freezer_temp->state(). >>>> print_log "Freezer temperature is %1.1f C\n", $freezer_temp->state() >> gives me >>>> Freezer temperature is 0.0 C >>>> >>>> Also I have debug=xpl but see nothing in the log. >>>> >>>> One thing I had to change from the other documentation is that the >> xpl-owfs perl script has changed to xpl-ownet and the XPL source has changed >> accordingly. >>>> Any ideas what is wrong? >>>> >>>> Richard >>>> >>>> >> ---------------------------------------------------------------------------- >> -- >>>> Live Security Virtual Conference >>>> Exclusive live event will cover all the ways today's security and >>>> threat landscape has changed and how IT managers can respond. >> Discussions >>>> will include endpoint security, mobile security and the latest in >> malware >>>> threats. >> http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___________________ >> _____________________________________ >>>> To unsubscribe from this list, go to: >> http://sourceforge.net/mail/?group_id=1365 >>> >>> >> ---------------------------------------------------------------------------- >> -- >>> Live Security Virtual Conference >>> Exclusive live event will cover all the ways today's security and >>> threat landscape has changed and how IT managers can respond. Discussions >>> will include endpoint security, mobile security and the latest in malware >>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ >>> ________________________________________________________ >>> To unsubscribe from this list, go to: >> http://sourceforge.net/mail/?group_id=1365 >>> >>> >>> >>> -- >>> Regards, >>> Richard >>> >>> Richard Williams >>> 10 Chase Grove, Taupo 3330 >>> New Zealand >>> Mob +64 (0)21 511 577 >>> >>> >> ---------------------------------------------------------------------------- >> -- >>> Live Security Virtual Conference >>> Exclusive live event will cover all the ways today's security and >>> threat landscape has changed and how IT managers can respond. Discussions >>> will include endpoint security, mobile security and the latest in malware >>> threats. >> http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___________________ >> _____________________________________ >>> To unsubscribe from this list, go to: >> http://sourceforge.net/mail/?group_id=1365 >> >> ---------------------------------------------------------------------------- >> -- >> Live Security Virtual Conference >> Exclusive live event will cover all the ways today's security and >> threat landscape has changed and how IT managers can respond. Discussions >> will include endpoint security, mobile security and the latest in malware >> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ >> ________________________________________________________ >> To unsubscribe from this list, go to: >> http://sourceforge.net/mail/?group_id=1365 >> >> >> ------------------------------------------------------------------------------ >> Live Security Virtual Conference >> Exclusive live event will cover all the ways today's security and >> threat landscape has changed and how IT managers can respond. Discussions >> will include endpoint security, mobile security and the latest in malware >> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ >> ________________________________________________________ >> To unsubscribe from this list, go to: >> http://sourceforge.net/mail/?group_id=1365 >> >> >> > > > ------------------------------------------------------------------------------ > Live Security Virtual Conference > Exclusive live event will cover all the ways today's security and > threat landscape has changed and how IT managers can respond. Discussions > will include endpoint security, mobile security and the latest in malware > threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ > ________________________________________________________ > To unsubscribe from this list, go to: > http://sourceforge.net/mail/?group_id=1365 |
From: Lieven H. <li...@li...> - 2012-11-05 19:24:47
|
Hello, I can reproduce the problem using the master branch of the github repository. It appears that the receiving xPL socket is not receiving any messages, although it is subscribed to the xpl hub. I have my actual home automation server running an not-up-to-bleeding-edge version of MH, and there the xPL code is working fine. I'll diff to see what changed in the mean time and try to come up with a fix. Kind regards, Lieven. Op 5-nov.-2012, om 16:01 heeft Johan Braeken <lis...@ce...> het volgende geschreven: > > Hi, > > I also experienced this problem, but unfortunately spend more than 2 > hours on it. :-) > > The issue is not specifiying port 0. > I think this is a good way of using a port that is free. > > > The issue is this: > > ... > my $listen_address; > if ( !($local) ) { > $listen_address = $::config_parms{'ipaddress_xpl'}; > $listen_address = $::config_parms{'xpl_address'} > unless $listen_address; > } > if ($main::OS_win || $::Info{'OS_name'} eq 'cygwin') { > $listen_address = $::Info{IPAddress_local} unless > $listen_address; > } > else { > # can't get *nix to bind to a specific address; defaults to > # kernel assigned default IP > $listen_address = '0.0.0.0'; > ... > > I don't know why "0.0.0.0" is used, but this is not working. > If I simply use the IP address that is configured on my PC, and also > specified with the "ipaddress_xpl" configuration in mh.private.ini, > everything works as expected. > I don't know why this is in the code, but I think it should be changed > as this is not working for Ubuntu 12.04.1 LTS > > > > Best regards, > > Johan. > > > > Quoting Andy McCallum <myi...@st...>: > >> Grrrrrrr. I just ran into the problem discussed below (and wasted 2 hours.) >> >> On a new build Ubuntu 12.04.1 system this auto port selection "feature" >> does not work. Considering the code change in xPL_Items.pl to use this >> feature adds negligible (read as "no") extra functionality to MH should >> we revert back to the code that works for all systems? >> >> ===>MichaelS: As the change author, would you mind reverting this part >> of your code revision? >> >> Many thanks, >> Andy. >> >> PS. This is particularly embarrassing since I am trying to convert a >> colleague to MH and it is his installation I am trying to get working >> with xPL. >> >> >> On 14/05/12 23:57, Michael Stovenour wrote: >>> I recently made the change to use port 0 so this is my fault. I am running >>> Windows 7 w/ Perl 5.12 and Debian Linux 5 w/ Perl 5.10. Both seem to work >>> fine for me. I'll do some research to see why it might be failing on your >>> system. The worst case is that I can restore the previous logic that picked >>> a base port and incremented by one on failure. >>> >>> This is how the inet stack "should" work >>> http://www.perlmonks.org/?node_id=579654. Specifying LocalPort => 0 isn't a >>> Perl trick it is part of the BSD Sockets implementation from many years ago. >>> I've been doing this for a long time in C. >>> >>> Sincerely, >>> Michael >>> >>> -----Original Message----- >>> From: Lieven Hollevoet [mailto:li...@li...] >>> Sent: Tuesday, May 08, 2012 3:03 PM >>> To: The main list for the MisterHouse home automation program >>> Subject: Re: [mh] XPL problem >>> >>> Hello Richard, >>> >>> I doubt that Misterhouse will be able to receive messages on port 0. And if >>> this is indeed the case, it would result in the behavior you describe. >>> >>> Now why MH tries to listen on port 0: I have no idea. You should get a >>> report in your MH logfile at startup telling you at what port it is supposed >>> to be listening on (' - creating xpl listen on udp 49352' when I restart my >>> MH setup). Do you see the same port that is reported by the hub displayed >>> there? >>> >>> Kind regards, >>> Lieven. >>> >>> >>> >>> Op 7-mei-2012, om 22:41 heeft Richard Williams het volgende geschreven: >>> >>>> Hi Lieven , >>>> >>>> Thanks for your reply. >>>> >>>> My broadcast address is 10.255.255.255 (mask = 255.0.0.0). I have the >>> firewall turned it off. >>>> I tried starting xpl-hub first in verbose mode and got this. >>>> >>>> $ xpl-hub -v -i eth0 >>>> Listening on 10.255.255.255:3865 >>>> Sending on 10.255.255.255 >>>> Adding client: 10.0.0.9:0 "mhouse-mh.misterhouse" >>>> Adding client: 10.0.0.9:40860 "bnz-ownet.claudia" >>>> >>>> Misterhouse sends a hbeat packet at the start and then in 5 minute >>> intervals. Does this mean that it is connected? >>>> I notice that the client port for Misterhouse is 0 whereas the other >>> clients have a high port number. My understanding is that port 0 is >>> reserved. Could this be the problem? >>>> Richard >>>> >>>> On 8 May 2012 05:42, Lieven Hollevoet <li...@li...> wrote: >>>> Hello Richard, >>>> >>>> I have a comparable setup as you have, only I'm using a hardware OneWire >>> to ethernet device (hollie-utilmon). >>>> The only two differences in MH configuration: >>>> * I configure the complete name of the sensor, without using a wildcard in >>> the name as you do >>>> * I configure the xpl-broadcast address to be my local subnet broadcast >>> address (192.168.1.255). I don't know what your netmask is, is >>> 10.255.255.255 your local broadcast address, or should it be 10.0.0.255? >>>> If you run the hub in verbose mode, do you actually see Misterhouse >>> connecting to it (first startup the hub with --verbose and then >>> Misterhouse). It could be that Misterhouse is able to send messages but not >>> receive any because it did not find the hub. A reason for this might be the >>> broadcast address that is not setup correctly. >>>> Kind regards, >>>> Lieven. >>>> >>>> Op 7-mei-2012, om 11:45 heeft Richard Williams het volgende geschreven: >>>> >>>>> Hi there, >>>>> >>>>> I'm trying to get my 1-wire devices working with XPL after giving up a >>> while ago. I got them working with owfs i.e. Owfs_DS18S20() but not with XPL >>> which I gather is the suggested way of doing it. >>>>> I have mr setup thus: >>>>> ipaddress_xpl_broadcast = 10.255.255.255 >>>>> ipaddress_xpl = 10.0.0.9 >>>>> xpl_nohub = 1 >>>>> debug=xpl >>>>> >>>>> I have some table items matching my sensors. >>>>> XPL_SENSOR, bnz-ownet.*:10.B5ED38010800, air_temp, , temp >>>>> XPL_SENSOR, bnz-ownet.*:10.438939010800, freezer_temp, , temp >>>>> >>>>> I have xpl-hub running and xpl-logger logging events such as >>>>> 10.0.0.9:40447 [xpl-stat/hbeat.app: mhouse-mh.misterhouse -> * >>> 5/0/10.0.0.9] >>>>> 10.0.0.9:40447 [xpl-stat/hbeat.app: bnz-ownet.claudia -> * >>> 5/59241/10.0.0.9] >>>>> 10.0.0.9:40447 [xpl-stat/hbeat.app: bnz-listener.claudia -> * >>> 5/42363/10.0.0.9] >>>>> 10.0.0.9:40447 [xpl-trig/sensor.basic: bnz-ownet.claudia -> * >>> 10.438939010800/temp/-19.3125] >>>>> 10.0.0.9:40447 [xpl-stat/sensor.basic: bnz-ownet.claudia -> * >>> 10.B5ED38010800/temp/11.4375] >>>>> So it appears that both mr and 1-wire are sending updates over XPL OK. >>> But I get nothing when I try to read the state $freezer_temp->state(). >>>>> print_log "Freezer temperature is %1.1f C\n", $freezer_temp->state() >>> gives me >>>>> Freezer temperature is 0.0 C >>>>> >>>>> Also I have debug=xpl but see nothing in the log. >>>>> >>>>> One thing I had to change from the other documentation is that the >>> xpl-owfs perl script has changed to xpl-ownet and the XPL source has changed >>> accordingly. >>>>> Any ideas what is wrong? >>>>> >>>>> Richard >>>>> >>>>> >>> ---------------------------------------------------------------------------- >>> -- >>>>> Live Security Virtual Conference >>>>> Exclusive live event will cover all the ways today's security and >>>>> threat landscape has changed and how IT managers can respond. >>> Discussions >>>>> will include endpoint security, mobile security and the latest in >>> malware >>>>> threats. >>> http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___________________ >>> _____________________________________ >>>>> To unsubscribe from this list, go to: >>> http://sourceforge.net/mail/?group_id=1365 >>>> >>>> >>> ---------------------------------------------------------------------------- >>> -- >>>> Live Security Virtual Conference >>>> Exclusive live event will cover all the ways today's security and >>>> threat landscape has changed and how IT managers can respond. Discussions >>>> will include endpoint security, mobile security and the latest in malware >>>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ >>>> ________________________________________________________ >>>> To unsubscribe from this list, go to: >>> http://sourceforge.net/mail/?group_id=1365 >>>> >>>> >>>> >>>> -- >>>> Regards, >>>> Richard >>>> >>>> Richard Williams >>>> 10 Chase Grove, Taupo 3330 >>>> New Zealand >>>> Mob +64 (0)21 511 577 >>>> >>>> >>> ---------------------------------------------------------------------------- >>> -- >>>> Live Security Virtual Conference >>>> Exclusive live event will cover all the ways today's security and >>>> threat landscape has changed and how IT managers can respond. Discussions >>>> will include endpoint security, mobile security and the latest in malware >>>> threats. >>> http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___________________ >>> _____________________________________ >>>> To unsubscribe from this list, go to: >>> http://sourceforge.net/mail/?group_id=1365 >>> >>> ---------------------------------------------------------------------------- >>> -- >>> Live Security Virtual Conference >>> Exclusive live event will cover all the ways today's security and >>> threat landscape has changed and how IT managers can respond. Discussions >>> will include endpoint security, mobile security and the latest in malware >>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ >>> ________________________________________________________ >>> To unsubscribe from this list, go to: >>> http://sourceforge.net/mail/?group_id=1365 >>> >>> >>> ------------------------------------------------------------------------------ >>> Live Security Virtual Conference >>> Exclusive live event will cover all the ways today's security and >>> threat landscape has changed and how IT managers can respond. Discussions >>> will include endpoint security, mobile security and the latest in malware >>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ >>> ________________________________________________________ >>> To unsubscribe from this list, go to: >>> http://sourceforge.net/mail/?group_id=1365 >>> >>> >>> >> >> >> ------------------------------------------------------------------------------ >> Live Security Virtual Conference >> Exclusive live event will cover all the ways today's security and >> threat landscape has changed and how IT managers can respond. Discussions >> will include endpoint security, mobile security and the latest in malware >> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ >> ________________________________________________________ >> To unsubscribe from this list, go to: >> http://sourceforge.net/mail/?group_id=1365 > > > ------------------------------------------------------------------------------ > LogMeIn Central: Instant, anywhere, Remote PC access and management. > Stay in control, update software, and manage PCs from one command center > Diagnose problems and improve visibility into emerging IT issues > Automate, monitor and manage. Do more in less time with Central > http://p.sf.net/sfu/logmein12331_d2d > ________________________________________________________ > To unsubscribe from this list, go to: http://sourceforge.net/mail/?group_id=1365 > |
From: Lieven H. <li...@li...> - 2012-11-05 20:13:56
|
Tracking the problem here: https://github.com/hollie/misterhouse/issues/3 Regards, Lieven. Op 5-nov.-2012, om 16:01 heeft Johan Braeken <lis...@ce...> het volgende geschreven: > > Hi, > > I also experienced this problem, but unfortunately spend more than 2 > hours on it. :-) > > The issue is not specifiying port 0. > I think this is a good way of using a port that is free. > > > The issue is this: > > ... > my $listen_address; > if ( !($local) ) { > $listen_address = $::config_parms{'ipaddress_xpl'}; > $listen_address = $::config_parms{'xpl_address'} > unless $listen_address; > } > if ($main::OS_win || $::Info{'OS_name'} eq 'cygwin') { > $listen_address = $::Info{IPAddress_local} unless > $listen_address; > } > else { > # can't get *nix to bind to a specific address; defaults to > # kernel assigned default IP > $listen_address = '0.0.0.0'; > ... > > I don't know why "0.0.0.0" is used, but this is not working. > If I simply use the IP address that is configured on my PC, and also > specified with the "ipaddress_xpl" configuration in mh.private.ini, > everything works as expected. > I don't know why this is in the code, but I think it should be changed > as this is not working for Ubuntu 12.04.1 LTS > > > > Best regards, > > Johan. > > > > Quoting Andy McCallum <myi...@st...>: > >> Grrrrrrr. I just ran into the problem discussed below (and wasted 2 hours.) >> >> On a new build Ubuntu 12.04.1 system this auto port selection "feature" >> does not work. Considering the code change in xPL_Items.pl to use this >> feature adds negligible (read as "no") extra functionality to MH should >> we revert back to the code that works for all systems? >> >> ===>MichaelS: As the change author, would you mind reverting this part >> of your code revision? >> >> Many thanks, >> Andy. >> >> PS. This is particularly embarrassing since I am trying to convert a >> colleague to MH and it is his installation I am trying to get working >> with xPL. >> >> >> On 14/05/12 23:57, Michael Stovenour wrote: >>> I recently made the change to use port 0 so this is my fault. I am running >>> Windows 7 w/ Perl 5.12 and Debian Linux 5 w/ Perl 5.10. Both seem to work >>> fine for me. I'll do some research to see why it might be failing on your >>> system. The worst case is that I can restore the previous logic that picked >>> a base port and incremented by one on failure. >>> >>> This is how the inet stack "should" work >>> http://www.perlmonks.org/?node_id=579654. Specifying LocalPort => 0 isn't a >>> Perl trick it is part of the BSD Sockets implementation from many years ago. >>> I've been doing this for a long time in C. >>> >>> Sincerely, >>> Michael >>> >>> -----Original Message----- >>> From: Lieven Hollevoet [mailto:li...@li...] >>> Sent: Tuesday, May 08, 2012 3:03 PM >>> To: The main list for the MisterHouse home automation program >>> Subject: Re: [mh] XPL problem >>> >>> Hello Richard, >>> >>> I doubt that Misterhouse will be able to receive messages on port 0. And if >>> this is indeed the case, it would result in the behavior you describe. >>> >>> Now why MH tries to listen on port 0: I have no idea. You should get a >>> report in your MH logfile at startup telling you at what port it is supposed >>> to be listening on (' - creating xpl listen on udp 49352' when I restart my >>> MH setup). Do you see the same port that is reported by the hub displayed >>> there? >>> >>> Kind regards, >>> Lieven. >>> >>> >>> >>> Op 7-mei-2012, om 22:41 heeft Richard Williams het volgende geschreven: >>> >>>> Hi Lieven , >>>> >>>> Thanks for your reply. >>>> >>>> My broadcast address is 10.255.255.255 (mask = 255.0.0.0). I have the >>> firewall turned it off. >>>> I tried starting xpl-hub first in verbose mode and got this. >>>> >>>> $ xpl-hub -v -i eth0 >>>> Listening on 10.255.255.255:3865 >>>> Sending on 10.255.255.255 >>>> Adding client: 10.0.0.9:0 "mhouse-mh.misterhouse" >>>> Adding client: 10.0.0.9:40860 "bnz-ownet.claudia" >>>> >>>> Misterhouse sends a hbeat packet at the start and then in 5 minute >>> intervals. Does this mean that it is connected? >>>> I notice that the client port for Misterhouse is 0 whereas the other >>> clients have a high port number. My understanding is that port 0 is >>> reserved. Could this be the problem? >>>> Richard >>>> >>>> On 8 May 2012 05:42, Lieven Hollevoet <li...@li...> wrote: >>>> Hello Richard, >>>> >>>> I have a comparable setup as you have, only I'm using a hardware OneWire >>> to ethernet device (hollie-utilmon). >>>> The only two differences in MH configuration: >>>> * I configure the complete name of the sensor, without using a wildcard in >>> the name as you do >>>> * I configure the xpl-broadcast address to be my local subnet broadcast >>> address (192.168.1.255). I don't know what your netmask is, is >>> 10.255.255.255 your local broadcast address, or should it be 10.0.0.255? >>>> If you run the hub in verbose mode, do you actually see Misterhouse >>> connecting to it (first startup the hub with --verbose and then >>> Misterhouse). It could be that Misterhouse is able to send messages but not >>> receive any because it did not find the hub. A reason for this might be the >>> broadcast address that is not setup correctly. >>>> Kind regards, >>>> Lieven. >>>> >>>> Op 7-mei-2012, om 11:45 heeft Richard Williams het volgende geschreven: >>>> >>>>> Hi there, >>>>> >>>>> I'm trying to get my 1-wire devices working with XPL after giving up a >>> while ago. I got them working with owfs i.e. Owfs_DS18S20() but not with XPL >>> which I gather is the suggested way of doing it. >>>>> I have mr setup thus: >>>>> ipaddress_xpl_broadcast = 10.255.255.255 >>>>> ipaddress_xpl = 10.0.0.9 >>>>> xpl_nohub = 1 >>>>> debug=xpl >>>>> >>>>> I have some table items matching my sensors. >>>>> XPL_SENSOR, bnz-ownet.*:10.B5ED38010800, air_temp, , temp >>>>> XPL_SENSOR, bnz-ownet.*:10.438939010800, freezer_temp, , temp >>>>> >>>>> I have xpl-hub running and xpl-logger logging events such as >>>>> 10.0.0.9:40447 [xpl-stat/hbeat.app: mhouse-mh.misterhouse -> * >>> 5/0/10.0.0.9] >>>>> 10.0.0.9:40447 [xpl-stat/hbeat.app: bnz-ownet.claudia -> * >>> 5/59241/10.0.0.9] >>>>> 10.0.0.9:40447 [xpl-stat/hbeat.app: bnz-listener.claudia -> * >>> 5/42363/10.0.0.9] >>>>> 10.0.0.9:40447 [xpl-trig/sensor.basic: bnz-ownet.claudia -> * >>> 10.438939010800/temp/-19.3125] >>>>> 10.0.0.9:40447 [xpl-stat/sensor.basic: bnz-ownet.claudia -> * >>> 10.B5ED38010800/temp/11.4375] >>>>> So it appears that both mr and 1-wire are sending updates over XPL OK. >>> But I get nothing when I try to read the state $freezer_temp->state(). >>>>> print_log "Freezer temperature is %1.1f C\n", $freezer_temp->state() >>> gives me >>>>> Freezer temperature is 0.0 C >>>>> >>>>> Also I have debug=xpl but see nothing in the log. >>>>> >>>>> One thing I had to change from the other documentation is that the >>> xpl-owfs perl script has changed to xpl-ownet and the XPL source has changed >>> accordingly. >>>>> Any ideas what is wrong? >>>>> >>>>> Richard >>>>> >>>>> >>> ---------------------------------------------------------------------------- >>> -- >>>>> Live Security Virtual Conference >>>>> Exclusive live event will cover all the ways today's security and >>>>> threat landscape has changed and how IT managers can respond. >>> Discussions >>>>> will include endpoint security, mobile security and the latest in >>> malware >>>>> threats. >>> http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___________________ >>> _____________________________________ >>>>> To unsubscribe from this list, go to: >>> http://sourceforge.net/mail/?group_id=1365 >>>> >>>> >>> ---------------------------------------------------------------------------- >>> -- >>>> Live Security Virtual Conference >>>> Exclusive live event will cover all the ways today's security and >>>> threat landscape has changed and how IT managers can respond. Discussions >>>> will include endpoint security, mobile security and the latest in malware >>>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ >>>> ________________________________________________________ >>>> To unsubscribe from this list, go to: >>> http://sourceforge.net/mail/?group_id=1365 >>>> >>>> >>>> >>>> -- >>>> Regards, >>>> Richard >>>> >>>> Richard Williams >>>> 10 Chase Grove, Taupo 3330 >>>> New Zealand >>>> Mob +64 (0)21 511 577 >>>> >>>> >>> ---------------------------------------------------------------------------- >>> -- >>>> Live Security Virtual Conference >>>> Exclusive live event will cover all the ways today's security and >>>> threat landscape has changed and how IT managers can respond. Discussions >>>> will include endpoint security, mobile security and the latest in malware >>>> threats. >>> http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___________________ >>> _____________________________________ >>>> To unsubscribe from this list, go to: >>> http://sourceforge.net/mail/?group_id=1365 >>> >>> ---------------------------------------------------------------------------- >>> -- >>> Live Security Virtual Conference >>> Exclusive live event will cover all the ways today's security and >>> threat landscape has changed and how IT managers can respond. Discussions >>> will include endpoint security, mobile security and the latest in malware >>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ >>> ________________________________________________________ >>> To unsubscribe from this list, go to: >>> http://sourceforge.net/mail/?group_id=1365 >>> >>> >>> ------------------------------------------------------------------------------ >>> Live Security Virtual Conference >>> Exclusive live event will cover all the ways today's security and >>> threat landscape has changed and how IT managers can respond. Discussions >>> will include endpoint security, mobile security and the latest in malware >>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ >>> ________________________________________________________ >>> To unsubscribe from this list, go to: >>> http://sourceforge.net/mail/?group_id=1365 >>> >>> >>> >> >> >> ------------------------------------------------------------------------------ >> Live Security Virtual Conference >> Exclusive live event will cover all the ways today's security and >> threat landscape has changed and how IT managers can respond. Discussions >> will include endpoint security, mobile security and the latest in malware >> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ >> ________________________________________________________ >> To unsubscribe from this list, go to: >> http://sourceforge.net/mail/?group_id=1365 > > > ------------------------------------------------------------------------------ > LogMeIn Central: Instant, anywhere, Remote PC access and management. > Stay in control, update software, and manage PCs from one command center > Diagnose problems and improve visibility into emerging IT issues > Automate, monitor and manage. Do more in less time with Central > http://p.sf.net/sfu/logmein12331_d2d > ________________________________________________________ > To unsubscribe from this list, go to: http://sourceforge.net/mail/?group_id=1365 > |
From: Lieven H. <li...@li...> - 2012-11-05 21:01:56
|
Hello, I created a pull request to fix the problem https://github.com/hollie/misterhouse/pull/4 I propose to revert the change that tried to find an open port by passing port #0 to the open function. This seems not to work correctly on all platforms. Please test and if you agree I can merge the pull request. Kind regards, Lieven. Op 5-nov.-2012, om 21:13 heeft Lieven Hollevoet <li...@li...> het volgende geschreven: > Tracking the problem here: > https://github.com/hollie/misterhouse/issues/3 > > Regards, > Lieven. > > Op 5-nov.-2012, om 16:01 heeft Johan Braeken <lis...@ce...> het volgende geschreven: > >> >> Hi, >> >> I also experienced this problem, but unfortunately spend more than 2 >> hours on it. :-) >> >> The issue is not specifiying port 0. >> I think this is a good way of using a port that is free. >> >> >> The issue is this: >> >> ... >> my $listen_address; >> if ( !($local) ) { >> $listen_address = $::config_parms{'ipaddress_xpl'}; >> $listen_address = $::config_parms{'xpl_address'} >> unless $listen_address; >> } >> if ($main::OS_win || $::Info{'OS_name'} eq 'cygwin') { >> $listen_address = $::Info{IPAddress_local} unless >> $listen_address; >> } >> else { >> # can't get *nix to bind to a specific address; defaults to >> # kernel assigned default IP >> $listen_address = '0.0.0.0'; >> ... >> >> I don't know why "0.0.0.0" is used, but this is not working. >> If I simply use the IP address that is configured on my PC, and also >> specified with the "ipaddress_xpl" configuration in mh.private.ini, >> everything works as expected. >> I don't know why this is in the code, but I think it should be changed >> as this is not working for Ubuntu 12.04.1 LTS >> >> >> >> Best regards, >> >> Johan. >> >> >> >> Quoting Andy McCallum <myi...@st...>: >> >>> Grrrrrrr. I just ran into the problem discussed below (and wasted 2 hours.) >>> >>> On a new build Ubuntu 12.04.1 system this auto port selection "feature" >>> does not work. Considering the code change in xPL_Items.pl to use this >>> feature adds negligible (read as "no") extra functionality to MH should >>> we revert back to the code that works for all systems? >>> >>> ===>MichaelS: As the change author, would you mind reverting this part >>> of your code revision? >>> >>> Many thanks, >>> Andy. >>> >>> PS. This is particularly embarrassing since I am trying to convert a >>> colleague to MH and it is his installation I am trying to get working >>> with xPL. >>> >>> >>> On 14/05/12 23:57, Michael Stovenour wrote: >>>> I recently made the change to use port 0 so this is my fault. I am running >>>> Windows 7 w/ Perl 5.12 and Debian Linux 5 w/ Perl 5.10. Both seem to work >>>> fine for me. I'll do some research to see why it might be failing on your >>>> system. The worst case is that I can restore the previous logic that picked >>>> a base port and incremented by one on failure. >>>> >>>> This is how the inet stack "should" work >>>> http://www.perlmonks.org/?node_id=579654. Specifying LocalPort => 0 isn't a >>>> Perl trick it is part of the BSD Sockets implementation from many years ago. >>>> I've been doing this for a long time in C. >>>> >>>> Sincerely, >>>> Michael >>>> >>>> -----Original Message----- >>>> From: Lieven Hollevoet [mailto:li...@li...] >>>> Sent: Tuesday, May 08, 2012 3:03 PM >>>> To: The main list for the MisterHouse home automation program >>>> Subject: Re: [mh] XPL problem >>>> >>>> Hello Richard, >>>> >>>> I doubt that Misterhouse will be able to receive messages on port 0. And if >>>> this is indeed the case, it would result in the behavior you describe. >>>> >>>> Now why MH tries to listen on port 0: I have no idea. You should get a >>>> report in your MH logfile at startup telling you at what port it is supposed >>>> to be listening on (' - creating xpl listen on udp 49352' when I restart my >>>> MH setup). Do you see the same port that is reported by the hub displayed >>>> there? >>>> >>>> Kind regards, >>>> Lieven. >>>> >>>> >>>> >>>> Op 7-mei-2012, om 22:41 heeft Richard Williams het volgende geschreven: >>>> >>>>> Hi Lieven , >>>>> >>>>> Thanks for your reply. >>>>> >>>>> My broadcast address is 10.255.255.255 (mask = 255.0.0.0). I have the >>>> firewall turned it off. >>>>> I tried starting xpl-hub first in verbose mode and got this. >>>>> >>>>> $ xpl-hub -v -i eth0 >>>>> Listening on 10.255.255.255:3865 >>>>> Sending on 10.255.255.255 >>>>> Adding client: 10.0.0.9:0 "mhouse-mh.misterhouse" >>>>> Adding client: 10.0.0.9:40860 "bnz-ownet.claudia" >>>>> >>>>> Misterhouse sends a hbeat packet at the start and then in 5 minute >>>> intervals. Does this mean that it is connected? >>>>> I notice that the client port for Misterhouse is 0 whereas the other >>>> clients have a high port number. My understanding is that port 0 is >>>> reserved. Could this be the problem? >>>>> Richard >>>>> >>>>> On 8 May 2012 05:42, Lieven Hollevoet <li...@li...> wrote: >>>>> Hello Richard, >>>>> >>>>> I have a comparable setup as you have, only I'm using a hardware OneWire >>>> to ethernet device (hollie-utilmon). >>>>> The only two differences in MH configuration: >>>>> * I configure the complete name of the sensor, without using a wildcard in >>>> the name as you do >>>>> * I configure the xpl-broadcast address to be my local subnet broadcast >>>> address (192.168.1.255). I don't know what your netmask is, is >>>> 10.255.255.255 your local broadcast address, or should it be 10.0.0.255? >>>>> If you run the hub in verbose mode, do you actually see Misterhouse >>>> connecting to it (first startup the hub with --verbose and then >>>> Misterhouse). It could be that Misterhouse is able to send messages but not >>>> receive any because it did not find the hub. A reason for this might be the >>>> broadcast address that is not setup correctly. >>>>> Kind regards, >>>>> Lieven. >>>>> >>>>> Op 7-mei-2012, om 11:45 heeft Richard Williams het volgende geschreven: >>>>> >>>>>> Hi there, >>>>>> >>>>>> I'm trying to get my 1-wire devices working with XPL after giving up a >>>> while ago. I got them working with owfs i.e. Owfs_DS18S20() but not with XPL >>>> which I gather is the suggested way of doing it. >>>>>> I have mr setup thus: >>>>>> ipaddress_xpl_broadcast = 10.255.255.255 >>>>>> ipaddress_xpl = 10.0.0.9 >>>>>> xpl_nohub = 1 >>>>>> debug=xpl >>>>>> >>>>>> I have some table items matching my sensors. >>>>>> XPL_SENSOR, bnz-ownet.*:10.B5ED38010800, air_temp, , temp >>>>>> XPL_SENSOR, bnz-ownet.*:10.438939010800, freezer_temp, , temp >>>>>> >>>>>> I have xpl-hub running and xpl-logger logging events such as >>>>>> 10.0.0.9:40447 [xpl-stat/hbeat.app: mhouse-mh.misterhouse -> * >>>> 5/0/10.0.0.9] >>>>>> 10.0.0.9:40447 [xpl-stat/hbeat.app: bnz-ownet.claudia -> * >>>> 5/59241/10.0.0.9] >>>>>> 10.0.0.9:40447 [xpl-stat/hbeat.app: bnz-listener.claudia -> * >>>> 5/42363/10.0.0.9] >>>>>> 10.0.0.9:40447 [xpl-trig/sensor.basic: bnz-ownet.claudia -> * >>>> 10.438939010800/temp/-19.3125] >>>>>> 10.0.0.9:40447 [xpl-stat/sensor.basic: bnz-ownet.claudia -> * >>>> 10.B5ED38010800/temp/11.4375] >>>>>> So it appears that both mr and 1-wire are sending updates over XPL OK. >>>> But I get nothing when I try to read the state $freezer_temp->state(). >>>>>> print_log "Freezer temperature is %1.1f C\n", $freezer_temp->state() >>>> gives me >>>>>> Freezer temperature is 0.0 C >>>>>> >>>>>> Also I have debug=xpl but see nothing in the log. >>>>>> >>>>>> One thing I had to change from the other documentation is that the >>>> xpl-owfs perl script has changed to xpl-ownet and the XPL source has changed >>>> accordingly. >>>>>> Any ideas what is wrong? >>>>>> >>>>>> Richard >>>>>> >>>>>> >>>> ---------------------------------------------------------------------------- >>>> -- >>>>>> Live Security Virtual Conference >>>>>> Exclusive live event will cover all the ways today's security and >>>>>> threat landscape has changed and how IT managers can respond. >>>> Discussions >>>>>> will include endpoint security, mobile security and the latest in >>>> malware >>>>>> threats. >>>> http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___________________ >>>> _____________________________________ >>>>>> To unsubscribe from this list, go to: >>>> http://sourceforge.net/mail/?group_id=1365 >>>>> >>>>> >>>> ---------------------------------------------------------------------------- >>>> -- >>>>> Live Security Virtual Conference >>>>> Exclusive live event will cover all the ways today's security and >>>>> threat landscape has changed and how IT managers can respond. Discussions >>>>> will include endpoint security, mobile security and the latest in malware >>>>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ >>>>> ________________________________________________________ >>>>> To unsubscribe from this list, go to: >>>> http://sourceforge.net/mail/?group_id=1365 >>>>> >>>>> >>>>> >>>>> -- >>>>> Regards, >>>>> Richard >>>>> >>>>> Richard Williams >>>>> 10 Chase Grove, Taupo 3330 >>>>> New Zealand >>>>> Mob +64 (0)21 511 577 >>>>> >>>>> >>>> ---------------------------------------------------------------------------- >>>> -- >>>>> Live Security Virtual Conference >>>>> Exclusive live event will cover all the ways today's security and >>>>> threat landscape has changed and how IT managers can respond. Discussions >>>>> will include endpoint security, mobile security and the latest in malware >>>>> threats. >>>> http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/___________________ >>>> _____________________________________ >>>>> To unsubscribe from this list, go to: >>>> http://sourceforge.net/mail/?group_id=1365 >>>> >>>> ---------------------------------------------------------------------------- >>>> -- >>>> Live Security Virtual Conference >>>> Exclusive live event will cover all the ways today's security and >>>> threat landscape has changed and how IT managers can respond. Discussions >>>> will include endpoint security, mobile security and the latest in malware >>>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ >>>> ________________________________________________________ >>>> To unsubscribe from this list, go to: >>>> http://sourceforge.net/mail/?group_id=1365 >>>> >>>> >>>> ------------------------------------------------------------------------------ >>>> Live Security Virtual Conference >>>> Exclusive live event will cover all the ways today's security and >>>> threat landscape has changed and how IT managers can respond. Discussions >>>> will include endpoint security, mobile security and the latest in malware >>>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ >>>> ________________________________________________________ >>>> To unsubscribe from this list, go to: >>>> http://sourceforge.net/mail/?group_id=1365 >>>> >>>> >>>> >>> >>> >>> ------------------------------------------------------------------------------ >>> Live Security Virtual Conference >>> Exclusive live event will cover all the ways today's security and >>> threat landscape has changed and how IT managers can respond. Discussions >>> will include endpoint security, mobile security and the latest in malware >>> threats. http://www.accelacomm.com/jaw/sfrnl04242012/114/50122263/ >>> ________________________________________________________ >>> To unsubscribe from this list, go to: >>> http://sourceforge.net/mail/?group_id=1365 >> >> >> ------------------------------------------------------------------------------ >> LogMeIn Central: Instant, anywhere, Remote PC access and management. >> Stay in control, update software, and manage PCs from one command center >> Diagnose problems and improve visibility into emerging IT issues >> Automate, monitor and manage. Do more in less time with Central >> http://p.sf.net/sfu/logmein12331_d2d >> ________________________________________________________ >> To unsubscribe from this list, go to: http://sourceforge.net/mail/?group_id=1365 >> > |
From: John <jo...@to...> - 2012-11-05 22:09:57
|
Reverting makes sense. Dynamic port assignment seems like a brittle solution. Maybe the people needing that capability can describe the problem they are trying to solve and another solution can be used. John |
From: Eloy P. <pe...@ch...> - 2012-11-05 22:24:15
|
Hi Lieven, On 11/05/2012 04:01 PM, Lieven Hollevoet wrote: > Hello, > > I created a pull request to fix the problem > > https://github.com/hollie/misterhouse/pull/4 > > I propose to revert the change that tried to find an open port by passing port #0 to the open function. This seems not to work correctly on all platforms. > > Please test and if you agree I can merge the pull request. I have not tested but the change, i.e. reverting to the previous way that we were using to find an unused local port to listen on, seems good to me. I do not know where the idea that supplying a local port equal to zero to IO::Socket::INET->new() results in the operating system choosing an unused port comes from, and I have had a hard time finding documentation that supports this. In udp(7) on Linux I see this: "In order to receive packets, the socket can be bound to a local address first by using bind(2). Otherwise the socket layer will automatically assign a free local port out of the range defined by /proc/sys/net/ipv4/ip_local_port_range and bind the socket to INADDR_ANY." I do not see where in Perl's IO/Socket.pm or IO/Socket/INET.pm they are treating a local port equal to zero in a special way, and I checked the Perl shipped with Ubuntu 12.10 (5.14.2) and the Perl shipped with an old Debian (5.10.1) and there is no difference in the involved functions, so my guess is that it is a kernel change that caused this problem. In any case, I think it is probably not worth chasing this down and your proposed fix is the way to go. This has been broken since January of this year; the change was introduced in r1977. Cheers, Eloy Paris.- |
From: Lieven H. <li...@li...> - 2012-11-06 07:26:52
|
Hi, I merged the pull request, so the master branch should be fixed now. Kind regards, Lieven. On Mon, Nov 5, 2012 at 11:22 PM, Eloy Paris <pe...@ch...> wrote: > Hi Lieven, > > On 11/05/2012 04:01 PM, Lieven Hollevoet wrote: > >> Hello, >> >> I created a pull request to fix the problem >> >> https://github.com/hollie/misterhouse/pull/4 >> >> I propose to revert the change that tried to find an open port by passing port #0 to the open function. This seems not to work correctly on all platforms. >> >> Please test and if you agree I can merge the pull request. > > I have not tested but the change, i.e. reverting to the previous way > that we were using to find an unused local port to listen on, seems good > to me. > > I do not know where the idea that supplying a local port equal to zero > to IO::Socket::INET->new() results in the operating system choosing an > unused port comes from, and I have had a hard time finding documentation > that supports this. In udp(7) on Linux I see this: > > "In order to receive packets, the socket can be bound to a local > address first by using bind(2). Otherwise the socket layer will > automatically assign a free local port out of the range defined > by /proc/sys/net/ipv4/ip_local_port_range and bind the socket to > INADDR_ANY." > > I do not see where in Perl's IO/Socket.pm or IO/Socket/INET.pm they are > treating a local port equal to zero in a special way, and I checked the > Perl shipped with Ubuntu 12.10 (5.14.2) and the Perl shipped with an old > Debian (5.10.1) and there is no difference in the involved functions, so > my guess is that it is a kernel change that caused this problem. > > In any case, I think it is probably not worth chasing this down and your > proposed fix is the way to go. > > This has been broken since January of this year; the change was > introduced in r1977. > > Cheers, > > Eloy Paris.- > > > ------------------------------------------------------------------------------ > LogMeIn Central: Instant, anywhere, Remote PC access and management. > Stay in control, update software, and manage PCs from one command center > Diagnose problems and improve visibility into emerging IT issues > Automate, monitor and manage. Do more in less time with Central > http://p.sf.net/sfu/logmein12331_d2d > ________________________________________________________ > To unsubscribe from this list, go to: http://sourceforge.net/mail/?group_id=1365 > |
From: Lieven H. <li...@li...> - 2012-11-07 09:54:34
|
Hi, I found another problem with the xPL_Items.pm changes while I was testing the master branch. I would like to ask your opinion on it: https://github.com/hollie/misterhouse/issues/10 According to me the change made the reception of xPL messages more restrictive (it prevents devices that have white spaces in their messages to work correctly), I don't see the point of that and I would like to revert that back to the original behavior. Kind regards, Lieven. Op 6-nov.-2012, om 08:17 heeft Lieven Hollevoet <li...@li...> het volgende geschreven: > Hi, > > I merged the pull request, so the master branch should be fixed now. > > Kind regards, > Lieven. > > > > On Mon, Nov 5, 2012 at 11:22 PM, Eloy Paris <pe...@ch...> wrote: >> Hi Lieven, >> >> On 11/05/2012 04:01 PM, Lieven Hollevoet wrote: >> >>> Hello, >>> >>> I created a pull request to fix the problem >>> >>> https://github.com/hollie/misterhouse/pull/4 >>> >>> I propose to revert the change that tried to find an open port by passing port #0 to the open function. This seems not to work correctly on all platforms. >>> >>> Please test and if you agree I can merge the pull request. >> >> I have not tested but the change, i.e. reverting to the previous way >> that we were using to find an unused local port to listen on, seems good >> to me. >> >> I do not know where the idea that supplying a local port equal to zero >> to IO::Socket::INET->new() results in the operating system choosing an >> unused port comes from, and I have had a hard time finding documentation >> that supports this. In udp(7) on Linux I see this: >> >> "In order to receive packets, the socket can be bound to a local >> address first by using bind(2). Otherwise the socket layer will >> automatically assign a free local port out of the range defined >> by /proc/sys/net/ipv4/ip_local_port_range and bind the socket to >> INADDR_ANY." >> >> I do not see where in Perl's IO/Socket.pm or IO/Socket/INET.pm they are >> treating a local port equal to zero in a special way, and I checked the >> Perl shipped with Ubuntu 12.10 (5.14.2) and the Perl shipped with an old >> Debian (5.10.1) and there is no difference in the involved functions, so >> my guess is that it is a kernel change that caused this problem. >> >> In any case, I think it is probably not worth chasing this down and your >> proposed fix is the way to go. >> >> This has been broken since January of this year; the change was >> introduced in r1977. >> >> Cheers, >> >> Eloy Paris.- >> >> >> ------------------------------------------------------------------------------ >> LogMeIn Central: Instant, anywhere, Remote PC access and management. >> Stay in control, update software, and manage PCs from one command center >> Diagnose problems and improve visibility into emerging IT issues >> Automate, monitor and manage. Do more in less time with Central >> http://p.sf.net/sfu/logmein12331_d2d >> ________________________________________________________ >> To unsubscribe from this list, go to: http://sourceforge.net/mail/?group_id=1365 >> |
From: Eloy P. <pe...@ch...> - 2012-11-07 12:23:49
|
Hi Lieven, On 11/07/2012 04:54 AM, Lieven Hollevoet wrote: > Hi, > > I found another problem with the xPL_Items.pm changes while I was testing the master branch. > > I would like to ask your opinion on it: > > https://github.com/hollie/misterhouse/issues/10 > > According to me the change made the reception of xPL messages more restrictive (it prevents devices that have white spaces in their messages to work correctly), I don't see the point of that and I would like to revert that back to the original behavior. I don't understand why this change was made, but I remember the short discussion that resulted in the change. Take a look here to see if you can figure out a way to fix this gentleman's issue without breaking xPL for everybody else: http://tech.groups.yahoo.com/group/misterhouse/message/43779 Perhaps the "fix" is to not have devices with spaces in their names? Dunno. Cheers, Eloy Paris.- |
From: Lieven H. <li...@li...> - 2012-11-07 20:15:15
|
Hi Eloy, Op 7-nov.-2012, om 13:18 heeft Eloy Paris <pe...@ch...> het volgende geschreven: > Hi Lieven, > > On 11/07/2012 04:54 AM, Lieven Hollevoet wrote: > >> Hi, >> >> https://github.com/hollie/misterhouse/issues/10 >> >> According to me the change made the reception of xPL messages more restrictive (it prevents devices that have white spaces in their messages to work correctly), I don't see the point of that and I would like to revert that back to the original behavior. > I don't understand why this change was made, but I remember the short > discussion that resulted in the change. Take a look here to see if you > can figure out a way to fix this gentleman's issue without breaking xPL > for everybody else: > > http://tech.groups.yahoo.com/group/misterhouse/message/43779 > Thank for digging this up. As I expected indeed, the change was made for device/value pairs to support values that contain spaces. While digging further I found in the documentation of the xPL project (http://xplproject.org.uk/wiki/index.php?title=XPL_Specification_Document) the following rule: All structural elements of an xPL message, i.e. all header fields, schema class and type names, and the names of name/value pairs, must contain only the following characters: a-z, 0-9 and "-" (lower case letters, numbers and the hyphen/dash character -- ASCII 45 So there are two things I can conclude from this: * values should not have spaces in them, which is exactly what misterhouse is supporting by this change * there seems to be something wrong with my jeenode client because apparently it creates key/value pairs with a space at the end, causing the match in the subsequent perl code to fail. I'll fix that. Question is: do we want to support invalid xPL frames in Misterhouse? I have nothing against that if this helps people, but maybe it should not be the default way of working. We could add a setting through mh.private.ini to enable it? > Perhaps the "fix" is to not have devices with spaces in their names? Dunno. > Indeed, I don't have it (intentionally) in my installation, but I'll need to dig a bit further into that code to fix it. Kind regards, Lieven. |
From: Eloy P. <pe...@ch...> - 2012-11-07 20:44:10
|
Hi Lieven, On 11/07/2012 03:15 PM, Lieven Hollevoet wrote: > While digging further I found in the documentation of the xPL project (http://xplproject.org.uk/wiki/index.php?title=XPL_Specification_Document) the following rule: > > All structural elements of an xPL message, i.e. all header fields, schema class and type names, and the names of name/value pairs, must contain only the following characters: a-z, 0-9 and "-" (lower case letters, numbers and the hyphen/dash character -- ASCII 45 > > So there are two things I can conclude from this: > * values should not have spaces in them, which is exactly what misterhouse is supporting by this change Makes sense based on the documentation that you found. > * there seems to be something wrong with my jeenode client because > apparently it creates key/value pairs with a space at the end, > causing the match in the subsequent perl code to fail. I'll fix > that. I am curious about this but just in terms of your particular setup... did you write the JeeNode code for generating xPL messages, or it's something that JCW wrote and is part of JeeLib, or an example provided with JeeLib? Is it standard Arduino code? And thes xPL messages are transmitted via the RFM22B and received by the PC where MisterHouse runs on through a JeeLink? > Question is: do we want to support invalid xPL frames in Misterhouse? > I have nothing against that if this helps people, but maybe it should > not be the default way of working. We could add a setting through > mh.private.ini to enable it? Personally I think that we should not support invalid frames/PDUs from any protocol. We may find the situation where we have been accepting invalid frames since day one, or for a very long time. In these cases I think the decision to change things is a little more complicated because we would break working setups. In this case, however, this is a recent change, and before the change we were not accepting invalid frames, so I would support reverting the change and asking people to use compliant sensor names (without a space in them) to avoid running into issues. >> Perhaps the "fix" is to not have devices with spaces in their >> names? Dunno. >> > > Indeed, I don't have it (intentionally) in my installation, but > I'll need to dig a bit further into that code to fix it. Do you mean your JeeNode code or the MisterHouse code? Cheers, Eloy Paris.- > > Kind regards, > Lieven. > > |
From: Lieven H. <li...@li...> - 2012-11-07 21:41:26
|
Hi, I have reverted the change and merged it into master. John also supported this (on the issue list on github). Kind regards, Lieven. |
From: Lieven H. <li...@li...> - 2012-11-07 20:54:13
|
Hi Eloy, Op 7-nov.-2012, om 21:43 heeft Eloy Paris <pe...@ch...> het volgende geschreven: > Hi Lieven, > > [..] >> * there seems to be something wrong with my jeenode client because >> apparently it creates key/value pairs with a space at the end, >> causing the match in the subsequent perl code to fail. I'll fix >> that. > > I am curious about this but just in terms of your particular setup... > did you write the JeeNode code for generating xPL messages, or it's > something that JCW wrote and is part of JeeLib, or an example provided > with JeeLib? Is it standard Arduino code? > I have some jeenodes reporting motion/humidity/temperature/lightlevel. They are running the roomnode code. Reception of the messages is done by a jeelink running a modified version of the standard rfm12 test sketch. https://github.com/hollie/xpl-jeenode I then made an xpl-perl extension to communicatie with the jeelink to get the messages and to translate them into xpl messages. https://github.com/hollie/xpl-perl/blob/master/lib/xPL/Dock/Jeenodes.pm > And thes xPL messages are transmitted via the RFM22B and received by the > PC where MisterHouse runs on through a JeeLink? No, xPL is my interface to MH. The jeelink <> xpl interface is handled by my xpl-perl interface. I try to avoid adding drivers to MH as the xPL interface is working fine and it is the ideal way to separate drivers from the core code of MH. > >> Question is: do we want to support invalid xPL frames in Misterhouse? >> I have nothing against that if this helps people, but maybe it should >> not be the default way of working. We could add a setting through >> mh.private.ini to enable it? > > Personally I think that we should not support invalid frames/PDUs from > any protocol. > > We may find the situation where we have been accepting invalid frames > since day one, or for a very long time. In these cases I think the > decision to change things is a little more complicated because we would > break working setups. > > In this case, however, this is a recent change, and before the change we > were not accepting invalid frames, so I would support reverting the > change and asking people to use compliant sensor names (without a space > in them) to avoid running into issues. > OK, I could live with that. I did add to the mailing you digged up (I missed the thread because it didn't have xPL in it's subject :-)) a link to the place where a suggestion can be done to the author of the xpl-perl framework to fix the interface code. >>> Perhaps the "fix" is to not have devices with spaces in their >>> names? Dunno. >>> >> >> Indeed, I don't have it (intentionally) in my installation, but >> I'll need to dig a bit further into that code to fix it. > > Do you mean your JeeNode code or the MisterHouse code? I mean my xpl-perl jeenode interface. Kind regards, Lieven. |
From: Eloy P. <pe...@ch...> - 2012-11-10 06:26:18
|
Hi Lieven, On 11/07/2012 03:54 PM, Lieven Hollevoet wrote: [...] >> I am curious about this but just in terms of your particular setup... >> did you write the JeeNode code for generating xPL messages, or it's >> something that JCW wrote and is part of JeeLib, or an example provided >> with JeeLib? Is it standard Arduino code? >> > > I have some jeenodes reporting motion/humidity/temperature/lightlevel. They are running the roomnode code. Reception of the messages is done by a jeelink running a modified version of the standard rfm12 test sketch. > > https://github.com/hollie/xpl-jeenode > > I then made an xpl-perl extension to communicatie with the jeelink to get the messages and to translate them into xpl messages. > > https://github.com/hollie/xpl-perl/blob/master/lib/xPL/Dock/Jeenodes.pm > >> And thes xPL messages are transmitted via the RFM22B and received by the >> PC where MisterHouse runs on through a JeeLink? > > No, xPL is my interface to MH. The jeelink <> xpl interface is handled by my xpl-perl interface. I try to avoid adding drivers to MH as the xPL interface is working fine and it is the ideal way to separate drivers from the core code of MH. [...] >>> Indeed, I don't have it (intentionally) in my installation, but >>> I'll need to dig a bit further into that code to fix it. >> >> Do you mean your JeeNode code or the MisterHouse code? > > I mean my xpl-perl jeenode interface. Ah, pretty cool; thanks for the insight on your automation setup. I understand now. I am starting to plan deployment of Arduino-based sensors so this information helps me a lot with regards to what path to take to get the sensor readings into MisterHouse. Cheers, Eloy Paris.- |