DKTCOMEGA CPE Frequently Asked Questions (FAQ)
Answer:
Answer:
The device is born without firmware, so an appropriate firmware needs to be provisioned to the device via DHCP using options.
The device will in its DHCP Discoverer message indicate a “vendor-class-identifier = DKT_firstboot”, which the DHCP server should respond to with a specific firmware version to be offered, with the filename option, e.g.
filename "dkt_fw_01_06.img";
then configuration file, which holds the device configuration parameters, needs to be provisioned with the bootfile-name option, e.g.
option bootfile-name "MyCPE_Config.txt";
Please note that the CPE will request via DCHP discoverer a set of parameters (options), which all needs to be answered by the DHCP server. In any one of them is not answered, then correct boot process can’t be obtained.
Please refer to the user documentation (click
here) for details about the DHCP option settings.
Answer:
For the WAN port (fiber) connection you can write the following command either in the config script or in the command line (if you TELNET into the device, or try it in the script also):
for firmware revision earlier than 01_06_08 - mii_diag eth0 -p 16 -F 100BaseTx-FD.
for firmware revision 01_06_08 or later - switch --set-port-autonegotiation=
:<0|1>
This will change from auto negotiation to 100 BASE Full duplex. Typically we do not recommend customers to run in forced full duplex mode, but instead use the auto negotiation, however if some products have difficulties supporting that, a forced speed change is required.”
NOTE: For firmware revision 02_01 and later auto negotiation is disabled per default.
Answer:
In the generic configuration 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 :)
tftp -g -r my_conf_$WAN_MACADDR -l /tmp/config.sh $TFTP_SERVER
save_configuration
source /tmp/config.sh
Then your TFTP server should hold a library of all different device config files
Alternatively the following could be added to the dhcp configuration (works for DHCP3 on Linux), th will set the boot file-name to the client MAC address:
option bootfile-name = concat (suffix (concat ("0", binary-to-ascii (16, 8, "", substring (hardware, 1, 1))), 2),
suffix (concat ("0", binary-to-ascii (16, 8, "", substring (hardware, 2, 1))), 2),
suffix (concat ("0", binary-to-ascii (16, 8, "", substring (hardware, 3, 1))), 2),
suffix (concat ("0", binary-to-ascii (16, 8, "", substring (hardware, 4, 1))), 2),
suffix (concat ("0", binary-to-ascii (16, 8, "", substring (hardware, 5, 1))), 2),
suffix (concat ("0", binary-to-ascii (16, 8, "", substring (hardware, 6, 1))), 2));
Answer:
Yes, during boot process the CPE will generate a DHCP discoverer holding DHCP option 60 indicating the Vendor_Class_Identifier, which includes the current device firmware version, e.g. DKT_Firmware_v01_06. The DHCP server configuration file can be programmed to react to this option and provision a specific configuration based on this information.
Explaination about DHCP option 60:
A DHCP client sends vendor information in all DHCP packets that it sends to the DHCP server to indicate the vendor or the version of the operating system running on the client. This information is sent in the form of a vendor-class identifier option, as specified in RFC2132 section 9.13.
The DHCP servers implementing this specification use the information contained in this option to determine whether a client implements this specification and whether the options defined in this specification should be sent to it. For semantics on the usage of vendor class identifiers, refer to RFC2132 sections 8.4 and 9.13.
Answer:
The following instructions can be inserted in the DHCP server settings, please note that host name, IP and MAC Addresses are examples:
host dkt1 {
next-server 10.3.13.250;
server-name "10.3.13.250";
hardware ethernet 00:19:9f:00:09:ac;
fixed-address 10.3.111.10;
}
Answer:
Yes, please refer to support tab on www.dktcomega.com for the latest MIBs. These can be integrated with network management application that supports MIB-II.
Answer:
For security reasons the device will not allow any TELNET sessions per default. In order to overrule this setting, please insert the following instruction into the configuration script, which is provisioned to the device during boot up:
telnetd -l /bin/sh
Please note: this instruction has to be the last instruction in the script file!
Answer:
The script provisioned to the CPE at boot up is an ash shell type.
Answer:
For security reasons the device will not allow any switching between the LAN or WAN ports, per default. This can be overruled with the instruction:
switch --enable-lan
Then the device will be programmed to support simple switching between the ports. Please note that CPU port is not accessible from any of the LANs ports, hence communication with the onboard CPU is only possible from the WAN port side.
Answer:
DKTCOMEGA 79203, 79260:
The 4-port managed 100 Mbps CPE is a bi-directional 100 BASE-Bx-U type, running 1310 nm Tx/1550 nm RX – SC/PC type. The link partner, typically an access switch needs to operate the opposite, 100 BASE-Bx-D type.
The CATV Rx module is running 1550 nm Rx – SC/APC type.
Answer:
The DHCP server and TFTP server doesn’t need to be the same physical server. The DHCP server will serve the CPE with an IP Address, and via the option tftp-server-name ""; e.g.
option tftp-server-name “192.168.1.1”
the pointer to the TFTP server is provided. The CPE will then make a TFTP request for the device firmware (if applicable) and configuration, respectively.
Answer:
Yes, please refer to support tab on www.dktcomega.com for the latest MIBs. These can be integrated with network management application that supports MIB-II. The catvSwitch object in dkt_catv.mib can be programmed to turn the CATV module on/off.
Alternatively a TELNET or reboot of the CPE can be made and a new configuration script holding the following instruction can be provisioned:
switch -c 0
Answer:
Yes, please refer to support tab on www.dktcomega.com for the latest MIBs. These can be integrated with network management application that supports MIB-II. The reboot object in dkt_generic.mib can be programmed to reboot the device.
Alternatively a TELNET session to the device can be made (remember to grant access with the instruction: telnetd -l /bin/sh in the configuration script), and type the reboot command.
Question: Can't control bandwidth management via IEEE 802.3x (Flow Control)
Answer:
Per default flow control is disabled on all ports, so switch engine will ignore any PAUSE frames received, and will not parse these frames. It is possible to enable flow control on each of the ports with the syntax:
switch --enable-port-flowcontrol=
:<0|1>
Question: IGMP snooping, how to configure blocking of unknown multicasts
Answer:
In order to ensure a smooth, quick and continued IPTV experience, it is important to configure the switch behavior correctly. First of all it is important to shut off multicast traffic not designated for the STBs in use. Per default the CPE has an IGMP program running, which will make the approprieate switch filter settings for the multicast group, however the individual ports must be configured to block for the unwanted traffic. The same goes for the CPU port (port 5), so the following syntax should be used:
switch --enable-port-block-unknown-multicast=1:1 # Blocks all Multicast Ethernet frames destinated for LAN port 1 with address not present in CPE Address Translation Unit
switch --enable-port-block-unknown-multicast=2:1 # Blocks all Multicast Ethernet frames destinated for LAN port 2 with address not present in CPE Address Translation Unit
switch --enable-port-block-unknown-multicast=3:1 # Blocks all Multicast Ethernet frames destinated for LAN port 3 with address not present in CPE Address Translation Unit
switch --enable-port-block-unknown-multicast=4:1 # Blocks all Multicast Ethernet frames destinated for LAN port 4 with address not present in CPE Address Translation Unit
switch --enable-port-block-unknown-multicast=5:1 # Blocks all Multicast Ethernet frames destinated for CPU port with address not present in CPE Address Translation Unit
The drawback is that broadcast frames are treated multicast frames by the switch, so e.g. ARP packets could be discarded due to the above. This would cause that management of the CPE (done through port 5 CPU port) could be lost, due to ARP request frames from a management host would be filtered by the CPE switch before they arrive to the CPE CPU, due to the block of multicast frames on port 5. Workaround is to use the Copy of ARP frames to CPU port feature. Adding the following syntax to the configuration will pass all ARP frames to the CPE CPU, hence the blocking filter is bypassed:
switch --set-arp-mirroring=0:1 # Enables ARP mirroring for port 0 (WAN), so all incoming ARPs seen on WAN ports wil be copied to CPU port
The functionality works from firmware revision 02_13 and forward.
