This article demonstrates how to enable the Telnet password and secure the D6686 IPv6 Communicator from Internet based attackers, attempting to utilize the second available tunnel.
How to return the D6686 to factory settings.
How to determine which antenna to use with the B444 or B440 cellular cards.
What is the difference between the B440 antenna and the one used by the B444?
Can the antenna from the B440 be used on the B444?
Can not connect to a panel using a DX4020 and RPS?
There are a lot of things to check for when having connectivity issues between RPS and 7000/9000 series panels through a DX4020. Perform the following in order. A technician with a laptop and RPS installed on the laptop should be on site.
1.) Check for Bus Status LEDs (Red LEDs). If they are flashing, go to step 2. If they are not flashing, make sure that dip switches 1, 2, and 3 are closed (down) and dip switches 4 and 7 are open (up) (dip switches 5, 6, and 8 do not matter) and make sure that there is not a DX4010 on this panel addressed as 88 (you can only have 1 SDI address 80 and 1 SDI address 88 on the panel). If you still do not have Bus LEDs, latch down the reset pin. If they come on after this, change Enable SDI RPS to YES in the AUX / SDI RPS Parameters. If they still do not come on check wiring to the SDI bus, that the EEPROM chip on the DX4020 did not come loose, that the EEPROM on the panel is 6.0 or higher, for grounds on the panel, ensure DC voltage is ~12vDC between terminals R (power) and B (common), and disconnect all other SDI devices from the panel to eliminate the keypads and keypad wiring as issues. If after completing all of this, you still do not have bus LED status lights, replace the DX4020.
2.) Once you get the Bus Status LEDs, do a network test. This is the same thing as doing a ping from the command prompt. If they do not come back successful, go to step 3. If they do come back successful, go to step 4.
3.) If you are not successful with a network test on the panel, connect directly to the DX4020 with a crossover cable (pin 1 will be crossed with pin 3 and pin 2 will be crossed with pin 6) and try again. If you are still unsuccessful, check to ensure that your computer is on the same network as the DX4020. If it is, arp in the IP address of that card (arp –s IPaddress MACaddress). If you are running Vista, you MUST be in administrator mode to do this (go to cmd under programs – accessories, right click, and select run as administrator). Next, establish a telnet connection with the DX4020 (telnet enter, open IPaddress 1, wait for it to fail, then, enter open IPaddress 9999). If you are running Vista, telnet is not installed by default but the setup files are copied. You must add the telnet client component in Programs and Features. It is helpful with multiple LAN components to arp in the DX4020’s IP address while binding it to the specific connector which the DX4020 is attached. A main example of this would be if you have a wireless NIC and Ethernet Port. In this case put in arp –s IP_address_of_4020 MACaddress IPaddressofyoursystem. Once you are in, go to server configurations and verify the IP address, default gateway, and subnet mask. Remember that it is looking for the number of bits in the host portion of the subnet mask.
4.) Now that we have Bus connectivity (red LEDs) and can do a successful network test, try to connect to the panel and watch the SER RX and SER TX (green LEDs) on the DX4020. If the green SER RX LED comes on but not the green SER TX, go to step 5. If neither of these come on, then the data packets are not making it through the DX4020 to the serial bus for the panel to process. This can be due to the port being blocked (default port is 7700), non matching encryption keys, or a malfunctioning DX4020. While connected with a crossover cable, make sure the D6200 software is not running or use a different port than 7700. Turn off all firewalls and anti-virus software. Check to see if the receiver is running encryption and if they are, make sure the same key is in the DX4020 and in RPS. If you can now get in, but still can’t across a network, then the panel is setup correctly but a network device is down or the port or IP address is being blocked between their workstation and the panel.
5.) If you get the green SER RX but no SER TX, then the information is going through the DX4020 but the panel is not responding to the data. Telnet into the DX4020, scroll to the top line which should have the firmware version of 1.5D or higher (This must be Bosch released firmware, such as version 126.96.36.199 for a Xport-01 or version 188.8.131.52 for a Xport-03, to support Datagram type 02). The second line should have AES firmware version. If the card does not meet those requirements, download and update the firmware to the latest revision. If it does, verify the correct datagram type in channel 1 configurations. If the panel firmware revision is a G panel 7.0 or GV2 panel 7.06 or higher, you must use datagram type 02. Otherwise use datagram type 00. If you are using datagram type 02, you must use RPS version 5.5 or higher. If the green ser RX LED stays on, check that the baud rate and other settings are set to 9600, no parity with 1 stop bit, and force RTS and DTR are forced on in the AUX portion of the panel, and verify correct datagram is being used in the DX4020. The panel will not reply to invalid RAM pass codes over the SDI bus, thus will never reply with an invalid RAM pass code. Check the RAM pass code with another system that CAN get in, or with a D5200 programmer and use that in place of the ****** when connecting to the panel.
6.) If you continue to have issues after checking these things, contact Bosch Technical Support for further assistance.
Notes: If you can connect locally but not remotely, then the problem is not with the panel or DX4020. If at the remote location, they can connect to the same type of panel with the same firmware locally, then the problem lies in the network. It is important to note that the port used by RPS is UDP and must be open to inbound and outbound traffic on all routers and firewalls. This includes your own computer. Windows, Symantec, Norton, AVG, Trend Micro, MaCafee, and numerous other Operating Systems and Anti-Virus software come with some form of firewall built into them. For this reason, disable all these types of applications for the initial connection to verify that we can connect. After we know that we can connect, then build exceptions for the UDP port (default is 7700) in your applications.