DKT Comega juma-ii series User manual

juma/forsete-ii series user guide

2
i nt rod u ction
This is the user guide for the DKTCOMEGA 7973x/794xx JUMA/Forsete-II Series CPE.
The series include the following variants:
- 79734 – 1x 10/100/1000Mbps RJ-45
- 79741 – 4x 10/100/1000Mbps RJ-45, SNMP
- 79742 – 4x 10/100/1000Mbps RJ-45, SNMP, CATV
The user guide includes explaination of features supported from rmware revision 05_02.
Syntaxes for the individual features are listed in this document, please notice if the functionality is not
implemented in the revision of the rmware yet - it is be marked as
(feature will be supported in a future release)
index
The boot process of the CPE node ..................................................................................... 3
DHCP Settings ............................................................................................................. 4
Custom conguration .................................................................................................... 5
Device script command .................................................................................................. 7
Reboot ...................................................................................................................... 8
Save conguration to ash .............................................................................................. 8
dhcp option 82 ............................................................................................................ 8
support for ssh ........................................................................................................... 10
conguration of snmp values .......................................................................................... 12
syslog ...................................................................................................................... 12

3
the boot process of the cpe node
Boot start-up procedure:
• The rst time that the device boots, it issues a DHCP Discover with dhcp option 60 set to
DKT_F2_rstboot. The rmware can be downloaded to the unit.
• Alternatively if rmware is present in the device, the device issues a dhcp request with dhcp
option 60 set to DKT_F2_rmware_vXX_XX (where XX_XX is the version number of the rmware).
When a new node is unpacked from the factory, it doesn’t contain any rmware, and before it can
be used in must be updated with the latest revision. This mean that when the node is installed at the
customer premise, it will be required to remotely update with rmware, before it will be working. It
is highly recommended to visit www.dktcomega.com -> support -> rmware for latest boot loader and
rmware revision.
The managed node depends on DHCP negotiation. Through this negotiation the rmware ID of the man-
aged node is exchanged for a conguration le. The DHCP server hands out the conguration le depend-
ing on the rmware ID.
Uboot.
A device power-up it will start the uboot process. The purpose is to validate if the device has the correct
rmware image (if any), and bring it onto the network using DHCP.
Linux (Device OS system).
This is the main software with full network support and features to use the complete hardware platform.
The network is congured using DHCP, and the system conguration is downloaded using TFTP.
The rst bootp/dhcp request from the device can be used to remote upgrade the rmware. If a bootle
and a bootserver is given in the bootp response then the le is downloaded via tftp and executed by the
device.
The device is congured to not pass any trafc per default, so in order to pass trafc through the switch
engine, the switch --enable-lan command must be provisioned to the device. Also telnet daemon must be
started, with the use of telnetd -l /bin/sh command in the script
At device start-up conguration is provisioned automatically. Firmware is provisioned by request, either
at rst boot or when applicable
Ensures correct device settings and automatically rmware upgrade without user interaction
Firmware and conguration are provisioned by the operator
DHCP Discover, vendor class id = DKT_B2_firstboot
DHCP Offer, IP Address + firmware info, network info
DHCP Request, parameter list, network info + file name
DHCP ACK, respond parameter list, network info etc
TFTP Request – file name
TFTP Transfer – file name
DHCP Release – release IP address and boot
DHCP Discover, vendor class id = DKT_F2_firmware_vXX_XX,
request configuration (option 66, 67)
DHCP Offer, IP Address + configuration info, network info
DHCP Request, parameter list, network info + conf file
DHCP ACK, respond parameter list, conf file, network info etc
TFTP Request – conf file
TFTP Transfer – conf file
If DHCP offer end with ”/” instead of specific file-name
then CPE will try to make TFTP Request for:
<CFG_DIR>dkt_config_<MAC>.sh
<CFG_DIR>dkt_config_<Hostname>.sh
<CFG_DIR>dkt_config_<Model>.sh
<CFG_DIR>dkt_config.sh
If DHCP offer doesn’t include any firmware file name,
then the device will release the IP Address and
continue to next step, Linux start-up
BOOT LOADERLINUX
DHCP Server
DKT 797xx

