blazer_soi: blazer driver, serial port over tcp/ip

[alezz]

This is a version of blazer that allows the use of a ethernet to serial device, also called YPort.
Such a device allows a serial port to be connected to an existing ethernet network, and uses tcp to access the serial port. An example of this device is provided by Ethersex Project (http://www.ethersex.de); this driver extension has been tested with it.

[clepple]

Thanks for submitting this - it seems useful. However, the blazer driver will eventually be replaced by nutdrv_qx. Rather than add this code to individual drivers, what if it went into the core driver code?

There was an old patch which got misplaced during our move to Git. It allows the "port=" option in ups.conf to take a hostname:port pair to specify a TCP connection. I haven't compared the details of the code, but would this work with your device?

https://github.com/networkupstools/nut/tree/netport-on-2.7.1

Either way, we would need to provide a bit more documentation for end users.

[alezz]

Hi Charles,
Thanks for reply.
I've took a look at the code you suggested me and tested it with my device.
That patch implements tcp connection in serial.c, this is a more
flexible approach, as it is applicable to all serial drivers. However
the drivers then make ioctl calls to setup the tty port, and these fail.
At least, this is what happens to me with blazer_ser. Maybe the patch
has not been finished?
In my patch tcp is implemented only for blazer, but it works and it was
simple for me to write it.
About documentation, the man pages for blazer are sufficient, except for
the few parameters (variables) documented with "blazer_soi -h".

If the community thinks that would be useful, and we find out the best
implementing solution, I might think about improving this feature somehow.

On 04/04/2014 14:39, Charles Lepple wrote:

Thanks for submitting this - it seems useful. However, the blazer
driver will eventually be replaced by nutdrv_qx. Rather than add this
code to individual drivers, what if it went into the core driver code?

There was an old patch which got misplaced during our move to Git. It
allows the "port=" option in ups.conf to take a hostname:port pair to
specify a TCP connection. I haven't compared the details of the code,
but would this work with your device?

https://github.com/networkupstools/nut/tree/netport-on-2.7.1

Either way, we would need to provide a bit more documentation for end
users.

—
Reply to this email directly or view it on GitHub
#116 (comment).

[zykh]

Would it make sense to simply bypass ioctls/terminal-related actions?
Quick attempt at it (just for blazer/nutdrv_qx, at the moment):
https://github.com/zykh/nut/tree/netport

[clepple]

@zykh sorry I haven't had more time to comment on this, but the new netport branch looks good. We may want to have a few upsdebugx() calls during the netport setup, in case someone has a typo in their dev node name, and isn't expecting the network calls.

Also, did you happen to see why belkinunv was not using the serial.c shared code?

[zykh]

Added a debug line and removed fatal* calls.

belkinunv - there are 2 sets of functions:

• one (used normally) relies on serial.c code,
• the other one (used when the driver is called with the 'wait' flag/option, used as a workaround for a specific shutdown problem) doesn't, probably to avoid fatal* calls (it predates the introduction of the non-fatal versions of ser_* functions) and spurious logging messages.

@alezz, can you test blazer_ser/nutdrv_qx from the following branch?
https://github.com/zykh/nut/tree/netport

[alezz]

Hi @zykh . Sorry for my big delay in answering. Unfortunately due to lots of work to do I was not able to test it out and I'm not sure when I will have some minute to do that.

[jimklimov]

Hi all, given that this adds a standalone driver, there seems to at least be no code-wise conflict with this PR despite its age. But the points raised in review earlier about possibly sharing and unifying code with other NUT parts, and parsing "port" commonly as an "IP:PortNum" value in particular, make sense.

So I need some team consensus: is this good to merge "as is" to add a new driver and refine later when someone is annoyed (e.g. also regarding new nutdrv_* naming standard) or should issues raised above be resolved before or shortly after a merge? CC @clepple @aquette @zykh @alezz

Also seems I can not update the source branch of this PR, to merge the current NUT master into it and have Travis CI take a bite.

[clepple]

@jimklimov As you mentioned, the original PR adds a standalone driver, but it is resurrecting the blazer_* code that we were trying not to maintain in parallel with @zykh's nutdrv_qx codebase, and it does not have a man page to describe the differences between it and the original blazer_ser driver.

I think if someone is truly interested in supporting serial-to-TCP adapters, they need to be willing to start from more recent code (such as @zykh's netport branch), and then test against actual hardware. I have neither the time nor the hardware to do it myself, so maybe take my comments with a grain of salt.