Portserver Ts 4 Firmware
Verline
I have a RV50 that I am trying to set up port forwarding for a NI cRIO (cRIO runs real time Linux). I have setup the ports that I want to forward, but when I check with telnet on the cRIO, only some of the ports that I requested are open.
Hi Andrew,
The pop-up issue when updating radio firmware is known issue on version 4.13
image1270447 40.3 KB
It is not the root cause for port-forwarding.
If there are some ports can be forwarded, it means that the port-forwarding function is working.
Could you help to share which ports are not forwarded?
There are some ports that are used by RV50, so if you set up these ports for forwarding, it could be conflicted and these ports are not opened on your cRIO.
When I mentioned telnet in the original post I was mistaken, I am using an online port forwarding checker to see if they are open ( -ports/). I am checking ports using the same IP address I use to access the modem through the web (minus the 9191), which I believe is right. I work remotely so I do not have access to the cRIO display directly. I do have another cRIO that I was doing some checking with telnet on and got the two confused!
We purchased the ConnectPort LTS 16 port MEI RS232/422/485 RJ-45 terminal server. I need to find out what the current firmware version is and if it is patchable? I also need to know the current BIOS version.
We use cookies to provide our visitors with an optimal site experience. View our privacy notice and cookie notice to learn more about how we use cookies and how to manage your settings. By proceeding on our website you consent to the use of cookies.
Hi, currently, i am facing the same issue. any suggestions? i tried installing the agentless mgt service, it started showing the ports but later when i rebooted the server the AMS gone and port status went unknown once again. i did upgrade the firmware! how did you solve this or was it never resolved?
Most devices supported by OpenWrt have or can be modified to have a serial port. These serial ports typically provide a console to the bootloader and, when the firmware has booted, a console to the running system. A console to the running system will let you correct a misconfigured network, for example. Console access to the bootloader will often allow one to fetch and flash new firmware and may be the only way to do so on some routers if the firmware is not functional.
Most routers come with an UART integrated into the System-on-chip and its pins are routed on the Printed Circuit Board (PCB) to allow debugging, firmware replacement or serial device connection (like modems).
Once OpenWrt starts running, it is generally possible to enter failsafe mode with a terminal program attached to the serial port. Either in failsafe mode, or with OpenWrt running in normal mode, it is generally possible to enter commands the same way one would if using ssh over a network. One advantage is that if you've somehow configured your router so that the network or ssh isn't working, you can still access your router to manage it.
While a functional serial port can't protect you from a damaged bootloader or other low-level problems, it can be used to resolve many user-configuration errors, including, with luck, when the cat pulled the plug on your router as you were flashing it:-/
For low-level developers, or those that choose to flash their own bootloader, accessing the JTAG port may be the next step, as the serial port requires functional software (either the bootloader or a running system) to be useful. JTAG access falls into the realm of expert use. It is mentioned here mainly as a reminder that flashing a bootloader, no matter how many have been successful before you, is a risky endeavor that a serial port may not allow recovery from errors.
For help with the latter two, see soldering. But even if there is 9-pin D connector, beware the Voltage levels! While some may refer to this as an RS-232 or RS-422 interface, in most cases the voltage levels associated with those specifications are inappropriate and may permanently damage your router.
Also, in many modern devices you will only have 3-5 pins or holes, and that would be a TTL serial connection, requiring a TTL-USB dongle, which can be bought for real cheap from ebay or Amazon or any reputable DIY electronics seller as they are used to communicate with Arduino boards and other microcontroller-based IoT development boards.
Hint: In case of unpopulated holes in the shape of a SubD9, try fitting the pins from a disassembled SubD9 male plug into the holes instead of soldering the cable directly to the board. Fit perfectly on unbricked Asus and TP-Link routers and leaves no trace.
Sometimes by shortcutting some pins, connecting them to ground or to power you can change the serial mode. Some of them can help you to restore the bootloader since they allow you to write directly to memory or load something to ram through the serial connection, which can be useful for restoring a bootloader. Also if the original bootloader is password protected with this method you can replace it with a custom bootloader and bypass it.
For example in Lantiq Danube SoCs the default mode is CFG 01, but changing to CFG 04 which is known as UART mode allows you to upload to ram through the serial connection and automatically execute a bootloader in ascii format through the serial connection.
In order for the serial console to work, the logic levels on the wires should match those expected by your device. The first step therefore is to determine which voltage levels are required. Often, you can find this documented on the OpenWrt wiki or elsewhere. If you can't determine the voltage based on a clear description in the OpenWrt page for your device or your own knowledge of electronics, you should probably stop here until you are reasonably certain of the voltage levels required.
In case your device is using a TTL connection or what seems to be a TTL connection, you can try to find out by trial and error, at the risk of burning the USB-TTL dongle or to damage the OpenWrt device.
Reversing Rx and Tx will not damage anything (it may will result in garbled text on your terminal), as long as the pins or holes are indeed a TTL port. If it is not a TTL port then you could probably damage your OpenWrt device, or (more commonly) burn the USB-TTL dongle.
If you find something else, for example, that TX is shorted (0 Ohms) or that RX is open (OL = Open Line),this may mean that there is a resistor connecting a pin to GND that must be removed,or a resistor missing that is disconnecting the pin from the traces.
You will need a terminal emulation program on your computer (aka: client-device), such as minicom, hyperterminal, etc to communicate with your router's serial port (aka: host-device's serial port) to talk-with & listen-from router. This type of terminal emulation programs are also known as: communication tool/app. These communication terminal emulation programs need to be configured, to be compatible with your router (host-device), in particular, with regard to baud rate and flow control. If you are using only three wires (GND, TX, and RX) then hardware flow control should be turned off; you aren't using the pins (RTS and CTS) necessary for it to work. Rarely, the baud rate that the device expects might be different in the bootloader and the running firmware; if so, you'll need to modify the baud rate settings in your terminal emulator after the firmware boots up.
Terminal emulation software can interact with users via GUI1, TUI1, or CLI1 interface. Some terminal emulator software are specially programed/developed, to allow us communicate with remote device/terminal or local device/terminal or responder, so also known as: Communication tool. Some of such specially developed (communication) software/tool/app has its own GUI interface, and some (communication) software/tool/app needs to run inside/under a running shell.
Under a Desktop OS Linux distro the access to the serial adapter requires root permissions. We can override this behavior by making an udev rule. Create the file /etc/udev/rules.d/60-ttyUSBx.rules with this content:
First disable the console in the router you want to use it as a serial console adapter and install screen in it. Connect to the target router the serial pins, and then execute screen in the first router:
If you successfully receive router bootup logs but seem unable to send data (e.g. some keyboard input which might be required to intercept bootup, and where you're unable to stop continued kernel bootup), then this may be due to having configured the connection as hardware flow control rather than software (happened on TL-WDR3600 in my case).
For routers with a built in USB-connector (such as WNDR3700 for example), simply plugging in a USB-serial converter and installing the appropriate software will provide a serial console to the router.
Be aware, using this method relies on the kernel loading the modules so will only work once OpenWrt is up and running. It won't bring you the possibility to use the bootloader console to reflash since the USB drivers on the router won't be running.
These days, computer manufacturers are dropping RS232 serial ports, while USB ports are increasingly ubiquitous. Particularly if you need to TTL logic levels, USB is probably the way to go since you can get the right logic levels (the voltage) integrated in the USB-TTL converter.
If the serial port pinout is not shown on your model's devicepage, do a Google search. Most of the time, the serial port(s), if they exist, have already been documented by others. If methods listed here are not enough for you, consider to go deeper reading -engineering-serial-ports/
c80f0f1006