325xi, I just logged in and it seems serproxy is running ok now. I think you’re saying the segfault happens when running serproxy on another platform, not on Vera, right? What you might try doing is downloading the unmodified serproxy: http://www.lspace.nildram.co.uk/freeware.html
That takes the port settings from a configuration file. The modified serproxy deployed on Vera just changes the ‘readcfg’ to read the configuration from the Luup engine using http gets to get the ports, settings, etc., and to auto-scan for ports. But the actual function of serial port forwarding is unmodified. So you could use the unmodified serproxy and just add the ports manually to the Luup engine and to the serproxy configuration file.
As far as the error you’re seeing below… It’s not necessarily an error. Everytime you save changes, the Luup engine restarts, and the Luup services on port 49451 are unavailable for 4 seconds or so. Same thing when the list of ports changes and serproxy restarts the Luup engine.
===—Running… is when serproxy starts. So in your logs, I see serproxy is trying to run ‘find_self’, which just does a wget to retrieve the results of the lu_finddevice request. The download fails, presumably because the Luup engine isn’t running. So serproxy exits, and the start_serproxy script just restarts it again. So it’s normal for it to fail a few times when Vera first starts and the Luup engine isn’t up yet, and also after saving. But, after a few retries, the Luup engine should be back up and the lu_finddevice request should not fail, and so serproxy can go ahead and read the configuration using a few more wget’s.
You may see several more ‘download failed’ when serproxy uses the lu_variableget to request the port settings. This is normal. It just means you didn’t specify any settings yet on the ‘serial port configuration’ page, so those variables aren’t set. Serproxy will then use some hardcoded defaults (9600,N,8,1)
The key is that you should see:
===Setting up serproxy for…
Serproxy - ©1999 Stefano Busti - Waiting for clients
at the end of the log. Those Setting up serproxy for… lines will show you what port settings our modified ‘readcfg’ passed on to the serproxy app.