1
Sítě / Re:T-Mobile Fiber 2 Gbps a vlastní zařízení
« kdy: 06. 03. 2026, 17:48:46 »
A trochu mimo téma, ale netušíte někdo, kdy T-Mobile konečně na optice zprovozní IPv6?
Zobrazit příspěvky
Tato sekce Vám umožňuje zobrazit všechny příspěvky tohoto uživatele. Prosím uvědomte si, že můžete vidět příspěvky pouze z oblastí Vám přístupných.
2
Sítě / Re:T-Mobile Fiber 2 Gbps a vlastní zařízení
« kdy: 06. 03. 2026, 11:17:23 »SMS přišla:
Dobry den, zasuvka pro objednavku O-8508297xxxx na Fiber Internet je pripravena. Nyni staci zapojit vas vlastni HW a poslat SMS pro jeho zprovozneni. SMS v nasledujicim zneni zaslete na cislo 5025 (pripadne +420 736 370 574). FIBER "TECHNOLOGIE" "SERIOVE CISLO" "CISLO OBJEDNAVKY" Podrobnejsi instrukce jsme vam poslali i v e-mailu. Nebo je najdete na https://www.t-mobile.cz/dcpublic/Fiber-Internet-Pozadavky-na-zarizeni.pdf. Pekny den, Vas T-Mobile
To je super info, diky. Poslali jeste neco zajimavyho v tom e-mailu, krome toho PDF? Jak presne tedy ma byt ten format te SMS, co ma byt misto "TECHNOLOGIE"?
3
Server / Re:FreeIPA a mailserver Stalwart
« kdy: 24. 11. 2025, 12:40:53 »
Nevim jestli jsem pochopil dotaz 
ale kouknul bych na OpenOTP, ten má nějakou formu LDAP bridge - https://www.rcdevs.com/products/ldproxy/
ale kouknul bych na OpenOTP, ten má nějakou formu LDAP bridge - https://www.rcdevs.com/products/ldproxy/
4
Sítě / Re:T-Mobile Fiber 2 Gbps a vlastní zařízení
« kdy: 09. 10. 2025, 12:36:54 »
Ještě je možnost pořídit si za pár korun https://www.ebay.com/itm/267199518784 a strčit to do SFP+ v routeru, to by těch 2G mělo jet. Stačí jen naklonovat vendor ID + SN z dodaného ONT (viz https://github.com/hwti/G-010S-A) a na routeru zprovoznit PPPoE nad VLAN 2510.
Další info k tomu modulu tady: https://hack-gpon.org/ont-nokia-g-010s-a/, případně rád poradím. Funguje mi to už rok, jen tedy na 1G - mám to v obyčejném SFP(ne +) a objednán jen 1G.
Další info k tomu modulu tady: https://hack-gpon.org/ont-nokia-g-010s-a/, případně rád poradím. Funguje mi to už rok, jen tedy na 1G - mám to v obyčejném SFP(ne +) a objednán jen 1G.
5
Sítě / Re:Řešení malé LAN s IP kamerami
« kdy: 03. 10. 2025, 15:34:44 »VLANy jsou v tomto příkladu obdobnou tří nepropojených switchů, kde do jednoho jdou všechny kamery, druhého personál a třetího ostatní. Takže pokud si někdo z personálu nastaví IP z rozsahu kamer, tak se na ně stejně nedostane. Pokud by tam byl switch bez konfigurace VLAN, tak by se na ně dostal.Já jsem variantu provozovat více subnetů na jednom interface/nonVLAN switchi vůbec neuvažoval, protože to není síť ale prasárna, tam nebude fungovat ani DHCP. To tu nemůžeme nikomu radit jako řešení.
6
Sítě / Re:Řešení malé LAN s IP kamerami
« kdy: 03. 10. 2025, 13:11:55 »
Já asi nechápu dotaz, přece používání různých subnetů s jedním switchem automaticky znamená rozdělení na VLANy?
7
Sítě / Re:ZTE WF831 bridge mode
« kdy: 28. 07. 2025, 10:06:25 »
Modul je zavedený OK. Skoro to z toho logu vypadá, že nastavené je to dobře, jen není IP adresa na LTE interface? Jak vypadá ifconfig?
8
Sítě / Re:ZTE WF831 bridge mode
« kdy: 25. 07. 2025, 09:49:34 »
MAC Bind u konfigurace APN musí být buď prázdné, pak se veřejná adresa předá prvnímu zařízení/MAC adrese na LAN, případně se tam dá natvrdo dát MAC adresa toho routeru.
IPv6 bych upřímně ani nezapínal, protože pak se ten telnet s veřejně známým heslem dostane na veřejný internet a nejde to nijak vypnout ani zablokovat...
IPv6 bych upřímně ani nezapínal, protože pak se ten telnet s veřejně známým heslem dostane na veřejný internet a nejde to nijak vypnout ani zablokovat...
9
Sítě / Re:ZTE WF831 bridge mode
« kdy: 25. 07. 2025, 09:42:12 »
Jsem vyhrabal nějaký poznámky
telnet přístup
gdm7243 login: root
Password：Si8a&2vV9
Aby bridge/passthru vůbec fungoval, musí být tyhle hodnoty:
ucfg get config nat
ENABLE=1
ucfg get config wan
network_mode=bridge
Musí být zavedený modul ip_passthrough:
lsmod | grep -q ip_passthrough
Měl by být nastaven cca takto:
echo Y > /sys/kernel/debug/ippassthrough/eth0/outiface
echo Y > /sys/kernel/debug/ippassthrough/eth0/enabled
echo Y > /sys/kernel/debug/ippassthrough/eth0/enable_bridge
echo Y > /sys/kernel/debug/ippassthrough/lte0pdn0/enabled
echo Y > /sys/kernel/debug/ippassthrough/lte0pdn0/enable_bridge
Na lte0pdn0 musí nejprve dojít k přiřazení IP adresy z LTE než tu samou předá přes DHCP:
lte0pdn0 Link encap:Ethernet HWaddr 60:14:66:63:82:46
inet addr:10.153.160.204 Bcast:10.153.160.255 Mask:255.255.255.0
Pak by to mělo vypadat nějak takhle:
telnet přístup
gdm7243 login: root
Password：Si8a&2vV9
Aby bridge/passthru vůbec fungoval, musí být tyhle hodnoty:
ucfg get config nat
ENABLE=1
ucfg get config wan
network_mode=bridge
Musí být zavedený modul ip_passthrough:
lsmod | grep -q ip_passthrough
Měl by být nastaven cca takto:
echo Y > /sys/kernel/debug/ippassthrough/eth0/outiface
echo Y > /sys/kernel/debug/ippassthrough/eth0/enabled
echo Y > /sys/kernel/debug/ippassthrough/eth0/enable_bridge
echo Y > /sys/kernel/debug/ippassthrough/lte0pdn0/enabled
echo Y > /sys/kernel/debug/ippassthrough/lte0pdn0/enable_bridge
Na lte0pdn0 musí nejprve dojít k přiřazení IP adresy z LTE než tu samou předá přes DHCP:
lte0pdn0 Link encap:Ethernet HWaddr 60:14:66:63:82:46
inet addr:10.153.160.204 Bcast:10.153.160.255 Mask:255.255.255.0
Pak by to mělo vypadat nějak takhle:
Kód: [Vybrat]
Jul 25 09:37:33 gdm7243 daemon.info dnsmasq[6152]: [DHCP PROXY] apn(1) address get 194.228.92.128
Jul 25 09:37:33 gdm7243 daemon.info dnsmasq[6152]: [DHCP PROXY] apn(1) address get 194.228.92.129
Jul 25 09:37:38 gdm7243 daemon.info dnsmasq[6152]: [DHCP PROXY] apn(1) address get 10.153.160.204
Jul 25 09:37:38 gdm7243 daemon.info dnsmasq[6152]: [DHCP PROXY] apn(1) address get 194.228.92.128
Jul 25 09:37:38 gdm7243 daemon.info dnsmasq[6152]: [DHCP PROXY] apn(1) address get 194.228.92.129
Jul 25 09:37:43 gdm7243 daemon.info dnsmasq[6152]: [DHCP PROXY] apn(1) address get 10.153.160.204
Jul 25 09:37:43 gdm7243 daemon.info dnsmasq[6152]: [DHCP PROXY] apn(1) address get 194.228.92.128
Jul 25 09:37:43 gdm7243 daemon.info dnsmasq[6152]: [DHCP PROXY] apn(1) address get 194.228.92.129
Jul 25 09:37:45 gdm7243 daemon.info dnsmasq[6152]: [DHCP PROXY] device<dc:2c:6e:c7:ff:a2> dhcpp_is_bridge
Jul 25 09:37:45 gdm7243 daemon.info dnsmasq[6152]: [DHCP PROXY] dhcpproxy check request mac:dc:2c:6e:c7:ff:a2
Jul 25 09:37:45 gdm7243 daemon.info dnsmasq[6152]: [DHCP PROXY] mac<dc:2c:6e:c7:ff:a2> is bridge,vid:0,port:eth0
Jul 25 09:37:45 gdm7243 daemon.info dnsmasq[6152]: [DHCP PROXY] device<dc:2c:6e:c7:ff:a2>is passthrough bridge port
Jul 25 09:37:45 gdm7243 daemon.info dnsmasq[6152]: [DHCP PROXY] recv dhcp_packet from Bridge Port
Jul 25 09:37:45 gdm7243 daemon.info dnsmasq[6152]: [DHCP PROXY] [DHCP PROXY] hlen 6 xid 5429df6a ciaddr 10.153.160.204 yiaddr 0.0.0.0 siaddr 0.0.0.0 giaddr 0.0.0.0 chaddr dc:2c:6e:c7:ff:a2 sname
Jul 25 09:37:45 gdm7243 daemon.info dnsmasq[6152]: [DHCP PROXY] dhcpproxy check request mac:dc:2c:6e:c7:ff:a2
Jul 25 09:37:45 gdm7243 daemon.info dnsmasq[6152]: [DHCP PROXY] mac<dc:2c:6e:c7:ff:a2> is bridge,vid:0,port:eth0
Jul 25 09:37:45 gdm7243 daemon.info dnsmasq[6152]: [DHCP PROXY] IP 192.168.0.1
Jul 25 09:37:45 gdm7243 daemon.info dnsmasq[6152]: [DHCP PROXY] Adapter index 2
Jul 25 09:37:45 gdm7243 daemon.info dnsmasq[6152]: [DHCP PROXY] MAC 60:14:66:63:82:45
Jul 25 09:37:45 gdm7243 daemon.info dnsmasq[6152]: [DHCP PROXY] get_lease_by_mac:ip:<10.153.160.204>,expired:<4918>, vid 0
Jul 25 09:37:45 gdm7243 daemon.notice dnsmasq[6152]: [DHCP PROXY] Received dc:2c:6e:c7:ff:a2 REQUEST
Jul 25 09:37:45 gdm7243 daemon.notice dnsmasq[6152]: [DHCP PROXY] Sending ACK to 10.153.160.204
Jul 25 09:37:45 gdm7243 daemon.info dnsmasq[6152]: [DHCP PROXY] [DHCP PROXY] hlen 6 xid 5429df6a ciaddr 10.153.160.204 yiaddr 10.153.160.204 siaddr 0.0.0.0 giaddr 0.0.0.0 chaddr dc:2c:6e:c7:ff:a2 sname
Jul 25 09:37:49 gdm7243 daemon.info dnsmasq[6152]: [DHCP PROXY] apn(1) address get 10.153.160.204
Jul 25 09:37:49 gdm7243 daemon.info dnsmasq[6152]: [DHCP PROXY] apn(1) address get 194.228.92.128
Jul 25 09:37:49 gdm7243 daemon.info dnsmasq[6152]: [DHCP PROXY] apn(1) address get 194.228.92.129
10
Sítě / Re:ZTE WF831 bridge mode
« kdy: 24. 07. 2025, 14:10:41 »
Ten "bridge" mód je strašnej hack, WAN adresu reálně dostane pořád ten modem a ten tu samou pak přes DHCP předá jednomu/prvnímu klientovi na LAN. A pak tam jsou iptables pravidla, díky kterým to funguje.
Zkontroloval bych jestli tam není natvrdo zadaná MAC adresa povolená na tom LAN portu.
Já mám WF830 a taky mi to nešlo rozchodit, nakonec jsem se tam přihlásil telnetem a po nějakým laborování a pochopení jak to má fungovat se mi to povedlo zprovoznit. Možná by pomohlo i udělat factory reset.
Zkontroloval bych jestli tam není natvrdo zadaná MAC adresa povolená na tom LAN portu.
Já mám WF830 a taky mi to nešlo rozchodit, nakonec jsem se tam přihlásil telnetem a po nějakým laborování a pochopení jak to má fungovat se mi to povedlo zprovoznit. Možná by pomohlo i udělat factory reset.
11
Sítě / Re:Statická IPv4 a IPv6 PD na DOCSIS síti
« kdy: 17. 06. 2025, 10:32:41 »
Na webu to mají - https://www.vodafone.cz/pece/internet-data/kabelovy-internet/pevny-internet-kabel-vlastni-modem/ a https://www.vodafone.cz/_sys_/FileStorage/download/3/2025/pozadavky-na-zarizeni-docsis.pdf?nc=13 - takže teoreticky by to jít mělo, držím palce nicméně souhlas, že takových zařízení stejně moc není a bude se to přinejlepším chovat jako VF modem v bridge, tj. bez IPv6.
Kdysi jsem to zvažoval, abych se zbavil obří krabice VF Station, ale nic moc menšího splňujícího specifikace jsem stejně nenašel.
nicméně souhlas, že takových zařízení stejně moc není a bude se to přinejlepším chovat jako VF modem v bridge, tj. bez IPv6.Kdysi jsem to zvažoval, abych se zbavil obří krabice VF Station, ale nic moc menšího splňujícího specifikace jsem stejně nenašel.
12
Sítě / Re:Doporučené postupy k IPv6 pro domácí síť
« kdy: 14. 05. 2025, 10:10:10 »
Řešim úplně ty samý problémy Ještě výživnější to je s dual WAN.
Jinak k 3) - to je specifikum Mikrotika, taky mě to štvalo, nakonec jsem přešel na OpenWRT, kde je to pořešené pěkně:
Ještě výživnější to je s dual WAN.Jinak k 3) - to je specifikum Mikrotika, taky mě to štvalo, nakonec jsem přešel na OpenWRT, kde je to pořešené pěkně:
Citace
ip6hint: Subprefix ID to be used if available (e.g. 1234 with an ip6assign of 64 will assign prefixes of the form ...:1234::/64 or given LAN ports, LAN & LAN2, and a prefix delegation of /56, use ip6hint of 00 and 80 which would give prefixes of LAN ...:xx00::/64 and LAN2 ...:xx80::/64)
13
Bazar / Re:Prodám 100Mbit switche
« kdy: 01. 05. 2025, 22:09:44 »
Já do toho nechci moc kecat, ale podle mě jsou ty BayStacky gigabitový a nebyly to úplně špatný stroje, měly i slušný L3 funkce. Ale už je to dost let
14
Sítě / Re:IPv6 dualhome
« kdy: 11. 04. 2025, 17:25:35 »Problem tohohle reseni dualhomingu je, ze si klient bude vybirat zdrojovou adresu podle nejdelsi bitove shody - takze nelze jedno pripojeni povazovat za aktivni a druhe za pasivni backup. Provoz typicky poleze do obou, a pokud je jedna pripojka vyrazne slabsi nez druha, tak to bude mit na klienty negativni dopad.
Tohle chápu a zatím mi to nevadí, chtěl jsem to nejdřív jen rozchodit. Ten source routing mezi routery zkusím, díky.
15
Sítě / IPv6 dualhome
« kdy: 11. 04. 2025, 16:14:40 »
Zdravím, mám dva OpenWRT routery v "HA", na vnitřních VLAN je pro IPv4 VRRP a každý router má vlastní WAN. Na IPv4 s WAN maškarádou failover mezi nimi funguje samozřejmě pěkně.
Teď se snažím rozchodit IPv6. Na jednom routeru je nativní DHCP-PD /56, na druhém prozatím HE tunel /48. Oba routery jsou nastavené stejně, konektivita na každém je funkční, na každé VLAN běží RA/SLAAC a adresy to přiděluje dobře.
Takhle to vypadá na PC na vnitřní VLAN:
Jen mi ale uniká, jak docílit, aby spojení z PC odcházely přes tu bránu která zdrojový prefix přidělila? Aktuálně to funguje blbě - zdrojová adresa se (asi) zvolí správně podle RFC3484, ale vše odchází jen přes první bránu, takže pokud se to zrovna netrefilo tak to nefunguje.
Teď se snažím rozchodit IPv6. Na jednom routeru je nativní DHCP-PD /56, na druhém prozatím HE tunel /48. Oba routery jsou nastavené stejně, konektivita na každém je funkční, na každé VLAN běží RA/SLAAC a adresy to přiděluje dobře.
Takhle to vypadá na PC na vnitřní VLAN:
Kód: [Vybrat]
2: ens192: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 state UP qlen 1000
inet6 2a01:9425:xxxx:170:dfce:768d:c031:a141/64 scope global dynamic noprefixroute
valid_lft 37309sec preferred_lft 32989sec
inet6 2001:470:xxxx:70:14e2:e8aa:6284:2403/64 scope global noprefixroute
valid_lft forever preferred_lft forever
Kód: [Vybrat]
2001:470:xxxx:70::/64 dev ens192 proto ra metric 100 pref medium
2001:470:xxxx::/48 via fe80::f2ad:4eff:fe28:9c73 dev ens192 proto ra metric 100 pref medium
2a01:9425:xxxx:170::/64 dev ens192 proto ra metric 100 pref medium
2a01:9425:xxxx:100::/56 via fe80::f29f:c2ff:fe61:7afa dev ens192 proto ra metric 100 pref medium
fe80::/64 dev ens192 proto kernel metric 1024 pref medium
default proto ra metric 100 pref medium
nexthop via fe80::f29f:c2ff:fe61:7afa dev ens192 weight 1
nexthop via fe80::f2ad:4eff:fe28:9c73 dev ens192 weight 1
Jen mi ale uniká, jak docílit, aby spojení z PC odcházely přes tu bránu která zdrojový prefix přidělila? Aktuálně to funguje blbě - zdrojová adresa se (asi) zvolí správně podle RFC3484, ale vše odchází jen přes první bránu, takže pokud se to zrovna netrefilo tak to nefunguje.