4
dhcp settings
The CPE requires a dhcp server connected to the ber WAN port before power on.
Please refer to Appendix 3 – DHCP Settings for example of DHCP settings
1) The device requests in its Uboot DHCP discoverer:
Option: 1, 3
2) DHCP Server offers in its response:
Option: 53, 54, 51, 1, 3

5
3) CPE requests in its LINUX Boot-up process, where conguration le is requested:
Option: 1, 3, 6, 12, 43, 54, 66, 67 - Please make sure that DHCP Server responds to these option re-
quests, as it will inuence on the booting sequence, if these are not correctly answered, and may cause
inproper booting of the device.
custom configuration
When the OS issue a dhcp request a lename of a conguration le can be sent to the device. This
conguration le is then downloaded by tftp during the boot process and issued instead of the default
conguration. In this way it is possible to persist settings for each customer (by mapping the hardware
address of the node and the customer number).
The server and the lename of the conguration le should be sent in respective tftp-server-name (op-
tion 66) and bootle-name (option 67) from the dhcp server. Notice these options are different from the
bootle/bootserver used in the bootp response.
If it is not feasible that the dhcp server distinguish the customer’s congurations base on the hardware
address an alternative method can be used. The dhcp server sends out the name of a generic congura-
tion. This conguration can then include instruction to the node of fetching a node specic congure by
tftp where the requested lename is a combination of the node hardware address.
In the generic conguration script, which is common for all devices and that will provisioned during boot
up, the following instructions can be inserted:
source /etc/dhcp.vars
export WAN_MACADDR=$(ip addr show dev eth0 | grep “ether” | cut -d “ “ -f6 | tr -d :)
tp -g -r my_conf_$WAN_MACADDR -l /tmp/cong.sh $TFTP_SERVER
save_conguration
source /tmp/cong.sh
Alternatively, if DHCP oer in the response instead just end with ”/” instead of specic le-name then the device
will try to make TFTP Request for:
<CFG_DIR>dkt_cong_<MAC>.sh
<CFG_DIR>dkt_cong_<Hostname>.sh
<CFG_DIR>dkt_cong_<Model>.sh <CFG_DIR>dkt_cong.sh

6
An example of a conguration le could be the following:
####################################################################
# DKT conguration
# Firmware version: XX_XX
####################################################################
switch --enable-lan # enable LAN ports
# Example, how to create 4 VLANs, egress tagged on WAN and untagged on all LANs
conf vlan init
conf vlan create vlan-table vid 100
conf vlan create vlan-table vid 200
conf vlan create vlan-table vid 300
conf vlan create vlan-table vid 400
conf vlan set vlan-table vid 100 member 0,4
conf vlan set vlan-table vid 200 member 1,4
conf vlan set vlan-table vid 300 member 2,4
conf vlan set vlan-table vid 400 member 3,4
conf vlan set pvid port 0 100
conf vlan set pvid port 1 200
conf vlan set pvid port 2 300
conf vlan set pvid port 3 400
conf vlan set pvid port 4 100
conf vlan set vlan-table vid 100 tag-member 4
conf vlan set vlan-table vid 100 untag-member 0
conf vlan set vlan-table vid 200 untag-member 1
conf vlan set vlan-table vid 300 untag-member 2
conf vlan set vlan-table vid 400 untag-member 3
# Example, how to enable double tagging on WAN, dene SVID for each origin port
conf svlan init
conf svlan set service-port 4
conf svlan create svlan-table svid 500
conf svlan create svlan-table svid 600
conf svlan create svlan-table svid 700
conf svlan set svlan-table svid 500 member 0,4
conf svlan set svlan-table svid 600 member 1,4
conf svlan set svlan-table svid 700 member 2,4
conf svlan set port 0 svid 500
conf svlan set port 1 svid 600
conf svlan set port 2 svid 700
conf svlan set svlan-table svid 500 untag-member 0
conf svlan set svlan-table svid 600 untag-member 1
conf svlan set svlan-table svid 700 untag-member 2
#
# e following command enables TELNET access from WAN
telnetd -l /bin/sh
# End of DKT conguration
####################################################################

