Scannex ip.buffer User Manual

Download

Page 1

ip.buffer Manual

25th March 2013

Firmware Version 2.80

Page 2

ip.buffer Manual

Date Author Release

2007-06-21 MP For version 1.00

...

2008-05-02 MP For version 2.00

2008-06-16 MP For version 2.10

2008-08-29 MP For version 2.20

2008-09-03 MP For version 2.21

2008-12-12 MP For version 2.30

2009-04-15 MP For version 2.40

2009-09-22 MP For version 2.41

2010-02-02 MP For version 2.50

2010-07-28 MP For version 2.60

2011-04-14 MP For version 2.70

Added 48V schematic details

2012-02-08 MP For version 2.75

2012-07-10 MP For version 2.76

2013-03-25 MP For version 2.80

Reformatting Removed HTTP info

Scannex Electronics Ltd, UK t: +44(0)1273 715460 f: +44(0)1273 715469

http://www.scannex.co.uk info@scannex.co.uk

Scannex LLC, USA t: 1-866-4BUFFER

(1-866-428-3337)

http://www.scannex.com info@scannex.com

Page 3

Table of Contents

1.Introduction...............................................1

1.1.The Range............................................1

1.2.Features..............................................1

1.3.Block Diagrams......................................3

1.3.1.System Overview..............................3

1.3.2.Source...........................................4

1.3.3.Destination.....................................5

1.4.Firmware.............................................6

1.4.1.Crypto-Free....................................6

1.4.2.SSL...............................................6

2.GPRS (Cellular) Modem..................................7

2.1.GPRS Safety Precautions...........................7

2.1.1.GPRS Radiation Exposure Statements......7

2.2.Installing a SIM card................................8

2.3.Installing the antenna..............................8

3.Fitting Batteries..........................................9

3.1.1.Battery Precautions...........................9

3.1.2.Installing in an ip.1..........................10

3.1.3.Installing in an ip.4..........................11

4.Physical Mounting.......................................12

4.1.ip.1 – plastic box..................................12

4.1.1.DIN Rail Mounting............................12

4.1.2.Wall mounting................................12

4.2.ip.4 – metal case..................................12

5.Installation...............................................13

5.1.Connections........................................13

5.2.Getting Started....................................14

5.3.Forgotten passwords & factory defaults.......15

6.Front Panel...............................................16

7.Status Web page.........................................18

7.1.Channel: Source...................................18

7.2.Channel: Storage..................................18

7.3.Channel: Destination..............................19

7.4.Modem..............................................19

7.5.System..............................................19

8.SETUP.....................................................20

8.1.Web Interface......................................20

8.2.Global: Settings....................................21

8.2.1.Network.......................................21

8.2.2.Time...........................................26

8.2.3.Power..........................................27

8.2.4.Modem.........................................28

8.2.5.Modem Out...................................30

8.2.6.SMTP Email Servers..........................34

8.2.7.Alerts..........................................36

8.2.8.Alert List......................................39

8.2.9.RADIUS.........................................40

8.2.10.Certificates for SSL/TLS and SSH........44

8.2.11.FTP...........................................46

8.2.12.Web...........................................48

8.2.13.Cloud Server................................50

8.3.Date and Time Synchronize......................52

9.Channels..................................................53

10.Sources..................................................56

10.1.COM Serial........................................56

10.1.1.Settings......................................56

10.1.2.Connection to a PC serial port...........59

10.1.3.When using a Y-lead.......................59

10.2.TCP.................................................60

10.2.1.Match, Send & Heartbeat special

characters............................................61

10.3.UDP.................................................62

10.3.1.Syslog Collection...........................62

10.3.2.SNMP Trap Collection......................62

10.3.3.RADIUS Accounting Collection............64

10.4.FTP Server.........................................65

10.4.1.FTP Server Notes...........................66

10.5.None...............................................66

10.6.Common Modules................................67

10.6.1.Protocol......................................67

10.6.2.Protocol: ASCII Lines.......................69

10.6.3.Protocol: Alcatel TCP/IP [port 2533]....70

10.6.4.Protocol: Avaya RSP TCP/IP...............71

10.6.5.Protocol: Binary (full 8-bit)...............71

10.6.6.Protocol: Generic Records................72

10.6.7.Protocol: Inter-Tel/Mitel Axxess & 5000

TCP/IP [port 4000]..................................75

10.6.8.Protocol: iSDX binary......................76

10.6.9.Protocol: NEC (STX/ETX) Serial.........76

10.6.10.Protocol: NEC NEAX TCP/IP.............78

10.6.11.Protocol: Nortel BCM Live TCP/IP......79

10.6.12.Protocol: Nortel Meridian & Norstar.. .80

10.6.13.Protocol: Panasonic KX-TD TCP/IP [port

2300]..................................................82

10.6.14.Protocol: Philips FDCR TCP/IP [port

2599]..................................................82

10.6.15.Time Stamping............................83

10.6.16.Extra tokens for delivery filenames....85

10.6.17.Pass-through...............................86

10.6.18.Notification................................89

11.Destinations............................................90

11.1.Email push (SMTP client).......................90

11.2.HTTP POST to Cloud Server....................91

11.3.FTP Server.........................................92

11.3.1.Supported FTP server commands........93

11.4.FTP Push (client).................................94

11.4.1.Overwrite and Append.....................96

11.4.2.Tmp File & Rename mode................96

11.5.TCP Server (passive).............................97

11.6.TCP Push (active/client)........................98

11.7.COM port serial.................................100

11.8.Legacy Emulation (TCP Server)...............102

11.9.None..............................................103

11.10.Destination Common Modules...............104

11.10.1.Data Markers.............................104

11.10.2.Data Security.............................104

11.10.3.Push Triggers.............................105

12.Storage.................................................107

13.Tools....................................................108

13.1.General...........................................108

13.1.1.Live Record View..........................108

13.1.2.Storage Counters..........................109

Page 4

13.1.3.Reboot Lua.................................109

13.1.4.Reboot ip.buffer (cold boot)............109

13.1.5.Battery off (shutdown)...................109

13.2.Modem...........................................110

13.2.1.Clear timers...............................110

13.2.2.Hangup & Reset / Hangup & Power cycle

.......................................................110

13.3.Source, Pass-through, and Destination......110

13.4.Network..........................................111

13.4.1.Ping a device..............................111

13.4.2.Listening Ports.............................111

13.4.3.Network Tables............................111

13.5.Log................................................111

13.5.1.View Log....................................111

13.5.2.Send Log to Cloud Server................111

13.6.System............................................112

13.6.1.Upgrade Firmware........................112

13.6.2.Check for Updates........................113

13.6.3.System Memory...........................113

13.6.4.Diagnostics Dump.........................113

14.Advanced Setup......................................114

14.1.Configuration (Advanced).....................114

14.1.1.Edit..........................................114

14.1.2.Ad hoc change.............................115

14.1.3.Download...................................115

14.1.4.Upload......................................115

14.2.Script.............................................116

14.2.1.Edit..........................................116

14.2.2.Download...................................116

14.2.3.Upload......................................116

14.3.Server Certificate..............................117

14.3.1.Generate...................................117

14.3.2.Upload......................................118

14.3.3.Download server certificate............118

14.3.4.Download SSH publickey.................118

15.Advanced Topics......................................119

15.1.Replication of settings.........................119

15.2.Lua extensions..................................119

15.2.1.Alert System...............................119

15.2.2.Delivery Trigger System..................120

15.2.3.Comments within Lua code.............120

15.2.4.Sending data to the channel source. . .120

15.3.Example scripts.................................121

15.3.1.Simple prefix..............................121

15.3.2.Duplicating data..........................122

15.3.3.Discarding data............................122

15.3.4.Masking telephone digits................123

15.3.5.Upgrading Firmware – the Last Resort.124

16.SNMP Traps............................................125

16.1.Trap List..........................................125

16.2.Variable Bindings...............................126

17.SNMP Agent OID List..................................127

18.Cloud Server HTTP Implementation...............128

19.Licenses................................................129

19.1.Lua License......................................129

19.2.zlib License......................................129

19.3.X509 certificate generation license.........130

19.4.SNMP Trap Decoding............................131

20.Specifications.........................................132

21.Optional 48V Power Supply.........................133

21.1.Two-pin connector..............................133

21.2.Schematic........................................133

22.PSTN Modem Country Codes and Approvals......134

23.Safety Warnings.......................................136

23.1.Optional AA Battery Caution..................136

23.2.Real Time Clock Battery Caution.............136

23.3.Ethernet Ports Caution........................136

23.4.Power Supply Caution..........................137

23.4.1.Scannex Approved PSUs..................137

23.5.General Warnings...............................137

23.6.Modem Caution (if fitted).....................137

23.7.A note about Power Connection, Surge

Protectors, and lightning............................137

23.8.South Africa.....................................137

24. Approvals.............................................138

24.1.EMC...............................................138

24.2.Safety.............................................138

24.3.Environmental...................................138

24.4.PSTN Modem.....................................138

24.5.GPRS Modem....................................138

24.6.Export Control..................................138

24.7.European Union (EU) Statement.............139

24.7.1.EMC, Safety, and R&TTE Directive

Compliance.........................................139

24.7.2.Network Compatibility Declaration....139

24.8.Deutsch..........................................139

24.9.USA...............................................140

24.9.1.FCC Registration Information...........140

24.9.2.Repair Information........................140

24.9.3.FCC Rules Part 15 - Computing Devices

.......................................................141

24.9.4.GPRS Modem...............................141

24.10.Canada..........................................142

24.10.1.Industry Canada Information..........142

24.10.2.GPRS Modem.............................142

24.10.3.Industry Canada Regulatory Compliance

Information for Class B Equipment.............143

25.European Union Waste Electrical and Electronic

Equipment (WEEE) Statement..........................144

25.1.UK Users.........................................144

25.2.European Users (outside the UK).............144

25.3.Manufacturer/Responsible Party.............144

Page 5

Scannex ip.buffer User Manual

1 . I n t r o d u c t i o n

1.1. The Range

The ip.buffer is designed to collect and store information from such devices as telephone PBXs – for CDR/SMDR collection, for alarm and traffic management, and to allow passthrough access for moves and changes.

The product range includes three main devices:

• ip-4 = 128Mbyte memory with 4 serial ports

• ip-1 = 32Mbyte memory with 1 serial port

The ip-4 device includes internal temperature monitoring, built in global or GPRS modem, plus the SEbus expansion connector. They also have an option for 48VDC power (see Section

21). They are both built inside a metal box that can be rack mounted in a 1U high bay. The ip-1 device has an optional global PSTN or GPRS modem and is housed in a plastic

casing with facilities for wall mounting, tie-wrapping, and DIN rail mounting. All three devices allow battery backup using 3 standard AA NiMH batteries. With fully

charged cells the unit can continue to operate for approximately 2 hours.

1.2. Features

All devices have proprietary Scannex features and advanced facilities:

• Collection

o Auto pin detection on the serial ports

o Auto baud rate and protocol detection on the serial ports

o Collection from serial and TCP/IP enabled devices

o Collection from devices that perform FTP push

o Collection of UDP data including syslog information, SNMP Traps (with trap

decoding and SNMP get queries on connected devices), and RADIUS Accounting

o Support for ASCII, Binary and iSDX data sources

o Automatic partitioning of NAND flash memory with optional settings for

limiting memory sizes of each channel

• Various delivery options including:

o HTTP/HTTPS post to web Cloud Server

o FTP/SFTP push

o FTP server

The detection is performed using voltage sensing, so the ip.buffer can detect whether the data

source is DCE or DTE wired even with no data

Each ip.buffer can collect data from as many TCP/IP devices as there are serial ports. Each

channel can be assigned to either the serial port or a TCP/IP or UDP/IP collection.

Page 1

Page 6

Scannex ip.buffer User Manual

o Email/SMTP push

o TCP/IP push

o TCP/IP server

o COM port serial

• LAN and management features

o Fully web-based setup and status information

o “Reflective Routing” on the LAN to allow easy access from different subnets

o Email, HTTP POST, and SNMP alert mechanisms to enable a pro-active

system

o Extremely powerful Lua4 scripting engine

o SNTP (Simple Network Time Protocol) time synchronisation with daylight

saving option

o Settings can be quickly replicated across multiple ip.buffers for bulk

installations

o All changes to the settings occur immediately – no need for reboot

o Fully fail-safe firmware upgrades. The power can fail at any point in the

upgrade process and the ip.buffer will recover with the old version (or the new version if successfully uploaded).

o Simple SNMP v1/v2c agent to provide inventory information to SNMP clients

o Centralised updates via standard web-server (See section Error: Reference

source not found)

o Supports Proxy servers running HTTP, SOCKS 5 and SOCKS 4a protocols.

• Security features

o Option to authenticate to one or two RADIUS servers

o https (SSL) access for web pages (optional) (See section 8.2.12)

o SSL/TLS link encryption for HTTP post, FTP, email, and TCP connections

(optional) (See section 11)

o SFTP/SSH encryption for SFTP push (See section 11.4)

o Additional Scannex 40-bit encryption for further security of the transported

data

In practise it means you do not have to have a gateway address, or the correct gateway,

programmed in the ip.buffer when connecting into it for web services and the like.

See www.lua.org However, several extensions have been applied to the Lua base.

Even Lua script changes can occur while the ip.buffer is still running

Page 2

Page 7

Scannex ip.buffer User Manual

1.3. Block Diagrams

1.3.1. System Overview

Conceptual view of the ip.buffer (ip.4-128m):

The ip.buffer is “channel based” with each channel allowing separate collection and delivery methods.

Page 3

Alerts

SNMP Agent

SNMP Trap

Sender

Modem

Manager

Web Server

SNTP Client (Time Sync)

SMTP Client

(Email)

HTTP Client

(Web post)

RADIUS

Client

Lua Core – configuration, scripts, notifications

System

Health

Monitoring

Log Files

Secret Store

Channel #4

Source StorageLua Script Destination

Pass-

through

Protocol

Channel #2

Source StorageLua Script Destination

Pass-

through

Protocol

Channel #3

Source StorageLua Script Destination

Pass-

through

Protocol

Channel #1

Source StorageLua Script Destination

Pass-

through

Protocol

Page 8

Scannex ip.buffer User Manual

1.3.2. Source

The four source collection modules run independently. Each source can collect from a different source device, and the ip.buffer allows any mix of serial, TCP, UDP or FTP across the four channels.

Although the ip.buffer is “channel based” with custom Lua scripting it is possible to send data across to other channels. For example, one physical data source (e.g. COM port) may contain a mixture of CDR, and Alarms information – custom Lua scripting can split this information into two channel storage areas.

Page 4

Source x 4

Serial

TCP/IP

Client

Server

FTP Server

UDP/IP

RAW

SNMP Trap

Radius

Accounting

Syslog

Page 9

Scannex ip.buffer User Manual

1.3.3. Destination

The four destination delivery modules also run independently. Each destination can deliver using a different method. Or, they can use the same method (e.g. FTP Push) but deliver to a different central server. Each channel can be configured to use any combination of LAN/WAN/DSL or Modem interfaces.

Page 5

Page 10

Scannex ip.buffer User Manual

1.4. Firmware

The firmware is available in two variants:

1.4.1. Crypto-Free

The Crypto-Free firmware variant has no SSL/TLS options or code. It is provided to comply with certain export/import restrictions around the world. Even if the internal configuration requests SSL/TLS it will not use SSL/TLS – the cipher code is not built into this firmware version.

