1

(32 odpowiedzi, napisanych Oprogramowanie / Software)

Znalazłem.
W pliki ax.ovpn
zamianst ustawić:

ca ca.crt
cert ax.crt
key ax.key

ustawiłem

ca ax.crt
cert ax.crt
key ax.key

2

(32 odpowiedzi, napisanych Oprogramowanie / Software)

Tak, podmieniam zarówno dla serwera jak i dla klienta.
Może cos jest na rzeczy bo jak łączę się z telefonu na którym napewno mam stary certyfikato to jest ten sam błąd.
Będę jeszcze testował.

3

(32 odpowiedzi, napisanych Oprogramowanie / Software)

wyczyściłem wszystkie certyfikaty i podgrałem je na nowo
easyrsa init-pki
wydaje się, że są ok

4

(32 odpowiedzi, napisanych Oprogramowanie / Software)

tak, zarówno na serwerze i kliencie mam ten sam czas

5

(32 odpowiedzi, napisanych Oprogramowanie / Software)

Mam podobny problem z VPN

Ruch wydaje się być ok bo po stronie serwera mam następujący log:

2025-01-03 15:13:59 OpenVPN 2.5.3 arm-openwrt-linux-gnu [SSL (OpenSSL)] [LZO] [LZ4] [EPOLL] [MH/PKTINFO] [AEAD]
2025-01-03 15:13:59 library versions: OpenSSL 1.1.1l  24 Aug 2021, LZO 2.10
2025-01-03 15:13:59 WARNING: --keepalive option is missing from server config
2025-01-03 15:13:59 net_route_v4_best_gw query: dst 0.0.0.0
2025-01-03 15:13:59 net_route_v4_best_gw result: via 0.0.0.0 dev
2025-01-03 15:13:59 NOTE: the current --script-security setting may allow this configuration to call user-defined scripts
2025-01-03 15:13:59 Diffie-Hellman initialized with 2048 bit key
2025-01-03 15:13:59 TUN/TAP device tun0 opened
2025-01-03 15:13:59 net_iface_mtu_set: mtu 1500 for tun0
2025-01-03 15:13:59 net_iface_up: set tun0 up
2025-01-03 15:13:59 net_addr_v4_add: 10.8.0.1/24 dev tun0
2025-01-03 15:13:59 /usr/libexec/openvpn-hotplug up home tun0 1500 1621 10.8.0.1 255.255.255.0 init
2025-01-03 15:13:59 Could not determine IPv4/IPv6 protocol. Using AF_INET
2025-01-03 15:13:59 Socket Buffers: R=[180224->180224] S=[180224->180224]
2025-01-03 15:13:59 UDPv4 link local (bound): [AF_INET][undef]:1194
2025-01-03 15:13:59 UDPv4 link remote: [AF_UNSPEC]
2025-01-03 15:13:59 MULTI: multi_init called, r=256 v=256
2025-01-03 15:13:59 IFCONFIG POOL IPv4: base=10.8.0.2 size=252
2025-01-03 15:13:59 Initialization Sequence Completed
2025-01-03 15:17:48 31.0.78.226:44811 TLS: Initial packet from [AF_INET]31.0.78.226:44811, sid=646395dc 6563206d
2025-01-03 15:17:49 31.0.78.226:44812 TLS: Initial packet from [AF_INET]31.0.78.226:44812, sid=be966f40 5c34d717
2025-01-03 15:17:50 31.0.78.226:44813 TLS: Initial packet from [AF_INET]31.0.78.226:44813, sid=c008f251 37e74833
2025-01-03 15:17:52 31.0.78.226:44816 TLS: Initial packet from [AF_INET]31.0.78.226:44816, sid=f3d86bad f7c218eb
2025-01-03 15:17:56 31.0.78.226:44828 TLS: Initial packet from [AF_INET]31.0.78.226:44828, sid=18e494e3 9e5fcddf
2025-01-03 15:18:04 31.0.78.226:44869 TLS: Initial packet from [AF_INET]31.0.78.226:44869, sid=e3175853 0dcfac22
2025-01-03 15:18:45 31.0.78.226:44809 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
2025-01-03 15:18:45 31.0.78.226:44809 TLS Error: TLS handshake failed
2025-01-03 15:18:45 31.0.78.226:44809 SIGUSR1[soft,tls-error] received, client-instance restarting
2025-01-03 15:18:47 31.0.78.226:44810 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
2025-01-03 15:18:47 31.0.78.226:44810 TLS Error: TLS handshake failed
2025-01-03 15:18:47 31.0.78.226:44810 SIGUSR1[soft,tls-error] received, client-instance restarting
2025-01-03 15:18:48 31.0.78.226:44811 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
2025-01-03 15:18:48 31.0.78.226:44811 TLS Error: TLS handshake failed
2025-01-03 15:18:48 31.0.78.226:44811 SIGUSR1[soft,tls-error] received, client-instance restarting
2025-01-03 15:18:49 31.0.78.226:44812 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
2025-01-03 15:18:49 31.0.78.226:44812 TLS Error: TLS handshake failed
2025-01-03 15:18:49 31.0.78.226:44812 SIGUSR1[soft,tls-error] received, client-instance restarting
2025-01-03 15:18:50 31.0.78.226:44813 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
2025-01-03 15:18:50 31.0.78.226:44813 TLS Error: TLS handshake failed
2025-01-03 15:18:50 31.0.78.226:44813 SIGUSR1[soft,tls-error] received, client-instance restarting
2025-01-03 15:18:52 31.0.78.226:44816 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
2025-01-03 15:18:52 31.0.78.226:44816 TLS Error: TLS handshake failed
2025-01-03 15:18:52 31.0.78.226:44816 SIGUSR1[soft,tls-error] received, client-instance restarting
2025-01-03 15:18:56 31.0.78.226:44828 TLS Error: TLS key negotiation failed to occur within 60 seconds (check your network connectivity)
2025-01-03 15:18:56 31.0.78.226:44828 TLS Error: TLS handshake failed
2025-01-03 15:18:56 31.0.78.226:44828 SIGUSR1[soft,tls-error] received, client-instance restarting