7
device script commands
The following commands are supported in the script that will be downloaded to the CPE via TFTP during
boot-up process.
This command is used to congure the switch in the unit. The command takes one or more of the following
parameters, with the syntax switch --nn or conf xx.
The 79741/742 models have 4 LAN ports, whereas 79734 model has 1 LAN port. The port outline and port
mapping is as follows, shown from the front:
4 port (79741/742):
LAN1
1
LAN2
2
LAN3
3
LAN4
4
Please refer to syntax guide for Command Line Interface, to congure VLAN, QoS
etc. parameters

8
re boot
The device can be accessed via TELNET, and is rebooted with the use of “reboot” command. TELNET ac-
cess must however be congured in the conguration le.
# e following command enables TELNET access from WAN
telnetd -l /bin/sh
save configuration to flash
Per default device conguration is provisioned via DHCP at boot, and it will be stored in device RAM
memory, which means that the device would need to have the conguration loaded at every boot.
Concept is if dhcp service is out, the device will restore its latest saved – the latest saved conguration is
the incident where there is a difference between saved conguration and provisioned conguration. Also
the CPE will get an ad-hoc link-local IP address, which is an auto conguration algorithm described in the
IETF Draft “Dynamic Conguration of IPv4link-local addresses”.
Procedure is to
- insert a syntax in the conguration le “save_conguration”
Please note that the syntax “save_conguration” will be ltered by the device, so if you do a “cat /tmp/
cong.sh” or “cat /mnt/ash/cong.sh” this command is not visible.
When dhcp service comes back, then the device will lease an IP address again, but not fetch any new
conguration, as it will keep its restored conguration until next boot process.
# e following command allows the conguration to be saved to ash memory, and this will be restore if dhcp
service is out.
save_conguration
dhcp option 82
DHCP Option 82 relay feature will be supported in a future release.
DHCP Relay Agent Information Option 82 is an extension to the Dynamic Host Conguration Protocol
(DHCP), and is dened in RFC 3046 and RFC 3993. DHCP Option 82 can be used to send information about
DHCP clients to the authenticating DHCP server. DHCP Option 82 can as an example identify the VLAN
number, port number as well as a customer ID of a client, during any IP address allocation. When DHCP
Option 82 is enabled on the CPE, it inserts the per port dened information into the DHCP packets as they
pass through the CPE on their way to the DHCP server. The DHCP server stores the IP allocation record.
The CPE will strip off the DHCP reply from the DHCP server, so the clients will never see the DHCP option
82 information.
The DHCP Option 82 information can hold a 32 char string per port.
# Syntax is switch --set-port-dhcp-option82=PORT:enable[:Circuit ID[:Remote ID]]
switch --set-port-dhcp-option82=1:1:”DKT 797xx LAN port 1”:”Client XYZ”
switch --set-port-dhcp-option82=2:1:”DKT 797xx LAN port 2”:”Client XYZ”
switch --set-port-dhcp-option82=3:1:”DKT 797xx LAN port 3”:”Client XYZ”
switch --set-port-dhcp-option82=4:1:”DKT 797xx LAN port 4”:”Client XYZ”

9