The firmware is labelled IPBCFx.xx.xx where x.xx.xx is the version number. The version number at the footer of each web page will have the marking “IPBCF”.

The CF / Crypto-free version will not show any of the SSL/TLS options on the web setup pages.

1.4.2. SSL

The SSL firmware variant has full SSL/TLS6 code and web options. The firmware is labelled IPBSSLx.xx.xx where x.xx.xx is the version number.

It is your responsibility to check with your country’s current laws before downloading and using the SSL firmware variant in the ip.buffer! Some countries have severe penalties – you have been warned! Additionally, if you are re-exporting an ip.buffer you must comply with all local export regulations. Scannex can assume no liability or responsibility for the use or misuse of the SSL variant.

In addition, the SSL version includes facilities for generating RSA certificates, as well as tools to upload device and vendor certificates and keys.

The version number at the footer of each web page will have the marking “IPBSSL”.

SSL version 3 (with support for SSL version 2 “hello”) and TLS version 1.0

Page 6

Page 11

Scannex ip.buffer User Manual

2 . G P R S ( C e l l u l a r ) M o d e m

Some models of the ip.buffer come fitted with a GPRS modem allowing for delivery of data and remote access over the cellular/mobile network.

They are shipped without a SIM card and without an antenna and so require an appropriate data-enabled SIM card for the country of installation1 and a suitable GPRS antenna prior to use.

2.1. GPRS Safety Precautions

If the ip.buffer is fitted with a GPRS Radio Module (RF) transmitter the following operating conditions and restrictions must be observed at all times.

• Be sure the use of this product is allowed in the country and in the environment

required. The use of this product may be dangerous and has to be avoided in the following areas:

◦ Where it can interfere with other electronic devices in environments such as

hospitals, airports, aircrafts, etc.

◦ Where there is risk of explosion such as gasoline stations, oil refineries, etc

• It is responsibility of the user to enforce the country regulation and the specific

environment regulation

2.1.1. GPRS Radiation Exposure Statements

Failure to meet these requirements may mean the maximum permissible exposure (MPE) limit is exceeded!

• This transmitter must not be collocated or operated in conjunction with any other

antenna or transmitter.

• The device is designed for and intended to be used in fixed and mobile

applications.

◦ "Fixed" means that the device is physically secured at one location and is not

able to be easily moved to another location. The antenna for a fixed device is mounted on an outdoor permanent structure with a minimum separation distance of 2 meters (79 inches)

◦ "Mobile" means that the device is designed to be used in other than fixed

locations and generally in such a way that a separation distance of at least 20 cm is maintained between the transmitter's antenna and the body of the user or nearby persons.

• The antenna gain must not exceed 2 dBi

in mobile applications and 7dBi in Fixed

SIM 1.8/3V Mini-Subscriber Identity Module (SIM)

Antenna gain in dB relative to an isotropic radiator

Page 7

Page 12

Scannex ip.buffer User Manual

2.2. Installing a SIM card

The GPRS module uses a SIM 1.8/3V Mini-Subscriber Identity Module (SIM).

To insert the SIM card proceed as follows:

• Make sure that the ip.buffer is disconnected from the supply voltage and any

batteries are removed.

• The ip.buffer must be opened to insert the SIM card. ◦ For an ip1 device the housing is fastened by four screws in the base ◦ For an ip2/ip4 device the housing is fastened by 2 screws in the case sides

• The SIM card holder is visible on the GPRS modem motherboard.

• Slide the SIM card under the flap of the SIM card holder, with the gold-coloured

microchip facing down.

◦ The SIM card holder has a groove to accept the SIM card. ◦ The notched corner of the SIM matches the notch in the card holder. ◦ Slide the SIM card into the holder as far as possible.

2.3. Installing the antenna

• Disconnect the ip.buffer from the power supply

• Connect an appropriate fixed or portable (e.g. 'stub') aerial of suitable gain to the

antenna connector SMA socket

◦ The SMA socket is situated on the rear of the ip.buffer next to the power

connector.

◦ The antenna can be a broadband type covering the 800-1900MHz range of the

module, or one that is specific for the country of operation.

Page 8

Page 13

Scannex ip.buffer User Manual

3 . F i t t in g B a t t e r i e s

The ip.buffer can run from 3 x standard AA-size Ni-MH batteries when the mains power fails (supplied without batteries). With fully charged batteries the ip.buffer should run for at least 2 hours (although this run time can be limited using the configuration options).

3.1.1. Battery Precautions

• Use only AA sized rechargeable Ni-MH batteries with a

capacity of at least 2000mAH.

• Batteries should all be of the same capacity, manufacturer, and type.

• RISK OF EXPLOSION IF BATTERIES OF INCORRECT TYPE ARE FITTED.

Never use non-rechargeable batteries.

• Do not burn or puncture the batteries. The cells may explode.

• Check with local requirements for possible special disposal instructions.

• When replacing batteries all batteries should be replaced at the same time.

• Remove the batteries from the product if the product will not be used for some

time (several months or more).

• Check with local requirements for shipping restrictions before shipping with batteries fitted. Some authorities strongly recommend shipping without batteries fitted!

Batteries not supplied.

Page 9

Page 14

Scannex ip.buffer User Manual

3.1.2. Installing in an ip.1

The battery compartment for the ip.1, which has a plastic case, is accessible beneath the cover in the lid. Undo the retaining screw and insert the batteries over the ribbon, observing polarity. The ribbon will help in the battery removal.

Remove the power supply and all other connectors from the unit before opening the case!

Page 10

Page 15

Scannex ip.buffer User Manual

3.1.3. Installing in an ip.4

The ip.4 has a metal case. The case has to be opened by removing the screws on either side, and then sliding the top case section off. Inside, the battery compartment lid is fixed by one screw. Observe polarity when inserting the batteries. Take care not to damage or touch the rest of the circuit board.

Remove the power supply and all other connectors from the unit before opening the case!

Page 11

Page 16

Scannex ip.buffer User Manual

4 . P h ys i c a l M o u n t i n g

4.1. ip.1 – plastic box

4.1.1. DIN Rail Mounting

Fits “top-hat” DIN rail, as per DIN E0022, 35x15 or 35x7.5mm. To fit:

● Hang the ip.buffer onto the top lip of the DIN rail

● Push the bottom of the box down onto the rail until it clicks into place

To remove:

● Push box up and unhook from the top of the DIN rail lip.

4.1.2. Wall mounting

● Mount two flat-headed screws (not supplied) that are 90mm apart in a vertical line ○ The stem should be no more than 4.5mm diameter ○ The screw head should be between 6mm and 11mm

● Leave the heads proud of the wall ○ The head should be no more than 6mm from the wall

● Slot the box onto the screws.

4.2. ip.4 – metal case

19” rack mounting:

● Screw the two ears onto the sides of the casing, using the 6 screws provided.

● Mount in a 1U rack position.

Page 12

Page 17

Scannex ip.buffer User Manual

5 . I n s t a l l a t i o n

5.1. Connections

• Plug the plug-top Power Supply Unit (PSU) into an AC 100-240V mains outlet

situated near the unit.

• Connect the cord from the PSU into the DC power input of the ip.buffer.

o The green Status (S) LED should flash once a second, indicating the unit is

functioning correctly.

o The power cable can be retained:

 Slot the cable into the recessed cable-restraint on the underside of

the ip.1, or,

 Use a cable-tie on the ip.4

• Connect the ip.buffer to a network hub or switch. Make sure you connect the

“LAN” port, and not the “SEbus” connector! o The yellow Link (L) LED should light and flash in time with network traffic.

• If required, and fitted in the ip.buffer, connect the modem port to the

telephone with an appropriate adapter if needed.

Page 13

Page 18

Scannex ip.buffer User Manual

5.2. Getting Started

• On your PC, run the SEDiscover

application, and press the F5 key (or the

magnifying glass). This will locate all ip.buffers (and NetBuffers) on the LAN. o SEDiscover will only show ip.buffers that are physically connected to the

same network segment. It will not show ip.buffers that are separated by a router/gateway/firewall.

o If you have problems locating the ip.buffer:

 Disconnect the PC from the main network.  Connect a CAT5 cable directly between the PC and the ip.buffer.  Make sure the PC has a fixed IP address (e.g. 192.168.0.111)  Retry SEDiscover

• The default IP address of the ip.buffer will be 192.168.0.235

• You can highlight the entry in SEDiscover and press the world icon to go straight

to the web page of the ip.buffer

• You should see the ip.buffer’s main status page.

• The default username and password for the Setup & Tools pages are:

o Username = “admin”

o Password = “secret”

• You can change the ip.buffer's IP address, subnet & gateway details:

o Through the web-page at any time (assuming you have the correct username

and password!)

o With SEDiscover if the ip.buffer has been powered up for less than 5

minutes3.

You can download this from our website at www.scannex.com. SEDiscover uses a more acceptable

protocol when compared with the older NBDiscover application.

Even if the ip.buffer is on a different subnet, the SEDiscover tool (v2.2+) inserts a temporary static route into your PC’s routing table. The added routes are removed when you close SEDiscover. In addition, if you have multiple ip.buffers with the same IP address, the SEDiscover tool inserts a static ARP entry to allow direct access. Note that these facilities are not readily available when not using the SEDiscover tool.

If the ip.buffer has been powered up for more than 5 minutes, you can hold the front recessed button for 2 seconds only to enable updating through SEDiscover.

Page 14

Page 19

Scannex ip.buffer User Manual

5.3. Forgotten passwords & factory defaults

If the password is forgotten, there is one sure way to gain access to the ip.buffer:

Once you have performed this action there is no way to recover any of the data or settings. Everything will be completely and utterly erased! Use this as a last resort only.

• With the ip.buffer running its normal firmware...

• Press and hold the button on the front of the ip.buffer for more than 10 seconds

o The red LED will blink every second until you have held it down for 10

seconds

o Then the red LED will blink rapidly

• Now release the button

• The ip.buffer will erase all parameters and data and reboot.

• When the reboot process completes the ip.buffer will be reset to factory

settings.

There is a programmable option which allows for a 5-minute access after power-up – without requiring a username and password. If this option is not enabled (it is off by default) then you have to resort to the wipe-everything method above.

Page 15

Page 20

Scannex ip.buffer User Manual

6 . F r o n t P a n e l

The LEDs on the front panel show the following information:

●

Channel 1..4

Off Source not connected

On Source Connected

Flashing Data Arriving

●

L: LAN

Off No Ethernet Connection

On Ethernet Connected

Flashing Ethernet Activity

●

M: Modem

Off Modem Off-Line

Slow Flash Answering or Dialling

Fast Flash Negotiating PPP

On Modem On-Line

●

S: Status

Blinks every second to indicate the ip.buffer is functioning normally

●

E: Error Blinks when booting. Normally off

Firmware >= 2.76: The “S” green LED will blink at least every second to show the ip.buffer is running. When any data arrives, the “S” green LED will blink more rapidly2.

Firmware <= 2.75: All LEDs (except the “L” LAN) will flash on, then off every 8 seconds to show that the operating system kernel is functioning. The LAN LED is controlled directly by the Ethernet circuitry.

When the ip.buffer boots up, the Modem LED will flash if there is a modem present. If no modem is installed, the Modem LED will not light (except for the regular 8 second flash)

This 'quieter' LED display was introduced because there was some confusion over the 8-second flash and end users thought the red “E” LED was indicating something!

Page 16

Page 21

Scannex ip.buffer User Manual

7 . S t a t u s W eb p ag e

The status web page is accessible by anyone on the LAN. It provides a visual guide to the status of the ip.buffer, as well as more detailed information. Use the mouse to hover over one of the coloured cells to show detailed information – that information will appear on the right hand side of the page.

When first loaded, the status web page will automatically refresh every 5 seconds. If you need to freeze the automatic update, click on the “stop” radio button at the bottom of the page.

7.1. Channel: Source

Green Connected

Amber Connected, but quiet

Red Not connected

White Source task not running1.

• A double ended arrow ⇔ after the source name (e.g. “COM1 ⇔”) indicates that

the pass-through socket is currently connected and active. Hovering over the source will show which IP address is connected2.

• An asterisk * after the source name (e.g. “COM1 *”) indicates that there is Lua

script processing applied to this channel.

• An infinity sign before the source name (e.g. “∞COM1”) indicates that the serial

diagnostics loopback mode is enabled.

7.2. Channel: Storage

• Shows how much data is stored for the channel

• Shows when the last write occurred

• Shows how much data has been lost (if the memory has been exceeded)

Some of the full NAND Flash storage area is reserved for firmware (4Mb), configuration settings, encryption keys, certificates, bad flash blocks, etc. Usable storage space will be approximately 5Mb less than the total. The web status screen shows the true capacity available for data storage.

This can happen if the power supply is not providing a voltage within the specifications for running the ip.buffer. If the ip.buffer boots with low volts it will prevent collection and delivery until the supply reaches a suitable supply voltage. An email alert and SNMP trap are sent out in this condition. Additionally, the System Status (section 7.5) will be red and show “Power: Low volts!!”

Your browser needs to have a suitable Unicode font installed to show the double arrow. If no suitable font exists you will probably see a small square box: □

Page 17

Page 22

Scannex ip.buffer User Manual

7.3. Channel: Destination

White Not connected

Green Currently connected

Red The last delivery had a problem

• For the “push” methods of delivery you can also request an immediate delivery

by hovering over the destination cell which will show a “[ Push Now! ]” button in the detail panel.

7.4. Modem

White Idle

Amber Answering, Dialling, Negotiating PPP

Green Online

• When online, shows the Local and Remote IP addresses for the PPP link.

• When the modem was last used, and what PPP state was reached (to help

diagnose PPP configuration errors)

• The tasks that are requesting modem usage

• The hold off timer for the modem

7.5. System

• System

Green System fine

Red System error

o Total percentage usage of memory o The current time

• Alerts

Green No alerts

Amber Alerts Pending

Red Error sending the alert(s)

o Alerts currently active are shown when you hover over the alerts cell

e.g. low volts on power input; overfull memory

Page 18

Page 23

Scannex ip.buffer User Manual

8 . S E T U P

Firmware version 1.60 and above use new web technologies (AJAX in particular – Asynchronous Javascript And XML) to provide a more logical setup interface. Before describing the settings that are available it is worth outlining the general design of the web interface:

8.1. Web Interface

The setup pages are built in a modular fashion. Some pages will automatically load some of the modules when you open a page. For other pages the modules will only load when you choose to examine the settings within the module.

There are two ways to view and hide a module:

1. Click on the “top / hide” links at the right of the module block

2. Click on the blue bar (with the white text) on the left of the module. e.g. “ Network ”

Some pages, like the channel settings page, will dynamically fetch the appropriate module as you change the source and destination combo-box. Once a module has been fetched, it remains in the browser and does not need fetching again.

You may notice the text “Loading…” appear when you open a module for the first time. When using the LAN this message will flash up briefly. However, when connected via a modem this message is visible longer – as it takes longer to fetch the module over the relatively slow PPP connection.

All text fields allow special characters to be entered with a backslash “\” character. For example “\t” is a [TAB] character, “\r” is [CR], “\n” is [LF]. Additionally, “\xnn” will enter a two digit hex character – e.g. “\xc9”. For this reason, if you want to enter a genuine backslash character, enter “\\” - e.g. “let\\me\\in” is the character sequence “let\me\in”

