|
30.12.2020., 23:28 | #301 | |
Premium
Datum registracije: Jun 2012
Lokacija: Zagreb
Postovi: 505
|
Citiraj:
|
|
30.12.2020., 23:31 | #302 | ||
Premium
Datum registracije: Feb 2007
Lokacija: Istra
Postovi: 3,008
|
Citiraj:
Kakav autokey u linux cronu na nekoj headless kanti koja dela 24/7? Kroz web sučelje naravno radi. Browser u post zakvači neke "random" varijable koje ja ne mogu jednostavno izmisliti, a nema ih kod logina i ostalih funkcija. U nedostatku vremena puštam to programiranje za neka bolja vremena. Inače danas sam skinuo log iz speedšrota, uptime je bio od 02.12. kada je izgleda povukao novi fw, verzija 09022001.00.032T2. Nakon toga se čudno ponaša, povremeno se dogodi neki "soft reset", vrijeme mu se vrati na 1970-01-01, onda se ETH portovi ugase i nakon nekog vremena opet je online i synca se s NTP serverom. Nema druge nego ga zaobići i router na ONT preko switcha ili direkt. Eto, ja si dao truda, ali ne želim više vrijeme trošiti na tu kramu Citiraj:
Github nije moj, našao sam ga slučajno Evo ako imaš volje za proučavati, ovo je reboot spremljen iz chrome, mrvicu drugačiji je iz FF, ali ista stvar: Code:
curl 'http://192.168.1.1/data/Reboot.json?_time=1609358749921&_rand=208&_time=1609358749921&_rand=377' \ -H 'Connection: keep-alive' \ -H 'Accept: application/json, text/javascript, */*' \ -H 'User-Agent: Mozilla/5.0 (X11; Linux x86_64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/87.0.4280.88 Safari/537.36' \ -H 'X-Requested-With: XMLHttpRequest' \ -H 'Referer: http://192.168.1.1/html/content/config/problem_handling.html' \ -H 'Accept-Language: en-US,en;q=0.9,hr;q=0.8,sr;q=0.7' \ -H 'Cookie: session_id=1FBFC14009C9B8EA617C501E71F277AF' \ --compressed \ --insecure Kad složim ovakav isti request u curl, ne dobivam odgovor Ovi parametri _time i _rand mi nisu jasni otkuda ih browser dobiva? Zadnje izmijenjeno od: c-shadow. 30.12.2020. u 23:40. |
||
|
|
Oglas
|
|
04.01.2021., 01:51 | #303 | |
Premium
Datum registracije: Dec 2007
Lokacija: Osijek
Postovi: 296
|
Citiraj:
Dodatno kada se ima podešeno timerule za paljenje / gašenje wlana, prilikom paljenja pali oba wifi 2.4 i 5 Ghz iako treba po postavkama koristiti samo 2.4. Ima li netko rješenje kako ugasiti 5G jer mi je nepotreban? |
|
07.01.2021., 10:49 | #304 |
Uptime freak
Datum registracije: Dec 2002
Lokacija: Ri, Cro
Postovi: 2,734
|
Htjedoh rec nes vezano za ono sto svi imaju problema uz PPPoE stack... sve vise pocinjem misliti da je modem ko modem ok, nego da netko s druge strane napravi nesto zbog cega veza puca. Naime, od 17.12. do danas, 07.01., Mikrotik je dizao PPPoE u urednim 24h intervalima, downtime bi bio po 1 sekundu nakon isteka 24 sata. Danas, prvi radni dan nakon blagdana, kao da je netko došao sa godišnjeg i eto prvog random disconnecta. Nemam drugog objašnjenja... |
08.01.2021., 02:09 | #305 | |
Premium
Datum registracije: Oct 2010
Lokacija: Kaštel Lukšić
Postovi: 1,404
|
vlan3880
Jan 8 01:35:39 pppoe-relay[21491]: PADS packet from 00:90:1a:a2:ba:40 on interface vlan3880 does not have Relay-Session-Id tag
Jan 8 01:35:39 pppd[21497]: PAP authentication succeeded
Jan 8 01:35:39 pppd[21497]: peer from calling number 00:90:1A:A2:BA:40 authorized
Jan 8 01:35:39 pppd[21497]: local IP address 93.xxx.xxx.xxx
Jan 8 01:35:39 pppd[21497]: remote IP address 172.29.252.66
Jan 8 01:35:40 nat: apply nat rules (/tmp/nat_rules_ppp0_vlan3880)
Jan 8 01:35:40 wan: finish adding multi routes
Jan 8 01:35:40 miniupnpd[7387]: shutting down MiniUPnPd
Jan 8 01:35:40 start_ddns: update WWW.NO-IP.COM noip, wan_unit 0
Jan 8 01:35:41 miniupnpd[4625]: version 1.9 started
Jan 8 01:35:41 miniupnpd[4625]: HTTP listening on port 37616
Jan 8 01:35:41 miniupnpd[4625]: Listening for NAT-PMP/PCP traffic on port 5351
Jan 8 01:35:41 ddns update: ez-ipupdate: starting...
Jan 8 01:35:42 ddns update: connected to dynupdate.no-ip.com (52.9.108.157) on port 443.
Jan 8 01:35:43 WAN Connection: WAN was restored.
Jan 8 01:35:43 ddns update: request successful
Jan 8 01:35:43 ddns update: asusddns_update: 0
Jan 8 01:35:44 ddns: ddns update ok
Jan 8 01:35:44 ddns update: exit_main
Ponekad ali jako jako rijetko 1 ili 2 puta mjesečno kao da mu DSLAM nešalje odgovor a PPPoE User/Pass su uredni:Code:
WAN Connection: Failed to authenticate ourselves to peer. Code:
pppd[21497]: PAP authentication succeeded pppd[21497]: peer from calling number 00:90:1A:A2:BA:40 authorized Malo sam čačkao po netu ove MAC adrese došao do rezultata JUNIPER NETWORKS i UNISPHERE SOLUTIONS kojeg je Juniper Networks otkupio tako bar kaze wikipedia(https://en.wikipedia.org/wiki/Unisphere_Networks) Googlanjem Juniper VDSL DSLAM bacilo mi je linkove na alibabu https://www.alibaba.com/product-deta...039244471.html Tako da moj zaključak je da i DSLAMi su im jedna vrsta šrota.--> Dali je i dalje moguće skidanje i decrypt confinga sa starog SpeedŠrota ili su to oped nekako onemogućili u novijim FW?
Trebalo bi mi da se pozabavim oko rješavanja mita VoIPa pošto idem u nabavu VoIP rutera. https://www.asus.com/Networking-IoT-...es/DSL-AC68VG/ Ako proradi pišem how to kao što je bilo i za DSL-AC68-U @Delboy OFFTOPIC Citiraj:
Prije da se koriste šta jeftinijom varijantom DSLAMa kao što i rade sa ruterima. Evo ti log što meni Asus radi pri obnovi IP adrese: Code:
Jan 8 01:35:28 pppd[21497]: Connection terminated. Jan 8 01:35:28 pppd[21497]: Modem hangup Jan 8 01:35:28 nat: apply redirect rules Jan 8 01:35:38 pppoe-relay[21491]: PADO packet from 00:90:1a:a2:ba:40 on interface vlan3880 does not have Relay-Session-Id tag Jan 8 01:35:38 pppoe-relay[21491]: PADO packet from 00:90:1a:a3:1b:ba on interface vlan3880 does not have Relay-Session-Id tag Jan 8 01:35:38 pppoe-relay[21491]: PADO packet from 88:a2:5e:1c:ff:80 on interface vlan3880 does not have Relay-Session-Id tag Jan 8 01:35:38 pppoe-relay[21491]: PADO packet from 88:a2:5e:1c:ff:d2 on interface vlan3880 does not have Relay-Session-Id tag Jan 8 01:35:38 pppoe-relay[21491]: PADO packet from 88:a2:5e:1c:f8:92 on interface vlan3880 does not have Relay-Session-Id tag Jan 8 01:35:38 pppoe-relay[21491]: PADO packet from 88:a2:5e:1c:f8:bb on interface vlan3880 does not have Relay-Session-Id tag Jan 8 01:35:38 pppoe-relay[21491]: PADO packet from 00:90:1a:a2:bb:df on interface vlan3880 does not have Relay-Session-Id tag Jan 8 01:35:38 pppoe-relay[21491]: PADO packet from 00:90:1a:a3:1b:aa on interface vlan3880 does not have Relay-Session-Id tag Jan 8 01:35:38 pppoe-relay[21491]: PADO packet from 00:90:1a:a2:bc:fa on interface vlan3880 does not have Relay-Session-Id tag Jan 8 01:35:38 pppoe-relay[21491]: PADO packet from 00:90:1a:a4:e3:73 on interface vlan3880 does not have Relay-Session-Id tag Jan 8 01:35:38 pppoe-relay[21491]: PADO packet from 00:90:1a:a4:e3:1f on interface vlan3880 does not have Relay-Session-Id tag Jan 8 01:35:38 pppoe-relay[21491]: PADO packet from 3c:61:04:d3:1f:40 on interface vlan3880 does not have Relay-Session-Id tag Jan 8 01:35:39 pppd[21497]: Connected to 00:90:1a:a2:ba:40 via interface vlan3880 Jan 8 01:35:39 pppd[21497]: Connect: ppp0 <--> vlan3880 Jan 8 01:35:39 pppoe-relay[21491]: PADS packet from 00:90:1a:a2:ba:40 on interface vlan3880 does not have Relay-Session-Id tag Jan 8 01:35:39 pppd[21497]: PAP authentication succeeded Jan 8 01:35:39 pppd[21497]: peer from calling number 00:90:1A:A2:BA:40 authorized Jan 8 01:35:39 pppd[21497]: local IP address 93.xxx.xxx.xxx Jan 8 01:35:39 pppd[21497]: remote IP address 172.29.252.66 Jan 8 01:35:40 nat: apply nat rules (/tmp/nat_rules_ppp0_vlan3880) Jan 8 01:35:40 wan: finish adding multi routes Jan 8 01:35:40 miniupnpd[7387]: shutting down MiniUPnPd Jan 8 01:35:40 start_ddns: update WWW.NO-IP.COM noip, wan_unit 0 Jan 8 01:35:41 miniupnpd[4625]: version 1.9 started Jan 8 01:35:41 miniupnpd[4625]: HTTP listening on port 37616 Jan 8 01:35:41 miniupnpd[4625]: Listening for NAT-PMP/PCP traffic on port 5351 Jan 8 01:35:41 ddns update: ez-ipupdate: starting... Jan 8 01:35:42 ddns update: connected to dynupdate.no-ip.com (52.9.108.157) on port 443. Jan 8 01:35:43 WAN Connection: WAN was restored. Jan 8 01:35:43 ddns update: request successful Jan 8 01:35:43 ddns update: asusddns_update: 0 Jan 8 01:35:44 ddns: ddns update ok Jan 8 01:35:44 ddns update: exit_main Code:
WAN Connection: Failed to authenticate ourselves to peer. Code:
pppd[21497]: PAP authentication succeeded pppd[21497]: peer from calling number 00:90:1A:A2:BA:40 authorized Malo sam čačkao po netu ove MAC adrese došao do rezultata JUNIPER NETWORKS i UNISPHERE SOLUTIONS kojeg je Juniper Networks otkupio tako bar kaze wikipedia(https://en.wikipedia.org/wiki/Unisphere_Networks) Googlanjem Juniper VDSL DSLAM bacilo mi je linkove na alibabu https://www.alibaba.com/product-deta...039244471.html Tako da moj zaključak je da i DSLAMi su im jedna vrsta šrota. Zadnje izmijenjeno od: Nikky. 08.01.2021. u 09:25. |
|
08.01.2021., 09:40 | #306 | |
Premium
Datum registracije: Jun 2012
Lokacija: Zagreb
Postovi: 505
|
Citiraj:
Isto tako nije problem "kineski šrot"-DSLAM. Da je Huaweijev DSLAM šrot, ne bi ga koristio dobar dio Europe, između ostalog i DT u Njemačkoj, Openreach u UK itd. Problem je negdje dalje u njihovoj mreži jer se događa samo HT-u. Kad ide bitstream za nekog drugog ISP-a na istom tom DSLAM-u, nema PPPoE failurea (slučaj kod mene, 2 providera na bitstreamu i sad HT). |
|
08.01.2021., 23:27 | #307 |
Premium
Datum registracije: May 2008
Lokacija: hr
Postovi: 755
|
@Karlo666 Moguće da onda postoji neki limit na BRAS-u (od kojeg je mac adresa koju dobiješ kao odgovor na pppoe request) koliko requestova moze doći sa pojedinog dlsam porta. Za voip podatke, decrypt tool ne radi na novoj verziji speedporta jer su promijenili način kako se kriptira config backup, ali se može izvuči bar password: (polje t_password) http://192.168.1.1/data/IPPhoneHandler.json Za username čes morati pogađati ako ga neznaš, ide onaj oblik pperic22@ims.t-com.hr, pa gađaj brojeve od 1 dok ne proradi. To sam našao na https://github.com/nikolas-n/Speedpo...e-Router-hacks |
09.01.2021., 00:44 | #308 | |
Premium
Datum registracije: Oct 2010
Lokacija: Kaštel Lukšić
Postovi: 1,404
|
Citiraj:
Dakle imam u planu nabaviti onaj stari Speedport W724V Type Ci a zanima me dali se i dalje može decryptat confing iz njega sa onom skriptom na njegovom najnovijem FWu? Novi Speedport Plus me nezanima. |
|
09.01.2021., 01:13 | #309 |
Premium
Datum registracije: May 2008
Lokacija: hr
Postovi: 755
|
Radilo je bilo na zadnjim verzijama 09091601.00.039 i 09091602.00.006 (valjda su to zadnje) |
18.01.2021., 16:45 | #310 |
Uptime freak
Datum registracije: Dec 2002
Lokacija: Ri, Cro
Postovi: 2,734
|
Kad bi meni netko rekao što se događa svakih otprilike 17.30 sati, to bi ja volio znati. To bi zapravo mogao biti ključni dio problema s ovim ruterom (u pppoe passthrough modu) jer je nevjerojatno da točno toliko traje PPPoE konekcija koju je nakon pucanja nemoguće ponovno uspostaviti bez reboota rutera. Dio izvoda iz spajanja za 12. mjesec i 01. mjesec... Kao što rekoh prije, negdje od 21.12. od 06.01. je držalo bez problema po 24h, rekonekti koji se vide su namjerni: Dakle, ili je netko bio na godišnjem u T-Comu od 21.12. do 06.01. i nije čačkao po DSLAM-u ili njihovoj mreži općenito i zato je radilo bez pucanja, ili je nešto bilo ugašeno tih 15-16 dana što inače izaziva pucanje veze svakih 17 i pol sati. Brijem da bi nešto moglo biti u tim brojkama... |
|
|
Oglas
|
|
23.01.2021., 03:43 | #311 |
Uptime freak
Datum registracije: Dec 2002
Lokacija: Ri, Cro
Postovi: 2,734
|
Danas sam došao do zaključka. Dakle DSLAM ima ograničenje MAC adresa i samo koji mu se prvi javi njemu odgovara. Stvar je u tome što se na Speedšrotu ne može ugasiti "always on" način, pa kad veza pukne, bilo to nakon x sati ili nakon 24h, ako Speedšrot prvi pokuša napraviti konekciju, DSLAM zapamti njegov MAC i onda se router iza može slikati. Rješenje je staviti ruter koji nema samo PPPoE passthrough, nego se može podesiti da se ne spaja automatski. Onda Mikrotik ili bilo koji drugi ruter sam uspostavi vezu, ponekad istu sekundu nakon pucanja (ako je 24h) ili nakon par minuta ako je puklo iz čista mira (Mikrotik javlja kao i Asus od kolege, "maximum number of sessions exceeded" i "authentication failed" kad pukne iz čista mira, valjda dok DSLAM ne skuži da je PPPoE konekcija pala). |
31.01.2021., 17:17 | #312 | |
Premium
Datum registracije: Oct 2010
Lokacija: Kaštel Lukšić
Postovi: 1,404
|
Citiraj:
Isto tako pošto imam config decryptan ZTE V4 našao sam EchoTime i EchoRetry postavke.ISPovi ruteri nukeaju DSLAM po 30 requestova po sekundi sa 20 pokušaja pa im PPPoE krepa pa onda ide klasika FactoryReset i čupanje iz struje na 10 sec. Dok je na mom i bratovom po defaultu 6 requestova i 10 pokušaja(valjalo bi se poigrat s tim) Ako unesem vrijednosti od ISPa u svoj totalno poludi i za PPPoE obnovu mu treba između 40sec do minut ipo. http://imgur.com/dDmArP0 Sent from my Nexus 6P using Tapatalk |
|