10
support for ssh
Please note that support for SSH is available for all DKTCOMEGA CPE platforms except HW revision “FE1
0” or earlier. HW revision can found via SNMP OID -.1.3.6.1.4.1.27304.10.1.0
Alternatively with DKT-GENERIC-MIB::hwVersion.0
HW with values of “ERROR” or “FE1 0” do not support SSH.
In order to have SSH support, please insert the following command in the conguration script:
# SSH daemon is started with the following command
/etc/init.d/sshd start
The CPE is precongured with a login for SSH, please consult DKTCOMEGA for user name and password.
The rst time the SSH daemon is started; two secret key les are generated.
Please note that it takes a while to generate the secret key les. The secret key les are not automati-
cally stored to ash.
Save the SSH secret key les to ash using save_conguration in the conguration le:
# Save conguration to ash memory, same SSH key is used at every boot
save_conguration
Now it is possible to log into the CPE as the user ”Administrator” (case sensitive) through SSH.
ssh Administrator@<IP address>
or
ssh -l Administrator <IP address>
or using e.g. Putty application
When logged in as Administrator, it is not possible to make any changes, as you must switch user to root
with this command:
su
Now it is possible to run all of the conguration commands, and it is possible to change the password of
the user with the command
passwd <username>
If password is changed remember save to ash with the save_conguration command.
When nished, type exit to return to the Administrator user.
To log out, type exit again.
The daemon is started by the normal conguration le by inserting the following commands (the lines
should replace the telnetd command):
# Some conguration commands
# Start SSH daemon
/etc/init.d/sshd start
# Save conguration and SSH secret les to ash
save_conguration

11
The sshd script automatically restores password- and SSH key les from ash before the SSH daemon is
started.
Procedure for changing SSH password on all CPE units.
If password for Administrator is to be changed for all CPE’s do the following:
1) Log into one CPE via ssh
2) change user to root with command su
3) cd /etc
4) change password of the CPE
5) Now copy the shadow le to a tftp server, typing “tp -p -l shadow -r shadow <TFTP Server IP Address>”
This le has to be pushed to all CPE’s
6) you can edit CPE’s conguration les by inserting the following commands:
tp -g -r shadow -l /tmp/shadow <TFTP Server IP Address> # is will get the shadow le for Administrator from
TFTP server and temporarily store this in /tmp directory
chown root /tmp/shadow # change owner of shadow
chmod 600 /tmp/shadow # change rights of shadow
mv /tmp/shadow /etc/ # move the shadow le to correct directory
save_conguration # save conguration to ash memory, now the password is saved locally on each CPE

12
configuration of snmp values
SNMP feature will be supported in a future release.
The following SNMP values can be set by the conguration le:
SysContact the administrate contact for the network
echo “syscontact techsup[email protected]” >> /etc/snmp/snmpd.local.conf
SysLocation for the location of the system
echo “syslocation somewhere” >> /etc/snmp/snmpd.local.conf
SysName the name of the system e.g the customer identication
echo “sysname customerXYZ” >> /etc/snmp/snmpd.local.conf
syslog
Syslog feature will be supported in a future release.
Support for remote logging via syslog (RFC 3164)
To start syslog, enter the following line in your conguration le
syslogd [-l <log level>] -R <Remote server IP>
The syslog daemon sends logging information in UDP packets - port 514.
If all IP addresses are handled by the DHCP server, then there is also a way that the syslog daemon may
be started by the DHCP client:
echo “-O logsrv” > /tmp/dhcp_requests.txt
/etc/init.d/udhcpc restart
The daemon will be started by the DHCP client if the log server parameter (DHCP option 7) is received in
the DHCP response.
You may control which extra DHCP options that are requested in DHCP option 55. It is done by creating a
le /tmp/dhcp_requests.txt containing just one line with a list of request commands to the DHCP client.
The format of the line is:
-O <option name> [-O <option name>] ...
The following values for <option name> are currently supported:
Name DHCP Option Description
dns 6Domain name server IP
logsrv 7 Log server IP address
hostname 12 Hostname of the box
domain 15 Domain name
serverid 54 DHCP server identier