Hálózatok általános

Helló,

ahogy itt a korábbi threadben megénekeltük, én is Ubiquiti/Unifi felhasználó lettem a javaslatotokra Mikrotik után.

Egy Expresst vettem anno routernek, fél évig hiba nélkül ment is egy AP-vel, de volt egy Network verzióváltás, amitől cpu usage 100% lett. Írtam a supportnak, elismerték, hogy szar lett az update, és addig is, amíg javítják a szoftvert (2-3 hónap) küldenek ingyen egy Cloud Gateway Ultra-t (!), használjam AP-ként az Expresst.

Így is lett, az UCG lett a main router, lett három 2.5G switch, 2 AP, teljesen szuperül működött minden a hálózatban. Van Home Assistant, 40 zigbee eszköz, 50+ okoseszköz, több mint egy éve csont nélkül minden fainul működik.

Aztán jött a fekete kedd a héten: megjelent a Network 9.3.4 után két héttel (ami csont nélkül ment) az OS 4.3.6 frissítés.

Sajnos auto-upgradere volt állítva, így kedd 3:30-kor fel is rakta, rebootolt, és azóta egy shitshow az egész:

- ssh-val (sem a device, se a local) nem tudok belépni, akárhányszor enable-disable + jelszót cserélek

- az IOT eszközök random nem tudnak az AP-khez, és/vagy a cloudjukhoz kapcsolódni:

HomeWizzard (IOT) szenzorok: víz/gáz/áram: local IP-t kapnak, debugban kézzel / HA tudja weben queryzni őket, de a saját cloudjuk alatt disconnected státuszban vannak, nem küldenek adatot

Tuya (IOT) eszközök: HA-ban (Tuya clouddal) nem látszanak, saját Tuya appból 3-5mp várás után látszanak, localból működnek

Samsung/SmartThings (nagy) eszközök: AP-re sem tudnak visszakapcsolódni, disconnected, értelem szerűen a cloudjukból sem látszanak, local módjuk nincs.

Bosch (nagy) eszközök: csont nélkül mennek a régi beállításokkal, localban, cloudban.

Bosch termo/hőszivattyú (nagy) vezérlés: csont nélkül régi beállításokkal, localban, cloudban.

Klímák (gyári IOT wifi kártya) wifi vezérlés: se kép se hang, local IP-t kap, kifele nem tud beszélni, 8 percenként connect-disconnect loop.

Eddig próbáltam:

1. a megbízható eszközök egy SSID alatt - és aminek van local interface-e - a "fő" hálózatban (VLAN0) voltak (Samsung, Bosch, Tuya).

Ez 2.4/5G, WPA2/3, minden láthat mindent.

2. az "egyebek"-nek van egy külön SSID/ VLAN1, ami 2.4G only, IOT kapcsolóval, client separation-ben, a DMZ-ben lévő VLAN0-s HA-t látják csak

3. a support azt kérte, hogy csináljak egy dedikált 2.4G-t wifit default beállításokkal, és próbáljam átrakni a cuccokat (SSID: iot-testing)

nehezítés, hogy ezek a szenzorok nehezen hozzáférhető helyeken (vízakna, 4m magasan a lépcsőházban, 25m-re az eon-dobozban)  vannak.

Random a Homewizzardból az egyiket átrakni az iot-testingre, ez kb 3 percig működött is, látszott a cloudjából, aztán megint eltűnt (zölden villog, nem folyamatosan világít)

A Samsung eszközök 1-2-3 SSID-kre egyátalán nem tudnak csatlakozni!

A Tuya az új teszt SSID-n is ugyanúgy random hol látszik a cloudból, hol nem, a HA sehogy sem tudja kezelni.

