Wirenboard6:InstallingOnTheRemoteSite/en: различия между версиями
(Новая страница: «To send MQTT messages from the controller to the cloud service, the MQTT bridge is used, the configuration of which is configured on the controller in the file <c…») |
|||
(не показано 10 промежуточных версий этого же участника) | |||
Строка 359: | Строка 359: | ||
</pre> | </pre> | ||
Затем выполните команду | |||
<pre> | <pre> | ||
Строка 366: | Строка 366: | ||
Если вы хотите передавать данные на несколько серверов одновременно, создайте несколько разделов <code>connection</code>. | |||
== | == Возможные неполадки GPRS-соединения == | ||
Возможных причин отсутствия GPRS-подключения может быть несколько. | |||
* | * Закончился оплаченный лимит трафика. | ||
* | * Низкий уровень сигнала, плохой контакт антенны. | ||
* | * СИМ-карты некоторых операторов рассчитаны только на 4G-сети, 3G-подключение установить с ними не получится. | ||
* | * Проверьте, правильно ли вставлена СИМ-карта в слот. | ||
* | * Возможно, СИМ-карта нерабочая. | ||
* | * Ваш тарифный план не предусматривает пакетную передачу данных. | ||
Прежде чем идти в личный кабинет и звонить провайдеру, можно выполнить ряд простых проверок. | |||
Запустите команду | |||
<pre>gammu networkinfo</pre> | <pre>gammu networkinfo</pre> | ||
Строка 396: | Строка 396: | ||
</pre> | </pre> | ||
Важно, что контроллер подключен к пакетной сети передачи данных <pre>(GPRS : attached)</pre> и GPRS-соединение установлено. | |||
После этого оцените уровень сигнала в minicom командой <code>AT+CSQ</code> | |||
Вы получите результат в виде <code>13,99</code> | |||
Первая цифра показывает мощность сигнала: > 9 — удовлетворительный, > 14 — хороший, > 19 — отличный. Низкие и нестабильные значения CSQ означают, что антенна плохо расположена, неаккуратно подключена, радиообстановка неблагоприятная. | |||
Если обе проверки пройдены, но связи нет, обратитесь к провайдеру (загляните в личный кабинет), можете проверить СИМ-карту в смартфоне. |
Версия 19:40, 27 июня 2019
Внимание: Отображаемое название «Wiren Board 6: Installing On The Remote Site» переопределяет ранее заданное отображаемое название «WirenBoard6:InstallingOnTheRemoteSite».
This article highlights the network aspects of professional installation of the controller in industrial and commercial facilities.
Choosing a network configuration controller
The Wiren Board 6 controllers come with a different set of network devices. It is necessary to understand in what conditions the controller will be operated and what equipment will be optimal.
Minimum equipment
Controllers Wiren Board 6 have two Ethernet-interfaces 100 Mbit/s (eth0, eth1) on board in any configuration.
Advanced features
Optionally, the controllers come with Wi-Fi interface (wlan0) (802.11 bgn 2.4 G), 3G modem (WCDMA/HSPA, GSM/GPRS/EDGE) or 2G modem (GPRS). With any of them you can connect the controller to the Internet, and with Ethernet and Wi-Fi — also connect to the local network. 3G-modem is implemented on SIMCom SIM5300E chip, 2G-modem is implemented on SIMCom SIM800 or Neoway M660A chips, Wi-Fi — on Realtek 8723BU chip.
Factory configuration of network devices
Ethernet
In the factory configuration, both Ethernet interfaces and Wi-Fi and loopback are configured in the controller. The network settings file is /etc/network/interfaces
. Interfaces eth0/1 have no fixed address and get Sammie settings via DHCP.
Wi-Fi
On Wi-Fi interface wlan0 by default is the open hotpoint with the fixed address 192.168.42.1, clients receive addresses on DHCP which are distributed by dnsmasq daemon in the range of 192.168.42.50 — 192.168.42.150
.
The SSID of the wireless controller network is formed from the prefix “WirenBoard-” and the serial number of the controller printed on the side sticker. In a wireless network, the controller has not only an IP address, but also DNS aliases for easy connection, wiren
, wiren.local
, wiren_board
, wirenboard.local
, wirenboard
.
GPRS
Cellular data connection is not enabled by default and requires configuration. The controller has slots for installation of SIM-cards, but currently the software is only supported first.
Optionally, the controller is equipped with 3G or 2G-modems (modems are non-removable and soldered on the Board at the factory).
3G-модем
The modem is represented in the system by two devices: /dev/ttyGSM
(link to one of the console ports ttymxc), connected to the UART-interface of the modem chip, and a composite USB-device /dev/ttyACM0-6
, used for communication ttyACM0
. The limitations of the UART port do not allow to realize the full potential of data transfer rate in 3G networks (theoretically up to 7.2 Mbit/s for reception and up to 5.76 Mbps for transmission). The port ttyACM0 is limited only by the transmission speed of USB2.0 (theoretically, up to 280 Mbps).
The presence of two interfaces allows you to simultaneously use the first device (/dev/ttyGSM
) to send AT-commands (to know the level of the cellular signal, send SMS, USSD-balance request etc) through minicom or gammu programs, and the second is (/dev/ttyACM0
) for network communication.
hardware control in the controller is represented by turning on/off the modem through its PWRKEY input, the state of which is controlled by one of the GPIOs of the processor. For the user, the modem power management interface provides the command wb-gsm
with the options on, off, reset, restart_if_broken.
2G-modem
The maximum data transfer rate in GPRS is 85.6 kbit/s, which is clearly not enough to transfer large amounts of data. The GPRS channel can be used to access the command line interface (ssh) or to send SMS. 2G modems are represented in the system by one device, /dev/ttyGSM
. Simultaneous transmission of data and AT commands in the 2G modem is not implemented.
GSM-antennas
The controller is optionally equipped with one of two GSM antennas: a remote one, on a 2.5 m cable, with a gain of 3.5 dB, or - a short pin antenna screwed directly onto the SMA(female)-controller connector. When mounting the controller in metal boxes, use an external antenna. Regular antennas of the controller provide communication in conditions of good reception. In difficult radio conditions, it is necessary to purchase antennas with high gain or directional antennas. Frequency range of 3G-antennas — 1900-2100 MHz, 2G — 900/1800 MHz. Antenna cable connector — SMA(male).
Network interface configuration
Ethernet interface configuration
It is often necessary for the controller to have a permanent address on the local network. This is achieved either by configuring the DNCP server (binding the IP address to the MAC address of the network interface of the controller) or by explicitly specifying the IP address in the network settings.
Let's take a closer look at how to set a fixed address on the Ethernet interface.
For static address settings, specify the following configuration:
auto eth0 iface eth0 inet static address 192.0.2.7 netmask 255.255.255.0 gateway 192.0.2.254 hostname Wirenboard
By default, if the address is static, the DNS servers listed in the /etc/resolv.conf
file are used, and there is a symbolic link to /mnt/data/etc/resolv.conf
.
You can add your DNS servers:
nameserver 192.168.0.1 nameserver 8.8.8.8 nameservеr 8.8.4.4
These servers use the dnsmasq service, which serves local DNS queries on the controller. To understand what upstream server are used by dnsmasq at the moment, run the command
service dnsmasq stop dnsmasq --no-daemon --log-queries ^C service dnsmasq start
The dnsmasq program displays in the console which servers are used, for example:
dnsmasq: using nameserver 192.168.0.1#53 dnsmasq: using nameserver 8.8.8.8#53 dnsmasq: using nameserver 8.8.4.4#53
Wi-Fi Setting
The settings of the access point are determined by the daemon hostapd (settings file /etc/hostapd.conf
).
To connect to the controller via Wi-Fi over a secure channel, write to the end of the file/etc/hostapd.conf
the following configuration:
wpa=2 wpa_passphrase=your_password wpa_key_mgmt=WPA-PSK wpa_pairwise=TKIP CCMP rsn_pairwise=TKIP CCMP
Restart hostapd: /etc/init.d/hostapd restart
, after which connection to the controller via Wi-Fi will be possible only with the passwordyour_password.
An example of how to configure Wi_Fi adapter to connect to a local network can be found in our wiki.
PPP settings
The pppd daemon is pre-installed on the controller, which is used to create a connection to the provider's network via 3G/2G modem. The PPP daemon creates when you connect the network interface ppp (ppp0 is the default). In the factory configuration settings for the ppp0 port is commented out, and there is no connection with the mobile provider. In our Wiki we recommend using the following settings for the ppp0 interface in the /etc/network/interfaces
file:
auto ppp0 iface ppp0 inet ppp provider mts #Restart modem if it's frozen pre-up wb-gsm restart_if_broken #Then wait for it to load and find the network. pre-up sleep 10
Even if the modem is in a hung or disconnected state, the pre-up wb-gsm restart_if_broken
command will reboot the modem and make sure it is available before starting the connection. A ten-second delay (pre-up sleep 10
) before connection is usually enough to establish a network connection from the first time.
String provider
makes pppd
find the settings file for a specific provider in the directory /etc/ppp/peers
, in this example it is the file /etc/ppp/peers/mts
. For compatibility reasons, this file specifies that the modem device /dev/ttyGSM
should be used as the modem device in the factory setting. If you have a 3G modem installed on your controller, replace it with a faster one /dev/ttyACM0
.
To ensure that the controller does not stop trying to communicate when the connection is lost, the options in the provider settings file /etc/ppp/peers/
must be uncommented
persist maxfail 0
The packet data Protocol parameters and connection numbers for each provider are stored in the /etc/chatscripts directory. In most cases, you do not have to change anything in these files.
PPP is for a primary and backup Internet access
The easiest way to provide access to the Internet, if ppp0 — the only WAN-interface. The ppp0 interface is configured as described above, and then, with the ifup ppp0
command, an Internet connection is established through the network of the cellular operator.
Difficulties begin when the controller is connected to Ethernet and has a default gateway in one network, and also connects to a cellular data network.
In this configuration, we are faced with the following feature: the PPP Protocol provides a point-to-point connection and does not assume a default gateway.
In the case of a PPP connection where there is no default gateway (for example, we have not connected an Ethernet cable), pppd will add the IP address of the ppp partner as the default gateway to the routing table in the system. If a default gateway is already specified, a new default gateway is not added to the routing table. And then when the main Ethernet channel falls, the Internet connection is lost, despite the active connection. In this case, you must add a second default gateway through the ppp0 interface. The metric of any new gateway must be different from the metrics available, so we explicitly specify the metric when creating a new default gateway.
To ensure failover of connections we need to provide for any procedure for raising and fall of the interfaces. The task is to provide communication regardless of the order of raising the interfaces and switching when one of them crushes.
The default gateway with metric 0 in the routing table is created for the eth0 interface, which we will consider to be the primary interface for Internet access. Set the default gateway via the ppp0 interface to 100 metric (or any metric other than 0).
The daemon uses the /etc/ppp/ip-up directory to execute commands after any ppp interface is initialized.d
. The name of the ppp interface is also passed to the script as command-line parameters (in our case, there is only one such interface — ppp0).
Create the add_routes script in the /etc/ppp/ip-up directory.d
and make it executable (chmod +x /etc/ppp/ip-up.d/add_routes
):
#!/bin/sh route del default dev ppp0 2>/dev/null route add default dev ppp0 metric 100 2>/dev/null
The first command removes the default gateway, in case it was created with metric 0. The second adds a default gateway with a metric of 100 for the ppp0 interface. Therefore, we have two default gateways with different metrics:
If one of them falls, the traffic will be transmitted through the other and Vice versa. Start ping 8.8.8.8 and then remove and insert the RJ-45 plug:
Sometimes there is a problem with the availability of provider DNS servers. For all connections prescribe public servers from Google and OpenDNS.
"'eth0:"' From /etc/dhcp/dhclient.conf
remove the domain-name-servers
parameter from the request parameter, and after the request parameter specify the open DNS servers Google and OpenDNS:
prepend domain-name-servers 8.8.4.4, 8.8.8.8, 208.67.222.222, 208.67.220.220;
"'ppp0:"' In the /etc/ppp/ip-up directory.d
create a script (and give it execute permissions) that will add Google DNS servers and OpenDNS to the resolv file.conf
when the interface is up.
if [ ! -e /etc/resolv.conf ]; then : > /etc/resolv.conf fi #OpenDNS printf '%s\n%s\n' "nameserver 208.67.222.222" "$(cat /etc/resolv/conf)" >/etc/resolv.conf printf '%s\n%s\n' "nameserver 208.67.220.220" "$(cat /etc/resolv.conf)" >/etc/resolv.conf #Google DNS printf '%s\n%s\n' "nameserver 8.8.8.8" "$(cat /etc/resolv.conf)" >/etc/resolv.conf printf '%s\n%s\n' "nameserver 8.8.4.4" "$(cat /etc/resolv.conf)" >/etc/resolv.conf
VPN
For remote access to the controller we will use OpenVPN. It is assumed that the server is already present and configured, you must install and configure the client on the controller.
To ensure greater reliability, two server processes are started on a server with 2 IP addresses, one of which listens on port 1194 TCP on IP1 and the other - on port 1194 UDP on IP2. (This is optional, you can use a single server process).
On the controller, we enable 2 OpenVPN clients and explicitly set the route for IP2 via the ppp0
interface for one of them.
OpenVPN installation is standard, using open-rsa
.
To do this, install openvpn
and easy-rsa
on the controller:
apt-get install openvpn easy-rsa
Copy
cp -R /usr/share/easy-rsa /etc/openvpn/
Copy the CA certificate ca.crt
to the controller in /etc/openvpn/easy-rsa/keys
folder
In the folder
/etc/openvpn/easy-rsa
create a subfolder keys
:
mkdir keys && chmod 600 keys && cd keys
Create a certificate signing request (with the name corresponding to the serial number of the controller, in this case that's A7ZO7UCC):
cd /etc/openvpn/easy-rsa/ source ./vars ln -s openssl-1.0.0.cnf openssl.cnf ./build-req A7ZO7UCC
Copy the received request A7ZO7UCC.csr
to the server in an arbitrary directory and sign it.
cd /etc/openvpn/easy-rsa source ./vars ./sign-req /root/certs/A7ZO7UCC
Signed A7ZO7UCC certificate.crt
copy to the controller in the directory /etc/openvpn/easy-rsa/keys
.
On the server in the configuration file (/etc/vpn/server.conf
) see which client-address match file is specified in the ifconfig-pool-persist < /code> parameter and add the address for the client-controller from the network address range described in the
server
parameter of the configuration file to this file.
For example,
service openvpn stop
mcedit /etc/openvpn/ipp.txt
Add the line A7ZO7UCC,10.8.0.48
service openvpn start
For the second server instance, we perform the same operation with its configuration files, the IP addresses should be different, for example, add an entry
A7ZO7UCC,10.9.0.48
The configuration files for the client on the controller for the two connections will be stored in the /etc/openvpn/client files.conf
and /etc/openvpn/client1.conf
.
Contents of the client configuration file:
client
dev tun
proto udp
remote vpn.mydomain.com 1194
resolv-retry infinite
nobind
persist-key
persist-tun
ca /etc/openvpn/easy-rsa/keys/ca.crt
cert /etc/openvpn/easy-rsa/keys/A7ZO7UCC.crt
key /etc/openvpn/easy-rsa/keys/A7ZO7UCC.key
remote-cert-tls server
verb 3
link-mtu 1542
keysize 128
#keysize 128 - for compatibility with existing clients
In the configuration file of the second vpn connection, CLIENT1.conf
replace proto udp
with proto tcp
and specify the second IP address of the server in the remote
parameter.
Startup of the OpenVPN service on the controller is enabled by the command:
update-rc.d openvpn defaults
Check server availability
ping 10.8.0.1
AutoSSH
Another fallback controller connection will be based on the AutoSSH
. The mechanism of work is as follows: SSH-connection from the controller to the server is established, and the ssh-port of the controller is forwarded to one of the free ports on the localhost server. Service аutossh ensures that the ssh connection is not broken, and in case of the gap restores it. Recovery is not instantaneous — for a while, the port used on the server's localhost
is held by the sshd
daemon.
Install on the controller apt-get install autossh
. Generate a key pair for the user root
:
ssh-keygen
Password is empty.
To maintain remote connections, create a user remote
on the server with the shell /bin/false
:
<заранее>команду adduser --Home /для дома/дистанционный --оболочку /bin/false в удаленных и
Here, in file /home/remote/.ssh/authorized_keys
on the server, we add key created on the controller /root/.ssh/id_rsa.pub
with the preamble
no-agent-forwarding,no-X11-forwarding,permitopen="localhost:62001"
this will provide additional security for the server when the controller is connected. Port 62001 is the port of the localhost server to which the ssh port of this controller will be redirected.
The first time we connect from the controller to the server manually:
ssh remote@vpn.mydomain.com
On the controller, create a file \etc\systemd\system\autossh.service
to run it autossh
as a service:
[Unit]
Description=Keeps an ssh tunnel to remote host open
After=network.target
[Service]
User=root
# -p [PORT]
# -l [user]
# -M 0 --> no monitoring
# -N Just open the connection and do nothing (not interactive)
# LOCALPORT:IP_ON_EXAMPLE_COM:PORT_ON_EXAMPLE_COM
ExecStart=/usr/bin/autossh -M 0 -N -o ServerAliveInterval=15 -o ServerAliveCountMax=5 -o ExitOnForwardFailure=yes -R 62001:127.0.0.1:22 -p 22 remote@vpn.mydomain.com
#ExecStop=/usr/bin/killall -9 autossh
RestartSec=5
Restart=always
[Install]
WantedBy=multi-user.target
Add service to autorun on the controller
systemctl enable autossh.service
After starting the service, we can connect to the controller on the server using the command
ssh 127.0.0.1 -p 62001
Data transfer from controller to the cloud
To send MQTT messages from the controller to the cloud service, the MQTT bridge is used, the configuration of which is configured on the controller in the file \mnt\data\etc\mosquito\conf.d\bridge.conf
connection wb_devices_cloud.wb_A7ZO7UCC
address cloud_server.com
notifications true
notification_topic /client/wb_A7ZO7UCC/bridge_status
topic /devices/# both 2 "" /client/wb_A7ZO7UCC
topic /config/# both 2 "" /client/wb_A7ZO7UCC
topic /rpc/# both 2 "" /client/wb_A7ZO7UCC
username wb_A7ZO7UCC
password your_mqtt_cloud_password
Затем выполните команду
service mosquitto restart
Если вы хотите передавать данные на несколько серверов одновременно, создайте несколько разделов connection
.
Возможные неполадки GPRS-соединения
Возможных причин отсутствия GPRS-подключения может быть несколько.
- Закончился оплаченный лимит трафика.
- Низкий уровень сигнала, плохой контакт антенны.
- СИМ-карты некоторых операторов рассчитаны только на 4G-сети, 3G-подключение установить с ними не получится.
- Проверьте, правильно ли вставлена СИМ-карта в слот.
- Возможно, СИМ-карта нерабочая.
- Ваш тарифный план не предусматривает пакетную передачу данных.
Прежде чем идти в личный кабинет и звонить провайдеру, можно выполнить ряд простых проверок.
Запустите команду
gammu networkinfo
Network state : home network
Network : 250 01 (MTS, Russian Federation), LAC 18A6, CID 796B11
Name in phone : "MTS RUS"
Packet network state : home network
Packet network : 250 01 (MTS, Russian Federation), LAC 18A6, CID 796B11
Name in phone : "MTS RUS"
GPRS : attached
Важно, что контроллер подключен к пакетной сети передачи данных
(GPRS : attached)
и GPRS-соединение установлено.
После этого оцените уровень сигнала в minicom командой AT+CSQ
Вы получите результат в виде 13,99
Первая цифра показывает мощность сигнала: > 9 — удовлетворительный, > 14 — хороший, > 19 — отличный. Низкие и нестабильные значения CSQ означают, что антенна плохо расположена, неаккуратно подключена, радиообстановка неблагоприятная.
Если обе проверки пройдены, но связи нет, обратитесь к провайдеру (загляните в личный кабинет), можете проверить СИМ-карту в смартфоне.