Default settings in the manual are shown in italic green. e.g. [60] denotes a default value of 60.

Page 19

Page 24

Scannex ip.buffer User Manual

8.2. Global: Settings

http://192.168.0.235/setup/settings.shtm

The global settings are divided into several main modules.

Device Name

The device name is used for:

• Display in the status page

• Identification when using SEDiscover

• As the “from” address when sending emailed data and email alerts

• By the Cloud Server for data, alerts, and updates

8.2.1. Network

LAN/Ethernet

Assignment

“Fixed IP” will apply the static assignments below. “DHCP” will obtain network assignments from the LAN2.

For static multi-homed addresses, click the “multihoming ” link.

[Fixed IP]

Fixed IP Dotted IP address. [192.168.0.235]

Subnet Dotted Subnet. [255.255.255.0]

Gateway Dotted Gateway address. [192.168.0.1]

The email client will strip any illegal characters when using the name. Only “A”-“Z”, “a”-“z”, “0”-“9”, “_”, “-” and “~” are allowed. These are the characters supported by the Scannex SECollector utility.

The DCHP Option 61 Client ID includes the Ethernet MAC address and a suffix sequence of hex characters (which uniquely identify the individual DHCP request on the ipbuffer). When assigning a permanent allocation on the DHCP server (e.g. Microsoft DHCP Server), use the full client ID string and not just the Ethernet MAC address.

Page 20

Page 25

Scannex ip.buffer User Manual

Multihome IP (global)

You can assign up to two other IP addresses for the ip.buffer. This allows connection with a device that is physically on the same Ethernet network, but is not on the same IP subnet.

The Multihome IP setting module is also available from within the TCP Source module. Effectively, a copy of the settings can be seen and edited there. Please note that the settings are global and apply to all channels.

2nd IP Dotted IP address. [blank]

2nd Subnet Dotted Subnet. [255.255.255.0]

3rd IP Dotted IP address. [blank]

3rd Subnet Dotted Subnet. [255.255.255.0]

For example, if the PBX has a fixed IP address of 192.0.2.3:

• 2

IP = 192.0.2.4

• 2

Subnet = 255.255.255.0

• The PBX should be plugged into the same hub/switch as the ip.buffer

• The ip.buffer can now connect directly to the PBX (or the PBX can access the

ip.buffer on its extra address of 192.0.2.4)

Only the primary address is visible to SEDiscover and only the primary address can use DHCP. The 2nd and 3rd IP addresses are meant for accessing devices that cannot be brought onto the LAN (e.g. they have a fixed IP address)

Page 21

Page 26

Scannex ip.buffer User Manual

Name Servers

DNS 1

Dotted IP addresses for Domain Name Servers3. [192.168.0.1] The name servers can be on the LAN, or accessible via the

Gateway. Typically, the gateway IP address can be used as this will proxy the DNS requests.

DNS 2 Secondary DNS server. [255.255.255.255]

Proxy Server

The ip.buffer can talk to the outside world through a proxy server. The proxy servers can be used when delivering to HTTP POST, FTP Push, and Email Push4.

Type of proxy

“None (no proxy)” - communicate directly. “HTTP/1.1 using CONNECT” - communicate using the HTTP

proxy protocol5. “SOCKS 5” - communicate using SOCKS version 5. “SOCKS 4a” - communicate using SOCKS version 4a.

[None (no proxy)]

Server

The name, or IP address, of the proxy server. (When using HTTP

Proxy protocol: not a URL, so no 'http:', just an plain

address or name) [blank]

TCP Port

The TCP port that the proxy server is listening on. The normal

ports are 8080 when using HTTP Proxy, and port 1080

when using SOCKS 5 or SOCKS 4a. [blank]

Username The username, if needed, for the proxy server. [blank]

Password The password, if needed, for the proxy server. [blank]

No Proxy For

A list of explicit, or wildcard6, addresses or names to skip proxy

for. Typically you enter the names or addresses of local

machines in this list to prevent them needlessly going via

the proxy. Separate the list with commas, semicolons, or

spaces. e.g. “192.168.*, *.scannex.com, *.scannex.co.uk” [blank]

If in doubt about the proxy settings then the IT department usually will know!

DNS name-to-IP entries are cached for a maximum of 5 minutes. The DNS server can specify a

shorter time in the time-to-live field of the DNS response.

TCP Push is not supported because you cannot reliably know whether the proxy has lost connection

with the remote server – stale connections would be a problem.

Do not confuse this with the delivery/destination type. The HTTP Proxy protocol can be used for delivering by FTP push and by email (because the HTTP protocol is used for talking to the proxy only).

“*” = anything, “?” = any character.

Page 22

Page 27

Scannex ip.buffer User Manual

SNMP Traps

Destination

Dotted IP address for SNMP traps. [255.255.255.255] “0.0.0.0” will disable SNMP trap transmission “255.255.255.255” will broadcast traps across the LAN

SNMP traps are sent in SNMP v1 format. The MIB definitions for the ip.buffer and NetBuffer are available from Scannex.

SNMP Agent

UDP Port

The port for the agent. Set to zero (0) to disable SNMP Agent

completely. [161]

Community

The SNMP community name. This value is shared between all

SNMP activities and modules. [public]

Name override

The name to return for sysName. If left blank this will default to

the string “ip.buffer-00-02-ae-xx-xx-xx” (the serial number) [blank]

Contact

A contact name, number, or email. This value is simply reported

back to the SNMP agent when querying the sys information group. [blank]

Location

A location for this device. This value is simply reported back to

the SNMP agent when querying the sys information group.

[blank]

See section 17 for details on the complete SNMP OID values.

Page 23

Page 28

Scannex ip.buffer User Manual

Syslog

Server Dotted IP address or name for syslog output messages. [blank]

On bootup, a syslog message “system: ip.buffer starting” is output with facility KERNEL, severity NOTICE.

All protected GETs and POSTs to the web-server will output a syslog USER facility with NOTICE severity message in the form:

“web:

ipaddress method /url?query username

”

Where:

•

ipaddress

is the browser's IP address in dotted form. e.g. “192.168.0.235”

•

method

is either “GET” or “POST”

•

/url?query

are the url and query (if present) given for the GET or POST

•

username

is the user that performed the action (if applicable) By tracking the syslog output it is possible to maitain a basic audit tracking log of changes made to the ip.buffer7.

Bandwidth Limiting

Max data

Value in kilo-bytes per second. [0] “0” means unlimited.

Normally the ip.buffer will transmit stored data as fast as it can. In some circumstances this is undesirable. Setting a value other than zero will limit the transfer rate for all data deliveries across the Ethernet interface. (Deliveries across the PPP interface will be sent as fast as possible.)

Version 2.30+ stores all syslog messages in the Log, even if the syslog server entry is blank.

Page 24

Page 29

Scannex ip.buffer User Manual

8.2.2. Time

The ip.buffer includes SNTP client code so it can contact a remote time server and synchronise the date and time. The server is contacted whenever the ip.buffer is booted, and whenever the daily time update is performed8.

When the ip.buffer is in a remote location that has no LAN access to the Internet, the SNTP client can dial through the modem to contact a public SNTP server – keeping the date and time always up to date.

SNTP – Simple Network Time Protocol

Server

Address or IP address of an accessible SNTP server. Blank = no

SNTP update performed. e.g. “time.nist.gov” [blank]

Interface

“LAN only” – will connect only using Ethernet “Modem only” – will always use PPP “LAN then Modem” – will try to use Ethernet. If that fails it will

try PPP

“Modem then LAN” – will try to use PPP and if that fails it will

try Ethernet.

For the Modem dial-out setup see section 8.2.5 [LAN only]

Update At

The daily time, in 24hr “HHMM” format, when the SNTP should be

contacted. Blank = no daily update. [0200]

Variance

The number of minutes that the “Update At” time should be

varied by for each ip.buffer serial number. [0]

Sync Now

A write-only value that forces the ip.buffer to contact the SNTP

server immediately. “No” waits until the normal update time to contact the server. “Sync on save” will contact the SNTP server when you save

the form (pressing the “SAVE” button)

[No]

Last SNTP

Shows the last date and time a reply from the SNTP server was

received.

When using the HTTP POST features for data delivery, alert delivery, or central updates the web

server can also apply time changes back to the ip.buffer (firmware >= version 2.75)

Page 25

Page 30

Scannex ip.buffer User Manual

Time Zone & Daylight Saving

The daylight saving option is applied both to the reply from the SNTP server and to the internal clock. If you do not use the SNTP server, the DST options can still be used.

Time Zone

The time-zone offset, in hours, from UTC/GMT. You can enter

positive and negative, as well as fractional hour values. [0]

Daylight Saving

Sets whether Daylight Saving Adjustment is performed. “No” does not apply DST. “Adjust” Will adjust for DST. [No]

DST Start

Which

Chooses which week number. “1st” first week of the month. “2nd” second week. “3rd” third week. “4th” fourth week. “Last” the last specified day in the month.

Day The day of the week that DST should change.

Month The month that DST should change.

Time The time, in 24hr “HHMM” format, when DST should change.

DST End

The same entries as for “DST Start” apply.

8.2.3. Power

Battery Power

Run Limit

Time, in minutes, before powering off when running on batteries. A value of “0” will run the ip.buffer until the batteries are dead

(recharging will take longer though). [60]

Ethernet

Whether Ethernet is powered when running on batteries9. “Always on” Ethernet powered on batteries. “Off (save power)” No Ethernet on batteries10. [Always on]

Modem

Whether the modem is powered when running on batteries “Always on” modem powered on batteries. “On demand (no dial in)” powered when needed. “Off (save power)” No modem on batteries. [Always on]

If the Ethernet switch is powered off, then the ip.buffer will automatically cut power to the

Ethernet circuit. It will check every 10 seconds to see whether the Ethernet link has been restored.

A delay of 10 seconds before killing power allows any SNMP Traps to be sent first.

Page 26

Page 31

Scannex ip.buffer User Manual

8.2.4. Modem

If a modem is not physically present then all the web options for using the modem will not be shown.

The PPP interface only allows access to the ip.buffer itself. The ip.buffer will not work as a modem router (this protects the internal LAN from any dial-in attacks).

Modem General (global)

Country

The default of “B5” should work in most countries. [B5] For specific country codes please refer to Section 22.

Initialisation Applies extra commands after resetting the modem. [blank]

ip.buffer Address

If set to a dotted IP address, then the ip.buffer will assume this

address when a computer dials in. If set to blank, then the ip.buffer will become the next IP address

up from the calling computer. e.g. if the computer is

10.10.0.23, then the ip.buffer will become 10.10.0.24.

[blank]

Only for RJ-modem.

Page 27

Page 32

Scannex ip.buffer User Manual

Dial-In

Answer After

The number of rings to answer in. If the line rings less than this,

then a dial-in trigger is generated (and you can force

delivery on individual channels). [2]

Answer Time

The maximum time (in seconds) for answering, negotiating the

modem and negotiating the PPP before hanging up and

aborting the incoming connection. [120]

Username Username for incoming connections (case sensitive) [user]

Password Password for incoming connections (case sensitive) [password]

CHAP

Specifies the authentication required for incoming connections. “PAP or CHAP” will allow either PAP (Password Authentication

Protocol) which will send the username and password “in

the clear” (i.e. can be eavesdropped), and CHAP

(Challenge Handshake Authentication Protocol). “CHAP only” will only allow the more secure CHAP protocol.

[CHAP only]

Computer Address

If the calling computer is setup to use automatic IP assignment,

then this value is the address given to the computer. If the calling computer has a static IP address on its PPP

interface, then this value is not used. [192.168.234.1]

Only for RJ-modem. GPRS modem does not require this setting. NOTE: The GRPS modem will only

answer incoming DATA calls. VOICE calls will never be answered, but will perform a trigger.

Page 28

Page 33

Scannex ip.buffer User Manual

8.2.5. Modem Out

If a modem is not physically present then all the web options for using the modem will not be shown.

The ip.buffer will not dial-out during the first 5 minutes of boot-up. This allows for dial-in access. See section 8.2.4

Modem GPRS settings (global)

These settings only appear for the GPRS & EDGE mobile modems. They do not appear for the RJ-modem.

SIM PIN

If the SIM requires a PIN number, then enter it here. The value is

always hidden.

[blank]

Band

Which GSM/GPRS frequency bands are enabled on the modem.

The frequencies used vary by country. “All bands” - auto-detect. “GSM-850 & PCS-1900 (Americas)” - used in Canada, the

United States, and many other countries in the Americas. “E-GSM-900 & DCS-1800” - Extended GSM used in most parts

of the world: Europe, Middle East, Africa, Australia,

Oceania. “P-GSM-900 only” - only Primary GSM 900MHz “DCS-1800 only” - only DCS 1800MHz “PCS-1900 only” - only PCS 1900MHz

[All bands]

If the SIM card is protected with a PIN and an incorrect PIN number is entered, the ip.buffer will try once only. If the entered PIN number gives an error, the internal PIN number is erased (but you will still see “*******” on the web). The ip.buffer Log will record that the PIN attempt failed. This is to prevent the SIM card getting locked completely!

Page 29

Page 34

Scannex ip.buffer User Manual

Modem Dial-Out (global)

Dial Type

“Tone dialling” – uses DTMF tone dialling. “Pulse dialling” – uses loop disconnect dialling

[Tone dialling]

Connect

“On demand (firewalled)” – dial out only when required. “Nailed-up (permanent)” – dials out and stays connected.

Use for situations like GPRS VPN networks for remote management.

[On demand (firewalled)]

Connect Time

Maximum time (in seconds) to dial, connect, and negotiate PPP. If

this time is exceeded, the ip.buffer will hangup and abort the call. [150]

Online max time

Maximum amount of time (in minutes) to spend in one dial out

connection. When this time limit is exceeded, all working delivery tasks are told to finalise their delivery and finish early. Once all the tasks have completed, the modem connection is terminated. [15]

Interval time

Time (in seconds) to wait after hanging up the modem. This time

is effective for both unsuccessful and successful connection attempts15. [60]

Retry limit

Maximum number of times to dial before waiting a hold-off

period. [3]

Hold off time

Time (in minutes) to wait if tried “Retry Limit” times without

managing to connect to the ISP16.

Should be longer than the interval time. [60]

ISP sequence

“#1 then #2 on fail” will always try ISP #1 first. ISP #2 will

only be used if ISP #1 fails.

“Alternate #1 & #2” will try ISP #1 and ISP #2 in turn.

