Re: xPL Lib - updates

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

Hi Tom,

> >
> > If xpllib is running as a hub client (i.e. has bound to port
50,000+, it
> > should only *ever* listen on the loopback address - this ties in
with the
> > hub which should only ever broadcast to the loopback address.
>
> Ah, but it doesn't listen on the loopback address (which is impossible
> btw), it listens on IPAddress.Any

Ah - I think you've uncovered a bit of a bug here... it should not be
listening on IPAddress.Any - it should be listening on the loopback address
only (unless it's bound directly to port 3865 of course).

Why is it impossible to listen on the loopback address
(IPAddress.Loopback)?
Surely the loopback interface is treated the same as any other IP
interface?

> <code_snippet>
>     While Portnum < XPL_BASE_DYNAMIC_PORT + 512 And Not Portnum = 0
>       Try
>         sockIncoming.Bind(New IPEndPoint(IPAddress.Any, Portnum))
>         XPL_Portnum = Portnum
> </code_snippet>

Yep, definately a bug :-)

> > I'd suggest that the value of listenon should only be used if
xpllib is not
> > working as a hub client, i.e. it has bound directly to the base
port 3865.
> > However, I don't know of any apps where it is recommended to bind
to the
> > base port, as you prevent a hub from starting up.
> > Therefore I can't see where listenon would be useful?
> >
>
> I'm doing this whole exercise because I plan to run xPL thingies on my
pc which:
> - is connected to the internet;
> - is dhcp-server for the local area network
> - acts as a firewall.
>
> So it has 2 network cards, but I want to make sure that all the xPL
> packages stay within the local area network, and that no xPL device
> accepts anything from the internet.
>
> Because the xPLListener is listening on some port 500x on
> IPAddress.Any, it would receive package from both sides (if the
> firewall doesn't stop them).

Correct - which is why the listener should only act on traffic coming from
the loopback interface if it is acting as a hub client.

> > > - Added support for a configuration item
"listento": this is the
> > > address from which to accept incoming data: valid values
> > > are "ANY", "ANY_LOCAL" or a specific IP.
> >
> > Again, when running as a hub client, xpllib should only have
bound to the
> > loopback ddress, so should only ever receive messages from the
loopback
> > address, so again I'm not sure of the use of this parameter.
> >
>
> Same reasoning as above: suppose you are listening on both
> IPAddresses, then you may choose to refuse packages from unknown
> sources.
>
> It is a security thing:
> - either you listen on all addresses, but then you better check what
you receive
> - or you listen on a specific address and then you can be sure it is
> coming from a trusted party (depending on your setup).
> Duing the config stage, you have to listen on all ip addresses,
> because there is no way to know which address is used for xPL.
> Because there is a check on incoming data, package from an unknown
> source will still be rejected.

This should really be the job of the hub - as it is the hub that will be
receiving the packets from the network and just relaying them to local hub
clients via the loopback interface.

The addition of the hubBindIpAddress config option in the latest hub code
should help here, as it allows you to restrict where packets can come from,
but the issue with xpllib binding to all interface certainly needs
addressing.

> You are focusing on using xPLLib on a single PC communicating with the
> xPLHub, but can it not also serve in a scenario where xPL devices are
> distributed over multiple PCs ?

This is certainly not the case - I'd guess that nearly everyone on here has
several hosts running xPL apps - including bridges between RS232/485 and
Ethernet.

Personally I have 22 xPL instances at present, spread across 8 different
hosts.

> For example on a server have an xPL
> device control print jobs, send out xPL messages for each print job it
> receives, etc.  Here it would make sense to limit the
"listento"
> addresses, if you want to give control to a select few (ok, bad
> example because it is usually no threat to give people control over a
> printer ;-)

I'm not sure if you're familiar with why xPL requires a hub/client
architecture, so I'll explain it here:

xPL over Ethernet uses UDP datagrams on port 3865.

Applications send xPL messages by transmitting a UDP packet to the
broadcast address on port 3865.

However, the problem comes when you have several apps running on the same
PC:
How can they all bind to port 3865 to listen to the xPL messages? The
answer is... they can't.

To get around this problem, a "hub" application binds to port
3865, and all the other apps on the PC bind to dynamic ports.
When the apps transmit their heartbeats, they include a port= element so
that the hub knows which port they're listening on.
When the hub sees an incoming xPL message on port 3865, it relays it (via
the loopback address) to the other apps that are listening on dynamic
ports.

So, an app will only ever receive xPL messages from the hub, which is
running on the same PC, and can therefore transmit via the loopback
address.

> Sidenote:
> In fact here you can see that I wanted "listento" to be
something like
> "filter[16]" or "group[16]".  HAL treats a
"listento[16]" in the
> config.list message ok, presents it nicely to the user and sends the
> result as it should.  But when going back a second time to the
> configuration screen, it cannot handle the multiple values stored in
> the same item.

I'll look into this.

> > OK - what happens if a new release of xpllib comes across an
existing XML
> > config file?
> > How much of it can it read, or does it ignore the whole thing and
come up as
> > a new instance?
>
> At first sight (did not test it) it will accept the file, but it will
> not have read its InstanceName, so I am sure it will crash somewhere
> :-)
> Maybe a solution might be to add a version attribute in the XML file ?
>  Or in the filename ?
> Best is to delete the existing file, HAL will send its stored
> configuration over and then xPLLib will save in the new format.

Probably - I'll take a look when you send the code over.

Regards,

John