iServer on livebox and windows - different behavior
2 March, 2012 - 11:25
Hi All
I’ve been experimenting with xapflash with windows iServer (iServer F that comes with xapflash). My setup was:
192.168.1.250 – web server storing xapflash swf, config.xml, xapconfig.xml (iserver ipaddr set to 192.168.1.100)
192.168.1.100 – pc running iServer F
192.168.1.50 – PLC with custom xap stack
Everything worked like a charm. I was able to start IE on 192.168.1.100, point to http://192.168.1.250/xapflash.swf and control 192.168.1.50
Yesterday I received livebox, flashed it and seems it works. At least I can see it’s heartbeats and queries with xfxviewer. So I made changes to xapconfig.xml on 192.168.1.250 setting iserver address to 192.168.1.41 (static address for livebox). With this configuration I can still use web browser to connect to192.168.1.100 and open http://192.168.1.250/xapflash.swf but now I am unable to control anything – PLC at 192.168.1.50 does not receive any bytes on it's listening socket, althought when I push UI button I can see proper xapBSC.cmd message fired (with xfxViewer). Strangely enough swf client receives xapBSC.info messages and reflect them in the UI. So there is a "one-way" communication - PLC is visible by the clients, but no client commands reach PLC
Also, one thing I noticed - when I run iServer in debug mode it show that is receives xapBSC.cmd messages and then it does something called "filter compare" (not sure what's the correct function name, but it's from filter.c file) and this compare always results in match=0. So looks like it simply does not know where to route the message. And when xapBSC.info comes from the PLC iServer does the same stuff but always ends up with match=1 and then routes message to appropriate client IP. Maybe I just need to supply PLC IP in it's heartbeats (I am setting the "port" value only)?
Any help highly appreciated
Thanks in advance
Dmitry
2 March, 2012 - 16:21
#4
One obvious thing stands out
One obvious thing stands out ID is uppercase. I wonder if there is a bug deep in the xaplib library that is not being case agnostic. Also you are using ID=01 instead of ID=* yes it should match but again there might an issue around that too.
If others are matching and this one isn't then I think we might have a smoking gun.
Also this is a v13 message I've not done a lot of testing with this.
Brett
3 March, 2012 - 00:42
#5
Can't see the issue
I had a close look at xaplib2 the filters are case agnostic so there isn't an issue there. Looking at iServer I did see a case issue however this is deleting a filter, so its not applicable in your case. But I will file an issue on that.
The iserver will only forward message that it has been told to filter according to what the .SWF application tells. You need to gather the debug that iServer display when a CLIENT (.SWF) application connects and sets up all the filter for what is allowed to by relayed by iServer.
The iServer has been working successfully for many other folk and you are the first to report an issue, I can only say at this point it looks more like a configuration problem, however I won't rule anything out until we can better understand what is going on. Often bugs lay dorment for a long time.
If you can reduce this to a simple case of ONE control item in the .SWF and send synthetic event via xFXViewer that isn't being routed, and the windows iServer does, that would give me a chance to reproduce then I could investigate a little deeper.
Brett
3 March, 2012 - 18:00
#7
Direct addressing xAP
Really? Well this device is operating against the xAP standards that say it should use a BROADCAST not UNICAST. Thats pretty poor for the PLC to have such a non-standard implementation.
Well spotted - I did find a few things in the iServer that I will tidy up anyway with regards to case, but I suspect nobody is running into these. Glad its sorted. If you want to share your LUA solution for others post it to the sample scripts section.
Brett
This is how xapBSC.info message is properly routed to the client
[dbg][rx.c:23:readXapData] Rx xAP packet
xap-header
{
v=13
hop=1
uid=FFDBDB02
class=xAPBSC.info
source=khome.PLC.41:study.light.1
}
input.state
{
state=OFF
}
[dbg][parse.c:33:xapGetValueF] section=xap-header key=target
[dbg][filter.c:136:xapCompareFilters] match=0
[dbg][parse.c:33:xapGetValueF] section=xap-header key=source
[dbg][parse.c:42:xapGetValueF] found value=khome.PLC.41:study.light.1
[dbg][filter.c:53:xapFilterAddrSubaddress] filterAddr=use.last.device addr=khome.PLC.41:study.light.1
[dbg][filter.c:136:xapCompareFilters] match=0
[dbg][parse.c:33:xapGetValueF] section=xap-header key=source
[dbg][parse.c:42:xapGetValueF] found value=khome.PLC.41:study.light.1
[dbg][filter.c:53:xapFilterAddrSubaddress] filterAddr=khome.PLC.41:study.light.1 addr=khome.PLC.41:study.light.1
[dbg][filter.c:136:xapCompareFilters] match=1
[dbg][main.c:125:sendToClient] 192.168.1.100 msg <xap>xap-header
{
v=13
hop=1
uid=FFDBDB02
class=xapbsc.info
source=khome.plc.41:study.light.1
}
input.state
{
state=off
}
</xap>