Dlink DIR-320 for organizing a backup channel
You know how it sometimes happens: immersed in the fantastic world of new knowledge, you sit, relax, in front of the manual, and then a hysterical subject flies in, throwing thunder, lightning and caviar. When it is possible to extinguish an explosion of emotions, the situation will begin to clear up.
So, the essence of the problem: there is a certain computer / terminal in a hard-to-reach place, to which a not very stable communication channel is organized. If there is no connection at the right moment, this terminal becomes the site of a local whirlwind, in the whirlwind of which everything is worn, from small to large.
The essence of the task: to organize a backup communication channel with auto-switching to it, in the event of the main crash and back when the main one rises.
In this publication, I will describe my decision on the memorable DLink DIR-320.
I spent a lot of time searching in vain first for methods and implementations, then for firmware and scripts, before I came to the answer. I hope this information will be useful.
For some reasons, the connection at this point leaves much to be desired. After several precedents, the list was on the table.
Quite an ordinary task, it would seem, but I have not yet come across it in this form.
The thinking and exploratory processes produced the following variants:
1. To get an alternative provider on our router (cisco 2801) and arrange switching via ip sla .
2. In parallel with our wired connection, start an alternative provider directly to the terminal and organize switching using a proxy server or scripts.
3. Actually install DLink in front of the terminal and organize switching on it.
The first, the most preferred option, had to be dropped immediately, as the indicated tsiska does not support ip sla (or I was looking badly). Here it is generally interesting that out of a whole fleet of routers, only one 3550 supports it to the extent it is needed.
')
The variant with the software on the terminal seems to be unreliable, and plus for that for the sake of these purposes, some UserGate was not very desirable. Scripts on the final machine, even if they are in the scheduler, look more like crutches.
In general, in the end, I chose the “iron” solution: Dlink - especially since I heard about the existence of alternative firmware with redundancy support.
But in fact, as usual, everything was not so easy.
The first and last, seemingly step: find the firmware that supports 3G modems and backup. The latter brand is completely connected to the 3G network, but, unfortunately, there is no way to configure the simultaneous operation of two channels and it does not have a CLI.
Pretty quickly managed to find the firmware with the required parameters. It turned out to be some semi-official software with support for WiMAX and 3G modems. It is a nice interface, convenient and logical. It even had a real “Backup” item in which you can configure two addresses to check availability, the main channel and the backup one. Of course, this did not work, otherwise there would not be this article. Switching occurred only in one direction: from the modem to the wire, and the modem was considered the main one. No efforts to remedy the situation failed. Access to the command line of the device was closed, so that the freedom of flight of thought was limited to the strict framework of the web interface.
The search continued. Some of the firmware was not installed, the other did not have a telnet, and the third did not understand the connection of USB devices.
And finally, I found it: an ugly, but free - firmware for the Asus model . She easily and permanently sat down in the memory of the device. The web-face didn’t really succeed, but we don’t drink honey from it. The command line in all its glory, USB-devices were completely defined, support for 3G modems from the box was implied, but still failed to connect to the network from the web interface, PPP logs are silent.
Well, there was only a way of this ITshnik: the console. Fortunately, the firmware is based on Linux.
The task is as follows:
1) Keep two connections active at the same time: cable and 3G,
2) Check periodically the availability of a particular host,
3) In case of its inaccessibility, change the default route via the cable interface to the PPP (3G) interface
4) In case of restoration of the channel, change the route back.
Since the modem settings do not work from the web interface, it must be connected via a script.
In the course of the work it became clear that we cannot do without pitfalls.
1) In the routing table, there are simultaneously two default routes with the same metric: via the ppp0 (3G) interface and via vlan1 (WAN). Priority is considered a wired connection. Since it is impossible to simply change the route metric in Linux, the route through the vlan1 interface, in which case, we will delete or add.
2) Tests have shown that it is not enough just to change the default route. There is a connection from DLinka itself, but not from the end machine. After a brief mental effort, it becomes clear that NAT does not work. NAT rules remain from the previous connection and packets from the computer are lost on the DLink. In this case, I may have made it inefficient, but at the same time as the route was removed / added, a new NAT rule is applied.
3) A very unpleasant inexplicable moment: in case of unavailability of the host via a wired connection, 3G falls off in 15-20 seconds. And it falls off so that the physical reboot of the router is necessary. But if you have time to transfer the route to the modem during this time, then everything works fine.
Crontab does not allow running scripts more than once per minute. You can make a script that 10 times, for example, runs in a cycle and once a minute run it on the crown. But after a series of tests, it turned out that somehow it worked crookedly, as if not every 6 seconds, as it should. Therefore, we had to dwell on the variant of the infinite loop with a delay, which will be launched when the device starts. Delay selected in 2 seconds.
4) To configure the modem, you need the Vendor ID and Product ID parameters. In Linux, they are easy to recognize using the lsusb command. It will return a list of devices connected via USB-interface, in which in the format Vendor ID: Product ID (two 4-digit values) there will be necessary parameters. Two notes: in DLink, there is no such command and you need to add another 0x to the specified lines first.
5) It is problematic to set a host on the Internet to check access. It will be available via a modem and after the restoration of the wired channel, the condition will not work. I came out not in the most beautiful way, but quite effective: I ping the host of my local network; to do this, it is enough to set the autoload to add a static route to this network via the WAN interface. However, no one forbids to set a route to the address xyzw 255.255.255.255 on the Internet through this interface - the result will be the same.
6) After all the changes in the command line, you need to save them with the following commands:
nvram commit
flashfs enable
flashfs save
flashfs commit
Minimum settings via the web interface: set the WAN IP address:
However, even this can be done on the command line (ifconfig, route)
Frankly, part of the script for connecting a modem and post-loading, I inherited by inheritance, so the author of the lines is not known to me, but thanks a lot to this person.
All necessary scripts with comments are attached to the article:
1. post-boot - the main script that runs after the device starts.
It runs the LED control script, adds the route we need, runs the modem.sh and pingtest.sh scripts .
2. ledctl - LED control script
3. modem.sh - script for connection via modem
4. pingtest.sh - script to check node availability and switch routes
5. Dlink.sh - summary file: corrected the necessary parameters, copied from the editor, inserted into the console and executed.
In the original, I corrected only the necessary parameters and commented out what is not needed.
The scheme of work is as follows:
After the device starts, the post-boot script is launched, which sets the necessary parameters, including adding the route we need to the local network
This script runs modem.sh and pingtest.sh. Modem.sh runs only once until it connects to the network.
Pingtest.sh runs in the memory of the router all the time and every two seconds checks the availability of the host.
There are three options for migrating these scripts:
a) copy them to a flash drive, mount it to the fs router and transfer it to the desired directory,
b) create them through the built-in editor vi (I will not wish the enemy)
c) insert the lines in order into the file with the echo command (this method is implemented in the Dlink.sh file)
Download scripts
Yes, there are other ways out of this situation, such as using ready-made solutions (DrayTek VigorFly 200) or sharpening a more logical and simple piece of hardware on the Mikrotik, but the main requirements were “now and cheap”.
In the course of working on this task, I gained some experience. Even while it is difficult to say whether it is useful. However, almost any experience is better than none.
===================================
Interfaces:
br0 - LAN
vlan1 - WAN
ppp0 - interface via 3G modem
====================================
This photo shows the results of the ping, how the response time changes when the channel is switched:
By the way, when switching from a wireless channel to a wired one, ping stops until you restart it. That is, when surfing, the switch will be completely invisible, but the download may be interrupted.
====================================
Routing table:
Kernel IP routing table
=====================================
Logs (tail -f / usr / tmp / syslog) of successful connection to the 3G network:
UPD.
I have not had to face the following problem, but in the comments a dinam user warns that there is a good old DIR-320 , and there is a new device based on another Ralink chipset, DIR-320NRU , which does not have alternative firmware.
It differs from the DIR-320 with the inscription " H / W ver ": B1 on the case instead of " H / W ver: A1 "
So, the essence of the problem: there is a certain computer / terminal in a hard-to-reach place, to which a not very stable communication channel is organized. If there is no connection at the right moment, this terminal becomes the site of a local whirlwind, in the whirlwind of which everything is worn, from small to large.
The essence of the task: to organize a backup communication channel with auto-switching to it, in the event of the main crash and back when the main one rises.
In this publication, I will describe my decision on the memorable DLink DIR-320.
I spent a lot of time searching in vain first for methods and implementations, then for firmware and scripts, before I came to the answer. I hope this information will be useful.
Decision
For some reasons, the connection at this point leaves much to be desired. After several precedents, the list was on the table.
Quite an ordinary task, it would seem, but I have not yet come across it in this form.
The thinking and exploratory processes produced the following variants:
1. To get an alternative provider on our router (cisco 2801) and arrange switching via ip sla .
2. In parallel with our wired connection, start an alternative provider directly to the terminal and organize switching using a proxy server or scripts.
3. Actually install DLink in front of the terminal and organize switching on it.
The first, the most preferred option, had to be dropped immediately, as the indicated tsiska does not support ip sla (or I was looking badly). Here it is generally interesting that out of a whole fleet of routers, only one 3550 supports it to the extent it is needed.
')
The variant with the software on the terminal seems to be unreliable, and plus for that for the sake of these purposes, some UserGate was not very desirable. Scripts on the final machine, even if they are in the scheduler, look more like crutches.
In general, in the end, I chose the “iron” solution: Dlink - especially since I heard about the existence of alternative firmware with redundancy support.
But in fact, as usual, everything was not so easy.
The first and last, seemingly step: find the firmware that supports 3G modems and backup. The latter brand is completely connected to the 3G network, but, unfortunately, there is no way to configure the simultaneous operation of two channels and it does not have a CLI.
Pretty quickly managed to find the firmware with the required parameters. It turned out to be some semi-official software with support for WiMAX and 3G modems. It is a nice interface, convenient and logical. It even had a real “Backup” item in which you can configure two addresses to check availability, the main channel and the backup one. Of course, this did not work, otherwise there would not be this article. Switching occurred only in one direction: from the modem to the wire, and the modem was considered the main one. No efforts to remedy the situation failed. Access to the command line of the device was closed, so that the freedom of flight of thought was limited to the strict framework of the web interface.
The search continued. Some of the firmware was not installed, the other did not have a telnet, and the third did not understand the connection of USB devices.
And finally, I found it: an ugly, but free - firmware for the Asus model . She easily and permanently sat down in the memory of the device. The web-face didn’t really succeed, but we don’t drink honey from it. The command line in all its glory, USB-devices were completely defined, support for 3G modems from the box was implied, but still failed to connect to the network from the web interface, PPP logs are silent.
Well, there was only a way of this ITshnik: the console. Fortunately, the firmware is based on Linux.
The task is as follows:
1) Keep two connections active at the same time: cable and 3G,
2) Check periodically the availability of a particular host,
3) In case of its inaccessibility, change the default route via the cable interface to the PPP (3G) interface
4) In case of restoration of the channel, change the route back.
Since the modem settings do not work from the web interface, it must be connected via a script.
Details and obstacles
In the course of the work it became clear that we cannot do without pitfalls.
1) In the routing table, there are simultaneously two default routes with the same metric: via the ppp0 (3G) interface and via vlan1 (WAN). Priority is considered a wired connection. Since it is impossible to simply change the route metric in Linux, the route through the vlan1 interface, in which case, we will delete or add.
2) Tests have shown that it is not enough just to change the default route. There is a connection from DLinka itself, but not from the end machine. After a brief mental effort, it becomes clear that NAT does not work. NAT rules remain from the previous connection and packets from the computer are lost on the DLink. In this case, I may have made it inefficient, but at the same time as the route was removed / added, a new NAT rule is applied.
3) A very unpleasant inexplicable moment: in case of unavailability of the host via a wired connection, 3G falls off in 15-20 seconds. And it falls off so that the physical reboot of the router is necessary. But if you have time to transfer the route to the modem during this time, then everything works fine.
Crontab does not allow running scripts more than once per minute. You can make a script that 10 times, for example, runs in a cycle and once a minute run it on the crown. But after a series of tests, it turned out that somehow it worked crookedly, as if not every 6 seconds, as it should. Therefore, we had to dwell on the variant of the infinite loop with a delay, which will be launched when the device starts. Delay selected in 2 seconds.
4) To configure the modem, you need the Vendor ID and Product ID parameters. In Linux, they are easy to recognize using the lsusb command. It will return a list of devices connected via USB-interface, in which in the format Vendor ID: Product ID (two 4-digit values) there will be necessary parameters. Two notes: in DLink, there is no such command and you need to add another 0x to the specified lines first.
5) It is problematic to set a host on the Internet to check access. It will be available via a modem and after the restoration of the wired channel, the condition will not work. I came out not in the most beautiful way, but quite effective: I ping the host of my local network; to do this, it is enough to set the autoload to add a static route to this network via the WAN interface. However, no one forbids to set a route to the address xyzw 255.255.255.255 on the Internet through this interface - the result will be the same.
6) After all the changes in the command line, you need to save them with the following commands:
nvram commit
flashfs enable
flashfs save
flashfs commit
Customization
Minimum settings via the web interface: set the WAN IP address:
However, even this can be done on the command line (ifconfig, route)
Scripts
Frankly, part of the script for connecting a modem and post-loading, I inherited by inheritance, so the author of the lines is not known to me, but thanks a lot to this person.
All necessary scripts with comments are attached to the article:
1. post-boot - the main script that runs after the device starts.
It runs the LED control script, adds the route we need, runs the modem.sh and pingtest.sh scripts .
2. ledctl - LED control script
3. modem.sh - script for connection via modem
4. pingtest.sh - script to check node availability and switch routes
5. Dlink.sh - summary file: corrected the necessary parameters, copied from the editor, inserted into the console and executed.
In the original, I corrected only the necessary parameters and commented out what is not needed.
The scheme of work is as follows:
After the device starts, the post-boot script is launched, which sets the necessary parameters, including adding the route we need to the local network
This script runs modem.sh and pingtest.sh. Modem.sh runs only once until it connects to the network.
Pingtest.sh runs in the memory of the router all the time and every two seconds checks the availability of the host.
There are three options for migrating these scripts:
a) copy them to a flash drive, mount it to the fs router and transfer it to the desired directory,
b) create them through the built-in editor vi (I will not wish the enemy)
c) insert the lines in order into the file with the echo command (this method is implemented in the Dlink.sh file)
Download scripts
Yes, there are other ways out of this situation, such as using ready-made solutions (DrayTek VigorFly 200) or sharpening a more logical and simple piece of hardware on the Mikrotik, but the main requirements were “now and cheap”.
In the course of working on this task, I gained some experience. Even while it is difficult to say whether it is useful. However, almost any experience is better than none.
Applications
===================================
Interfaces:
br0 - LAN
vlan1 - WAN
ppp0 - interface via 3G modem
====================================
This photo shows the results of the ping, how the response time changes when the channel is switched:
By the way, when switching from a wireless channel to a wired one, ping stops until you restart it. That is, when surfing, the switch will be completely invisible, but the download may be interrupted.
====================================
Routing table:
Kernel IP routing table
=====================================
Logs (tail -f / usr / tmp / syslog) of successful connection to the 3G network:
Running modem.sh
Aug 17 05:51:37 kernel: usb.c: registered new driver serial
Aug 17 05:51:37 kernel: usbserial.c: USB Serial support registered for Generic
Aug 17 05:51:37 kernel: usbserial.c: Generic converter detected
Aug 17 05:51:37 kernel: usbserial.c: Generic converter now attached to ttyUSB0 (or usb/tts/0 for devfs)
Aug 17 05:51:37 kernel: usbserial.c: Generic converter detected
Aug 17 05:51:37 kernel: usbserial.c: Generic converter now attached to ttyUSB1 (or usb/tts/1 for devfs)
Aug 17 05:51:37 kernel: usbserial.c: Generic converter detected
Aug 17 05:51:37 kernel: usbserial.c: Generic converter now attached to ttyUSB2 (or usb/tts/2 for devfs)
Aug 17 05:51:37 kernel: usbserial.c: USB Serial Driver core v1.4
Aug 17 05:51:52 pppd[508]: pppd 2.4.5 started by admin, uid 0
Aug 17 05:51:55 pppd[508]: Serial connection established.
Aug 17 05:51:55 pppd[508]: Using interface ppp0
Aug 17 05:51:55 pppd[508]: Connect: ppp0 <--> /dev/usb/tts/2
Aug 17 05:51:58 pppd[508]: Could not determine remote IP address: defaulting to 10.64.64.64
Aug 17 05:51:58 pppd[508]: local IP address 10.117.240.93
Aug 17 05:51:58 pppd[508]: remote IP address 10.64.64.64
Aug 17 05:51:58 pppd[508]: primary DNS address 85.26.231.218
Aug 17 05:51:58 pppd[508]: secondary DNS address 83.149.49.70
Aug 17 05:51:58 Static: connected to ISP
UPD.
I have not had to face the following problem, but in the comments a dinam user warns that there is a good old DIR-320 , and there is a new device based on another Ralink chipset, DIR-320NRU , which does not have alternative firmware.
It differs from the DIR-320 with the inscription " H / W ver ": B1 on the case instead of " H / W ver: A1 "
Source: https://habr.com/ru/post/130796/
All Articles