Zastanawiają mnie te porty 31.0.78.226:44811 przy każdej próbie są inne.


Po stronie klienta:

2025-01-03 15:18:05 TLS: Initial packet from [AF_INET]91.246.x.x:1194, sid=30583668 7bdbb665
2025-01-03 15:18:05 VERIFY ERROR: depth=1, error=self-signed certificate in certificate chain: CN=linksys, serial=444184125679151739318744995188917151675732335198
2025-01-03 15:18:05 Sent fatal SSL alert: unknown CA
2025-01-03 15:18:05 OpenSSL: error:0A000086:SSL routines::certificate verify failed:
2025-01-03 15:18:05 TLS_ERROR: BIO read tls_read_plaintext error
2025-01-03 15:18:05 TLS Error: TLS object -> incoming plaintext read error
2025-01-03 15:18:05 TLS Error: TLS handshake failed
2025-01-03 15:18:05 Closing DCO interface
2025-01-03 15:18:05 SIGUSR1[soft,tls-error] received, process restarting
2025-01-03 15:18:05 MANAGEMENT: >STATE:1735913885,RECONNECTING,tls-error,,,,,
2025-01-03 15:18:05 Restart pause, 16 second(s)

Co może być przyczyną braku połączenia VPN?
Jeszcze jakiś czas temu działało.

wybaczcie, jakaś pomroczność mnie ogarnęła

Cześć,
zainstalowałem openwrt na AX3000T zgodnie z instrukcją na:
https://www.androidpimp.com/wireless-ro … 0t-router/
https://openwrt.org/inbox/toh/xiaomi/ax3000t

Niestety zatrzymałem się na kroku
sysupgrade -n /tmp/openwrt-mediatek-filogic-xiaomi_mi-router-ax3000t-squashfs-sysupgrade.bin

Mogę zalogować się do konsoli:
BusyBox v1.36.1 (2024-09-16 20:47:44 UTC) built-in shell (ash)

  _______                     ________        __
|       |.-----.-----.-----.|  |  |  |.----.|  |_
|   -   ||  _  |  -__|     ||  |  |  ||   _||   _|
|_______||   __|_____|__|__||________||__|  |____|
          |__| W I R E L E S S   F R E E D O M
-----------------------------------------------------
OpenWrt SNAPSHOT, r27433-7e1d092552
-----------------------------------------------------
=== WARNING! =====================================
There is no root password defined on this device!
Use the "passwd" command to set up a new password
in order to prevent unauthorized SSH logins.
--------------------------------------------------
root@OpenWrt:~#

po wykonaniu polecenia:
sysupgrade -n /tmp/openwrt-mediatek-filogic-xiaomi_mi-router-ax3000t-squashfs-sysupgrade.bin

mam:
root@OpenWrt:/tmp# sysupgrade -n /tmp/openwrt-mediatek-filogic-xiaomi_mi-router-ax3000t-squashfs-sysupgrade.bin
verifying sysupgrade tar file integrity
Mon Sep 16 20:57:08 UTC 2024 upgrade: Commencing upgrade. Closing all shell sessions.
Command failed: Connection failed
root@OpenWrt:/tmp# Connection to 192.168.1.1 closed by remote host.
Connection to 192.168.1.1 closed.
gc@gc-Vostro-3350:~$

pomożecie?

