Re: Re: xPL Monitor: triple msgs

["John B" <home-automation@xxxxxxxxxxxxxxxx>]

Hi Tom,

> Isn't there also a security concern here if you open a port to traffic
> coming from the internet ?  If the lights start flashing you know a
> hacker has found his way in :-)
> It would be possible, wouldn't it ?  Just send a correctly formed
> packet to port 3865 with the command X10_ALL_LIGHTS_ON...

Yes, this is certainly possible.

However, if you leave your PC wide open to the Internet, you're likely to
run into bigger problems than people just turning your X10 modules on and
off - you're likely to get infected by a worm/virus long before anyone
finds your xPL port is open.

If your PC is protected by a firewall (as all Internet-connected PCs should
be) and you haven't specifically opened port 3865 (which you shouldn't!)
then there should be no problem with people being able to control your xPL
devices.

> > > (In fact, I think I saw a few other possible improvements,
but I
> > > better shut up being a newbie on the list ;-)
> >
> > Please feel free to make any suggestions - it's nearly 2 years
since the hub
> > was written - and the VB.NET version was itself taken from Tony's
VB6
> > version which itself had been through several phases of
development.
>
>
> Okay, you asked for it!
> - drop the structure structXPLHub, use a class instead

Any advantages to doing this?

> - use a collection to store XPLHubs  (maybe rename to XPLApps "en
> passant") instead of a fixed size array

Yep, good idea.

> - put the IPAddress to bind to in the .config (ok, done ;-)

Indeed ;-)

> - put  XPL_BASE_PORT and MAX_XPL_MSG_SIZE in the .config

I disagree here :-)

- The base port is our official IANA-allocated port - and I can't think of
a reason why it should ever be changed (though if you had a reason in mind,
please let me know in case I haven't thought of something).

- The maximum xPL message size is set based on the maximum reliable UDP
packet size of 1500 bytes - we don't really want users playing around with
this as it could lead to reliability issues.

> - IsMsgLocal: check against the configured address instead

Yep - need to change this.

> - rewrite the "find XPLHub in array" using collection logic

OK

> - send the message to the configured address not the loopback address

The message is *supposed* to go to the loopback address.
Hub clients bind to a dynamic port on the loopback address, and the hub
sends messages to those ports on the loopback address.

> - add logic to remove XPLHubs from the collection: upon HBEAT.END and
> if a time-out happens because no more heartbeats (then you can make
> use of the otherwise unused "Refreshed" property stored in
XPLHub)

Yep, it looks like this bit was overlooked!

> - maybe save state when the hub goes down so that it can be restarted
> and immediately functions when it comes back up ?

Yep, I think Tony has already added this capability to the hub in xPLHal -
I'll merge in his code.

> I admit: no earth-shocking suggestions.  It works great as it is now,
> so why try to fix it.  Maybe I'll implement the suggestions and then
> forward the source to you.  Then you can still ignore it ;-)

The changes that you've outlined shouldn't take that long to implement, and
they should help to tidy up the source a bit - I'll see if I can get them
done this week and publish an update.

> I'm enthousiastic about this whole xPL project.  I'll definitely use
it!

Great :-)

Regards,

John