Hi,
our monitoring network has several hundred gauging stations, a mixture of CR510 and CR1000. We have several modem gateways, each is a cisco router with several digital (mica) modems in it, connected to ISDN Primary Rate Interfaces. We use another product for managing communications, however the question has been asked if LoggerNetAdmin running on a server (i.e. as a service) would be able to utilise our existing infrastructure to establish an alternative telemetry management.
The usual process is to telnet to the telnet gateway, the gateway prompts for a modem gateway and port number (10 modem ports available on each), authentication in the form of username and password must be provided, then the dial sequence can be submitted (eg ATD0123456). At that point the usual modem commands are in play.
So, I've been all over the manual and there's no real indication if we can achieve this with LoggerNetAdmin, I'd be grateful for an answer.
Thanks in advance for any information.
RdeV.
You should be able to do this using the Generic modem option in Loggernet - see the help. You would need to append the generic modem to an IPPort root device and put the dialling commands in the generic modem setup.
More advanced modem back support is planned for the future but we do not have a release date for this yet - it is likely to be towards the end of this year at the earliest.
* Last updated by: aps on 3/22/2011 @ 7:48 AM *
Hello again,
firstly many thanks for that aps, that's what I tried however we didn't progress past that point and didn't get to actually dial anything successfully before the project was dropped.
However, we are returning to this issue once more, this time because a recent modem gateway capital replacement (now Cisco 3925) is not cooperating with our usual application (SODA4) for voice modems (we have about 50 of those) and we need to run up a standby application for them.
Is there any chance the modem gateway support has improved with subsequent releases of Loggernet? I can't see much in the LN4.1 doco, is LNAdmin4.1 any different?
Thanks very much,
RdeV.
There is no difference in the 4.1 Admin version. As mentioned before we will be supporting modem pooling and terminal server connected modems in Loggernet 4.2 including those which support the RFC2217 protocol.
It is quite likely that your CISCO device will support this but to my knowledge we have not tested it.
Release is not planned until later in the year though.
The protocol described by RFC 2217 is a telnet protocol extension that allows a client application to take control of a single serial port by doing things like setting port parameters (baud rate and etc.) and receive UART events from the server. Its scope does not include things like multiplexing serial ports like RdeV describes above. It will work with terminal servers that offer a separate TCP port for each serial port that is offered.
It sounds to me like the generic modem route should perform what is needed and I am curious what was tried and failed before that route was abandoned.
Correct, but RDev says they now have a new CISCO router. If the modems are the same then the generic modem option may well work.
However, I did a quick search on Cisco's site seemed to show that some of the modem modules available for the new device use RFC 2217 protocols so I thought I would mention that too.
Thanks very much for your replies.
The transaction LN needs to control:
1. Telnet to telnet gateway
2. At the telnet gateway prompt enter the Cisco modem gateway hostname and port*
3. Enter user and password authentication
4. After establishing the connection to the modem, dial the remote station, connect, interrogate/ download etc
5. Hang up
* The ports in the gateway are pre- allocated to modems, ten are available in the pool.
SODA does this but no amount of tweaking has helped for remote stations equipped with COM220/320 voice modems, however NextG (Modmax IIRC)is fine through the new Cisco 3925. However, we do know that LN4.1 can connect individually to all of the remote modem types via a local modem and a direct line, however that is not an ideal solution for an entire state network, nor compliant with telecoms policy.
I presume scripting in the Generic Modem type can pass the routing and authentication, I'd be happy at this stage if I could dial just one station though the 3925 to prove the concept, then we can look at establishing LNAdmin as a service using multiple lines and all of the voice stations (Perl I'd guess, Net::Telnet).
Thanks very much for your replies.
The transaction LN needs to control:
1. Telnet to telnet gateway
2. At the telnet gateway prompt enter the Cisco modem gateway hostname and port*
3. Enter user and password authentication
4. After establishing the connection to the modem, dial the remote station, connect, interrogate/ download etc
5. Hang up
* The ports in the gateway are pre- allocated to modems, ten are available in the pool.
SODA does this but no amount of tweaking has helped for remote stations equipped with COM220/320 voice modems, however NextG (Modmax IIRC)is fine through the new Cisco 3925. However, we do know that LN4.1 can connect individually to all of the remote modem types via a local modem and a direct line, however that is not an ideal solution for an entire state network, nor compliant with telecoms policy.
I presume scripting in the Generic Modem type can pass the routing and authentication, I'd be happy at this stage if I could dial just one station though the 3925 to prove the concept, then we can look at establishing LNAdmin as a service using multiple lines and all of the voice stations (Perl I'd guess, Net::Telnet).
It seems the Generic modem option is what you need and from what you have said it should work if you can work out the commands to send and the necessary delays.
As I said before to do this add an IPPort as the root device with the IP address of the server and 23 (Telnet) as the port. Then add a generic modem and under the Modem tab enter the dial and end script commands that you will need to work out. The commands should include the sequence for authentication and you could try adding the ATD... command as well to dial the modem, waiting for the expected connect response. You may not need any end script unless your modem needs it, although you might consider adding the "+++" (with a second delay either side) and ATH<CR> just to make sure the modem hangs up. Instead of putting the dial commands here you may be able to just include the authentication commands and add a Phone modem to the generic modem and use the dial functions built into Loggernet, selecting a suitable modem type. Add the logger (or Pakbus port plus logger) to the modem.
To help write the dial script search for "generic modem commands" in the Loggernet help.