Pomogło dzięki.
Jakąś pomroczność janśą miałęm. Teraz już będę pamiętał!

Mam za to dodatkowe pytania. Skorzystałem z opisu na stronie: https://www.linksys.com/us/support-arti … Num=316324
Ruter wystartował mi z LUCI 19.07 czy to oznacza, że na drugiej partycji była kopia LUCI 19.07?
Spodziewałem się, że przywrócony zostanie oryginalny soft linksys.

Cześć,
Zrobiłem atuializację LUCI z 19.07 na 21.02 na WRT1200AC.
Zrobiłem 1 update softu i opcją zachowania konfiguracji. Ruter uruchomił się, wolno wszysto działało ale działało, jedyne co to nie udało się połączyć z PPPoE. Zrobiłem drugi raz update do 21.02 ale tym razem bez zachowania konfiguracji. No i tutaj zaczął się problem. Ruter po restarcie nie wstaje. NIe przydziela adresu IP po LAN.
Próbowałem na sztywno ustawić adres IP na karcie sieciowej w komputerze na adres 192.168.1.2, maska 255.255.255.0, brama 192.168.1.1. Niestety nie pomaga. Co mogę z tym zrobić, prośba o pomoc.

Pozdrawiam

10

(6 odpowiedzi, napisanych Oprogramowanie / Software)

Aktualizacja zakończyła się sukcesem smile
Dzięki.

11

(6 odpowiedzi, napisanych Oprogramowanie / Software)

Cześć,
chciałbym zrobić upgrade LEDE z wersji 17.01 do 19.01 (luci-19.07-snapshot-r10731-e68d589e7b-mvebu-cortexa9-linksys_wrt1200ac-squashfs-sysupgrade.bin).
Zrobiłem aktualizację poprzez opcję: LuCI → System → Backup / Flash Firmware → Actions: Flash new firmware image.
Zaznaczyłem opcję: Keep settings: Yes. Po wgraniu wersja pozostała bez zmian 17.01

     _________
    /        /\      _    ___ ___  ___
   /  LE    /  \    | |  | __|   \| __|
  /    DE  /    \   | |__| _|| |) | _|
/________/  LE  \  |____|___|___/|___|                      lede-project.org
\        \   DE /
  \    LE  \    /  -----------------------------------------------------------
   \  DE    \  /    Reboot (17.01-SNAPSHOT, r3322-5feb4f0)
    \________\/    -----------------------------------------------------------

-----------------------------------------------------------------------------
|                                                                           |
| Build time: 2017-04-21 20:26 CEST                                         |
|                                                                           |
| Cezary Jackiewicz (obsy), http://eko.one.pl                               |
|                                                                           |
-----------------------------------------------------------------------------


Pytania:
1) Aby zrobić aktualizację do wersji 19.01 murze odznaczyć opcję: Keep settings?
2) Czy aktualizacja bez zachowania ustawień spowoduje, że będę musiał instalować pakiety od nowa tzn. np. mosquito, sterowniki itd.?

12

(31 odpowiedzi, napisanych Oprogramowanie / Software)

Faktycznie smile dzięki

13

(31 odpowiedzi, napisanych Oprogramowanie / Software)

Zainstalowałem broker komunikatów MQTT zgodnie z poradnikiem na eko. Chciałem ustawić autentykację po loginie i haśle zgodnie z http://www.steves-internet-guide.com/mq … d-example/

Niestety wersja mosquitto z repozytorium OpenWRT nie posiada narzędzia do generowania pliku z hasłem mosquitto_passwd. Co można w takim przypadku zrobić?

14

(109 odpowiedzi, napisanych Oprogramowanie / Software)

Po jakimś czasie ruszyło. Dzięki za pomoc.

15

(109 odpowiedzi, napisanych Oprogramowanie / Software)

Problem z datą się rozwiązał - data ustwiła się właściwa. Niestety pojawił się inny problem - brak internetu hmm. Coś się pomieszało z DNS. Ping google po IP działa:

root@LEDE:~# ping  216.58.209.67
PING 216.58.209.67 (216.58.209.67): 56 data bytes
64 bytes from 216.58.209.67: seq=0 ttl=55 time=45.185 ms
64 bytes from 216.58.209.67: seq=1 ttl=55 time=45.411 ms
64 bytes from 216.58.209.67: seq=2 ttl=55 time=45.414 ms

ustawienia DNS:

root@LEDE:~# cat /tmp/resolv.conf.auto
# Interface wan
nameserver 194.204.152.34
nameserver 194.204.159.1

restart dns kończy się tak:

root@LEDE:~# /etc/init.d/dnsmasq restart
udhcpc: started, v1.25.1
udhcpc: sending discover
udhcpc: no lease, failing

co wspólnego miała data w systemie z ustawianiem DNS? Czy może to w czym innym jest problem?

