Appendix A - Supported video modes ..........................................................12
Appendix B - Conguration pages .................................................................13
Appendix C - Dimensions ................................................................................20
Appendix D - Tips for success when networking ALIF units ...................21
Appendix E - Troubleshooting .........................................................................23
Appendix F - Glossary ......................................................................................25
Appendix G - Open source licenses ..............................................................28
Index
INSTALLATION
CONFIGURATIONOPERATION
FURTHER
INDEX
1
INFORMATION
Page 3
Introduction
WELCOME
Thank you for choosing the ADDERLink™ INFINITY (aka ALIF) family of high capacity
digital extenders/switches. By encoding high quality video, digital audio and USB data into
Internet Protocol (IP) messages, ALIF units offer exible ways to link peripherals and
systems via standard networks.
This guide covers the ALIF101T-DVI unit, a highly compact dongle which can be attached
to its host computer and transfer high quality DVI video and USB signals across your
network.
One-to-one conguration
The simplest conguration links one RX unit to a single TX unit, either by a direct link or over much
greater distances via a high speed network.
ALIF101T
One-to-many conguration
Using multicast techniques, an unlimited number
of receivers* can receive video and audio data
streams from a single TX unit.
ALIF RX
ALIF RX
ALIF and AIM
Where multiple ALIF units are used on a network, we have developed the
ADDERLink INFINITY Management (AIM) server to allow comprehensive and secure
central control of all transmitters, receivers and users.
™
ALinkDDER
When using an AIM server to congure ALIF units, it is vital that all ALIF units that
you wish to locate and control are set to their factory default settings. Otherwise
they will not be located by the AIM server. If necessary, perform a factory reset on
each ALIF unit.
Note: If you are using one or more ALIF101T transmitters within an installation managed by
an AIM server, the AIM server must be running rmware version 4.12 or above.
Please also see Appendix D - Tips for success when networking ALIF units
M ANAGER
1
2
INSTALLATION
CONFIGURATIONOPERATION
ALIF101T
* A maximum of thirteen concurrent USB inputs (via
multiple RX units) are permitted to a single TX unit.
Installation involves linking the ALIF101T unit to various ports on the
host computer, while the ALIF RX unit is attached to your peripherals:
Cable tie
mounting slot
Status
indicators
(page 10)
‘Suitable for installation in Information Technology
Rooms in accordance with Article 645 of the
National Electrical Code and NFPA 75.
Peut être installé dans des salles de matériel de
traitement de l’information conformément à l’article
645 du National Electrical Code et à la NFPA 75.’
INSTALLATIONCONFIGURATIONOPERATION
DVI-D input
connector
(page 5)
Black USB plug provides Hi-Speed USB
signals (plus power if the external power
adapter is not present)
Reset
button
(page 7)
Red USB plug provides
power only when the
external power adapter is
not present
(page 6)
Ethernet
port
(page 5)
Optional
external power
input
(page 6)
FURTHER
INFORMATION
INDEX
4
Page 6
Video link
The ALIF101T unit is supplied with a DVI-D (single link) video connector. Video signals
at pixel clocks up to 165MHz (equivalent to a maximum resolution of 1920 x 1200 at
60Hz) are permissible.
To make a video link
1 Connect the ALIF101T video connector to the DVI-D socket of the host computer:
Host
computer
DVI-D video
port
Network link
ALIF transmitters and receivers can either be connected directly to each other or via a
high speed network.
A single Gigabit Ethernet port is located on the front panel. For direct links via Ethernet
cable, the length of cable should not exceed 100 metres (328 feet). Network cables
used for connections may be category 5, 5e, 6 or 7 twisted-pair cable. The ALIF101T
unit has an auto-sensing capability on its network interfaces, so for direct point-to-point
connections, no ‘crossover’ Ethernet cable is required.
To link the ALIF101T unit
1 Connect a CAT 5, 5e, 6, or 7 cable to the Gigabit Ethernet socket on the front panel
of the ALIF101T unit.
CAT 5, 5e, 6, or 7 link
either directly from
the other ALIF unit
or from a Gigabit
Ethernet switch
INSTALLATIONCONFIGURATIONOPERATION
2 Connect the other end of the cable either directly to an ALIF receiver or to a Gigabit
Ethernet switch, as appropriate.
3 [For connections via a network] repeat steps 1 and 2 for the other ALIF unit(s).
Please see Appendix D for important tips about networking ALIF units.
FURTHER
INFORMATION
INDEX
5
Page 7
USB and power connections
The ALIF101T unit is designed to be as exible as possible. It can either operate using
an optional external power adapter (see page 3) or derive all of its power from its
two USB plugs. The main advantage offered by using an external power adapter is that it
allows the ALIF101T unit to be active before the host computer; thus allowing a remote
user to access the host’s initial boot up and access the BIOS menu, when required.
If powered by USB only, then both the black and red USB plugs need to be connected.
If powered by external power adapter, only the black Hi-Speed USB plug needs to be
connected, for signal purposes. Whenever, the external power adapter is attached and
operating, then power will be taken from it rather than the USB plugs. There is no
problem if the red USB plug remains connected while the power adapter is used.
This is summarized as follows:
Power Black Red
adapter USB USB Power sourcing behavior
Black USB plug provides
USB signals (plus power if
the external power adapter
is not present)
Host computer
USB ports
INSTALLATIONCONFIGURATIONOPERATION
ûüüPower taken from both USB plugs.üüûPower taken from power adapter only.üüüPower taken from power adapter only, unless it becomes
unavailable, in which case power will be taken from both
USB plugs after a short interruption.
Note: The USB plugs do not operate as a seamless failover for the external power adapter; there
will be a short interruption as operation switches from one power source to the other.
Support for audio
The ALIF101T can derive its (digital) audio feed from the USB connection. The digital
audio is converted to analog as it is transferred to the receiver(s), where it is output via
their 3.5mm jack(s). The audio source is controlled from the System Conguration page
of the internal utility (see page 14) as follows:
• When the Enable Audio-1 option is checked, the ALIF101T arranges a bi-directional
audio stream with the host computer via the USB connection.
• The Enable Audio-2 option has no effect on the DVI variant.
Red USB plug provides
power only when the
external power adapter is
not present
FURTHER
INFORMATION
From the optional
external power
adapter
INDEX
6
Page 8
Conguration
INITIAL CONFIGURATION
ALIF units are designed to be as exible as possible and this principle extends also to
their conguration.
Direct linking
Where ALIF transmitters and receivers are directly linked to each other, very little
conguration action is required, provided that they have their factory default settings in
place. If the standard settings have been changed in a previous installation, you merely
need to perform a factory reset on each unit.
Networked linking
Where ALIF units are connected via networked links, you can either congure them
individually, or congure them collectively using an AIM server:
• Conguring networked ALIF units individually - You need to specify the
network addresses of the ALIF units so that they can locate each other. This is done by
running the ADDERLink INFINITY browser-based conguration utility on a computer
system linked to the same network as the ALIF units.
• Conguring ALIF units collectively - The ADDERLink INFINITY Management
(AIM) server allows you to congure, control and coordinate any number of ALIF
transmitters and receivers from a single application.
Note: If you are using one or more ALIF101T transmitters within an installation managed by
an AIM server, the AIM server must be running rmware version 4.12 or above.
IMPORTANT: When using AIM to congure ALIF units, it is vital that all units that you
wish to locate and control are set to their factory default settings. Otherwise they
will not be located by the AIM server. If necessary, perform a factory reset on each
ALIF unit.
Please also see Appendix D - Tips for success when networking ALIF units
Manual factory reset
A factory reset returns ALIF101T unit to its default conguration. You can perform
factory resets using the ADDERLink INFINITY browser-based conguration utility or
by using this direct manual method.
To perform a manual factory reset
1 Power on the ALIF101T unit.
2 Use a narrow implement (e.g. a straightened-out paper clip) to press-and-hold
the recessed reset button on the front panel for roughly fteen seconds, until the
indicators turn blue(Note: alternating red/green indications will occur during the fteen second period while the button is still pressed).
Use a straightened-out paper
clip to press the reset button
for roughly 5 seconds
3 Release the reset switch.
The indicators will remain blue for a short while (less than ten seconds) while
ALIF101T unit congures itself and should then change to green if all connections
are correct; or orange if one or more of the video, USB and/or network links are
missing.
NOTE: If you are performing a factory reset and intend to disconnect the power
immediately after the reset, you must wait at least 30 seconds after you have released the
reset button for it to complete the process.
The browser-based conguration utility within all TX and RX units requires a network
connection between the ALIF101T unit and a computer on the same network. The
conguration utility allows you to perform many important functions. Please see
Appendix B.
To connect a computer to access the conguration utility
1 Connect a CAT 5, 5e, 6, or 7 link cable to the network port on the front panel.
The port automatically congures itself, so no cross-over cable is required (but is
supported if you do use one).
To access the browser-based conguration utility
1 Temporarily connect the ALIF101T unit and your computer, as discussed left.
2 Run a web browser on your computer and enter the IP address of the ALIF101T unit:
169.254.1.33
Note: If the IP address of ALIF101T unit has been changed and is not known, providing it is
appropriate to do so, perform a manual factory reset to restore the default address.
The opening page of the ALIF conguration utility should be displayed:
INSTALLATIONCONFIGURATIONOPERATION
Temporary link
from your computer
to the ALIF101T
network port
2 Connect the other end of the link cable directly to the network port of your
computer.
Use the menu options to choose
the required conguration page
You can nd further information about the conguration pages later in this guide:
• Appendix B - Conguration pages
FURTHER
INFORMATION
INDEX
8
Page 10
RESTORING A BACKUP FIRMWARE IMAGE
The ALIF101T unit retains a backup image of the previous rmware version in order to
provide a fallback in case of any issues with the primary image. The backup image has no
video or USB functionality; once invoked, you will need to load an upgrade le using the
web interface or via an ADDERLink INFINITY Manager (AIM) to load a new primary
image - see Performing an upgrade (shown right).
To restore the backup rmware image
1 Power on the ALIF101T unit.
2 Use a narrow implement (e.g. a straightened-out paper clip) to press-and-hold the
recessed reset button for roughly ten seconds until the indicators ash green/red.
Use a straightened-out paper
clip to press the reset button
for roughly 10 seconds
3 Release the reset switch.
The ALIF101T unit will switch to the backup rmware image. Once complete,
ALIF101T unit will then continually ash green/red.
4 Perform an upgrade to reinstate a fresh primary rmware image - see right.
PERFORMING AN UPGRADE
ALIF101T units are ash upgradeable using the method outlined here. However, for
larger installations we recommend that you use the ADDERLink INFINITY Manager
(AIM) to upgrade multiple ALIF units. When using the method below, the ALIF101T unit
will be upgraded in sequence.
IMPORTANT: Upgrades must be performed equally on transmitters and
receivers at the same time. Mixed rmware operation is not supported.
WARNING: During the upgrade process, ensure that power is not
interrupted as this may leave ALIF101T unit in an inoperable state.
If the upgrade process is interrupted and fails, it may be necessary to switch to the
backup rmware image in order to regain operation. See left for details.
To upgrade a single ALIF101T unit via the network link
1 Download the latest upgrade le from the Adder Technology website.
Note: Upgrade les containing “txd” are required for DVI variants.
2 Temporarily connect the ALIF101T unit and a computer via a network (see
ADDERLink INFINITY browser-based conguration utility section for details).
3 Run a web browser on your computer and enter the IP address of the ALIF101T unit
to be upgraded.
4 Click the Firmware Upgrade link. Within the Firmware Upgrade page, click the Choose
File button. In the subsequent le dialog, locate the downloaded upgrade le - check
that the le is correct for ALIF101T unit being upgraded. The le contains main and
backup images, you can choose to upgrade either the Main or the Backup.
5 Click the Upgrade Now button. A progress bar will be displayed (however, if your
screen is connected to ALIF101T unit being upgraded then video may be interrupted)
and the status indicators on ALIF101T unit will ash while the upgrade is in progress.
6 The indicators should stop ashing in less than one minute, after which ALIF101T unit
will automatically reboot itself. The upgrade process is complete.
INSTALLATIONCONFIGURATIONOPERATION
Finding the latest upgrade les
Firmware les for the ALIF101T units are available from the Support > Product
Downloads section of the Adder Technology website (www.adder.com).
Note: It is possible to downgrade the ADDERLink INFINITY rmware. After installing the
older rmware, perform a factory reset on each ADDERLink INFINITY in order to clear
the conguration le.
FURTHER
INFORMATION
INDEX
9
Page 11
Operation
In operation, many ALIF installations require no intervention once congured. The TX and
RX units take care of all connection control behind the scenes so that you can continue
to work unhindered.
STATUS INDICATORS
The two top panel indicators on the ALIF101T unit provide a useful guide to operation:
Main status indicators
Network specic
indicators
Main status indicators
• Off No power
• Green Operating - Video, USB and network link all present
• Orange Operating - But video, USB and/or network link missing.
• Red (momentarily) Unit is booting up, or
(consistently) Unit has failed, try rebooting.
• Red/green ashing Unit is in backup mode.
• Blue Factory reset has been activated.
• Red/blue ashing Unit is in upgrade mode.
• Fast green ash Unit is in identify mode (see page 14).
Network specic indicators
• Orange Off: No link On: Link established
• Green Off: No link Flashing: Network activity On: Quiescent link
RESETTING
The recessed reset button provides a way to take control of the ALIF101T if normal
operation is affected. You will need a thin implement, such as a straightened out paper
clip to press and hold the button. Depending on when you release the button, one of
three functions will occur:
Required function Release time Indicators
To reboot to the primary rmware version less than 10s red
To boot to the backup rmware version* 10 to 14s green/red ash
To restore factory settings and reboot more than 15s blue
* The backup rmware version has no video or USB functionality. Once invoked, you will need
to load an upgrade le to restore normal operation - see page 9.
To reset the ALIF101T
1 Power on the ALIF101T unit.
2 Use a narrow implement (e.g. a straightened-out paper clip) to press-and-hold the
recessed reset button. The status indicators will immediately turn red:
Use a straightened-out paper
clip to press the reset button
for roughly 10 seconds
3 Release the reset switch at the appropriate time (see the table above).
NOTE: If you are performing a factory reset and intend to disconnect the
power immediately after the reset, you must wait at least 30 seconds after
you have released the reset button for it to complete the process.
INSTALLATIONCONFIGURATIONOPERATION
FURTHER
INFORMATION
INDEX
10
Page 12
Further information
This chapter contains a variety of information, including the following:
• Getting assistance - see right
• Appendix A - Supported video modes
• Appendix B - Conguration pages
• Appendix C - Dimensions
• Appendix D - Tips for success when networking ALIF units
• Appendix E - Troubleshooting
• Appendix F - Glossary
• Appendix G - Open source licenses
GETTING ASSISTANCE
If you are still experiencing problems after checking the information contained within this
guide, then please refer to the Support section of our website:
www.adder.com
INSTALLATIONCONFIGURATIONOPERATION
FURTHER
11
INFORMATION
INDEX
Page 13
APPENDIX A - Supported video modes
The following video modes are supported and can be automatically congured by the
ALIF101T. If a recognized video mode cannot be found, contact Technical Support for
help.
cvt reduced 640 x 480 @ 60Hz
vesa 640 x 480 @ 60Hz
vesa 640 x 480 @ 72Hz
vesa 640 x 480 @ 75Hz
ibm 640 x 480 @ 75Hz
cvt reduced 800 x 600 @ 60Hz
vesa 800 x 600 @ 56Hz
vesa 800 x 600 @ 60Hz
vesa 800 x 600 @ 72Hz
vesa 800 x 600 @ 75Hz
cvt 1024 x 600 @ 60Hz
cvt reduced 1024 x 600 @ 60Hz
cvt reduced 1024 x 768 @ 60Hz
vesa 1024 x 768 @ 60Hz
vesa 1024 x 768 @ 70Hz
ibm 1024 x 768 @ 70Hz
vesa 1024 x 768 @ 75Hz
ibm 1024 x 768 @ 75Hz
cvt reduced 1152 x 864 @ 60Hz
vesa 1152 x 864 @ 70Hz
vesa 1152 x 864 @ 75Hz
cvt 1280 x 720 @ 60Hz
vesa 1280 x 720 @ 60Hz
vesa 1280 x 768 @ 60Hz
vesa reduced 1280 x 786 @ 60Hz
vesa 1280 x 786 @ 75Hz
vesa 1280 x 786 @ 85Hz
vesa 1280 x 800 @ 60Hz
cvt reduced 1280 x 960 @ 60Hz
vesa 1280 x 960 @ 60Hz
cvt reduced 1280 x 1024 @ 60Hz
vesa 1280 x 1024 @ 60Hz
ibm 1280 x 1024 @ 67Hz
vesa 1280 x 1024 @ 75Hz
cvt reduced 1360 x 768 @ 60Hz
vesa 1360 x 768 @ 60Hz
vesa 1366 x 768 @ 60Hz
vesa reduced 1366 x 768 @ 60Hz
vesa 1400 x 1050 @ 60Hz
vesa reduced 1400 x 1050 @ 60Hz
cvt reduced 1600 x 900 @ 60Hz
vesa reduced 1600 x 900 @ 60Hz
cvt reduced 1600 x 1200 @ 60Hz
vesa 1600 x 1200 @ 60Hz
vesa 1680 x 1050 @ 60Hz
vesa reduced 1680 x 1050 @ 60Hz
cvt reduced 1920 x 1080 @ 50Hz
cvt 1920 x 1080 @ 50Hz
vesa 1920 x 1080 @ 60Hz
vesa reduced 1920 x 1200 @ 60Hz
sun 1024 x 768 @ 77Hz
sun 1152 x 900 @ 66Hz
sun 1152 x 900 @ 76Hz
sun 1024 x 1024 @ 61Hz
sun 1280 x 1024 @ 67Hz
sun 1280 x 1024 @ 76Hz
INSTALLATIONCONFIGURATIONOPERATION
FURTHER
INFORMATION
12
INDEX
Page 14
APPENDIX B - Conguration pages
This section covers the browser-based conguration utility for the ALIF101T unit. The
pages are titled as follows:
• System Conguration • System Messages
• Video Conguration • Statistics
• Analogue Video Conguration • Firmware Upgrade
• USB Settings • Reboot
• Security • About
• AIM Manager
INSTALLATIONCONFIGURATIONOPERATION
FURTHER
13
INFORMATION
INDEX
Page 15
System Conguration
Unit Name
Name details that you can alter to distinguish this unit from all others. The name entered here will be read by
AIM units (if used) for administration purposes.
Unit Description
Allows you to optionally add a description of the unit, such as its location. Useful when many ALIF units are being used.
System port
This section determines the IP Address, Netmask and Gateway details for the Gigabit Ethernet port located on
the front panel. The default IP address is 169.254.1.33 which is the zero cong IP address that allows ALIF101T
unit to work immediately in point-to-point mode. You are recommended to change this to an appropriate
address in the private IP range 192.168.xxx.xxx
The default netmask is 255.255.0.0. If you change the IP address to the private range, you are recommended to
change this to 255.255.255.0 The default gateway address is 0.0.0.0
Force Multicast
By default, the ALIF101T unit will use unicast transmission when only a single RX is connected. This would then
be upgraded to multicast when one or more other RX units are added. By ticking this option, the ALIF101T
unit will always use multicast. This option should be ticked for most installations as it provides the most efcient
way to deliver video and audio to multiple destinations.
Enable options
These checkboxes allow you to determine which peripheral options will be used: Video, digital audio and USB.
• When the Enable Audio-1 option is checked, the ALIF101T arranges a bi-directional audio stream with the host
computer via the USB connection.
• When the Enable Audio-2 option is checked (affects DisplayPort and HDMI models only), the EDID denition
of the DisplayPort or HDMI connection will be altered to permit a uni-directional audio stream via the video
output. This allows the use of embedded audio, even when the video display itself does not support audio.
Note: It is possible for both options to be enabled at the same time without issue.
Identify unit
When clicked, these buttons cause the top indicators to ash to assist with identifying the ALIF101T unit within
a rack.
• The Identify Unit (short) button ashes the indicators for ve seconds.
• The Identify Unit (long) button ashes the indicators for one hour but can be overridden by clicking the
Identify Unit (short) button.
Target Multicast Conguration
This option allows you to congure an IP address to which this transmitter can send multicast video and audio
data, and from which multiple receivers can tap into it.
Note: The multicast addresses for each service endpoint must be unique across the whole ALIF installation.
Update Now
Click to save and implement your changes.
Thumbnail
The Thumbnail shows snap shots of the video feeds that are connected and reports the video resolutions/color
depths that have been detected. Click the Refresh Thumbnail button to update. Note: For security reasons the
thumbnail image is not displayed when the ALIF101T unit is under AIM control.
To get here
1 Connect your computer to the network port on the front panel.
2 Run a web browser and enter the IP address of the unit. If the address is
unknown, perform a manual factory reset to http://169.254.1.33
3 If necessary, click the System Conguration link.
INSTALLATIONCONFIGURATIONOPERATION
FURTHER
INFORMATION
INDEX
14
Page 16
Video Conguration
To get here
1 Connect your computer to the network port on the front panel.
2 Run a web browser and enter the IP address of the unit. If the address is
unknown, perform a manual factory reset to http://169.254.1.33
3 Click the Video Conguration link.
Peak bandwidth limiter percentage
The ALIF101T unit will employ a ‘best effort’ strategy in sending video and other data over the IP network.
This means it will use as much of the available network bandwidth as necessary to achieve optimal data quality,
although typically the ALIF101T unit will use considerably less than the maximum available. In order to prevent
the ALIF101T unit from ‘hogging’ too much of the network capacity, you can reduce this setting to place a
tighter limit on the maximum bandwidth permissible to the ALIF101T unit. Range: 0 to 95%.
Background Refresh
The ALIF101T unit sends portions of the video image only when they change. In order to give the best user
experience, the ALIF101T unit also sends the whole video image, at a lower frame rate, in the background. The
Background Refresh parameter controls the rate at which this background image is sent. The default value is
‘every 32 frames’, meaning that a full frame is sent in the background every 32 frames. Reducing this to ‘every
64 frames’ or more will reduce the amount of bandwidth that the ALIF101T unit consumes. On a high-trafc
network this parameter should be reduced in this way to improve overall system performance. Options: every
32 frames, every 64 frames, every 128 frames, every 256 frames or disabled.
Enable Magic Eye
This feature, enabled as standard, aims to reduce the effect of dithering - a technique used by some graphics
cards to improve the perceived quality and color depth of images by diffusing or altering the color of pixels
between video frames. The Magic Eye feature increases the frame rate and eliminates unnecessary network
trafc by ignoring the color dithering where it occurs. If the video source is not noisy or dithered then you
can switch off Magic Eye to enable full color accuracy. Magic Eye mode can remain enabled without penalty for
video that does not have dither or noise.
Use Default DDC and Choose Default DDC
When the Use Default DDC option is unticked, ADDERLink INFINITY will use the EDID that is reported by
the monitor connected to the receiver unit. However, if you tick the Use Default DDC option, you can then
select from a range of preset video resolutions from the Choose Default DDC drop down box. Once selected,
ALIF101T unit will report itself to prefer this video mode.
Enable Hot Plug Detect on change of display
When this option is ticked, every time the monitor is changed at the receiver unit, hot plug state changes are
sent to the graphics card of the PC attached to the ALIF101T unit as if a screen has just been attached.
Period of Hot Plug Detect signal
This is the length of time that the hot-plug detect signal is de-asserted. The default of 100ms is sufcient for the
majority of HDMI/DP++ graphics cards, however, a small minority may need to be given a longer a period.
Frame skipping percentage
Frame Skipping involves ‘missing out’ video frames between those captured by the ALIF101T unit. For video
sources that update only infrequently or for those that update very frequently but where high delity is not
required, frame skipping is a good strategy for reducing the overall bandwidth consumed by the system. Range: 0
to 100%.
Compression
Determines the (AFZ and AFZ+) compression method used for video transmission. Choices are:
• ‘Pixel perfect’ - only uses pixel perfect AFZ,
• ‘Adaptive’ - guarantees frame rate, builds to pixel perfect,
• ‘Smoothest video’ - forces the maximum compression, or
• ‘Advanced’ - allows you to choose a xed compression mode:
• ‘AFZ only (pixel perfect),
• ‘AFZ+ Minimum compression’,
• ‘AFZ+ Middle compression’, or
• ‘AFZ+ Maximum compression’.
INSTALLATIONCONFIGURATIONOPERATION
FURTHER
INFORMATION
INDEX
15
Page 17
USB Settings
Security
Enable Dummy Boot Keyboard
When ticked, ALIF101T unit will report a virtual dummy boot keyboard to the attached PC to ensure that
a keyboard is always reported when the PC boots up. The dummy boot keyboard uses one of the 13 USB
endpoints, therefore if all 13 endpoints are required elsewhere for USB devices (or a KVM switch only supports
two HID devices) then it can be disabled by deselecting this option. See also Reserved Port Range below.
Disable Hi-Speed
This option allows you to force the system to run at the low/full USB speed of 12Mb/s, thus forcing USB 2.0 Hi-
Speed devices to adapt to the lower rate.
Hub Size
Using this option you can select whether ALIF101T unit should report itself as a 13 or a 7 port USB hub. Some
USB hosts are only able to support 7 port USB hubs. If this option is set to 7, then only 7 USB devices are
supported by the PC.
Reserved Port Range
For some devices, e.g. touch screens, you may wish to ensure that they are always reported to the same USB
port number so that the USB driver will always nd the device. This option allows you reserve up to 8 ports
for certain devices. At the RX unit, the devices are assigned to the reserved ports. If a port reservation is to be
applied, then the dummy boot keyboard should be disabled. The default value for this option is ‘0’, i.e. disabled.
USB Encryption
This setting determines whether encryption should be applied to the USB data passed across the link. Note
that video data is never encrypted.
Control Encryption
This setting determines whether encryption should be applied to the control data passed across the link. The
“Prefer off” setting means that control encryption is enabled if the receiver at the other end of the link has
“always on” selected, otherwise it is disabled. Note: video data is never encrypted.
Secure web pages with password
When ticked, this option enables https security so that the conguration pages are only accessible to the admin
user with a password.
Change/conrm password
These options allow you to change the admin password for the system.
INSTALLATIONCONFIGURATIONOPERATION
FURTHER
INFORMATION
To get here
1 Connect your computer to the network port on the front panel.
2 Run a web browser and enter the IP address of the unit. If the address is
unknown, perform a manual factory reset to http://169.254.1.33
3 Click either the USB Settings or Security links, as appropriate.
INDEX
16
Page 18
AIM Manager
System Messages
Enable AIM Control
Click this button to allow an AIM (Adder Innity Manager) box to take control of this TX. When the button is
clicked, the ALIF101T unit will be rebooted to allow the AIM box to discover and control it.
INSTALLATIONCONFIGURATIONOPERATION
Enable system messages
Tick to allow the creation of status and error messages by ALIF101T unit.
Send system messages to remote Log Server
Choose this option to send the system messages to a remote server via the network. Provide the IP address of
a suitable server here also.
ADDERLink INFINITY servers use the User Datagram Protocol (UDP) for all Syslog trafc.
Store system messages in unit
When ticked, this option will store system messages within the memory of ALIF101T unit. Click the View
messages button to view the list or the Clear messages button to delete the list.
Update Now
Click to save and implement any changes that you make.
To get here
1 Connect your computer to the network port on the front panel.
2 Run a web browser and enter the IP address of the unit. If the address is
unknown, perform a manual factory reset to http://169.254.1.33
3 Click either the AIM Manager or System Messages links, as appropriate.
FURTHER
INFORMATION
INDEX
17
Page 19
Statistics
Firmware Upgrade
Enable collection of bandwidth statistics
ALIF units can record data transfer statistics from the System port and plot them on a graph for
troubleshooting and optimization purposes. When you enable this option, you will rst be presented with a pop
up from which you can choose which aspects you would like to graph: Data throughput, various packet rates
and/or frame rates.
Submit
Click this button after ticking the above checkbox to plot the chosen statistics on a pop up graph.
INSTALLATIONCONFIGURATIONOPERATION
Upgrade
Use this page to upgrade the main or backup rmware image on ALIF101T unit. Please see the section
Performing an upgrade for details.
Reboot
Reboot
Use this page to perform a reboot or a factory reset. Please see the section Manual factory reset for details.
To get here
1 Connect your computer to the network port on the front panel.
2 Run a web browser and enter the IP address of the unit. If the address is unknown,
perform a manual factory reset to http://169.254.1.33
3 Click either the Statistics , Firmware Upgrade or Reboot links, as appropriate.
FURTHER
INFORMATION
INDEX
18
Page 20
About
About
This page displays key information about the ALIF101T unit that may be requested by Adder Technical Support.
INSTALLATIONCONFIGURATIONOPERATION
To get here
1 Connect your computer to the network port on the front panel.
2 Run a web browser and enter the IP address of the unit. If the address is unknown,
perform a manual factory reset to http://169.254.1.33
3 Click the About link.
FURTHER
INFORMATION
INDEX
19
Page 21
APPENDIX C - Dimensions
0.2”
(5mm)
0.98”
(25mm)
INSTALLATIONCONFIGURATIONOPERATION
4 x M3 holes
1.3”
(33mm)
2.95” (75mm)
4.33”(110mm)
0.91”
(23mm)
1.97”
(50mm)
2.2”
(56mm)
FURTHER
INFORMATION
INDEX
20
Page 22
APPENDIX D - Tips for success when networking ALIF units
ALIF units use multiple strategies to minimize the amount of data that they send
across networks. However, data overheads can be quite high, particularly when very
high resolution video is being transferred, so it is important to take steps to maximize
network efciency and help minimize data output. The tips given in this section have been
proven to produce very benecial results.
Summary of steps
• Choose the right kind of switch.
• Create an efcient network layout.
• Congure the switches and devices correctly.
Choosing the right switch
Layer 2 switches are what bind all of the hosts together in the subnet. However, they are
all not created equally, so choose carefully. In particular look for the following:
• Gigabit (1000Mbps) or faster Ethernet ports,
• Support for IGMP v2 (or v3) snooping,
• Support for Jumbo frames up to 9216-byte size,
• High bandwidth connections between switches, preferably Fiber Channel.
• Look for switches that perform their most onerous tasks (e.g. IGMP snooping) using
multiple dedicated processors (ASICS).
• Ensure the maximum number of concurrent ‘snoopable groups’ the switch can
handle meets or exceeds the number of ALIF transmitters that will be used to create
multicast groups.
• Check the throughput of the switch: Full duplex, 1Gbps up- and down- stream speeds
per port.
• Use the same switch make and model throughout a single subnet.
• You also need a Layer 3 switch. Ensure that it can operate efciently as an IGMP
Querier.
For the latest list of switches known to work with ALIF, please
download the latest white paper ‘Successful ADDERLink INFINITY
Implementation’ from www.adder.com/white-papers
Creating an efcient network layout
Network layout is vital. The use of IGMP snooping also introduces certain constraints, so
take heed:
• Keep it at. Use a basic line-cascade structure rather than a pyramid or tree
arrangement.
• Keep the distances between the switches as short as possible.
• Ensure sufcient bandwidth between switches to eliminate bottlenecks.
• Where the AIM server is used to administer multiple ALIF transceivers, ensure the
AIM server and all ALIF units reside in the same subnet.
• Do not use VGA to DVI converters, instead replace VGA video cards in older systems
with suitable DVI replacements. Converters cause ALIF TX units to massively increase
data output.
• Wherever possible, create a private network.
The recommended layout
The layout shown below has been found to provide the most efcient network layout for
rapid throughput when using IGMP snooping:
Note: From rmware version 3.1, tree and hierarchical structures of network switches are also
supported. The Transmitter now joins its own multicast group so there is always a route from
the querier to the transmitter which was previously missing in earlier rmware versions.
• Use no more than two cascade levels.
• Ensure high bandwidth between the two L2 switches and very high bandwidth
between the top L2 and the L3. Typically 10GB and 20GB, respectively for 48 port L2
switches.
continued
INSTALLATIONCONFIGURATIONOPERATION
FURTHER
INFORMATION
INDEX
21
Page 23
Conguring the switches and devices
The layout is vital but so too is the conguration:
• Enable IGMP Snooping on all L2 switches.
• Ensure that IGMP Fast-Leave is enabled on all switches with ALIF units connected
directly to them.
• Enable the L3 switch as an IGMP Querier.
• Enable Spanning Tree Protocol (STP) on all switches and importantly also enable
portfast (only) on all switch ports that have ALIF units connected.
• If any hosts will use any video resolutions using 2048 horizontal pixels (e.g. 2048 x
1152), ensure that Jumbo Frames are enabled on all switches.
• Choose an appropriate forwarding mode on all switches. Use Cut-through if available,
otherwise Store and forward.
• Optimize the settings on the ALIF transmitters:
• If moving video images are being shown frequently, then leave Frame Skipping at a
low percentage and instead reduce the Peak bandwidth limiter.
• Where screens are quite static, try increasing the Background Refresh interval and/
or increasing the Frame skipping percentage setting.
Make changes to the ALIF transmitters one at a time, in small steps, and view typical
video images so that you can attribute positive or negative results to the appropriate
control.
• Ensure that all ALIF units are fully updated to the latest rmware version (at least
v2.1).
INSTALLATIONCONFIGURATIONOPERATION
FURTHER
22
INFORMATION
INDEX
Page 24
APPENDIX E - Troubleshooting
Problem: The video image of the ALIF receiver shows horizontal lines across
the screen.
This issue is known as Blinding because the resulting video image looks as though you’re
viewing it through a venetian blind.
When video is transmitted by ALIF units, the various lines of each screen are divided up
and transmitted as separate data packets. If the reception of those packets is disturbed,
then blinding is caused. The lines are displayed in place of the missing video data packets.
There are several possible causes for the loss of data packets:
• Incorrect switch conguration. The problem could be caused by multicast ooding,
which causes unnecessary network trafc. This is what IGMP snooping is designed to
combat, however, there can be numerous causes of the ooding.
• Speed/memory bandwidth issues within one or more switches. The speed and
capabilities of different switch models varies greatly. If a switch cannot maintain pace
with the quantity of data being sent through it, then it will inevitably start dropping
packets.
• One or more ALIF units may be outputting Jumbo frames due to the video resolution
(2048 horizontal pixels) being used. If jumbo frames are output by an ALIF unit, but
the network switches have not been congured to use jumbo frames, the switches
will attempt to break the large packets down into standard packets. This process
introduces a certain latency and could be a cause for dropped packets.
• One or more ALIF units may be using an old rmware version. Firmware versions
prior to v2.1 exhibited an issue with the timing of IGMP join and leave commands that
caused multicast ooding in certain congurations.
Remedies:
• Ensure that IGMP snooping is enabled on all switches within the subnet.
• Where each ALIF unit is connected as the sole device on a port connection to
a switch, enable IGMP Fast-Leave (aka Immediate Leave) to reduce unnecessary
processing on each switch.
• Check the video resolution(s) being fed into the ALIF transmitters. If resolutions using
2048 horizontal pixels are unavoidable then ensure that Jumbo frames are enabled on
all switches.
• Check the forwarding mode on the switches. If Store and forward is being used, try
selecting Cut-through as this mode causes reduced latency on lesser switch designs.
• Ensure that one device within the subnet is correctly congured as an IGMP Querier,
usually a layer 3 switch or multicast router.
• Ensure that the rmware in every ALIF unit is version 2.1 or greater.
• Try adjusting the transmitter settings on each ALIF to make the output data stream as
efcient as possible. See ALIF transmitter video settings for details.
continued
INSTALLATIONCONFIGURATIONOPERATION
FURTHER
23
INFORMATION
INDEX
Page 25
Problem: The mouse pointer of the ALIF receiver is slow or sluggish when
moved across the screen.
This issue is often related to either using dithering on the video output of one or more
transmitting computers or using VGA-to-DVI video converters.
Dithering is used to improve the perceived quality and color depth of images by diffusing
or altering the color of pixels between video frames. This practice is commonly used
on Apple Mac computers using ATI or Nvidia graphics cards. VGA-to-DVI converters
unwittingly produce a similar issue by creating high levels of pixel background noise.
ALIF units attempt to considerably reduce network trafc by transmitting only the pixels
that change between successive video frames. When dithering is enabled and/or VGA-toDVI converters are used, this can have the effect of changing almost every pixel between
each frame, thus forcing the ALIF transmitter to send the whole of every frame: resulting
in greatly increased network trafc and what’s perceived as sluggish performance.
Remedies:
• Linux PCs
Check the video settings on the PC. If the Dither video box option is enabled, disable it.
• Apple Mac with Nvidia graphics
Use the Adder utility for Mac’s – Contact technical support.
• Apple Mac with ATI graphics
Enable the Magic Eye dither removal feature.
• Windows PCs
If you suspect these issues with PC’s, contact technical support for assistance.
• Replace old VGA adapters on host computers with DVI video cards.
Problem: My monitor is displaying a pink screen
It is possible that the source computer and ALIF transmitter are sending a high resolution
Dual Link signal in response to a request from your Dual Link monitor. However, your
ALIF receiver is unable to correctly process the signal, causing the pink screen issue (DVI
resolutions above 1920 x 1200 are generally Dual Link).
ALIF2002T and 2112T transmitters are able to send Dual Link video when requested,
however, an ALIF2000R receiver is required to process the higher resolution signal fully
at the other end. Other receivers, such as the ALIF1000R, 1002R and 2020R units cannot
process Dual Link DVI as they are Single Link devices.
Ensure that the ALIF transmitter is set to supply a Single Link EDID to the graphics card.
When the video source is changed to a Single Link video resolution, the pink screen
should disappear and the video should be displayed normally. Alternatively, change the
monitor to a Single Link DVI monitor.
It is important not to mix Dual Link Transmitters with Single Link Receivers.
On an AIM controlled system, ensure that the Video compatibility check is enabled as this
ensures that the correct video mode is displayed for the monitor being used.
Problem: The audio output of the ALIF receiver sounds like a scratched record.
This issue is called Audio crackle and is a symptom of the same problem that produces
blinding (see previous page). The issue is related to missing data packets.
Remedies:
As per blinding discussed previously.
Problem: AIM cannot locate working ALIF units.
There are a few possible causes:
• The ALIF units must be reset back to their zero cong IP addresses for AIM discovery.
If you have a working network of ALIF’s without AIM and then add AIM to the network
AIM will not discover the ALIFs until they are reset to the zero cong IP addresses.
• This could be caused by Layer 2 Cisco switches that have Spanning Tree Protocol
(STP) enabled but do not also have portfast enabled on the ports to which ALIF units
are connected. Without portfast enabled, ALIF units will all be assigned the same zero
cong IP address at reboot and AIM will only acquire them one at a time on a random
basis.
You can easily tell whether portfast is enabled on a switch that is running STP: When
you plug the link cable from a working ALIF unit into the switch port, check how long
it takes for the port indicator to change from orange to green. If it takes roughly one
second, portfast is on; if it takes roughly thirty seconds then portfast is disabled.
Remedies:
• Ensure that the ALIF units and the AIM server are located within the same subnet
because AIM cannot cross subnet boundaries.
• Manually reset the ALIF units to their zero cong IP addresses.
• Enable portfast on all switch ports that have ALIF units attached to them or try
temporarily disabling STP on the switches while AIM is attempting to locate ALIF units.
INSTALLATIONCONFIGURATIONOPERATION
FURTHER
INFORMATION
INDEX
24
Page 26
APPENDIX F - Glossary
Internet Group Management Protocol
Where an ALIF transmitter is required to stream video to
two or more receivers, multicasting is the method used.
Multicasting involves the delivery of identical data to
multiple receivers simultaneously without the need to
maintain individual links. When multicast data packets enter
a subnet, the natural reaction of the switches that bind
all the hosts together within the subnet, is to spread the
multicast data to all of their ports. This is referred to as
Multicast ooding and means that the hosts (or at least
their network interfaces) are required to process plenty of
data that they didn’t request. IGMP offers a partial solution.
The Internet Group Management Protocol (IGMP) is
designed to prevent multicast ooding by allowing Layer
3 switches to check whether host computers within
their care are interested in receiving particular multicast
transmissions. They can then direct multicast data only to
those points that require it and can shut off a multicast
stream if the subnet has no recipients.
There are currently three IGMP versions: 1, 2 and 3, with
each version building upon the capabilities of the previous
one:
• IGMPv1 allows host computers to opt into a multicast
transmission using a Join Group message, it is then
incumbent on the router to discover when they no
longer wish to receive; this is achieved by polling them
(see IGMP Querier below) until they no longer respond.
• IGMPv2 includes the means for hosts to opt out as well
as in, using a Leave Group message.
• IGMPv3 encompasses the abilities of versions 1 and 2
but also adds the ability for hosts to specify particular
sources of multicast data.
ADDERLink INFINITY units make use of IGMPv2 when
performing multicasts to ensure that no unnecessary
congestion is caused.
IGMP Snooping
The IGMP messages are effective but only operate at
layer 2 - intended for routers to determine whether
multicast data should enter a subnet. A relatively recent
development has taken place within the switches that
glue together all of the hosts within each subnet: IGMP
Snooping. IGMP snooping means these layer 2 devices now
have the ability to take a peek at the IGMP messages. As a
result, the switches can then determine exactly which of
their own hosts have requested to receive a multicast –
and only pass on multicast data to those hosts.
IGMP Querier
When IGMP is used, each subnet requires one Layer 3
switch to act as a Querier. In this lead role, the switch
periodically sends out IGMP Query messages and in
response all hosts report which multicast streams they
wish to receive. The Querier device and all snooping Layer
2 switches, then update their lists accordingly (the lists are
also updated when Join Group and Leave Group (IGMPv2)
messages are received).
IGMP Fast-Leave (aka Immediate Leave)
When a device/host no longer wishes to receive a
multicast transmission, it can issue an IGMP Leave Group
message as mentioned above. This causes the switch to
issue an IGMP Group-Specic Query message on the port
(that the Leave Group was received on) to check no other
receivers exist on that connection that wish to remain a
part of the multicast. This process has a cost in terms of
switch processor activity and time.
Where ALIF units are connected directly to the switch
(with no other devices on the same port) then enabling
IGMP Fast-Leave mode means that switches can
immediately remove receivers without going through
a full checking procedure. Where multiple units are
regularly joining and leaving multicasts, this can speed up
performance considerably.
Jumbo frames (Jumbo packets)
Since its commercial introduction in 1980, the Ethernet
standard has been successfully extended and adapted to
keep pace with the ever improving capabilities of computer
systems. The achievable data rates, for instance, have risen
in ten-fold leaps from the original 10Mbit/s to a current
maximum of 100Gbit/s.
While data speeds have increased massively, the standard
dening the number of bytes (known as the Payload)
placed into each data packet has remained resolutely stuck
at its original level of 1500 bytes. This standard was set
during the original speed era (10Mbits/s) and offered the
best compromise at that speed between the time taken to
process each packet and the time required to resend faulty
packets due to transmission errors.
But now networks are much faster and les/data streams
are much larger; so time for a change? Unfortunately, a
wholesale change to the packet size is not straightforward
as it is a fundamental standard and changing it would mean
a loss of backward compatibility with older systems.
Larger payload options have been around for a while,
however, they have often been vendor specic and at
present they remain outside the ofcial standard. There
is, however, increased consensus on an optional ‘Jumbo’
payload size of 9000 bytes and this is fully supported by
the ADDERLink INFINITY (ALIF) units.
Jumbo frames (or Jumbo packets) offer advantages for
ALIF units when transmitting certain high resolution video
signals across a network. This is because the increased data
in each packet reduces the number of packets that need to
be transferred and dealt with - thus reducing latency times.
The main problem is that for jumbo frames to be possible
on a network, all of the devices on the network must
support them.
INSTALLATIONCONFIGURATIONOPERATION
FURTHER
INFORMATION
INDEX
25
Page 27
Spanning Tree Protocol (STP)
In order to build a robust network, it is necessary
to include certain levels of redundancy within the
interconnections between switches. This will help to
ensure that a failure of one link does not lead to a
complete failure of the whole network.
The danger of multiple links is that data packets, especially
multicast packets, become involved in continual loops as
neighbouring switches use the duplicated links to send and
resend them to each other.
To prevent such bridging loops from occurring, the
Spanning Tree Protocol (STP), operating at layer 2, is
used within each switch. STP encourages all switches
to communicate and learn about each other. It prevents
bridging loops by blocking newly discovered links until it
can discover the nature of the link: is it a new host or a
new switch?
The problem with this is that the discovery process can
take up to 50 seconds before the block is lifted, causing
problematic timeouts.
The answer to this issue is to enable the portfast variable
for all host links on a switch. This will cause any new
connection to go immediately into forwarding mode.
However, take particular care not to enable portfast on
any switch to switch connections as this will result in
bridging loops.
Forwarding modes
In essence, the job of a layer 2 switch is to transfer as
fast as possible, data packets arriving at one port out to
another port as determined by the destination address.
This is known as data forwarding and most switches offer
a choice of methods to achieve this. Choosing the most
appropriate forwarding method can often have a sizeable
impact on the overall speed of switching:
• Store and forward is the original method and requires
the switch to save each entire data packet to buffer
memory, run an error check and then forward if no
error is found (or otherwise discard it).
• Cut-through was developed to address the latency
issues suffered by some store and forward switches.
The switch begins interpreting each data packet as it
arrives. Once the initial addressing information has been
read, the switch immediately begins forwarding the
data packet while the remainder is still arriving. Once
all of the packet has been received, an error check is
performed and, if necessary, the packet is tagged as
being in error. This checking ‘on-the-y’ means that
cut-through switches cannot discard faulty packets
themselves. However, on receipt of the marked packet, a
host will carry out the discard process.
• Fragment-free is a hybrid of the above two methods.
It waits until the rst 64 bits have been received before
beginning to forward each data packet. This way the
switch is more likely to locate and discard faulty packets
that are fragmented due to collisions with other data
packets.
• Adaptive switches automatically choose between the
above methods. Usually they start out as a cut-through
switches and change to store and forward or fragmentfree methods if large number of errors or collisions are
detected.
So which one to choose? The Cut-through method has the
least latency so is usually the best to use with ADDERLink
INFINITY units. However, if the network components and/
or cabling generate a lot of errors, the Store and forward
method should probably be used. On higher end store and
forward switches, latency is rarely an issue.
Layer 2 and Layer 3: The OSI model
When discussing network switches, the terms Layer 2 and
Layer 3 are very often used. These refer to parts of the
Open System Interconnection (OSI) model, a standardized
way to categorize the necessary functions of any standard
network.
There are seven layers in the OSI model and these dene
the steps needed to get the data created by you (imagine
that you are Layer 8) reliably down onto the transmission
medium (the cable, optical ber, radio wave, etc.) that
carries the data to another user; to complete the picture,
consider the transmission medium is Layer 0. In general,
think of the functions carried out by the layers at the top
as being complex, becoming less complex as you go lower
down.
As your data travel down from you towards the
transmission medium (the cable), they are successively
encapsulated at each layer within a new wrapper (along
with a few instructions), ready for transport. Once
transmission has been made to the intended destination,
the reverse occurs: Each wrapper is stripped away and the
instructions examined until nally only the original data are
left.
So why are Layer 2 and Layer 3 of particular importance
when discussing ADDERLink INFINITY? Because the
successful transmission of data relies upon fast and reliable
passage through network switches – and most of these
operate at either Layer 2 or Layer 3.
The job of any network switch is to receive each incoming
network packet, strip away only the rst few wrappers to
discover the intended destination then rewrap the packet
and send it in the correct direction.
continued
INSTALLATIONCONFIGURATIONOPERATION
FURTHER
INFORMATION
INDEX
26
Page 28
In simplied terms, the wrapper that is added at Layer 2
(by the sending system) includes the physical address of
the intended recipient system, i.e. the unique MAC address
(for example, 09:f8:33:d7:66:12) that is assigned to every
networking device at manufacture. Deciphering recipients
at this level is more straightforward than at Layer 3, where
the address of the recipient is represented by a logical IP
address (e.g. 192.168.0.10) and requires greater knowledge
of the surrounding network structure. Due to their more
complex circuitry, Layer 3 switches are more expensive
than Layer 2 switches of a similar build quality and are
used more sparingly within installations.
INSTALLATIONCONFIGURATIONOPERATION
FURTHER
27
INFORMATION
INDEX
Page 29
APPENDIX G - Open source licenses
This product includes binaries that are derived from the open source community. The
modules listed below are licenced under the GNU General Public License v2 and must
be provided, in source form, on request:
The software included in this product contains copyrighted software that is licensed
under the GPL. You may obtain the complete Corresponding Source code from Adder
for a period of three years after the last shipment of this product, which will be no
earlier than 2028, by contacting support@adder.com or writing to :
Saxon Way, Bar Hill, Cambridge, CB23 8SL, United Kingdom
Please write “Source for product XXXXXXXX ” in the subject line (where XXXXXX
is the model and version number). This offer is valid to anyone in receipt of this
information.
This product includes binaries that are derived from the open source community. The
modules listed below are licenced under the GNU Lesser General Public License v2.1
and must be provided, in source form, on request:
kmod
libdaemon
avahi
libgpg-error
nettle
libgcrypt
gnutls
libmicrohttpd
In addition to the GPL modules listed, this product also includes binaries derived from
3rd party open sources that have their own license requirements. Each module is listed
below with their required Copyright statement and distribution conditions.
The OpenSSL toolkit stays under a dual license, i.e. both the conditions of
the OpenSSL License and the original SSLeay license apply to the toolkit.
See below for the actual license texts. Actually both licenses are BSD-style
Open Source licenses. In case of any license issues related to OpenSSL
please contact openssl-core@openssl.org.
Copyright (c) 1998-2011 The OpenSSL Project. All rights reserved.
Redistribution and use in source and binary forms, with or without modication, are
permitted provided that the following conditions are met:
1. Redistributions of source code must retain the above copyright notice, this list of
conditions and the following disclaimer.
2. Redistributions in binary form must reproduce the above copyright notice, this list
of conditions and the following disclaimer in the documentation and/or other materials
provided with the distribution.
3. All advertising materials mentioning features or use of this software must display the
following acknowledgment: “This product includes software developed by the OpenSSL
Project for use in the OpenSSL Toolkit. (http://www.openssl.org/)”
4. The names “OpenSSL Toolkit” and “OpenSSL Project” must not be used to endorse
or promote products derived from this software without prior written permission. For
written permission, please contact openssl-core@openssl.org.
5. Products derived from this software may not be called “OpenSSL” nor may “OpenSSL”
appear in their names without prior written permission of the OpenSSL Project.
6. Redistributions of any form whatsoever must retain the following acknowledgment:
INSTALLATIONCONFIGURATIONOPERATION
FURTHER
INFORMATION
INDEX
28
Page 30
“This product includes software developed by the OpenSSL Project for use in the
OpenSSL Toolkit (http://www.openssl.org/)”
THIS SOFTWARE IS PROVIDED BY THE OpenSSL PROJECT ``AS IS’’ AND ANY
EXPRESSED OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE OpenSSL PROJECT OR
ITS CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL,
SPECIAL, EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT
NOT LIMITED TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES;
LOSS OF USE, DATA, OR PROFITS; OR BUSINESS INTERRUPTION)
HOWEVER CAUSED AND ON ANY THEORY OF LIABILITY, WHETHER IN
CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING NEGLIGENCE OR
OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF THIS SOFTWARE, EVEN
IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
=============================================================
This product includes cryptographic software written by Eric Young (eay@cryptsoft.
com). This product includes software written by Tim Hudson (tjh@cryptsoft.com).
*/
Original SSLeay License
-----------------------
/* Copyright (C) 1995-1998 Eric Young (eay@cryptsoft.com) All rights reserved.
*
This package is an SSL implementation written by Eric Young (eay@cryptsoft.com).
The implementation was written so as to conform with Netscapes SSL.
*
This library is free for commercial and non-commercial use as long as the following
conditions are aheared to. The following conditions apply to all code found in this
distribution, be it the RC4, RSA, lhash, DES, etc., code; not just the SSL code. The SSL
documentation included with this distribution is covered by the same copyright terms
except that the holder is Tim Hudson (tjh@cryptsoft.com).
*
Copyright remains Eric Young’s, and as such any Copyright notices in the code are not to
be removed. If this package is used in a product, Eric Young should be given attribution
as the author of the parts of the library used. This can be in the form of a textual
message at program startup or in documentation (online or textual) provided with the
package.
*
Redistribution and use in source and binary forms, with or without modication, are
permitted provided that the following conditions are met:
1. Redistributions of source code must retain the copyright
notice, this list of conditions and the following disclaimer.
2. Redistributions in binary form must reproduce the above copyright
notice, this list of conditions and the following disclaimer in the
documentation and/or other materials provided with the distribution.
3. All advertising materials mentioning features or use of this software
must display the following acknowledgement:
“This product includes cryptographic software written by
Eric Young (eay@cryptsoft.com)”
The word ‘cryptographic’ can be left out if the rouines from the library
being used are not cryptographic related :-).
4. If you include any Windows specic code (or a derivative thereof) from
the apps directory (application code) you must include an acknowledgement:
“This product includes software written by Tim Hudson (tjh@cryptsoft.com)”
*
THIS SOFTWARE IS PROVIDED BY ERIC YOUNG ``AS IS’’ AND
ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR OR
CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED
TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA,
OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF
THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH
DAMAGE.
*
The licence and distribution terms for any publically available version or derivative of this
code cannot be changed. i.e. this code cannot simply be copied and put under another
distribution licence [including the GNU Public Licence.]
*/
All les in libev are
Copyright (c)2007,2008,2009,2010,2011,2012,2013 Marc Alexander Lehmann.
Redistribution and use in source and binary forms, with or without
modication, are permitted provided that the following conditions are
met:
INSTALLATIONCONFIGURATIONOPERATION
FURTHER
INFORMATION
INDEX
29
Page 31
* Redistributions of source code must retain the above copyright
notice, this list of conditions and the following disclaimer.
* Redistributions in binary form must reproduce the above
copyright notice, this list of conditions and the following
disclaimer in the documentation and/or other materials provided
with the distribution.
THIS SOFTWARE IS PROVIDED BY THE COPYRIGHT HOLDERS AND
CONTRIBUTORS “AS IS” AND ANY EXPRESS OR IMPLIED WARRANTIES,
INCLUDING, BUT NOT LIMITED TO, THE IMPLIED WARRANTIES OF
MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE ARE DISCLAIMED.
IN NO EVENT SHALL THE COPYRIGHT OWNER OR CONTRIBUTORS BE
LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY,
OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR
PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF
THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH
Additional license notices for Libgcrypt. -*- org -*-
This le contains the copying permission notices for various les in
the Libgcrypt distribution which are not covered by the GNU Lesser
General Public License (LGPL) or the GNU General Public License (GPL).
These notices all require that a copy of the notice be included
in the accompanying documentation and be distributed with binary
distributions of the code, so be sure to include this le along
with any binary distributions derived from the GNU C Library.
Redistribution and use in source and binary forms, with or without
modication, are permitted provided that the following conditions are
met:
* Redistributions of source code must retain the above copyright
notice, this list of conditions and the following disclaimer.
INSTALLATIONCONFIGURATIONOPERATION
FURTHER
INFORMATION
INDEX
30
Page 32
* Redistributions in binary form must reproduce the above copyright
notice, this list of conditions and the following disclaimer in the
documentation and/or other materials provided with the
distribution.
* Neither the name of the Intel Corporation nor the names of its
contributors may be used to endorse or promote products derived from
this software without specic prior written permission.
THIS SOFTWARE IS PROVIDED BY INTEL CORPORATION “AS IS” AND ANY
EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE
IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL INTEL CORPORATION OR
CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED
TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA,
OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF
THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH
DAMAGE.
#+end_quote
* X License
For les:
- install.sh
#+begin_quote
Copyright (C) 1994 X Consortium
Permission is hereby granted, free of charge, to any person obtaining a copy
of this software and associated documentation les (the “Software”), to
deal in the Software without restriction, including without limitation the
rights to use, copy, modify, merge, publish, distribute, sublicense, and/or
sell copies of the Software, and to permit persons to whom the Software is
furnished to do so, subject to the following conditions:
The above copyright notice and this permission notice shall be included in
all copies or substantial portions of the Software.
THE SOFTWARE IS PROVIDED “AS IS”, WITHOUT WARRANTY OF ANY KIND,
EXPRESS OR IMPLIED, INCLUDING BUT NOT LIMITED TO THE WARRANTIES
OF MERCHANTABILITY, FITNESS FOR A PARTICULAR PURPOSE AND
NONINFRINGEMENT. IN NO EVENT SHALL THE X CONSORTIUM BE LIABLE
FOR ANY CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN AN ACTION
OF CONTRACT, TORT OR OTHERWISE, ARISING FROM, OUT OF OR IN
CONNECTION WITH THE SOFTWARE OR THE USE OR OTHER DEALINGS IN THE
SOFTWARE.
Except as contained in this notice, the name of the X Consortium shall not
be used in advertising or otherwise to promote the sale, use or other deal ings in this Software without prior written authorization from the X Consor-
tium.
#+end_quote
* Public domain
For les:
- cipher/arcfour-amd64.S
#+begin_quote
Author: Marc Bevand <bevand_m (at) epita.fr>
Licence: I hereby disclaim the copyright on this code and place it
in the public domain.
#+end_quote
* OCB license 1
For les:
- cipher/cipher-ocb.c
#+begin_quote
OCB is covered by several patents but may be used freely by most
software. See http://web.cs.ucdavis.edu/~rogaway/ocb/license.htm .
In particular license 1 is suitable for Libgcrypt: See
http://web.cs.ucdavis.edu/~rogaway/ocb/license1.pdf for the full
license document; it basically says:
INSTALLATIONCONFIGURATIONOPERATION
FURTHER
INFORMATION
INDEX
31
Page 33
License 1 — License for Open-Source Software Implementations of OCB
(Jan 9, 2013)
Under this license, you are authorized to make, use, and
distribute open-source software implementations of OCB. This
license terminates for you if you sue someone over their
open-source software implementation of OCB claiming that you have
a patent covering their implementation.
License for Open Source Software Implementations of OCB
January 9, 2013
1 Denitions
1.1 “Licensor” means Phillip Rogaway.
1.2 “Licensed Patents” means any patent that claims priority to United
States Patent Application No. 09/918,615 entitled “Method and Apparatus
for Facilitating Efcient Authenticated Encryption,” and any utility,
divisional, provisional, continuation, continuations-in-part, reexamination,
reissue, or foreign counterpart patents that may issue with respect to the
aforesaid patent application. This includes, but is not limited to, United
States Patent No. 7,046,802; United States Patent No. 7,200,227; United
States Patent No. 7,949,129; United States Patent No. 8,321,675 ; and any
patent that issues out of United States Patent Application No. 13/669,114.
1.3 “Use” means any practice of any invention claimed in the Licensed Patents.
1.4 “Software Implementation” means any practice of any invention
claimed in the Licensed Patents that takes the form of software executing on
a user-programmable, general-purpose computer or that takes the form of a
computer-readable medium storing such software. Software Implementation does
not include, for example, application-specic integrated circuits (ASICs),
eld-programmable gate arrays (FPGAs), embedded systems, or IP cores.
1.5 “Open Source Software” means software whose source code is published
and made available for inspection and use by anyone because either (a) the
source code is subject to a license that permits recipients to copy, modify,
and distribute the source code without payment of fees or royalties, or
(b) the source code is in the public domain, including code released for
public use through a CC0 waiver. All licenses certied by the Open Source
Initiative at opensource.org as of January 9, 2013 and all Creative Commons
licenses identied on the creativecommons.org website as of January 9,
2013, including the Public License Fallback of the CC0 waiver, satisfy these
requirements for the purposes of this license.
1.6 “Open Source Software Implementation” means a Software
Implementation in which the software implicating the Licensed Patents is
Open Source Software. Open Source Software Implementation does not include
any Software Implementation in which the software implicating the Licensed
Patents is combined, so as to form a larger program, with software that is
not Open Source Software.
2 License Grant
2.1 License. Subject to your compliance with the term s of this license,
including the restriction set forth in Section 2.2, Licensor hereby
grants to you a perpetual, worldwide, non-exclusive, non-transferable,
non-sublicenseable, no-charge, royalty-free, irrevocable license to practice
any invention claimed in the Licensed Patents in any Open Source Software
Implementation.
2.2 Restriction. If you or your afliates institute patent litigation
(including, but not limited to, a cross-claim or counterclaim in a lawsuit)
against any entity alleging that any Use authorized by this license
infringes another patent, then any rights granted to you under this license
automatically terminate as of the date such litigation is led.
3 Disclaimer
YOUR USE OF THE LICENSED PATENTS IS AT YOUR OWN RISK AND UNLESS
REQUIRED BY APPLICABLE LAW, LICENSOR MAKES NO REPRESENTATIONS OR
WARRANTIES OF ANY KIND CONCERNING THE LICENSED PATENTS OR ANY
PRODUCT EMBODYING ANY LICENSED PATENT, EXPRESS OR IMPLIED, STATUT
ORY OR OTHERWISE, INCLUDING, WITHOUT LIMITATION, WARRANTIES
OF TITLE, MERCHANTIBILITY, FITNESS FOR A PARTICULAR PURPOSE, OR
NONINFRINGEMENT. IN NO EVENT WILL LICENSOR BE LIABLE FOR ANY
CLAIM, DAMAGES OR OTHER LIABILITY, WHETHER IN CONTRACT, TORT OR
OTHERWISE, ARISING FROM OR RELATED TO ANY USE OF THE LICENSED
PATENTS, INCLUDING, WITHOUT LIMITATION, DIRECT, INDIRECT, INCIDENTAL,
CONSEQUENTIAL, PUNITIVE OR SPECIAL DAMAGES, EVEN IF LICENSOR HAS
BEEN ADVISED OF THE POSSIBILITY OF SUCH DAMAGES PRIOR TO SUCH AN
OCCURRENCE.
#+end_quote
All of the documentation and software included in the 4.4BSD and 4.4BSD-Lite
Releases is copyrighted by The Regents of the University of California.
Copyright 1979, 1980, 1983, 1986, 1988, 1989, 1991, 1992, 1993, 1994
The Regents of the University of California. All rights reserved.
Redistribution and use in source and binary forms, with or without
modication, are permitted provided that the following conditions
are met:
1. Redistributions of source code must retain the above copyright
notice, this list of conditions and the following disclaimer.
2. Redistributions in binary form must reproduce the above copyright
notice, this list of conditions and the following disclaimer in the
documentation and/or other materials provided with the distribution.
3. All advertising materials mentioning features or use of this software
must display the following acknowledgement:
This product includes software developed by the University of
California, Berkeley and its contributors.
4. Neither the name of the University nor the names of its contributors
may be used to endorse or promote products derived from this software
without specic prior written permission.
THIS SOFTWARE IS PROVIDED BY THE REGENTS AND CONTRIBUTORS ``AS IS’’
AND ANY EXPRESS OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED
TO, THE IMPLIED WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A
PARTICULAR PURPOSE ARE DISCLAIMED. IN NO EVENT SHALL THE REGENTS OR
CONTRIBUTORS BE LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL,
EXEMPLARY, OR CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED
TO, PROCUREMENT OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA,
OR PROFITS; OR BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY
THEORY OF LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT
(INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF
THE USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH
DAMAGE.
The Institute of Electrical and Electronics Engineers and the American
National Standards Committee X3, on Information Processing Systems have
given us permission to reprint portions of their documentation.
In the following statement, the phrase ``this text’’ refers to portions
of the system documentation.
Portions of this text are reprinted and reproduced in electronic form in
the second BSD Networking Software Release, from IEEE Std 1003.1-1988, IEEE
Standard Portable Operating System Interface for Computer Environments
(POSIX), copyright C 1988 by the Institute of Electrical and Electronics
Engineers, Inc. In the event of any discrepancy between these versions
and the original IEEE Standard, the original IEEE Standard is the referee
document.
In the following statement, the phrase ``This material’’ refers to portions
of the system documentation.
This material is reproduced with permission from American National
Standards Committee X3, on Information Processing Systems. Computer and
Business Equipment Manufacturers Association (CBEMA), 311 First St., NW,
Suite 500, Washington, DC 20001-2178. The developmental work of
Programming Language C was completed by the X3J11 Technical Committee.
The views and conclusions contained in the software and documentation are
those of the authors and should not be interpreted as representing ofcial
policies, either expressed or implied, of the Regents of the University
Copyright (c) 1991, 1992 Paul Kranenburg <pk@cs.few.eur.nl>
Copyright (c) 1993 Branko Lankester <branko@hacktic.nl>
Copyright (c) 1993 Ulrich Pegelow <pegelow@moorea.uni-muenster.de>
Copyright (c) 1995, 1996 Michael Elizabeth Chastain <mec@duracef.shout.net>
Copyright (c) 1993, 1994, 1995, 1996 Rick Sladkey <jrs@world.std.com>
Copyright (C) 1998-2001 Wichert Akkerman <wakkerma@deephackmode.org>
Copyright (C) 2001-2017 The strace developers.
All rights reserved.
INSTALLATIONCONFIGURATIONOPERATION
FURTHER
INFORMATION
INDEX
33
Page 35
Redistribution and use in source and binary forms, with or without
modication, are permitted provided that the following conditions
are met:
1. Redistributions of source code must retain the above copyright
notice, this list of conditions and the following disclaimer.
2. Redistributions in binary form must reproduce the above copyright
notice, this list of conditions and the following disclaimer in the
documentation and/or other materials provided with the distribution.
3. The name of the author may not be used to endorse or promote products
derived from this software without specic prior written permission.
THIS SOFTWARE IS PROVIDED BY THE AUTHOR ``AS IS’’ AND ANY EXPRESS OR
IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED
WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR PURPOSE
ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHOR BE LIABLE FOR ANY
DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR CONSEQUENTIAL
DAMAGES (INCLUDING, BUT NOT LIMITED TO, PROCUREMENT OF
SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR
BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF
LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT (INCLUDING
NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE USE OF
THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH DAMAGE.
Copyright (C) 1993-2008 The Regents of the University of California.
Redistribution and use in source and binary forms, with or without
modication, are permitted provided that the following conditions
are met:
1. Redistributions of source code must retain the above copyright
notice, this list of conditions and the following disclaimer.
2. Redistributions in binary form must reproduce the above copyright
notice, this list of conditions and the following disclaimer in
the documentation and/or other materials provided with the
distribution.
3. The names of the authors may not be used to endorse or promote
products derived from this software without specic prior
written permission.
THIS SOFTWARE IS PROVIDED ``AS IS’’ AND WITHOUT ANY EXPRESS OR
IMPLIED WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED
WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
PURPOSE.
Redistribution and use in source and binary forms, with or without
modication, are permitted provided that the following conditions
are met:
1. Redistributions of source code must retain the above copyright
notice, this list of conditions and the following disclaimer.
2. Redistributions in binary form must reproduce the above copyright
notice, this list of conditions and the following disclaimer in
the documentation and/or other materials provided with the
distribution.
3. The names of the authors may not be used to endorse or promote
products derived from this software without specic prior
written permission.
THIS SOFTWARE IS PROVIDED ``AS IS’’ AND WITHOUT ANY EXPRESS OR
IMPLIED WARRANTIES, INCLUDING, WITHOUT LIMITATION, THE IMPLIED
WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
PURPOSE.
Some les in this package are licensed under the 4-clause BSD license,
the copyright on most of them belongs to The Regents of the University
of California. Since the license was retroactively changed in 1999 to
remove the advertising clause, they are effectively under the 3-clause
license even if the text of the license in the les hasn’t been
updated. See the following document for more details:
# Copyright (c) 2004-2017 by Internet Systems Consortium, Inc. (“ISC”)
# Copyright (c) 1995-2003 by Internet Software Consortium
#
# Permission to use, copy, modify, and distribute this software for any
# purpose with or without fee is hereby granted, provided that the above
# copyright notice and this permission notice appear in all copies.
#
# THE SOFTWARE IS PROVIDED “AS IS” AND ISC DISCLAIMS ALL WARRANTIES
# WITH REGARD TO THIS SOFTWARE INCLUDING ALL IMPLIED WARRANTIES OF
# MERCHANTABILITY AND FITNESS. IN NO EVENT SHALL ISC BE LIABLE FOR
# ANY SPECIAL, DIRECT, INDIRECT, OR CONSEQUENTIAL DAMAGES OR ANY
# DAMAGES WHATSOEVER RESULTING FROM LOSS OF USE, DATA OR PROFITS,
# WHETHER IN AN ACTION OF CONTRACT, NEGLIGENCE OR OTHER TORTIOUS
# ACTION, ARISING OUT OF OR IN CONNECTION WITH THE USE OR
PERFORMANCE OF THIS SOFTWARE.
#
# Internet Systems Consortium, Inc.
# 950 Charter Street
# Redwood City, CA 94063
# <info@isc.org>
# https://www.isc.org/
The following copyright notice applies to all les collectively
called the Network Time Protocol Version 4 Distribution. Unless
specically declared otherwise in an individual le, this entire
notice applies as if the text was explicitly included in the le.
***********************************************************************
* *
* Copyright (c) University of Delaware 1992-2015 *
* *
* Permission to use, copy, modify, and distribute this software and *
* its documentation for any purpose with or without fee is hereby *
* granted, provided that the above copyright notice appears in all *
* copies and that both the copyright notice and this permission *
* notice appear in supporting documentation, and that the name *
* University of Delaware not be used in advertising or publicity *
* pertaining to distribution of the software without specic, *
* written prior permission. The University of Delaware makes no *
* representations about the suitability this software for any *
* purpose. It is provided “as is” without express or implied *
* warranty. *
* *
***********************************************************************
Content starting in 2011 from Harlan Stenn, Danny Mayer, and Martin
Burnicki is:
***********************************************************************
* *
* Copyright (c) Network Time Foundation 2011-2017 *
* *
* All Rights Reserved *
INSTALLATIONCONFIGURATIONOPERATION
FURTHER
INFORMATION
INDEX
35
Page 37
* *
* Redistribution and use in source and binary forms, with or without *
* modication, are permitted provided that the following conditions *
* are met: *
* 1. Redistributions of source code must retain the above copyright *
* notice, this list of conditions and the following disclaimer. *
* 2. Redistributions in binary form must reproduce the above *
* copyright notice, this list of conditions and the following *
* disclaimer in the documentation and/or other materials provided *
* with the distribution. *
* *
* THIS SOFTWARE IS PROVIDED BY THE AUTHORS ``AS IS’’ AND ANY EXPRESS *
* OR IMPLIED WARRANTIES, INCLUDING, BUT NOT LIMITED TO, THE IMPLIED *
* WARRANTIES OF MERCHANTABILITY AND FITNESS FOR A PARTICULAR
PURPOSE *
* ARE DISCLAIMED. IN NO EVENT SHALL THE AUTHORS OR CONTRIBUTORS BE
* LIABLE FOR ANY DIRECT, INDIRECT, INCIDENTAL, SPECIAL, EXEMPLARY, OR *
* CONSEQUENTIAL DAMAGES (INCLUDING, BUT NOT LIMITED TO,
PROCUREMENT *
* OF SUBSTITUTE GOODS OR SERVICES; LOSS OF USE, DATA, OR PROFITS; OR *
* BUSINESS INTERRUPTION) HOWEVER CAUSED AND ON ANY THEORY OF
* LIABILITY, WHETHER IN CONTRACT, STRICT LIABILITY, OR TORT *
* (INCLUDING NEGLIGENCE OR OTHERWISE) ARISING IN ANY WAY OUT OF THE
* USE OF THIS SOFTWARE, EVEN IF ADVISED OF THE POSSIBILITY OF SUCH *
* DAMAGE. *
***********************************************************************
The following individuals contributed in part to the Network Time
Protocol Distribution Version 4 and are acknowledged as authors of
this work.
1. [1]Takao Abe <takao_abe@xurb.jp> Clock driver for JJY receivers