[#1 then #2 on fail]

Only for RJ-modem. GPRS does not require this setting.

Use a value of at least 30 seconds otherwise the internal modem may not dial.

Once a hold-off or interval period is in place, the user can clear the timer from the status web page by hovering over the “Modem” status panel and pushing the “[ Clear Timers! ]” button.

Only for RJ-modem. GPRS does not require this setting.

Page 30

Page 35

Scannex ip.buffer User Manual

Dial-Out Exclusion

Between The start time to begin exclusion. [1800]

…and The end time for the exclusion period. [1900]

If the modem is used as the primary means of data delivery it may be that the modem is in use all the time (when there are very large amounts of data to send). Since the modem is also used for administration of the ip.buffer it is advantageous to allow a known “window” when you can always dial-in.

During the exclusion time period the ip.buffer will not perform any new dial-out attempts. If the modem is in use when the exclusion time comes into force, the modem manager task will request that all delivery tasks finish their work early so the modem can be hung up soon.

Be aware that the dial-out exclusion time is based on the ip.buffer’s local clock. There may be clock-drift over periods of weeks and months. This clock drift can be eliminated by using SNTP (section 8.2.2)

ISP #1 & ISP #2 (RJ-modem only)

Number The full number for the ISP [blank]

Username The CHAP/PAP username for the ISP [blank]

Password The CHAP/PAP password for the ISP [blank]

GPRS Internet (GPRS-modem only)

APN

The GPRS service Access Point Name. e.g. “vodafone-data”

[blank]

Username The CHAP/PAP username for Internet access, if required. [blank]

Password The CHAP/PAP password for Internet access, if required. [blank]

Page 31

Page 36

Scannex ip.buffer User Manual

Firewalling

When using the “On demand” connection method and when connected to an ISP the ip.buffer implements a firewall to prevent any TCP/IP connections being made to the device. It is impossible to gain access to the web server, FTP server, or any other ports while dialled up to an ISP (even if the ISP is actually a RAS server).

If using the “Nailed-up (permanent)” connect type then the firewall is disabled. This allows remote management of the ip.buffers within a VPN network (e.g. through a specialised SIM contract).

DNS Servers

Normally, for Ethernet LAN connections, the ip.buffer will use the DNS1 and DNS2 addresses programmed in the Network & System web page. However, for delivery destinations that use the modem the DNS requests are sent across the PPP modem link using the DNS server addresses supplied at connection by the remote PPP end18.

If the remote machine name is already in the DNS cache (whether obtained via the LAN or the modem) the cache entry is used.

While the PPP link is active, the LAN DNS server addresses are still used for Ethernet LAN transfers.

Page 32

Page 37

Scannex ip.buffer User Manual

8.2.6. SMTP Email Servers

The ip.buffer allows two separate email servers to be programmed. For email data delivery, we strongly recommend sending the data “point-to-point”. That is to say, the ip.buffer should connect directly to the SMTP server that is processing the data, and it should not connect through any SMTP relays. This ensures that the data cannot be lost in transit19.

For the delivery of email alerts, any server could be used – whether that is a private server or a public one.

The SMTP#1 and SMTP#2 are global settings – editing within one module will affect all others.

The settings for each SMTP server are:

Name

A screen name used for choosing an SMTP server.

[SMTP1] & [SMTP2]

Interface

“LAN only” – will connect only using Ethernet “Modem only” – will always use PPP “LAN then Modem” – will try to use Ethernet. If that fails it will

try PPP

“Modem then LAN” – will try to use PPP and if that fails it will

try Ethernet.

For the Modem dial-out setup see section 8.2.5 [LAN only]

Server The name or IP address of the server20. [blank]

TCP Port The port number to connect to the server on. [25]

TLS/SSL

“No encryption” – a plain SMTP session “Explicit (by command)” – starts with a plain connection

and then upgrades to SSL/TLS. If the server does not support SSL/TLS then the delivery will fail.

“Implicit (by port)” – starts with an SSL/TLS connection.

[No encryption]

If using the point-to-point email delivery method across a public network we suggest using a nonstandard port number. Some ISPs now filter any port 25 traffic and perform anti-spam and other checks. You can use any port (e.g. 20025), as long as the server is programmed to use the same port! For any public SMTP server, port 25 should be used for non SSL traffic.

In the case of a modem-only connection, you can use the special designator “$” to denote the address of the other end of the PPP connection. This is helpful where the mail server machine is also a RAS/PPP server.

Page 33

Page 38

Scannex ip.buffer User Manual

Domain

Domain – you need to enter a domain name (e.g. “scannex.com”)

that is used for the “HELO”/“EHLO” logon sequence, and for the domain part of the “from” address. The from email address for alerts will be boxname@domain, while for data deliveries it will be boxname_channelname@domain.

[blank]

Username

Only enter a username if the server requires authentication for

sending emails. Usually required if sending to someone on a domain other than the server’s domain. [blank]

Password (see Username above). [blank]

Limit

When the SMTP server is used to send data this value, in

kilobytes, will break the emails into sizeable chunks.

[1024]

The recipient (email to) addresses are programmed individually for each channel and on the email alert setup.

Page 34

Page 39

Scannex ip.buffer User Manual

8.2.7. Alerts

The alert system allows the pro-active monitoring of the ip.buffer and all channels. Alerts can be sent as emails (which can be human-read or machine processed). Alternatively the alerts can be HTTP POST'd into the central Cloud Server – and the server can decide how best to deal with the alerts (see section 8.2.13).

Alerts are generated for memory full conditions, reboots, web configuration, authentication failures, channel quiets, and channel connects/disconnects.

Each alert has a “tag” that identifies the specific alert. Along with the “tag” there is usually a text field as well.

The emails contain the tags on the subject line, as well as the alert entry in the body HTML text of the email. All notification emails may include more than one tag on the subject line (separated by a comma), and will have the “status.lua” file attached.

When using HTTP POST, the alerts are sent through as fields. Each field has the prefix “alert_”. The “tag” follows – e.g. “alert_Reboot”. The field value is always the date (in the form “YYYY-MM-DD HH:MM:SS”), a space, and the alert text. It is relatively trivial to process these alerts in web-server-side scripting languages like ASP.NET, Java, PHP, etc21.

Alerts Method

Method

“Email (SMTP)” will send alerts by email “HTTP POST to Cloud Server” will send alerts by the HTTP

POST method to the Cloud Server. See 8.2.13 for details.

“Don't send alerts” will not send anything [Email (SMTP)]

Send Info

“yes” will send the information attachment with the alert. “no” will send just the alert. [yes]

Email Server

(Only visible if Method is “Email (SMTP)”)

SMTP

“SMTP #1” will send via SMTP server #1 “SMTP #2” will send via SMTP server #2 Click the “show” to view the actual SMTP#1 and SMTP#2

programming. [SMTP#2]

For SMTP settings see section 8.2.6

email to

The recipient(s) of the alert emails. Use a semicolon to separate

multiple recipients.

e.g. alerts@scannex.com;myemail@yahoo.com [blank]

Scannex can supply a licensed Web Server Support Package.

Page 35

Page 40

Scannex ip.buffer User Manual

Memory Alerts

Global Memory

Percentage level for the global memory full alert22. The tag is

“Full”.

0 will disable this alert. [75]

Channel #

Specifies the trigger level (in megabytes) to send a channel based

full alert. The tag is “Full#”.

0 will disable the alert for the given channel. [0]

Notification Alerts

Comfort

Sets the interval in minutes for the transmission of an alert back

to the central system to show that the ip.buffer is still running. The tag is “Comfort”.

[0]

Reboot

If enabled will send an alert when the ip.buffer is rebooted. The

tag is “Reboot”. [Notify]

Configure

If enabled, an alert will be sent when anyone changes the

settings through the webpage23. [Notify]

Authentication

If enabled, all FTP server authentication failures, all pass-through

authentication failures, and all TCP server authentication failures will be notified24. The tag is “Auth”. The alert text will indicate which service caused the authentication alert. [Notify]

Temperature Alerts

Temperature display and alerts is only available in the ip.4 product, and uses a small onboard thermometer chip located near the front panel, on the left side (looking at the LEDs). The internal temperature of the ip.buffer is approximately 5°C higher than the room temperature.

High

Sets the temperature high point, in integer degrees Celcius, to

send out an alert and trap. 0=no alert. The tag is “TempHi” [0]

Low

Sets the temperature low point, in integer degrees Celcius, to

send out an alert and trap. 0=no alert. The tag is “TempLo” [0]

The alert will be sent immediately the memory goes over the limit. However, repeat “Full” alerts will continue to be sent every 8 hours until the memory drops below the limit.

The first time a configuration is posted, the alert will be sent immediately. If configuration changes are performed over an extended period of time, reminder alerts will be sent every 10 minutes. If the configuration is left for more than 10 minutes the “Config” alert will clear.

There is no time-out on the authentication failures. All failures are sent immediately.

Page 36

Page 41

Scannex ip.buffer User Manual

Schedule for Quiet Alerts

The individual channels specify the timeout for the quiet alerts, but the schedule decides whether the alert is actually sent.

Days

Check which days to send quiet alerts.

[Mon,Tue,Wed,Thu,Fri,Sat,Sun]

Between The start time for the schedule25 [0000]

…and The end time for the schedule [2359]

Source Quiet Alerts

• These are duplicate entries as found in the individual channels

Channel #

The number of minutes of quiet before sending an alert. A value of “0” means disabled. [0]

Source Connect/Disconnect alerts

• These are duplicate entries as found in the individual channels

Channel #

“Ignore” – don’t send an alert on connect/disconnect. “Notify” – send an alert when connected or disconnected.

[Ignore]

If the alert cannot be sent, then new events will overwrite the pending ones.

You must enter the minutes as well as the hours. e.g. 10am should be entered as 1000; 9am can be written as 0900 or 900

Page 37

Page 42

Scannex ip.buffer User Manual

8.2.8. Alert List

Alert Tag Definition

Reboot

The ip.buffer has booted and started running code

Battery

The ip.buffer is running on battery power

Mains

The ip.buffer is running on mains power

Config

The ip.buffer has been reconfigured

LowVolts

The ip.buffer has started up running on a PSU that is too low

User

User triggered alert (i.e. clicked “Trigger User Alert!” on web page)

Auth

An authentication failure

Connect1, etc

A channel has connected

Disconnect1, etc

A channel has disconnected

Quiet1, etc

Channel has had no data (resent periodically)

Full1, etc

Channel has reached its full limit (resent every 8 hours)

Full

Global memory is full, as set in the alerts setting page (resent every 8 hours).

Comfort

ip.buffer is still alive (sent at the interval specified in the alerts setting page)

TempLo

The ip.buffer temperature is too low

TempHi

The ip.buffer temperature is too high

The config alert will be sent every 10 minutes while configurations are still in progress. It will clear after 10 minutes of making no configuration changes.

Temperature alerts are only available on the ip.4 product

Page 38

Page 43

Scannex ip.buffer User Manual

8.2.9. RADIUS

These settings allow the ip.buffer to refer back to one or two RADIUS servers for authentication of all server services. The ip.buffer uses UDP port 1812 for the RADIUS requests.

RADIUS Authentication Servers

Server 1

A dotted IP address or name for the RADIUS server. If this field is

blank then RADIUS authentication is effectively disabled and only local username/passwords are used. [blank]

Secret 1 The shared secret for server 1

[blank]

UDP Port 1 The UDP port for server 1 [1812]

Server 2 A dotted IP address or name for the backup RADIUS server. [blank]

Secret 2 The shared secret for server 2 [blank]

UDP Port 2 The UDP port for server 2 [1812]

Timeout The timeout (in seconds) for requests to the RADIUS server(s) [2]

NAS-Identifier

override

The identifier string to send to the server when issuing requests.

If blank, this will be the serial number of this ip.buffer but can be programmed to anything required. [blank]

NAS-IP-Address

A dotted IP address to send back to the RADIUS when issuing

requests. If the field is blank then the NAS-IP-Address field is not included in the request. This field is for complex RADIUS setups. [blank]

When replicating buffer settings it is not possible to transfer these secret values. The configuration file will have “********” for each of the secrets. You must manually edit those values in the file before uploading into the target buffer.

Page 39

Page 44

Scannex ip.buffer User Manual

Authentication Methods

Web

Authentication option for the web-server “Local only” – Uses the local username/password set in the

Web option. “RADIUS only” – Only asks the RADIUS server29. “RADIUS then Local on timeout” – Tries the RADIUS

server(s) and falls-back to the local username/password if

the server(s) time out30. “RADIUS and Local” - tries the RADIUS server(s) first, and

then tries the local username/password if the server(s)

time out or reject the username/password. [Local only]

Pass-through

Authentication option for the pass-through of all channels. (See above options) [Local only]

FTP Server

Authentication option for the FTP Server delivery of all channels. (See above options)

[Local only]

TCP Server

Authentication option for the TCP Server delivery of all channels. (See above options) [Local only]

Each RADIUS request packet includes the following information:

• Username and Password (encrypted using the MD5 according to the RADIUS spec)

• NAS-Identifier – as set above

• NAS-IP-Address – optional (as above)

• NAS-Port-Id – this string value indicates which internal service is requesting the

RADIUS authentication:

o “Web” - the web server o “FTP” - the FTP server o “P1”, “P2”, “P3”, “P4” - the pass-through socket for each channel o “T1”, “T2”, “T3”, “T4” - the TCP server delivery socket for each channel.

When rebooting, the ip.buffer will use the local username/password if the RADIUS cannot be contacted. As soon as the RADIUS server gives a reply the local username/password is never used again (until next reboot).

If contacting the RADIUS server times out, then every protected web-page (and section) will be slow to load in the browser.

Collecting with FTP Server is unaffected by this setting.

Page 40

Page 45

Scannex ip.buffer User Manual

The RADIUS server MUST reply with a packet that includes a “Filter-Id” string value. This Filter-Id string value specifies which services the user is allowed to access on the ip.buffer.

If there are multiple “Filter-Id” values that need to be returned, for the benefit of other devices or because of the RADIUS Server configuration, then the ip.buffer details can be prefixed with the string “Scannex:”32.

The Filter-Id should be built from the following string tags:

• W1 – user is allowed to read all protected web pages but cannot POST changes.

• W2 – user is allowed to read and write to the web pages

• W3 – user is allowed to only read the status pages

• P1, P2, P3, P4 – user can access the TCP pass-through socket for channels 1, 2,

3, or 4 respectively. Any number of these tag values can be present within the Filter-Id.

• T1, T2, T3, T4 – user can access the TCP Server delivery socket for channels 1,

2, 3, or 4 respectively. Any number of these tag values can be present within the Filter-Id string.

• F1, F2, F3, F4 – user can access FTP Server delivery

for channel 1, 2, 3 or 4

respectively. Only one “F” value should be present within the Filter-Id string34.

For example, a returned Filter-Id string of “W1F1P1P2P3P4T1T2T3T4” will allow readonly web access, access to FTP delivery channel 1, and all pass-through and TCP server delivery channels.

As another example, the Filter-Id string “P1P2P3P4” will only allow access to the passthrough sockets for all channels – but not web, FTP, nor TCP server delivery.

Web

The web-browser client is forced to use the Basic authorization method for http. The secure MD5 Digest authorization of http is physically impossible to use with RADIUS. For that reason you SHOULD use an https secure session when using the web (the web server can be programmed to force https). See section 8.2.12.

When using RADIUS for web access, the web server will deliver a simple cookie to the browser. This cookie enables the server to link the user's web session with the current username/password combination. As a consequence the ip.buffer only has to contact the RADIUS server once for that session (without a cookie it would have to contact the RADIUS server for every page and resource requested by the web-browser).

After switching authentication modes for web you may need to restart your web browser to get the new username and password in effect as it will have cached the cookies.

Applies to firmware >= 2.80

A RADIUS user can only access one channel's storage through the FTP server.

If there are multiple “F” values then only the first account is used.

Page 41

Page 46

Scannex ip.buffer User Manual

FTP

When FTP is linked to RADIUS then any channel that is set to deliver by “FTP Server” will be checked against RADIUS. When the user logs in the FTP server will contact the RADIUS server to determine which channel that user should access. The Filter-Id value is searched for the first “F” value – so there should only be one “F” value in the returned Filter-Id string. Consequently, if “F3” is received for a given user, then that user will log into channel 3.

Pass-through and TCP Server Delivery

When RADIUS is not used, both of these services only ask for a password. When the TCP/IP socket connects the user is shown a “Password:” prompt. However, when linked to RADIUS we need both a username and password from the client.

Hence, when either of these services is set to refer to RADIUS the end user should use the form “

user:password

” when replying to the “Password:” prompt.

If you enter just a password, then the RADIUS client will assume a username of “ipbuffer_boxname_serviceid”, e.g. “ipbuffer_Scannex_P1” for pass-through 1. e.g. “ipbuffer_Scannex_T3” for TCP Server channel 3.

Other considerations

Unless the RADIUS server can create a NAS-Identifier + User-Name to Filter-Id matrix then the inclusion of a user on the RADIUS server will allow access to the specified resources on all ip.buffers that refer to that RADIUS server.

The inclusion of programmable NAS-Identifier and NAS-IP-Address values should provide for enough flexibility to manage either groups of ip.buffers or individual ip.buffers at the RADIUS server. However, for some RADIUS servers, it may be that providing administrative web-access is all that is practical. This is the main reason for allowing each of the four services to choose where their authentication is taken.

Page 42

Page 47

Scannex ip.buffer User Manual

8.2.10. Certificates for SSL/TLS and SSH

The certificates35 section allows options to “lock” the ip.buffer to specific servers by checking the servers' certificates. Additionally, clients can be forced to provide a client certificate for checking against a list of approved fingerprints.

The fingerprints are a mathematical “hash” of the full certificate. There are two common methods of hashing certificates - “MD5” and “SHA1”. The ip.buffer uses the stronger SHA1 fingerprint hash method. The full certificates can be very large (several kilo-bytes), whereas an SHA1 hash is 20bytes long. In the ip.buffer it is shown as 20 pairs of hex numbers.

e.g. “0c:15:fe:6e:7f:b4:cd:2c:64:18:16:8b:d5:3a:67:6e:c7:54:b8:71” Locking an ip.buffer to a particular server certificate will prevent “man-in-the-middle”

style attacks and spoofing. The ip.buffer will only connect to the genuine server.

Security Certificate Fingerprints

Local Fingerprint

Shows the SHA1 hash fingerprint of the ip.buffer's TLS/SSK PKI

certificate. You can use this to check that the PC clients are actually connecting to this ip.buffer (and not being intercepted).

Download

Links for download the TLS/SSL PKI X509 certificate, or the SSH

publickey36. These files may be needed for inclusion in the allowed keys on your server.

Approved

Fingerprints

A list of SHA1 hash fingerprints for certificates that are approved

by this ip.buffer. You may enter just the fingerprint on each line, or “name=fingerprint” (so you can identify the fingerprints more easily). [Blank]

Recent Fingerprints

The Recent Fingerprint list shows the fingerprints of any

certificates that were not listed in the Approved Fingerprints list.

(SSH server fingerprints will be prefixed with the IP address and

SSH version number.37) “IP Address” is the IP address of the client or server. “Name” is the IP address or name that was programmed into the

ip.buffer. When a client connects this field will show

“(blank)”. CA certificates will show “CA” or “CA+1” “Certificate CN” is the Common Name that is entered into

the certificate on the server or client. You can hover the mouse over the “Approve” link to show the

SHA1 fingerprint of the certificate. Clicking “Approve” will add the fingerprint to the Approved

Fingerprints list.

SSL/TLS firmware only.

The SSH server publickey is taken from the TLS/SSL PKI certificate's RSA key.

The SSH fingerprints are SHA1 fingerprints, rather than the shorter and more usual MD5

fingerprints that are shown in most SSH client software on PCs.

Page 43

Page 48

Scannex ip.buffer User Manual

“Chains of trust”: Usually the server will only send a single certificate. That certificate may be signed by an approved person (e.g. Verisign etc), and a PC is able to check against a database of known certificate authorities to verify the certificate. The ip.buffer does not have a internal database of approved certificate authorities and can only verify certificates that were actually sent as part of the SSL/TLS handshake protocol. If multi-level certificates are required you should be able to load the whole certificate chain into your server.

Security Certificate Global Options

Verify Servers

“Ignore (allow any certificate)” – will allow any

certificate. The fingerprint of any servers the ip.buffer

connects to will appear in the “Recent Fingerprints” list. “Fingerprint must be approved” – only servers that have

certificates that match the approved fingerprint list can

be connected to. Any others will result in an error.

[Ignore (allow any certificate)]

Verify Date

“Ignore” – the validity date of the certificate is not checked. “Must be in date” – the certificate date is checked. If out of

date then an error is reported and the connection closed.

[Ignore]

Verify Name

“Ignore” – does not check the certificate name. “Address and CN must match” – the address entered in the

ip.buffer must match the certificate CN (Common Name)

field38. [Ignore]

Verify Clients

“Ignore (allow any certificate)” – will allow any

certificate. The fingerprint of any clients that connect to

the ip.buffer will appear in the “Recent Fingerprints” list. “Fingerprint must be approved” – only clients that have

certificates that match the approved fingerprint list can

be connected to. Any others will be rejected. In addition,

if a client does not provide a certificate then the client

will be rejected. The client certificate date and name are

also checked according to the above two rules.

[Ignore (allow any certificate)]

Only explicit common names are currently supported (e.g. “collect.scannex.com”). Wildcard

common names are not supported (e.g. “*.scannex.com”)

Page 44

Page 49

Scannex ip.buffer User Manual

8.2.11. FTP

The FTP server, as used for FTP server data delivery and FTP server data collection, has global settings.

FTP Server

TCP Port

The port number for the server. 0 will disable the FTP server completely. [21]

Interface

“LAN only” – dial-in PPP connections are blocked “Modem only” – Ethernet connections are blocked

“LAN or Modem” – either PPP or Ethernet can be used

[LAN or Modem]

Allow

You can enter a name, IP address, or wildcarded40 IP address to

restrict access to the FTP server for clients on the LAN.

You can also enter a comma- or semicolon-separated list.

Any non-matching clients will have their connection

immediately closed. (Hint: leave this blank until you have the system working, and

then secure it with a value) [blank]

TLS/SSL

“No Encryption” – uses plain FTP transfers “Explicit (by command)” – starts with a plain connection

and requires the client to negotiate SSL/TLS before

transferring data41. “Implicit (by port)” – starts with SSL/TLS

Note: Even if set to “No Encryption” the client can still request

an explicit SSL/TLS connection. [No encryption]

Passive Port Range

Lo The lowest port number to use [50000]

Hi The highest port number to use [50099]

When the FTP client request PASV (passive mode), the server will use one of the ports within this range, Lo-to-Hi. You can easily setup an inbound firewall rule if needed43.

If you are using collection with the FTP Server, then do not use the “Modem Only” setting – this

will prevent your device from connecting to the ip.buffer.

e.g. “192.168.0.*, device.scannex.com, 192.168.*”. Wildcards are “*” for anything, and “?” for

any single character.

Forcing “Explicit” SSL will still allow collection from non-SSL FTP devices.

When forcing “Implicit” SSL, all FTP connections must use SSL – including collecting FTP devices.

If the ip.buffer is behind a firewall, you will need to add “Services” to the firewall. The main service will be the FTP service (or specific TCP port if you use something other than 21). In addition, you should add the passive port range as services in the firewall. For all these services, tell the firewall to send the TCP traffic to the internal IP address of the ip.buffer. (Individual firewall configuration varies greatly.)

Page 45

Page 50

Scannex ip.buffer User Manual

Source Users

• These are duplicate entries as found in the individual channel “Source” setting

module when set to collect from FTP.

Channel #

The username for FTP collection for the channel (case sensitive).

[_channel1], [_channel2], etc

(password)

The password for FTP collection for the channel (case sensitive).

[password]

The username and password for each of the channels that are collecting data by FTP server.

Destination Users

• These are duplicate entries as found in the individual channel “Destination”

setting module when set to deliver by FTP Server.

Channel #

The username for FTP Server for the channel (case sensitive).

[Channel1], [Channel2], etc

(password)

The password for FTP Server for the channel (case sensitive).

[password]

Destination Users – the username and password for each of the channels that are delivering data by FTP server.

See the documentation relating to the FTP Server delivery mode in section 11.3.

Page 46

Page 51

Scannex ip.buffer User Manual

8.2.12. Web

You can set your own username and password for web-administration to prevent unauthorised modifications to the ip.buffer settings.

Web Server Security

Allow http

“No (https only)” – force the web-browser to use https.

Accessing port 80 (http) will redirect to port 443 (https).

“Yes (http & https)” – either http or https connections can

be made. The user is encouraged to use https by the use of a red banner at the top of the browser.

[Yes (http & https)]

Authorization

“Digest Only” – the web-browser must use MD5 digest

authorization. Passwords are protected.

“Basic & Digest” – either basic authorization (where the

username and password are sent unencrypted) or digest MD5 authorization is possible. [Digest Only]

WebLock

“Unlocked” – Scannex WebLock is not used. “WebLocked” – In cases where the username/password is not

secure enough, you can lock the web pages with the Scannex authentication/encryption. In this case, the user has to enter a numerical response to a challenge before gaining timed access to the setup pages45. [Unlocked]

On reboot

“Authenticate” – will always require a password. “5 minute window” – allows for 5 minutes grace after

rebooting where no password is required. [Authenticate]

Local Passwords

“Visible” – passwords can be read and written. “Obscured” – reading passwords will only show “********” on

both the web-page and configuration downloads46.

[Visible]

Only visible if the Scannex encryption key has been set for WebLock facilities.

One example is where you need to give temporary access to a user or on-site engineer. They will need the username/password anyway, but by using the WebLock you can restrict their access to a one-time operation. They call you with the serial number and challenge, and you provide them with a 5 digit response code that is derived from the private secret (which you don’t give out!)

Version 2.20+ now store all passwords in the write-only secret-store (the same area that the Scannex encryption secrets and PKI certificates and keys are stored). When set to “Obscured” it is not possible to simply read-out the configuration and write into another buffer to replicate the settings. Before uploading the saved configuration file you must replace all “********” values with the required passwords and secrets.

Page 47

Page 52

Scannex ip.buffer User Manual

User: Status Page

By default anyone can view the Status page of the buffer. These settings allow you to restrict access to the Status page.

Username

The username for the status page. If this is blank, then no authentication is performed for the status

page. If you are using RADIUS authentication, and want the status page authenticated, then you must fill in a username. [blank]

Password

The password for the status page. [blank]

Forgot the password? See section 5.3

Admin: Setup & Tools Pages

Username The username for setup and tools pages. [admin]

Password

The password for setup and tools pages. [secret]

Forgot the password? See section 5.3

Page 48

Page 53

Scannex ip.buffer User Manual

8.2.13. Cloud Server

The central Cloud Server feature of the ip.buffer allows central management of all configured ip.buffers with a standard web server. This is particularly useful for 'Managed Services' deployments where out-bound web browsing is allowed on customer sites.

The ip.buffer issues a requests (either with http or https) to the server. The server can respond and deliver:

• Lua script updates

• Firmware upgrades

• Configuration changes

• Requests for diagnostic dumps

• Requests for log files

• Time synchronisation

• Reboot requests.

Cloud Server (global)

Interface

“LAN only” – will connect only using Ethernet “Modem only” – will always use PPP “LAN then Modem” – will try to use Ethernet. If that fails it will

try PPP

“Modem then LAN” – will try to use PPP and if that fails it will

try Ethernet.

For the Modem dial-out setup see section 8.2.5 [LAN only]

URL

The full URL. This should be in the form “http[s]://

[user[:pass]@]server[:port]/directory/resour ce”.

You can also specify a choice of https / http by using

“http?://” or “http*://” as the URL

e.g. “https://192.168.0.240/private/update.php” e.g. “https://main:pass@192.168.0.241/ipbuffer/get.asp” e.g. “http://main@192.168.0.241:8081/ipbuffer.php”

[blank]

Managed by

“Cloud Server URL (default)” - the server specified by the

URL above will manage the ip.buffer

“Scannex Support Server” - the ip.buffer will be managed

by Scannex's ip.buffer support server47.

[Cloud Server URL (default)]

Modem ring

“Ignore” - does nothing when the modem line rings “Update on Ring” - triggers an update request when the

modem rings. [Contact on Ring]

This mode allows Scannex to assist in resolving site issues without having to obtain remote PC access, etc. Once switched back to the default setting, Scannex will have no access at all.

Page 49

Page 54

Scannex ip.buffer User Manual

Failure Delay

The time, in seconds, to wait after a connection to the Cloud

Server failed. [300]

The ip.buffer will check with the Cloud Server whenever it reboots, or when Lua reboots. An immediate check can also be performed with the “Tools / Check for Updates” link.

Page 50

Page 55

Scannex ip.buffer User Manual

8.3. Date and Time Synchronize

http://192.168.0.235/setup/time.shtm

The ip.buffer has a battery powered real time clock. The ip.buffer uses UTC (Universal Time, Coordinated) or GMT as its internal time48.

The web page allows very simple synchronisation with the PC's UTC clock. The page shows the time zone offsets for both the PC and the ip.buffer49. To simply synchronize the PC clock and the ip.buffer just click “SAVE”.

Alternatively you can manually enter a UTC/GMT time:

UTC Enter a manual time in the form “yyyy-mm-dd hh:mm:ss”

The Time Zone and Daylight Saving Time is applied to calculate the ip.buffer's local time. See section 8.2.2 for SNTP time-related settings, Time Zone and Daylight Saving Time settings.

Firmware 2.60 and before used local time internally.

Local time = UTC + TimeZoneOffset.

Page 51

Page 56

Scannex ip.buffer User Manual

9 . C h a n n e l s

http://192.168.0.235/setup/channel.shtm?ch=1

The ip.buffer has the concept of “channels” at the core. A channel consists of:

• The data source – Serial

, TCP, UDP, FTP Server, or “off” (Section 10)

• A pass-through channel that allows bidirectional access to the source from a

TCP/IP socket2 (Section 10.6.17)

• A method of delivery (the destination) – Email Push, HTTP POST to Web Server,

FTP Push, FTP Server, TCP Server, TCP Push, Pass-through Only (Section 11)

• Storage area – the memory (Section 12)

Channel 1 uses COM1, Channel 2 uses COM2, and so on

Each pass-through socket has a separate port number

Page 52

Page 57

Scannex ip.buffer User Manual

Name The name of the channel. [Channel1]

Source

Where to collect data from:

Type Description Section

COM1 Serial

Serial port 10.1

TCP

TCP/IP device 10.2

UDP

UDP/IP 10.2.1

FTP Server

Device FTP pushes into the ip.buffer

10.4

None (off)

No source (Lua scripting can still make use of the storage for this channel)

10.5

[COM1 Serial], [COM2 Serial], etc

Destination

How to deliver the data:

Type Description Section

Email push (SMTP client)

Deliver by email 11.1

HTTP POST to Cloud Server

Deliver by HTTP or HTTPS 11.2

FTP server

Computer collects data from ip.buffer with FTP

11.3

FTP push (client)

ip.buffer FTP pushes into a central computer

11.4

TCP server (passive)

Raw TCP/IP where computer connects to the ip.buffer

11.5

TCP push (active/client)

Raw TCP/IP where ip.buffer pushes into a central computer

11.6

COM port serial

Send data to a free serial port 11.7

Legacy

ip.buffer emulates legacy devices across TCP/IP or modem

11.8

None

No delivery of data (useful for just pass-through)

11.9

[FTP server]

Storage

How to handle memory for the channel. See section 12

The associated “Pass-through” socket can be used for engineer or administrative access to the data source. When the pass-through socket is connected the data may not be stored – this depends on the Pass-Through setting in 10.6.17.

It is also worth noting that each channel has its own method of delivering the data, so you can mix-and-match methods to suit the needs of the system as a whole.

Page 53

Page 58

Scannex ip.buffer User Manual

1 0 . So u rc es

10.1. COM Serial

All serial ports of the ip.buffer include full auto-pin detection, auto-baud1 rate measurement, and auto-parity detection. You can also set the type of hardware flow control for receive and transmit.

10.1.1. Settings

Serial

Autobaud

Whether Scannex auto-baud and auto-protocol detection is

enabled. [Enabled]

Baud

The baud rate, from 300 to 115200. If autobaud is enabled, this is

the starting baud rate. [115200]

Protocol The number of data bits and parity. [8N]

Rx/Tx

“DTE: Rx2/Tx3” – pin 2 is receive on the DB9 connector “DCE: Rx3/Tx2” – pin 3 is receive on the DB9 connector “Auto” – uses the detect voltage on the pin

“Diagnostics” – puts the COM port in a diag mode3. [Auto]

Rx Flow

Which control lines to use to stop the device sending more data.

[RTS]

On Passthrough

Which control line(s) to use to indicate when the passthrough

socket is connected. “None” – any control lines not used for Rx Flow are asserted. The Rx Flow control lines always take priority. For example, if

you choose “RTS & DTR” for Rx Flow control then the

passthrough setting will have no effect. [None]

The NetBuffer and ModemBuffer required a pause in the data after measuring the baud rate and before detecting the parity. The ip.buffer uses a different technique which means that a pause is not required.

If the device has TTL outputs, and not standard RS232 +ve/-ve signals, you cannot use Auto. The electronics require the receive pin to go negative to detect.

No data can be received in the Diagnostics mode. It reports a “Detect” number that can be reported to Scannex for problem solving.

Page 54

Page 59

Scannex ip.buffer User Manual

Serial Transmit

Tx Flow

Which control lines to monitor when deciding whether we can

send data into the device. [CTS]

Tx Size

Determines the maximum chunk size to transmit. The Tx Flow

control lines are only checked before sending each chunk. If the connected device has a small input buffer and uses hardware flow control then lower this value4. [16]

Tx Pause

Allows insertion of an inter-byte gap on transmission. The value is

measured in bits, so a value of 10 will halve the transmission speed. Use larger values to slow down the transmission into slow devices5. [0]

Serial Diagnostics

Loopback

“Normal = off” – no loopback “Diagnostics = on” – helps diagnose COM port issues. While

in loopback mode nothing is sent to the connected device and nothing is received from the device (Rx and Tx pins are effectively disconnected from the outside world)6. Be careful when trying to use bidirectional protocols with the diagnostic mode!

[Normal = off]

In most cases, the automatic settings will work perfectly. However, there are a few exceptions which need to be outlined:

When using higher baud rates (e.g. 115200), very small values of Tx Size will cause excessive CPU load when sending very large amounts of data out of multiple COM ports and may cause the ip.buffer to reset.

The receive speed/flow is unaffected.

If Tx Flow control is enabled, this is still respected and data will not be transmitted if the connected device is signalling that it is not ok to send.

Also, when using this feature, make sure the pass-through socket is in “Stored” or “Not stored”, as both the “Monitor” and “Debug” modes will dump any data that you try and send to the source.

Page 55

Page 60

Scannex ip.buffer User Manual

10.1.2. Connection to a PC serial port

If the ip.buffer is collecting data from a PC’s serial port it is possible the PC will “probe” the port for mice and modems on boot-up. This is usually done at 115200 baud. If the ip.buffer is set for autobauding, it may trigger the autobaud process whenever the PC is rebooted.

It is more of a problem if the ip.buffer is being used to administer a PC device through the serial port. If the PC probes for devices on boot up it will start an autobauding process that may never complete (if the PC doesn’t send data).

Disable autobauding for this special case.

For collection of SMDR/CDR data from a PBX we strongly recommend leaving autobaud enabled. If an engineer changes any settings then the ip.buffer will quickly lock onto the correct baud rate and continue logging.

10.1.3. When using a Y-lead

If the ip.buffer is connected in parallel to another logging device the ip.buffer will see two transmit lines (one from the device being logged, and one from the other device). In this case, depending on which logging device is connected first, the ip.buffer may not be able to decide which pin to log data from8.

There are two solutions:

1. Cut all pins other than the ground and transmit on the cable that connects to the ip.buffer. The ip.buffer will always get it right.

2. Force the DCE/DTE of the ip.buffer. You can determine which way round it should be by temporarily unplugging the secondary device. Then force this in the Serial port’s Source page. (The Rx/Tx setting.) Once you have forced the pin out, the secondary device can be reconnected.

If two Scannex devices are connected using a Y-lead (e.g. NetBuffer+ip.buffer or ip.buffer+ip.buffer) then please email Scannex for extra instructions and suggestions.

If the ip.buffer is set to “Auto”, and sees two transmit lines it will default to the standard PC pin

out (a DTE).

Page 56

Page 61

Scannex ip.buffer User Manual

10.2. TCP

There are two methods of connection with TCP. Either the ip.buffer behaves as a server and waits for the device to connect, or the ip.buffer connects into the device.

In addition, there are options for Match & Send (to allow for login sequences) and a regular heartbeat.

TCP/IP

Connect

“ipbuffer to Device (active/client)” – the device is

listening for the ip.buffer

“Device to ipbuffer (passive/server)” – the device will

connect into the ip.buffer (usually you have to program the device with the IP address of the buffer)

[Device to ipbuffer (passive/server)]

Address

For “ipbuffer to Device (active/client)” mode, this is

the name or IP address of the device you wish to collect data from. [blank]

Allow

For “Device to ipbuffer (passive/server)” mode, you

choose to enter a name, IP address, wildcarded IP address to specify which devices can connect. You can also enter a comma or semi-colon separated list9.

If this is blank then the ip.buffer will allow any device to

connect.

(Hint: start with a blank setting, get the configuration working

and then lock it down with a value) [blank]

TLS/SSL

“No encryption” - a regular TCP connection. “Implicit (by port)” - starts with an SSL/TLS connection.

For devices that require SSL/TLS (e.g. Nortel BCM Live Stream) [No encryption]

TCP Port The port number for the TCP/IP socket [2001], [2002], etc

e.g. “192.168.0.*, device.scannex.com, 192.168.*”. Wildcards are “*” for anything, and “?” for any

single character.

Page 57

Page 62

Scannex ip.buffer User Manual

Match & Send

#1..#4

The “match” of the match and send. As each match is detected in

the incoming data stream its corresponding send is output.

(See section 10.2.1) [blank]

The “send” of the match and send. After the last match & send

has been processed the source is then considered “connected”.

(See section 10.2.1) [blank]

Heartbeat

Interval

The number of seconds between sending the heartbeat string.

Zero is disabled. [0]

String The string to send for heartbeat. (See section 10.2.1) [blank]

10.2.1. Match, Send & Heartbeat special characters

• # = CR/LF character

• $ = NULL character, 0x00

• /nn = HEX character, e.g. /0D

• {nn…} = HEX character(s). e.g. {0D0A0A}

In version 2.60+ the Match & Send and Heartbeat settings now appear in the Protocol section if

applicable to the selected protocol.

Page 58

Page 63

Scannex ip.buffer User Manual

10.3. UDP

The ip.buffer is unique in that it allows collection of UDP data. Some devices, such as the Cisco Call Manager Express, send local data using the syslog protocol. The ip.buffer can collect this syslog data and treat it as normal data.

Allow

“blank” = any incoming UDP source To restrict to one device (or a list), enter a name, IP address, or

wildcarded IP address11. [blank]

UDP Port

The UDP/IP port number. 1813 or 1646 = RADIUS accounting collection. 514 = syslog service. 162 = SNMP trap collection [2001], [2002], etc

Packet

“ASCII + CR/LF” – takes the UDP packet and only stores

readable characters. Appends a carriage return & line feed.

“Length (LSB/MSB) + Binary” – stores a two byte length in

little endian format, and then the binary packet data.

“Binary” – stores just the pure, untouched, UDP packet data.

[ASCII + CR/LF]

There are special considerations for the specific ports 514 (syslog) and 162 (SNMP trap).

10.3.1. Syslog Collection

Set the port to 514 (syslog). You can only select the UDP packet type of “ASCII + CR/LF”.

10.3.2. SNMP Trap Collection

Set the port to 162 (SNMP trap). The “Packet” mode decides what is stored:

● “ASCII+CR/LF” - the SNMP trap is decoded into a single ASCII line and stored

. Internally the data is presented as ASCII data with 1 CR/LF. The decoded string includes the IP address of the sending device.

● “Length (LSB/MSB) + Binary” - the trap is stored as it was received with a length

prefix.

● “Binary” - the trap is stored as it was received.

Additionally, a section appears for SNMP trap collection:

e.g. “192.168.0.*, device.scannex.com, 192.168.*”. Wildcards are “*” for anything, and “?” for

any single character.

Prior to v1.63.48 only the binary modes were available for SNMP trap storage.

Page 59

Page 64

Scannex ip.buffer User Manual

SNMP Query

The SNMP Query mechanism provides for a method of checking that the connected device is still alive and connected. This is particularly important where the ip.buffer is collecting traps from a device that sends traps only infrequently14.

Community

The SNMP community. This value is shared between all SNMP

activities. [public]

Addresses

“blank” = no devices are queried Enter a list of addresses in the form “address=name” or just

“address” to query. Keep multiple entries separated by a newline. e.g. “192.168.0.241=MainPBX” [blank]

Time

The time interval, in seconds, to query the address list. 0=don't

query. [600]

At the time interval the ip.buffer will transmit an SNMP GET-NEXT query to each of the devices listed in the Addresses field. It will request the sysDescr, sysUpTime, and sysName fields15.

If the “Packet” entry is set to “ASCII + CR/LF” then the response from the device will be decoded. Additionally, any devices named in the address list are given the name as any SNMP trap or SNMP reply is decoded:

Incoming trap from an ip.buffer:

192.168.0.235: Trap E:6024.1.3 192.168.0.235 enterpriseSpecific s=2 100 E:6024.1.3.1=00_02_ae_10_06_4c E:6024.1.3.2="Scannex"

Response from a query where a name is provided:

192.168.0.241="Epson Laser": GetResponse system.sysDescr.0="EPSON Built-in 10Base-T/100Base-TX Print Server" system.sysUpTime.0=267127311 system.sysName.0="EPSON Laser"

Response from a query where only an IP address is provided:

192.168.0.242: GetResponse system.sysDescr.0="HP ETHERNET MULTIENVIRONMENT,ROM none,JETDIRECT,JD128,EEPROM V.28.47,CIDATE 11/17/2004" system.sysUpTime.0=5738382 system.sysName.0="EPSON Laser"

The SNMP Query options only appear when the port is set to 162

The ip.buffer does not keep track of the individual responses. It merely issues the request and collects the reply. It is up to the collecting computer to decide what action to take based on the presence or absence of the reply messages.

The ip.buffer requests the next OID from 1.3.6.1.2.1.1.1, 1.3.6.1.2.1.1.3, 1.3.6.1.2.1.1.5

A [TAB] character starts each var-bind (e.g. before the E:6024... sequence). This delimiter can be adjusted with a custom setting.

Page 60

Page 65

Scannex ip.buffer User Manual

10.3.3. RADIUS Accounting Collection

Set the port to either 1646 (the legacy port) or 1813. The ip.buffer will then behave as a simple RADIUS accounting server. Incoming RADIUS accounting packets are authenticated against the secret, and valid packets are decoded into simple ASCII lines that can be easily processed.

Packets that do not match the ip.buffer's secret are silently discarded (according the RFC requirements).

RADIUS Accounting

Secret The private secret for the RADIUS packets17. [“secret”]

The packets are decoded as follows:

192.168.0.16: Acct #1=”User” #40=1

The originating IP address is first, followed by “Acct”. Then each RADIUS attribute within the packet is output. The attribute number is given, not the name, followed by “=” and the value. Most of the RADIUS attributes are known, and are decoded into string, integer, date/time, or IP address. Octet attributes, and unknown attributes, are decoded into an ASCII hex representation, e.g. #24=0x12345678abcdef0

Unlike a full PC-based RADIUS server, the ip.buffer has a single secret for all clients. PC-based servers have one secret per client or group of clients.

Page 61

Page 66

Scannex ip.buffer User Manual

10.4. FTP Server

The ip.buffer can collect data from devices that perform an FTP push into the buffer. e.g. Cisco Call Manager 5.

The files pushed into the ip.buffer are stored into the single storage area for the channel. You can choose whether to apply a marker around the file. This is especially useful in rebuilding the files at the central site (particularly if the memory wraps and you lose the beginning marker).

FTP Server

Username

The ip.buffer has a single FTP server for all activities (collection

and delivery) and so you need to enter a unique username to distinguish the activity.

Obviously, you will need the same username and password that is

programmed into the sending device.

[_channel1], [_channel2], etc

Password The password. [password]

Timeout

A timeout (in minutes) for the FTP client. If the client does not

send an FTP command within this time period the ip.buffer will disconnect the session – if the client “hangs”.

“0” = disable the timeout. [0]

File Markers

“None” – just stores the files as-is. “Use {ftp…}” – applies the {ftp} begin and end markers “Use {ftp…}+CRLF” – applies the {ftp} begin and end markers

on a separate line. [Use {ftp…}]

The File Markers are in the form:

{ftp begin,time,ip,file}

Where:

“time” is the date and time (local buffer time) in the form yyyymmddhhmmss. “ip” is the IP address of the FTP client “file” is the filename the client is about to push

The file’s data is then processed through the ip.buffer’s record detector (which can include further modification such as adding a date time prefix etc). At the end of the file transfer a suffix is appended to the memory store:

{ftp end,time,ip,file}

If the FTP client aborts the transfer for any reason, then the following suffix is appended instead:

{ftp failed, time,ip,file}

Page 62

Page 67

Scannex ip.buffer User Manual

10.4.1. FTP Server Notes

As each channel can be configured for any form of collection, it is possible to collect data from multiple FTP clients. It is necessary to make the username for each collection and delivery channel unique so the FTP server code can determine the activity that is allowed.

Each username is exclusive – in other words, when one FTP client has successfully logged in with a username any other clients that try to use the same username will receive a “Busy” error from the FTP server when they try and log in.

(Devices like the Cisco Call Manager 5 will connect to the FTP server in the ip.buffer and remain connected permanently.)

Only the “STOR” and “APPE” commands are supported for channels that are collecting by FTP. The “LIST” and “RETR” commands will result in an error code while logged in with that username.

10.5. None

The source setting “None” will disable the input channel completely. However, the storage for that channel can still be used. For example another channel may

split its data with a Lua script and store half of the data in this channel.

Page 63

Page 68

Scannex ip.buffer User Manual

10.6. Common Modules

Whether collecting from Serial, TCP, UDP, or FTP Server, each channel includes a “Protocol Handler”, “Pass-through” options, and “Notification” options.

10.6.1. Protocol

Not available with UDP sources.

The protocol core in the ip.buffer provides for a flexible way of handling almost any data source or source protocol. With the exception of the Avaya RSP the included protocols just detect and pre-process data ready for storage. The Avaya RSP requires a bi-directional communication between the ip.buffer and the PBX. Practically any protocol can be added through Lua script extensions.

Protocol

“Alcatel TCP/IP [port 2533]” – connects to the Alcatel

PBX.

“ASCII lines” – processes data as lines of text, separated by

carriage returns and/or line feeds. “Avaya RSP TCP/IP” – the Avaya Reliable Session Protocol “Binary (full 8-bit)” – stores data “as-is”. “Generic Records” – receives records and sends

acknowledgements for a wide variety of older devices. “Inter-Tel/Mitel Axxess & 5000 TCP/IP [port

4000]” – for Inter-Tel PBXs.

“iSDX binary” – only stores 22-byte iSDX frames that start with

0xEE 0xFF. “NEC NEAX (STX/ETX) Serial” – NEC NEAX2400 over serial. “NEC NEAX TCP/IP” – the NEC NEAX protocol over network. “Nortel BCM Live TCP/IP” – live CDR collection from “Live

Stream” enabled BCMs18. “Nortel Meridian & Norstar” – processes data as lines of

text. Detects Norstar CDR, Meridian CDR and alarm

records. “Panasonic KX-TD TCP/IP [port 2300]” – connect to the

Panasonic KX-TD over the network. “Philips FDCR TCP/IP [port 2599]” – connect to the

Philips Sopho iS3000 etc. [ASCII lines]

Only available in the SSL firmware!

Page 64

Page 69

Scannex ip.buffer User Manual

Time Stamp

Allows the setting of a time-stamp that is applied to each

record19. See section 10.6.15 [blank]

Match & Send

Heartbeat

If the Source is set to “TCP” and the protocol is a 'generic' one

(e.g. ASCII Lines, Binary, or Generic Records) then the

Match & Send and Heartbeat settings appear and can be

edited.

[Parameters]

Some protocols have parameters that can be modified. The

options appear beneath the Time Stamp. Note that

changing the protocol will reset the parameters to default

values.

The individual protocol will provide the following services:

• Record presentation into Lua. When using Lua scripting for checking or filtering

incoming records, the Protocol will send a complete record to Lua. Some devices send multiple lines of data (e.g. Nortel Norstar) which are best kept as a logical “Record”. This allows for simple “keep/trash” decisions on records, as well as activities such as time-stamping.

• Tagging of records. In some protocols, such as the Nortel protocol, the record is

tagged with its type. This allows for easier filtering/detection/splitting of individual data types (e.g. CDR, alarm)

• Storage of complete records in memory. The internal file system keeps track of

record boundaries. This enables the delivery mechanisms to send sets of complete records.

When you change the protocol on a channel, the source is disconnected. In addition, if Lua is rebooted, then all sources will be temporarily disconnected (because each channel is using Lua to run the protocol).

The time stamp option is disabled for all binary protocols (e.g. Binary and iSDX)

Page 65

Page 70

Scannex ip.buffer User Manual

10.6.2. Protocol: ASCII Lines

The ASCII line protocol reads in lines from the data source. The top bit of data (D7) is always stripped. The line handling mechanism inside the protocol engine uses the following method to detect line endings: a CR followed by any number of LF characters, or an LF character followed by any number of CR characters. It should handle all data formats – Unix, DOS, Mac etc.

If STX...ETX data is received by this protocol it will change the ETX to a CR20.

Protocol Parameters

XON

“None” – Send nothing to the source. “Send” – an XON character (0x11, DC1) is sent to the data source

every 30 seconds. [None]

Allow

“ASCII only” – strips the high bit from the incoming data and

removes all NULL characters (0x00) and control codes. “ASCII + codes” – strips the high bit from the incoming data

but keeps NULL characters (0x00) and control codes.

[ASCII only]

Line ending

“As received” – saves the CR/LF, LF, CR exactly as collected. “Force CR+LF” – change all line endings to CR/LF.

[As received]

Timeout

If there is no line ending (or more precisely the first character of

the next line has not been received), the timeout decides

when to “finalise” the data and assume that nothing more

is arriving from the source. The value is the time in

milliseconds21. [1000]

This is a new feature to firmware 2.70

The “FTP Server” source type will override this value. The timeout is handled directly by

detecting when the FTP STOR operation has been completed.

Page 66

Page 71

Scannex ip.buffer User Manual

10.6.3. Protocol: Alcatel TCP/IP [port 2533]

The Alcatel protocol connects to the PBX and receives CDR data on TCP/IP port 2533. You should program the ip.buffer in the following way:

• Source type = TCP

• Connect = “ipbuffer to Device (active/client)” (enforced)

• Address = IP address of the Alcatel PBX

• TCP Port = 2533 (enforced)

It is vital that only one client connects to the Alcatel at a time! The PBX does not enforce this, so if more clients try to connect they will succeed – but CDR records will not be delivered to all clients (and the one that receives most of the records may not get 100%). Scannex have an AppNote that details ways to check the number of connections to the Alcatel.

Page 67

Page 72

Scannex ip.buffer User Manual

10.6.4. Protocol: Avaya RSP TCP/IP

The Avaya Reliable Session Protocol enables the Avaya PBX to connect to the ip.buffer and deliver CDR data.

You should program the ip.buffer in the following way:

• Source type = TCP

• Connect = “Device to ipbuffer (passive/server)” (enforced)

• Allow = blank (or can be the IP address of the Avaya PBX)

• TCP Port = 9000 (this is the default Avaya port)

There are no Protocol Parameters for the Avaya RSP. Blocks of lines are sent from the Avaya to the ip.buffer, and when received, the ip.buffer acknowledges their receipt and feeds the individual lines through to storage.

Although the Avaya RSP was designed for transferring data across a WAN from the PBX we strongly suggest that you site the ip.buffer directly next to the PBX to minimise any downtime across the network.

The Avaya can send data either with the RSP or with a raw TCP socket23. If you are able, it is more efficient to use a raw TCP connection, and set the ip.buffer protocol to “ASCII lines”24.

A multi-port ip.buffer can collect from multiple Avaya PBXs (or indeed any other IP-enabled devices)

10.6.5. Protocol: Binary (full 8-bit)

The binary protocol will simply grab the incoming data and store it. The size of the chunks are arbitrary and can be up to 2048 bytes long.

There are no parameters, and there is no option for time-stamping binary data. All 8-bits of data are stored without any modification.

You can use another port, other than 9000. However, make sure that the ip.buffer port and Avaya port agree. Additionally, if collecting from multiple Avayas into an ip.4, make sure that each Avaya uses a different port number.

The “Reliable Protocol” can be set to either “Y” or “N” in the “change ip-services” section of the Avaya admin.

Scannex can provide further information on how the Avaya can be configured for raw TCP delivery.

Page 68

Page 73

Scannex ip.buffer User Manual

10.6.6. Protocol: Generic Records

This protocol provides an easy way to collect ASCII data from a wide variety of devices. It is subtly different to the “ASCII Lines” protocol in the following ways:

• It will always terminate the record with CR+LF sequence (adding one if needed)

• It will throw away any “runt” records – records that do not terminate in the

“Suffix” character string.

• It will only keep data between the Prefix and Suffix strings. All other data is

discarded.

Protocol Parameters

Allow

“ASCII only” – strips the high bit from the incoming data and

removes all NULL characters (0x00) and control codes25.

“ASCII + codes” – strips the high bit from the incoming data

but keeps NULL characters (0x00) and control codes.

[ASCII only]

Type

“Lua Pattern” – The Prefix and Suffix are both interpreted as

Lua string patterns. This allows for very complex record boundaries.

“String Literal” – Treats Prefix and Suffix as literal strings

(i.e. not Lua patterns).

[String Literal]

Prefix

The string or Lua pattern that denotes the beginning of a record

(if applicable). [blank]

Suffix

The string or Lua pattern that denotes the end of a record. If left

blank then the protocol will look for either CR or LF characters. [blank]

ACK

The string to send back to the device. Some devices require a

positive acknowledgement from the ip.buffer. The Source must be a bidirectional device to allow this (i.e. COM or TCP) [blank]

Timeout

If there is no line ending suffix received the timeout decides

when to throw away the partial data received. [1000]

If the extracted record contains CR and LF characters these will be stripped from the record as control characters. If you have a multi-line record then you should choose “ASCII + codes”

Page 69

Page 74

Scannex ip.buffer User Manual

This “Generic Records” protocol can handle, amongst others, the following PBXs:

PBX Name Type Prefix Suffix ACK Coral Isis String Literal % $ [blank] NEC NEAX serial

String Literal \x02 \x03 [blank]

Nitsuko

String Literal [blank] [blank] [blank]

Tenovis (Bosch/Telenorma)

String Literal \x02 \x03 \x06

The ip.buffer includes a specific NEC NEAX protocol handler. The NEC is shown here for completeness.

The Nitsuko outputs an LF as a line ending. The Generic Records protocol will detect this and effectively convert to CR+LF line ending.

Page 70

Page 75

Scannex ip.buffer User Manual

10.6.7. Protocol: Inter-Tel/Mitel Axxess & 5000 TCP/IP [port 4000]

This simple protocol is for connecting with TCP/IP to an Inter-Tel PBX or Mitel 5000 PBX (repackaged Inter-Tel 5000). It provides the necessary sign on process to get the CDR records out of the PBX28.

The Inter-Tel protocol allows for the connecting client to advertise an “application” name. The ip.buffer declares itself as “ip.buffer-00-02-ae-xx-xx-xx” (where xx-xx-xx is the serial number).

Protocol Parameters

Password

If the PBX requires a password, enter it here.

[blank]

Handling

“Plain ASCII (original)” – receives the incoming records

as ASCII. Lines may be prefixed with “Q” and “R” letters.

“Length+ASCII (correct)” – correctly handles the Inter-Tel

protocol and stores the correct text.

[Plain ASCII (original)]

Although you can use the Match/Send fields to do the same thing, this protocol provides a convenient way of connecting to the Inter-Tel.

Page 71

Page 76

Scannex ip.buffer User Manual

10.6.8. Protocol: iSDX binary

The “iSDX binary” protocol will wait for the initial 0xEE and 0xFF characters of the iSDX binary format and then collect the rest of the 22-byte frame.

All other data is discarded.

Protocol Parameters

Format

“Pure Binary” - Stores the data “as-is”. No time stamping is

performed.

“ASCII Hex” – converts the 22-byte binary data into human

readable ASCII hex with a CR/LF at the end. Time stamping is performed.

[Pure Binary]

10.6.9. Protocol: NEC (STX/ETX) Serial

This protocol is for the serial-connected NEC PBX where each chunk of data is enclosed in 0x02...0x03 binary characters. All other data is discarded29.

A CR+LF sequence is automatically appended to each frame that is received (because the NEC does not use CR/LF characters but the ETX character).

Data is tagged as “cdr nec”.

Protocol Parameters

Save As

“Text Lines” – removes the STX & ETX characters and saves

the CDR records as normal lines of text with a CR/LF.

“Raw (STX..ETX)” – keeps the NEC format with STX (0x02) and

ETX (0x03) characters30.

[Text Lines]

Characters

“ASCII only” – strips the high bit from the incoming data and

removes all control characters.

“ASCII + codes” – strips the high bit from the incoming data

but keeps control characters.

[ASCII only]

The NEC NEAX protocol can also be handled in the “Generic Records” protocol.

Be careful if using the Time Stamp feature with the Raw format – your software may not like the mix of text and NEC records!

Page 72

Page 77

Scannex ip.buffer User Manual

10.6.10. Protocol: NEC NEAX TCP/IP

The NEC NEAX TCP/IP protocol will connect to a variety of NEC PBXs (including IVS, IPS, IPX, SV8300, SV8500, and SV7000) and collect CDR data.

The NEC protocol includes options for Device ID and parity. The ip.buffer protocol uses techniques to automatically discover both the parity and Device ID so that installation should be simple!

By default the NEC is listening on TCP port 60010. Consequently you should program the ip.buffer in the following way:

• Source type = TCP

• Connect = “ipbuffer to Device (active/client)”

• Address = IP address of the NEC

• TCP Port = 60010 (this is the default NEAX port)

Protocol Parameters

Interval

The time interval, in seconds, to probe the NEC for new data32.

[5]

Save As

“Text Lines” – removes the STX & ETX characters and saves

the CDR records as normal lines of text with a CR/LF.

“Raw (STX..ETX)” – keeps the NEC format with STX (0x02) and

ETX (0x03) characters33.

[Text Lines]

If the NEC has been programmed to listen on another TCP port then you should enter the same port number in the ip.buffer.

You should use an interval less than 120 seconds. If the NEC hears nothing from the ip.buffer for two minutes then it will terminate the connection.

Be careful if using the Time Stamp feature with the Raw format – your software may not like the mix of text and NEC records!

Page 73

Page 78

Scannex ip.buffer User Manual

10.6.11. Protocol: Nortel BCM Live TCP/IP

The “Nortel BCM Live TCP/IP” connects to a suitable BCM34 and provides a real-time stream over an SSL-link. Because this protocol requires SSL, it does not show in the CryptoFree firmware that is shipped by default.

Protocol Parameters

Username The username for logging onto the BCM's CDR service. [blank]

Password The password for logging onto the BCM's CDR service. [blank]

The call-record and alarm data is processed and handled in the same way as the “Nortel Meridian & Norstar” protocol.

The BCM needs to support the “Live Stream” running on TCP/IP. The older BCM models supported only DCOM connection (which is not supported by the ip.buffer)

Page 74

Page 79

Scannex ip.buffer User Manual

10.6.12. Protocol: Nortel Meridian & Norstar

The “Nortel Meridian & Norstar” protocol is based on the “ASCII lines” protocol. However, it is also aware of the record formats of Meridian and Norstar.

Protocol Parameters

Allow

“ASCII only” – strips the high bit from the incoming data and

removes all NULL characters (0x00) and control codes.35

“ASCII + NULLs + codes” – strips the high bit from the

incoming data but keeps NULL characters (0x00) and control codes.

[ASCII only]

Timeout

If there is no line ending (or more precisely the first character of

the next line has not been received), the timeout decides when to “finalise” the data and assume that nothing more is arriving from the source. The value is the time in milliseconds37. [1000]

The high bit is stripped for ASCII data. The Nortel Meridian will often send data with D7 set38. The protocol automatically strips the bit so that only pure ASCII is stored.

The protocol detects in the following way:

8 dashes at the

beginning of a line

This denotes the start of a Norstar record. All lines up to the next

8 dashes are assembled together and stored as one “cdr norstar” tagged record.

uppercase letter +

space + number

This is taken as a Meridian CDR record. Any following lines that

begin with “Space + &” are assembled together and stored as one “cdr meridian” tagged record.

3 or 4 uppercase

letters + 3 numbers

+ space

This is taken as a Meridian alarm record. It is stored as an

“alarm meridian” tagged record.

All others Passed as a single line, tagged as “ascii”.

Except for TAB (0x09), CR (0x0d), and LF (0x0a)

For example, if you rely on the NULL 0x00 byte sent within the Nortel Meridian PBX, then you should set the “Nortel Merdiain & Norstar” (or “ASCII lines”) protocol parameter to “ASCII + NULLs + codes”. If your software is confused by the NULL, then use “ASCII only”. Note: Hyperterminal strips the NULLs anyway.

The “FTP Server” source type will override this value. The timeout is handled directly by detecting when the FTP STOR operation has been completed.

Urban legend says that the Meridian sends in 7-bit Mark parity. This is not the case. The Meridian sets D7 when it is talking to a computer, and clears the bit when it is talking to a human via a terminal. In all cases, the Meridian UART is set to 8-bit no parity, but the setting of D7 makes it appear like 7-bit mark. Nortel references can be provided.

Page 75

Page 80

Scannex ip.buffer User Manual

10.6.13. Protocol: Panasonic KX-TD TCP/IP [port 2300]

Connects to the Panasonic KX-TD series over TCP/IP. You should program the ip.buffer in the following way:

• Source type = TCP

• Connect = “ipbuffer to Device (active/client)”

• Address = IP address of the Panasonic

• TCP Port = 2300 (this is the TCP port the Panasonic listens on)

Protocol Parameters

Password

The password for needed for connecting to the Panasonic KX-TD.

[PCCSMDR]

10.6.14. Protocol: Philips FDCR TCP/IP [port 2599]

Connects to the Philips Sopho iS3000 etc over TCP/IP. You should program the ip.buffer in the following way:

• Source type = TCP

• Connect = “ipbuffer to Device (active/client)”

• Address = IP address of the Philips

• TCP Port = 2599 (this is the TCP port the Philips listens on)

Protocol Parameters

Format

“Binary” - saves the records in pure binary with a two byte

length prefix.

“ASCII Hex” – converts the 22-byte binary data into human

readable ASCII hex with a CR/LF at the end. Time stamping is performed.

“CSV Lines” - decodes the data into comma-separated ASCII

Lines.

“Fixed ASCII Lines (normal)” - decodes the data into

fixed column ASCII Lines. [Fixed ASCII Lines]

Page 76

Page 81

Scannex ip.buffer User Manual

10.6.15. Time Stamping

ASCII based protocols include a field for specifying a date-time format string to prefix every record when in ASCII mode. Any text can be inserted, along with the following special tokens:

Token Result Example

Abbreviated weekday name.

Thu

Full weekday name.

Thursday

Abbreviated month name.

Jan

Full month name.

January

Date and time.

Thu Aug 23 15:17:02 2007

Day of the month (01-31)

Hour using 24-hour format (00-23)

Hour using 12-hour format (1-12)

Day of the year 001-366

235

Month (01-12)

Minute (00-59)

‘am’ or ‘pm’

Second (00-59)

Week number, starting from the first Sunday (00-53)

Week number, starting from the first Monday (00-53)

Day of the week number. Sunday = 0

Time

15:17:02

Year as 2-digit decimal.

Year as 4-digit decimal.

2007

Literal “%” character

date

Date tag in the format “{d YYYYMMDD}”

{d 20070621}

time

Date and time tag in format “{t YYYYMMDDhhmmss}”

{t 20070621151702}

Line Feed / Newline character

Carriage Return character

Must appear on its own – “date”

Must appear on its own – “time”

Page 77

Page 82

Scannex ip.buffer User Manual

Token Result Example

Tab character

Literal “\” character

Backspace character

Hex characters, e.g. “\x01\x7e”

Examples:

Prefix Description Example Output

%m/%d %H:%M

Month, Day, Hour, Minute

06/23 15:21

%y-%m-%d

Year-Month-Day

07-06-23

[Date %y-%m-%d]

As above but with literals

[Date 07-06-23]

Only full records are prefixed. If you require every line to be stamped, then use the “ASCII line” protocol.

Page 78

Page 83

Scannex ip.buffer User Manual

10.6.16. Extra tokens for delivery filenames

The following extra codes are available within filenames for push delivery operations (the standard codes in section 10.6.15 are also allowed):

Token Result Example

Date in the form, YYYYMMDD

20120618

Time in the 24hr form HHMMSS

152723

Eight digit hexadecimal delivery sequence number

00012adf

%nQ

Decimal sequence number with 'n' digits, where n is between 1 and 9 e.g. '%6Q' will output a 6 digit

015632

Page 79

Page 84

Scannex ip.buffer User Manual

10.6.17. Pass-through

The pass-through connection is limited to read-only when collecting from UDP or FTP..

TCP Port

The TCP/IP port that will listen for an incoming connection for

passthrough.

0 = disable passthrough. [0]

Interface

“LAN only” – dial-in PPP connections are blocked “Modem only” – Ethernet connections are blocked “LAN or Modem” – either PPP or Ethernet can be used

[LAN only]

Allow

“blank” will allow any client to connect to the ip.buffer for

passthrough on this channel.

Enter a name, IP address or wildcarded IP address to restrict

inbound access to only that LAN address41. You can also enter a list of addresses. [blank]

TLS/SSL

“No encryption” – a plain TCP/IP session “Implicit (by port)” – starts with an SSL/TLS connection. A

client that connects with plain TCP/IP will time out and be disconnected. [No encryption]

Client Type

“Auto” – if the client software negotiates Telnet options then we

send back further Telnet options.

“Telnet” – The ip.buffer sends Telnet options when the client

connects. This is necessary when a Linux telnet command is used to connect to a non-standard port.

“Raw TCP/IP” – No Telnet options. Every byte is transferred

without modification between source and pass-through.

[Auto]

Prompt

The prompt message for when a password is required42.

[Password:]

Password

A simple password string. When the client connects to the

passthrough TCP/IP socket they will be asked for the password43.

When a successful password is entered, the ip.buffer will send

back “OK” (CR/LF) to the client.

“blank” = no password checking [password]

Success

The string to send when the password is successfully entered.

[OK\r\n]

When dialling in with a modem the “Allow” address is ignored.

If you want to always send the prompt, even if the password entry is blank, then prefix the string with an exclamation mark “!”.

Only a single CR is required to finalise the password entry. If the client sends CR + LF, then the single LF will be consumed (ignored).

Page 80

Page 85

Scannex ip.buffer User Manual

Mode

“Not Stored” – When connected, the pass-through has

exclusive access to the source port. Nothing received from the source is stored.

“Stored” – When connected, the pass-through can read and

write to the source port (and the channel's protocol is prevented from writing to the source port). All data from the source is passed through to the protocol section for storage.

“Monitor” – the pass-through is read-only. Additionally the pass-

through socket can be connected even when the source is not connected.

“Debug” – The pass-through is read-only and presents debugging

information in a packetised format (for use with a PC application to show the data between source and protocol).

[Not stored]

While connected, a double arrow ⇔ will appear after the source name in the web status page. (e.g. “COM1 ⇔”)

Your browser needs to have a suitable Unicode font installed to show the double arrow. If no suitable font exists you will probably see a small square box: □

Page 81

Page 86

Scannex ip.buffer User Manual

Pass-through Mode Diagrams

The pass-through socket is not connected. The protocol has full read/write access to the source. Data that is received on the source is processed and stored normally.

When connected, the pass-through socket has full access to the source. Since the protocol does not “see” any received data from the source, nothing is processed and stored while the pass-through socket is connected45.

When connected, the pass-through socket has full access to the source. The protocol and storage will still store all data arriving at the source, even when the pass-through socket is connected46.

When connected, the pass-through socket will show all data arriving at the source. However, the pass-through socket cannot write any data to the source. The protocol, and storage, has full access to the source47.

“Debug” mode is similar to “Monitor” except that encoded data, and event information, is sent to the pass-through socket. The pass-through socket still cannot write data to the source.

Protocols that are bidirectional packet based, like the Avaya RSP, will prohibit this mode.

For non-bidirectional sources, like FTP Server and UDP, this is the only available mode.

Page 82

Pass-through not connected

Source Protocol

Passthru

“Not Stored”

Source Protocol

Passthru

“Stored”

Source Protocol

Passthru

“Monitor”

Source Protocol

Passthru

Page 87

Scannex ip.buffer User Manual

10.6.18. Notification

Each channel can send an alert (either by email or HTTP POST). There are two options for each channel’s data source:

Quiet

The number of minutes of quiet48 before sending an alert. When

the passthrough is connected (section 10.6.17), the ip.buffer will not “see” any data to stop the quiet alert.

“0” will disable the notification. [0]

Connects

“Ignore” – do nothing “Notify” – send an alert when the channel connects49 and

disconnects. [Ignore]

Once a channel has become quiet, the alert system will send regular quiet alerts at that interval. The alert system has a schedule to decide when to send these quiet alerts. See section 8.2.7

In the case of a TCP source that includes “Match/Send” fields, the channel is considered connected when the Match/Send process completes successfully. See section 10.2

Page 83

Page 88

Scannex ip.buffer User Manual

11 . D e s t i n a t i o n s

There are also common options for each destination type that are detailed in section 11.10

11.1. Email push (SMTP client)

The email client in the ip.buffer will send channel data directly to an SMTP server. You can choose to send the data in compressed, and/or encrypted form, and decide on the filename and extension.

The emails themselves are split into three parts:

1. Body. This includes basic information, in HTML format, about the ip.buffer.

2. Status attachment, “status.lua”. This is the complete Lua variable tree for the status. This contains detailed information about the status for every channel and the ip.buffer itself1.

3. Data attachment. The actual filename and format is decided by the setup.

email to

The address(es) of recipients. You can separate multiple email

address with a semicolon. e.g. “datacentre@scannex.co.uk;backup@scannex.com”

[blank]

Filename

The filename for the data file. Special tags are allowed – see

sections 10.6.16 and 10.6.15

[channel1.dat], [channel2.dat], etc

Compression

“none” – send the data “as-is” “zlib deflate” – compress with zlib deflate. The file suffix

“.zlib” will be added to the data filename. If the file is encrypted it must be decrypted before being decompressed. [none]

Server

Choose which SMTP server to send the data via. Use the “show” links to edit the global SMTP server settings. See

section 8.2.6 for server settings and data limits. [SMTP #1]

The internal Lua variable tree also includes other non-sensitive information.

Page 84

Page 89

Scannex ip.buffer User Manual

11.2. HTTP POST to Cloud Server

The ip.buffer can push data to the Cloud Server (running Scannex's server-side script).

Filename

The filename for the data file. Special tags are allowed – see

sections 10.6.16 and 10.6.15

[channel1.dat], [channel2.dat], etc

The Cloud Server does require a filename since it can override anything set in the buffer. Decisions for server-side file destination SHOULD be taken from ip.buffer Device Name, Channel Name, or Serial Number.

See section 8.2.13 for the Cloud Server settings.

Page 85

Page 90

Scannex ip.buffer User Manual

11.3. FTP Server

Username

The FTP server separates each channel with a different

username. When the FTP client software connects to the ip.buffer it will see only this channel’s file in the directory. [Channel1], [Channel2], etc

Password The associated password2. [password]

Filename The filename for the channel. [channel1.dat], [channel2.dat], etc

Compression

“none” – send the data “as-is”, uncompressed3. “zlib deflate” – compress with zlib deflate. The file suffix

“.zlib” will be added to the data filename. [none]

Limit

Sets the maximum amount of data that will be transferred in one

session. When the limit is reached the ip.buffer will stop at the next whole record in the storage. [0]

Autodelete

“No” – the client must delete the data. “Delete after download” – as soon as the ip.buffer sees that

the file has been successfully downloaded it will erase the stored data. [No]

Even if data is collected while logged into the FTP server, that data is not immediately visible to the FTP client, and the client cannot delete that new data. Issuing a “LIST” command (aka DIR) will “refreeze” the new data and make it visible.

Only one FTP client is supported per channel. In other words, all channels can connect at the same time, but two clients cannot connect into one channel – the FTP server will tell the second client that it is busy.

(The same applies for channels that are configured to collect by FTP server. Each channel can be used by only one FTP client device at a time.)

Both username and password are case sensitive!

If the channel is programmed to provide the file uncompressed, the FTP client can decide whether to retrieve an uncompressed or compressed version. By requesting the filename with “.zlib” it will obtain a compressed version. See www.zlib.net for more details on the zlib deflate method.

Page 86

Page 91

Scannex ip.buffer User Manual

11.3.1. Supported FTP server commands

The following commands are the native commands that are sent between the FTP client and server. The Windows command line tool FTP uses different commands for the user. e.g. the user types “DIR”, but the FTP command line tool actually sends “LIST” to the server.

USER selects the username4. The usernames are case sensitive. PASS send the password for the username. Incorrect usernames and/or passwords will

generate an email authentication alert (if enabled).

LIST obtain a directory listing. This will show the file and its uncompressed file size.

Each time the directory listing is retrieved, the channel is “frozen”. The correct action for a client is: connect, USER, PASS, LIST6, RETR, DELE, QUIT.

RETR Retrieve the file. Normally you RETR the filename that appeared in the LIST

command. However, you can choose to download a zlib compressed version by appending “.zlib” to the filename. All other extensions are ignored.

STOR This command is only available for channels that are configured to collect from FTP

server. The RETR, LIST, and DELE commands are not possible when logged into a username that is designated for collection.

APPE See STOR above for restrictions. The FTP tag will show a “+” before the filename. DELE Delete the data. If the FTP client has not issued a RETR, then this command will

delete all data that was frozen (i.e. not new data that has been stored since logging in). If the FTP client has issued a RETR, then this command will only delete what has been transferred to the client.

PORT tells the server where to connect to send the data or directory. PASV asks the server to open a listening socket so the client can connect to get the data

or directory.

LIMIT This is a non-standard command that allows the client to set a limit for the transfer

of data. This is particularly useful when downloading large files across a modem link, you can decide to download in 1Mbyte chunks. Provide the number of Kbytes to limit by, e.g. “LIMIT 1024”.

QUIT Close the FTP connection. HELP Obtain help – the list of supported commands.

This is the channel name (as mentioned in section 9)

The username and password supplied are case sensitive.

The LIST command is optional. The act of completing a login will automatically “freeze” the channel’s storage file.

In the standard FTP command line software in Windows, you can type “QUOTE LIMIT 1024” to send the command directly to the ip.buffer.

Page 87

Page 92

Scannex ip.buffer User Manual

11.4. FTP Push (client)

The ip.buffer can initiate an FTP transfer into a central FTP server. All FTP transfers require two sockets – one for the command socket, and one for the data. The FTP transfer in the FTP push delivery method uses the secure passive transfer for data8.

Interface

“LAN only” – will connect only using Ethernet “Modem only” – will always use PPP “LAN then Modem” – will try to use Ethernet. If that fails it will

try PPP

“Modem then LAN” – will try to use PPP and if that fails it will

try Ethernet.

Note: For the Modem dial-out setup see section 8.2.5

[LAN only]

Address

The IP address or name for the FTP server that the ip.buffer will

connect to.

[blank]

TCP Port The TCP/IP port to start communicating with the FTP server. [21]

Security

“FTP no encryption [port 21]” – a plain FTP session “FTPS/TLS explicit (by command) [port 21]” – starts

with a plain connection and then upgrades to SSL/TLS. If the server does not support SSL/TLS then the delivery will fail. Data transfers will be SSL/TLS as well.

“FTPS/TLS implicit (by port) [port 990]” – starts with

an SSL/TLS connection. Data transfers will be SSL/TLS as well.

“SFTP/SSH [port 22]” – connects using the SSHv2 protocol

with SFTP file transfer. [No encryption]

Username The username to log in. [username]

Password The password to log in10. [password]

Scannex ip.buffer User Manual

Specifications and Main Features

Frequently Asked Questions

User Manual