A klímához kell egy 5m-es létra, hogy meg tudjam nyomni a reset gombot :(

Mit szarhatott be:

- valami változott az SSID/wifi beállításoknál globálisan, de nem tudom mi. Az AI a PMF-et nyomatja, de az az új 2.4G-s teszt alatt alapból disabled.

- valami route nem enged ki bizonyos eszközöket / VLAN-ok at. Viszont ha wifin laptoppal megyek, nekem megy minden mindegyik alhálózatban 

- DNS feloldás nem jó, de laptopon meg jó. cseréltem DNS szervereket is, semmi, 2 nap eltelt, tehát valaminek már a TTL-je csak lejárt volna, de nem látszanak mégsem.

- új adblock / regió szűrés stb: ezt is ki/be kapcsolgattam, semmi változás

+1: mivel nem tudok ssh-n se belépni, így tcp_dumpot sem tudok nyomni, hogy mi a francért nem tudnak és hova nem tudnak connectelni az eszközök... gui-n ilyet tudomásom szerint nem lehet.

Találkozott már valaki ilyennel? Factory reseteljek vagy mi a vért csináljak még? Köszi előre is.

UPDATE 07-20:

- teljesen mindegy milyen Network verzióval, OS 4.3.6-tal *bármilyen backupra* visszaállva SZAR. Ugyanúgy nem routol/látszik random az eszközök fele

- full factory reset (összes AP, switch minden kurva anyja) után ugyanazokat az SSID-ket ugyanazzal a beállítással létrehozva GECIRE UGYANÚGY MŰKÖDIK MINT EDDIG.

most kézzel lehet az összes custom rule-t, routingot, VLAN-t újra felvenni, baszakodni

hát elmennek ezek a kurva anyjukba tényleg

UPDATE 08-04:

- véget ért a szabadság, újra játszok vele. MTU-t konzervatívra 1412-re véve (MSS Clamping) az eszközök egy része "félig" megjelent, a HomeWizard saját appja connectednek mutatja, de adat nem jön.
- a Jumbo Packages-t hiába kapcsolom ki/be, nem változik semmi.
- routing probléma nem lehet, mert az adat részben megy, akkor mi a vér?

közben a Network már 9.3.5, de nem oldotta meg.

Vajh rákapnak-e mások is erre a modellre? Kitolunk egy olyan ingyenes automatikus frissítést, ami téglásítja a termékeket, és egyben felajánljuk, hog előfizetési díj ellenében végülis lehet tovább használni az eszközöket...

Videó fanoknak:

https://www.youtube.com/watch?v=KNuZ3BjT7IU

Inkább olvasóknak:

https://consumerrights.wiki/Futurehome_Smarthub_Mandatory_Subscription_…

https://consumerrights.wiki/Belkin_Wemo_discontinuation_of_service

A problémám az lenne, hogy a KEA dhcp ddns service, eldobja dns szerver frissítését.

Az adott végpont, nincs is még benne a dns-ben, de mégis eldobja a hozzáadást, de azt nem találom meg hogy mi miatt.

Túrtam a netet, de szinte semmi hiba megoldás nincs fent.

A legfrissebb 2.6-os van fent, előtte ubuntu repoban lépő 2.0.2-es volt fent, azzal ment minden, de frissíteni akartam és közben elfelejtettem backupot csinálni.

A telepítő meg felül csapta a működő konfigot. 

Ez lenne a syslog hiba üzenet:

Jul 15 06:59:58 szo1vcdhcp1 kea-dhcp-ddns[6071]: ERROR DHCP_DDNS_NO_FWD_MATCH_ERROR Request ID 000001854548457BEBF758508CD742003CBF84AD0434F5969AA491381483D03521925E: the configured list of forward DDNS domains does not contain a match for: Type: 0 (CHG_ADD)
Jul 15 06:59:58 szo1vcdhcp1 kea-dhcp-ddns[6071]: Forward Change: yes
Jul 15 06:59:58 szo1vcdhcp1 kea-dhcp-ddns[6071]: Reverse Change: yes
Jul 15 06:59:58 szo1vcdhcp1 kea-dhcp-ddns[6071]: FQDN: [valami.teszt.lan.]
Jul 15 06:59:58 szo1vcdhcp1 kea-dhcp-ddns[6071]: IP Address: [1.1.1.2]
Jul 15 06:59:58 szo1vcdhcp1 kea-dhcp-ddns[6071]: DHCID: [000001854548457BEBF758508CD742003CBF84AD0434F5969AA491381483D03521925E]
Jul 15 06:59:58 szo1vcdhcp1 kea-dhcp-ddns[6071]: Lease Expires On: 20250715062851
Jul 15 06:59:58 szo1vcdhcp1 kea-dhcp-ddns[6071]: Lease Length: 5333
Jul 15 06:59:58 szo1vcdhcp1 kea-dhcp-ddns[6071]: Conflict Resolution Mode: check-with-dhcid
Jul 15 06:59:58 szo1vcdhcp1 kea-dhcp-ddns[6071]:   The request has been discarded.

Ez a ddns konfig:
 

{
"DhcpDdns":
{
  "ip-address": "127.0.0.1",
  "port": 53001,
  "control-socket": {
      "socket-type": "unix",
      "socket-name": "kea-ddns-ctrl-socket"
  },

  <?include "/etc/kea/tsig-keys.json"?>

  "forward-ddns" : {
      "ddns-domains" : [
          {
               "name": "teszt.lan",
               "key-name": "dns-key",
               "dns-servers": [
                   { "ip-address": "2.2.2.2" }
               ]
          }
      ]
  },
 

Ez pedig a dhcp4 konfig, ddns része:

     "dhcp-ddns": {
        "enable-updates": true,
        "server-ip" : "127.0.0.1",
        "server-port" : 53001,
        "sender-ip" : "127.0.0.1",
        "sender-port" : 3433,
        "max-queue-size" : 2048,
        "ncr-protocol" : "UDP",
        "ncr-format" : "JSON"
     },

     "ddns-send-updates": true,
     "ddns-qualifying-suffix": "teszt.lan",
     "ddns-override-client-update": false,
     "ddns-override-no-update": true,
     "ddns-generated-prefix": "dynamic",
     "ddns-update-on-renew": true,
 

Megoldas:
 a test.lan utan hianyzott a pont
 

A rovid tortenet annyi, hogy uj laptopomat eppen akkor helyeztem uzembe amikor kulfoldon (Anglia) voltam. Ott at is raktam a sim kartyat a regibol es szepen fel is csatlakozott.

Aztan hazajottem, es a modem nem mukodott az itthoni halozaton. Sim kartyat visszarakva a regi laptopba siman mukodik. Mar leirtam a modemet, de mivel sok idore kellett volna megvalni a laptoptol es mivel par nap mulva megint utaztam ezert offoltam.

Aztan amikor landoltam az USAban elso hasznalatkor szepen csatlakozott a mobilnet.

Az utnak vege, remenykedtem benne, hogy itthon majd megint mukdoni fog de sajnos semmi. ModemManager logjabol ennyi tellik:

<pre>
Jul 02 08:45:09 teller ModemManager[2882]: <msg> [modem1] simple connect started...
Jul 02 08:45:09 teller ModemManager[2882]: <msg> [modem1] simple connect state (6/10): register
Jul 02 08:45:09 teller ModemManager[2882]: <msg> [modem1] 3GPP packet service state changed (unknown -> detached)
Jul 02 08:45:09 teller ModemManager[2882]: <msg> [modem1] 3GPP packet service state changed (detached -> unknown)
...
<ugyenz percenkent>
...
Jul 02 08:46:11 teller ModemManager[2882]: <msg> [modem1] 3GPP packet service state changed (unknown -> detached)
Jul 02 08:46:11 teller ModemManager[2882]: <msg> [modem1] 3GPP packet service state changed (detached -> unknown)
Jul 02 08:46:11 teller ModemManager[2882]: <wrn> [modem1] registration in network failed: Network timeout
</pre>

Probaltam manualis halozatvalasztast, nem mukodott ugy sem, probaltam az APN beallitasokat a telekom leirasa alapjan beallitani (https://www.telekom.hu/lakossagi/ugyintezes/gyakori-kerdesek/4255/hogya…) a NetworkManager helyett, de ez se mukdott.

Ugyfelszolgalat allitja, hogy az o oldalukon semmi baj nincs es a tarsosztaly mar megnezte sokszor, es arra a konkluziora jutottak, hogy a hiba az en keszulekemben van. De nem tudnak IMEI alapjan logot nezni, hogy megis mi tortenik, mert ez tars sim es ossze van csomagolva az elsodleges szammal.

Szoval vettem egy sima feltoltos Yettel kartyat, amit bedugva es felconfolva megy minden szepen, tud csatlakozni stb.

En arra gyanakszom, hogy az elso feljelentkezesnel tortenik valami regisztracio, config push vagy valami hasonlo es roamingban ez valahogy furcsan viselkedik es ilyet eredmenyez.

Lassan 2 hete megy az odavissza a telekommal de meg mindig nem jarunk sokkal kozelebb a megoldashoz.

Van valami otlet, debug stb. amit meg tudnek probalni?

Ma 15 óra körül a Vidanet hálózata letérdelt - legalábbis Győr környékén. A visszajelzések szerint se TV, se internet nincs. Jelenleg is tart a kiesés.

Az F! rajongók örülhettek, pont a rajt előtt ment el az adás ...

Sziasztok!

Van esetleg valakinél tapasztalat két SONiC OSS switch közt MCLAG létrehozásában? A github doksi ebben a témában eléggé száraz/hiányos számomra...

köszönöm

Sziasztok,

egy régi p2p implementáció kivezetésén dolgozok StrongSwan/IPSec alapon, azonban random sokszorozódnak az SA -k, amellett, hogy maga a kapcsolat stabil mindket iranyban. 
Előzetesen:

• az auto=start tudom, hogy nem javallott mindkét oldalon, de az auto=add esetén egy elvesztett kapcsolat nem minden esetben tudott ujraépülni
• az FQDN alapu cimzeshez hozzatartozik, hogy akar a DNS -ben, akar a hosts fajlban megfeleloen szerepel.

Ime a ket oldal ipsec.conf -ja:

conn si
    keyexchange=ikev2
    ike=aes256-sha256-modp2048!
    esp=aes256-sha256!
    ikelifetime=8h
    keylife=1h


    left=ips-si.domain.hu
    leftauth=psk
    leftid=@ips-si.domain.hu
    leftsubnet=192.168.20.0/24

    right=ips-gd.domain.hu
    rightid=@ips-gd.domain.hu
    rightsubnet=10.20.0.0/16
    rightauth=psk

    auto=start
    closeaction=restart
    dpdaction=restart

conn gd
    keyexchange=ikev2
    ike=aes256-sha256-modp2048!
    esp=aes256-sha256!
    ikelifetime=8h
    keylife=1h


    left=ips-gd.domain.hu
    leftauth=psk
    leftid=@ips-gd.domain.hu
    leftsubnet=10.20.0.0/16

    right=ips-si.domain.hu
    rightid=@ips-si.domain.hu
    rightsubnet=192.168.20.0/24
    rightauth=psk

    auto=start
    closeaction=restart
    dpdaction=restart

mindekozben az ipsec statusall vonatkozo blokkja pedig sokszorozza az SA -kat:

Security Associations (24 up, 0 connecting):
          si[40]: ESTABLISHED 6 hours ago, 2a01:4ff:c012:2000::153[ips-gd.domain.hu]...2a01:4ff:c013:3000::240[ips-si.domain.hu]
          si{413}:  INSTALLED, TUNNEL, reqid 1, ESP SPIs: c5fd9cc5_i cce92764_o
          si{413}:   10.20.0.0/16 === 192.168.20.0/24
          si[39]: ESTABLISHED 6 hours ago, 2a01:4ff:c012:2000::153[ips-gd.domain.hu]...2a01:4ff:c013:3000::240[ips-si.domain.hu]
          si{435}:  INSTALLED, TUNNEL, reqid 1, ESP SPIs: c36bdd92_i c7ceb7e7_o
          si{435}:   10.20.0.0/16 === 192.168.20.0/24
          si[34]: ESTABLISHED 6 hours ago, 2a01:4ff:c012:2000::153[ips-gd.domain.hu]...2a01:4ff:c013:3000::240[ips-si.domain.hu]
          si{421}:  INSTALLED, TUNNEL, reqid 1, ESP SPIs: c541c8e1_i ce85eacb_o
          si{421}:   10.20.0.0/16 === 192.168.20.0/24
          si[33]: ESTABLISHED 6 hours ago, 2a01:4ff:c012:2000::153[ips-gd.domain.hu]...2a01:4ff:c013:3000::240[ips-si.domain.hu]
          si{430}:  INSTALLED, TUNNEL, reqid 1, ESP SPIs: c069c53d_i c0459266_o
          si{430}:   10.20.0.0/16 === 192.168.20.0/24
          si[32]: ESTABLISHED 6 hours ago, 2a01:4ff:c012:2000::153[ips-gd.domain.hu]...2a01:4ff:c013:3000::240[ips-si.domain.hu]
          si{420}:  INSTALLED, TUNNEL, reqid 1, ESP SPIs: c49e3ccc_i ce442666_o
          si{420}:   10.20.0.0/16 === 192.168.20.0/24
          si[31]: ESTABLISHED 6 hours ago, 2a01:4ff:c012:2000::153[ips-gd.domain.hu]...2a01:4ff:c013:3000::240[ips-si.domain.hu]
          si{416}:  INSTALLED, TUNNEL, reqid 1, ESP SPIs: c5371a79_i cd90a37b_o
          si{416}:   10.20.0.0/16 === 192.168.20.0/24
          si[28]: ESTABLISHED 6 hours ago, 2a01:4ff:c012:2000::153[ips-gd.domain.hu]...2a01:4ff:c013:3000::240[ips-si.domain.hu]
          si{424}:  INSTALLED, TUNNEL, reqid 1, ESP SPIs: c640fce2_i ca02677c_o
          si{424}:   10.20.0.0/16 === 192.168.20.0/24
          si[27]: ESTABLISHED 6 hours ago, 2a01:4ff:c012:2000::153[ips-gd.domain.hu]...2a01:4ff:c013:3000::240[ips-si.domain.hu]
          si{434}:  INSTALLED, TUNNEL, reqid 1, ESP SPIs: c5c5304b_i c6ecb0d4_o
          si{434}:   10.20.0.0/16 === 192.168.20.0/24
          si[26]: ESTABLISHED 6 hours ago, 2a01:4ff:c012:2000::153[ips-gd.domain.hu]...2a01:4ff:c013:3000::240[ips-si.domain.hu]
          si{427}:  INSTALLED, TUNNEL, reqid 1, ESP SPIs: cd38c425_i c31d41c4_o
          si{427}:   10.20.0.0/16 === 192.168.20.0/24
          si[25]: ESTABLISHED 6 hours ago, 2a01:4ff:c012:2000::153[ips-gd.domain.hu]...2a01:4ff:c013:3000::240[ips-si.domain.hu]
          si{418}:  INSTALLED, TUNNEL, reqid 1, ESP SPIs: c184a1b7_i c3c80d27_o
          si{418}:   10.20.0.0/16 === 192.168.20.0/24
          si[20]: ESTABLISHED 6 hours ago, 2a01:4ff:c012:2000::153[ips-gd.domain.hu]...2a01:4ff:c013:3000::240[ips-si.domain.hu]
          si{417}:  INSTALLED, TUNNEL, reqid 1, ESP SPIs: c7104173_i c985657d_o
          si{417}:   10.20.0.0/16 === 192.168.20.0/24
          si[19]: ESTABLISHED 6 hours ago, 2a01:4ff:c012:2000::153[ips-gd.domain.hu]...2a01:4ff:c013:3000::240[ips-si.domain.hu]
          si{426}:  INSTALLED, TUNNEL, reqid 1, ESP SPIs: c3495f02_i c9285dd9_o
          si{426}:   10.20.0.0/16 === 192.168.20.0/24

A kerdes az, hogy a fent emlitett auto parameterezesen kivul meg mi nem jo itt, ha a kapcsolat alapbol letrejon es stabil?

kis update: uniqueids=no eseten is ugyanez a szitu.

Sziasztok,

adott ket halozat (Hetzner internal network mindketto):

10.20.0.0/24 (GW 10.20.0.1, dhcp -n /32 -k vannak kiosztva; ARP -n csak a 10.20.0.1 latszik)
10.30.0.0/24 (GW 10.30.0.1, dhcp -n /32 -k vannak kiosztva; ARP -n csak a 10.30.0.1 latszik)

A ket halozat osszekotesere jott letre 1-1 gep IPSec tunnelel, 10.30.0.125, 10.20.0.126; ezek onmagukban mukodnek is, elerhetoek.

Az ARP hianya miatt csak ping erheto el network discovery ugyben.

A routing tabla igy fest 1-1 10.20.0.0/24 -ben levo gepen (csak az erintett routingok maradtak):

ip r
default via 172.31.1.1 dev eth0 
10.20.0.0/24 via 10.20.0.1 dev enp7s0 
10.20.0.1 dev enp7s0 scope link < ARP miatt feltetelezhetoen

Namost, itt ennek kellene bekerulnie elkepzeleseim szerint:

10.30.0.0/24 via 10.20.0.125 dev enp7s0 
10.20.0.126 dev enp7s0 scope link < ARP miatt

Azonban ez ugye nem mukodokepes, mert a 10.20.0.126 nem elerheto ARP -n, lasd fentebb. Tehat sem icmp, sem arp csomagok nem jutnak at a 10.20.0.126 -ra.

nft -vel a forward engedelyezve van a ket halozat kozott; SNAT a gateway -eken rendben.

10.30.0.125 -rol (a 10.30.0.0/24 -en levo gw) elerheto a 10.20.0.0/24 barmely gepe es viszont is a 10.20.0.126 -rol, DE bamrly, nem gateway geprol az ellentetes halozat semelyik gepe nem erheto el-

ping -c 1 -I 10.30.0.125 10.20.0.124
PING 10.20.0.124 (10.20.0.124) from 10.30.0.125 : 56(84) bytes of data.
64 bytes from 10.20.0.124: icmp_seq=1 ttl=62 time=16.9 ms

--- 10.20.0.124 ping statistics ---
1 packets transmitted, 1 received, 0% packet loss, time 0ms
rtt min/avg/max/mdev = 16.895/16.895/16.895/0.000 ms
 

A kerdes:
Hogyan oldjam meg oda-vissza az atjarast a fentiek alapjan a ket halozat kozott? Lathatoan kellene routing, csak azt gyakorlatilag nem tudtam implementalni.

Üdv, olyan helyen vagyok belföldön, ahol lényegében az egészetlen ésszerű megoldás a korlátlan mobilnet. T-ről váltottam két One-ra, aztán május 1-én tapasztaltam először, hogy természetellenesen lelassult, kb. olyan szintre, mint amilyen volt a net az ADSL-dialup korában. (1.) mindegy, hogy mobil hotspotot használok vagy (2.) LTE-routert az is mindegy, hogy csak egy eszközön használnám vagy 10-nél többön, ugyanaz a helyzet. Két teljesen különálló SIM-ről van szó, amik gondolom én, azonos cellákat használnak. Van ötletetek azzal kapcsolatban, hogy mit lehet tenni ügyféloldalon? Pl. OpenCellid-ről lepuskázva az LTE-routerbe be lehet állítani, hogy mindig ugyanazt használja, de nem véletlenül nem alapértelmezés. A szolgáltató mennyire rugdosható v hogyan állapítható meg, hogy direkt lassítanak-e? Nem torrentezek vagy ilyesmi, csak egész nap használom a netet. 

Feltűnt, hogy Németországban, magyar Vodafone (bocsánat, One) előfizetéssel, "magyar IP címet" kap a telefon. Értem ez alatt, hogy az látszik a külvilág felé, nyilván a telefonon valami RFC-1918 cím van, így bukkan elő a CGNAT mögül. Oké.

Viszont másoknak, más országban meg helyit osztanak (lásd mint előbb).

Őszintén szólva pont ezt nem néztem, amikor más országokban jártam, hogy mit kaptam.

Szóval: mitől függ (APN? EU vs. !EU?), hogy hol bukkan elő az ember, és ehhez kapcsolódóan az is érdekelne, hogy milyen kombó (magyar szolgáltató + csomag + ország) hogy viselkedik?

Mint mindig, elsősorban a konkrét tapasztalatokra vagyok kíváncsi, nem arra, hogy az AI  vagy a kereső mit mond.

Előre is köszi.