16

(109 odpowiedzi, napisanych Oprogramowanie / Software)

Wykonanie polecenia:

root@LEDE:~# touch -d 20171215 -t 180101 /etc/banner
root@LEDE:~# find /etc -type f -exec ls -al {} \;
-rw-rw-r--    1 root     root          1001 Jan 18  2021 /etc/banner

nie zmieniło daty modyfikacji pliku (również po restarcie).
Co ciekawe to samo polecenia na pliku etc/openwrt_version
ustawiło datę modyfikacji pliku na: Jan 18  2021 /etc/openwrt_version

Usunąłem z crontab wszystkie wpisy + restart i próbowałem jeszcze raz zmienić datę na /etc/banner - ciągle bez skutku.
Spróbuję jeszcze wyłączyć ruter na dłuższy czas.

17

(109 odpowiedzi, napisanych Oprogramowanie / Software)

Ruter: Linksys WRT1200AC

Odnośnie /etc/ to zgadza się.
W /etc mam plik /etc/banner do którego się odwołuje przy codziennym restarcie rutera. Data pliku: Jan 12  2021
Wpis z cronetab:
30 4 * * * sleep 70 && touch /etc/banner && reboot

Wystarczy, że odwołam się do innego pliku? Sprawdzę.

18

(109 odpowiedzi, napisanych Oprogramowanie / Software)

Mam problem z ustawieniem aktualnej daty i czasu na LEDE 17.01

1.    ping na serwer czasu działa:

  • ping 0.lede.pool.ntp.org

  • ping 1.lede.pool.ntp.org

  • ping 2.lede.pool.ntp.org

  • ping 3.lede.pool.ntp.org

2.    uci show system

root@LEDE:~# uci show system
system.@system[0]=system
system.@system[0].hostname='LEDE'
system.@system[0].ttylogin='0'
system.@system[0].log_size='64'
system.@system[0].urandom_seed='0'
system.@system[0].timezone='CET-1CEST,M3.5.0,M10.5.0/3'
system.@system[0].cronloglevel='8'
system.@system[0].log_port='514'
system.@system[0].conloglevel='8'
system.@system[0].log_proto='tcp'
system.@system[0].zonename='Europe/Warsaw'
system.ntp=timeserver
system.ntp.enabled='1'
system.ntp.server='0.lede.pool.ntp.org' '1.lede.pool.ntp.org' '2.lede.pool.ntp.org' '3.lede.pool.ntp.org'
system.led_wan=led
system.led_wan.name='WAN'
system.led_wan.sysfs='pca963x:caiman:white:wan'
system.led_wan.trigger='netdev'
system.led_wan.mode='link tx rx'
system.led_wan.dev='eth1'
system.led_usb1=led
system.led_usb1.name='USB 1'
system.led_usb1.sysfs='pca963x:caiman:white:usb2'
system.led_usb1.trigger='usbport'
system.led_usb1.port='usb1-port1'
system.led_usb2=led
system.led_usb2.name='USB 2'
system.led_usb2.sysfs='pca963x:caiman:white:usb3_1'
system.led_usb2.trigger='usbport'
system.led_usb2.port='usb2-port1' 'usb3-port1'
system.led_usb2_ss=led
system.led_usb2_ss.name='USB 2 SS'
system.led_usb2_ss.sysfs='pca963x:caiman:white:usb3_2'
system.led_usb2_ss.trigger='usbport'
system.led_usb2_ss.port='usb3-port1'

3.    Nie pomaga:

/etc/init.d/sysntpd stop
/etc/init.d/sysntpd start

4.    inne ntp

root@LEDE:~# date
Mon Jan 11 22:03:47 CET 2021
root@LEDE:~# /usr/sbin/ntpd -d -q -n -p ntp.task.gda.pl
ntpd: sending query to 153.19.250.123
ntpd: reply from 153.19.250.123: offset:-97027176.885222 delay:0.014579 status:0x24 strat:2 refid:0x65b164d2 rootdelay:0.005646 reach:0x01
ntpd: sending query to 153.19.250.123
ntpd: reply from 153.19.250.123: offset:-97027176.885171 delay:0.014696 status:0x24 strat:2 refid:0x65b164d2 rootdelay:0.005646 reach:0x03
ntpd: setting time to 2017-12-15 22:04:22.058336 (offset -97027176.885171s)
root@LEDE:~# date
Mon Jan 11 22:04:03 CET 2021

5.    co ciekawe samo polecenie date -s też nie działa

root@LEDE:~#  date -s "201712152207"
Fri Dec 15 22:07:00 CET 2017
root@LEDE:~# date
Mon Jan 11 22:06:50 CET 2021
root@LEDE:~#

co może być problemem?