- DIGI kábel TV
- A franciáknak elege van abból, hogy minden gyerek mobilozik
- Milyen NAS-t vegyek?
- Telekom otthoni szolgáltatások (TV, internet, telefon)
- Szabadulnak a kínai eszközöktől az amerikai szolgáltatók, de ez sokba kerül
- Aliexpress tapasztalatok
- Milyen program, ami...?
- Milyen routert?
- Jelszókezelők
- Kék halál (BSOD)
Új hozzászólás Aktív témák
-
Andralin
aktív tag
Sziasztok!
De örülök, hogy rátaláltam erre a topikra!
És ez a telnet exploit fantasztikus!!!
Nekem tegnap jött meg az M2-s kamerám és egy hatalmasat csalódtam, mert nem hajlandó rejtett SSID-vel fentmaradni a wifin! Nálam otthon rejtett az SSID, tudom, hogy nem sokat ér ha valaki ki akarja találni, de ezen akkor sem akarok változtatni.
Ha publikusra változtatom, akkor azonnal felmegy az M2 a wifire, ha visszarakom rejtettre, akkor meg elveszti a kapcsolatot és nem tud visszalépni rá.
Kicsit játszottam a linuxos rendszerében, és a következőkre jöttem rá.
Egy wpa_supplicant nevű alkalmazás fut rajta, ami a wifi csatlakozásért felelős, ez ott van a process listában:
wpa_supplicant -B -Dwext -iwlan0 -c /tmp/wpa_supplicant.confÉs az SSID-t meg a wifi jelszót ebből a fájlból olvassa ki: /tmp/wpa_supplicant.conf
Ez a fájl így néz ki:
ctrl_interface=/var/run/wpa_supplicant
ap_scan=1
network={
ssid="mywifissid"
psk="mywifipsk"
}A második sorban az ap_scan a lényeg, azt olvastam, hogy elvileg az 1-es lrték azt jelenti, hogy publikus SSID-re csatlakozzon, a 2-es pedig azt, hogy rejtett SSID-re.
Szóval valahogy át kellene írni rendszerszinten ezt a sort, arra, hogy ap_scan=2
Ezt szerintetek hogy tudnám megtenni?
Ha közvetlen szerkesztem a /tmp/wpa_supplicant.conf fájlt, annak természetesen nincs semmi azonnali hatása és a következő reboot után el is felejti.
Vajon boot során hogyan, mi alapján generálódik le ez fájl a /tmp-ben? Szóval mit kellene megváltozatni, hogy már a megfelelő 2-es értékkel jönnön létre ez a fájl és az alapján hozza létre a wifi kapcsolatot? -
Andralin
aktív tag
Sajnos az /etc az read-only fájlrendszeren van.
Már próbálkoztam a wpa_supplicant leállításával és újraindítással a módosított scan paraméterrel, de hiába.
A /system az eeprom-on van, írható és emlékszik a módosításokra boot után is. Ide mentettem a wpa_supplicant.conf átírt példányát. Egy scripttel felülírom a /tmp-ben a config fájlt az újjal, kikillelem a wpa_supplicant processzt majd újraindítom:cp /system/wpa_supplicant.conf /tmp
kill 127
rm /tmp/run/wpa_supplicant/wlan0
wpa_supplicant -B -Dwext -iwlan0 -c /tmp/wpa_supplicant.confEzek után sajnos nem tér vissza a wifi-re egyáltalán, hosszabb idő után se, ha kapcsolgatok hidden vagy sima SSID között az AP-n, akkor sem.
Azt tudom, hogy az SSID rejtése nem sokat ér, sőt, megfelelő linuxos progival némi hallgatózás után a wifi jelekből vissza lehet fejteni a rejtett SSID-t is.
![;]](//cdn.rios.hu/dl/s/v1.gif)
Nagyjából annyit ér az egész, hogy laikus szomszédok nem látják az AP-met.
De azért dühítő, hogy az összes többi eszközöm, köztük jópár okoseszköz gond nélkül támogatja a rejtett SSID-t, csak ez a kamera nem! Már 6 éve így van beállítva ezért nem fogom csak emiatt megváltoztatni.
-
Andralin
aktív tag
Siker!!!!!!
Elkezdtem játszani a wpa_supplicant.conf paramétereivel a leírása alapján: [link]
Nagynehezen kikísérleteztem, hogy tudja ez a rejtett SSID-t, csak kicsit trükkös paraméterekkel!
Az ap_scan=1 maradnia kell változatlannak, annyi kell csak, hogy a network blokkon belül beszúrjon az ember egy sort:
scan_ssid=1De aztán megoldani, hogy ez boot során automatán lefusson nem volt egyszerű!
Először is csináltam látrehoztam egy példányt a helyes, javított wpa_supplicant.conf fájlból a /system alatt.
Majd rájöttem, hogy az initből meghívott wifidaemon hozza létre a /tmp alatt a config fájl majd hívja meg a wpa_supplicant programot és ez ugye időbe telik. Korábban hiába másolom a /tmp-be a fájlt, mert utána felülírja a wifidaemon a saját verziójával. És ugye azt is meg kell várni, hogy elindul a wpa_supplicant mielőtt kinyírom a kill-el és elindítom újra a már javított fájlommal.Ezt úgy tudtam megoldani, hogy figyelem a wpa_supplicant által létrehozott wlan0 socket fájlt, amint ez a fájl megjelenik, indulhat a móka!
A lényeg, hogy végül ezeket a sorokat kellett a /system/init/ipcam.sh végére biggyeszteni:
file=/tmp/run/wpa_supplicant/wlan0
while [ ! -e "$file" ]
do
sleep 3
done
cp /system/wpa_supplicant.conf /tmp
killall wpa_supplicant
rm /tmp/run/wpa_supplicant/wlan0
wpa_supplicant -B -Dwext -iwlan0 -d -c /tmp/wpa_supplicant.conf &Így mostmár újraindítva automatikusan fel tud lépni a rejtett SSID-s wifire is!
Teljesen saját munka, ez a neten sehol nincs még dokumentálva kereséseim alapján.
Akinek hasznos. használja egészséggel!
Azért tényleg röhej, hogy a kínaiak ezt nem tudták beletenni!
Egy rohadt sor lett volna abban a szerencsétlen config fájlban![ Szerkesztve ]
-
Andralin
aktív tag
Az mindegy, hogy mikor cserélem le a konfigot, úgy is csak a következő elinduláskor olvassa be egyszer és kész.
Ezt a linket találtam én is, amit írtál, és tényleg ott a lényeg, a scan_ssid. Csak azzal szívtam, hogy az ap_scan ennél a kis mocsoknál nem lehet 2, mert akkor nem volt hajlandó csatlakozni a rejtettre!
Az ap_scan-t 1-nek kell hagyni és csakis így megy fel a rejtettre. -
Andralin
aktív tag
Csak egy kis érdekesség: több külföldi blogon olvastam, hogy az M2 kamerába valamilyen backdoor lehet, mert UDP protokollal küld adatokat kéretlenül külső címekre.
Gondoltam ezt még lecsekkolom. Beállítottam a tűzfalamat, hogy blokkolja és logolja a kameráról kifelé indított kapcsolatokat. A kamera álltában folyamatosan próbálkozik külső IP-ket elérni UDP-n!
Nálam pl. ezeket:Jan 31 20:12:40 kernel: DROP <4>DROPIN=br0 OUT=ppp0 <1>SRC=172.20.8.111 DST=185.96.5.201 <1>LEN=76 TOS=0x00 PREC=0x00 TTL=63 ID=0 DF PROTO=UDP <1>SPT=11874 DPT=32100 LEN=56
Jan 31 20:12:40 kernel: DROP <4>DROPIN=br0 OUT=ppp0 <1>SRC=172.20.8.111 DST=47.88.137.120 <1>LEN=76 TOS=0x00 PREC=0x00 TTL=63 ID=0 DF PROTO=UDP <1>SPT=11874 DPT=32100 LEN=56
Jan 31 20:12:40 kernel: DROP <4>DROPIN=br0 OUT=ppp0 <1>SRC=172.20.8.111 DST=23.234.53.180 <1>LEN=76 TOS=0x00 PREC=0x00 TTL=63 ID=0 DF PROTO=UDP <1>SPT=11874 DPT=32100 LEN=56Szóval azért nem árt egy tűzfal szintű tiltás...
-
Andralin
aktív tag
Igazad van, hogy a felhő alapú elérés miatt szükséges, hogy kifelé kukucskáljon a kamera.
De akkor is, ki tudja, hogy egyúttal milyen kéretlen információt, adatokat küld még haza a gyártónak a cucc. Lehet, hogy én vagyok túl paranoiás, de én annyira nem bízom meg bennük.
Legyen inkább portforward, és akkor én tartom kezembe a dolgokat, csak akkor érhető el az eszköz, ha én kintről megszólítom, magától nem tud kifelé üzengetni kéretlenül senkinek semmit.
[ Szerkesztve ]
-
Andralin
aktív tag
Én ilyen dolgokat próbálnék még ki a TP-LINK-en:
- nem túl bonyolult-e az SSID, ha igen, akkor megváltoztatni egy egyszerű rövid szóra, ami csak ékezet néküli kis betűkből áll
- kipróbálni minden fajta, régebbi, már nem biztonságos titkosítási módokat is egyenként, hátha valamelyikre felcsatlakozik, sorban ezeket:
- WEP
- WPA/TKIP
- WPA2/TKIP
- WPA2/AES- nincs-e valami advanced wifi beállítás elállítva (pl. RTS, DTIM), ha igen, akkor vissza az eredetire
-
Andralin
aktív tag
Megpróbálok ide írni, mert saját topikja nincs a kamerának, amelyikkel gond van.
Beszereztem egy kültéri kamerát is, egy Blitzwolf BW-SIC1 típust. Elsődleges szempont, hogy RTSP streamen keresztül külső netről elérjem.
Firmware update után egész jól használható, nem csak belső hálón tudom elérni RTSP protokollal (pl. VLC playerrel) hanem port tuning megfelelő beállítása után külső netről is stabilan és szépen elérhető a stream.
Viszont egy óriási gond van vele! Amint besötétedik és bekapcsol a kamera infrája, az RTSP stream azonnal lehal. És ilyenkor minden egyes RTSP csatlakozási kísérlet (pl. VLC playeren a Play gomb megnyomása) a kamera újrabootolását váltja ki.
Amint van megint elég fény, stabilan jön az adat.Az infra LED-et nem lehet manuálisan kapcsolni, csakis automatikus, ezzel nem tudok játszani.
És ami érdekes, hogy a saját appjában nézve a stream működik mindig, sötétben is, bekapcsolt infrával is! Csak az RTSP stream hal meg ha az infra aktív.Valaki találkozott már hasonló buggal? Mi a franc okozhat ilyen hibát?
[ Szerkesztve ]
-
Andralin
aktív tag
Köszönöm a tippedet, igazából nekem is megfordult a fejembe a táphiba egypillanatra, de nem gondoltam volna, hogy tényleg az lesz.
Hát a tanácsodat olvasva csak összeeszkábáltam csatlakozót egy másik, komolyabb tápra és kipróbáltam vele. Tényleg az lesz a lúdas!
Ráakasztottam egy 12V 10A-es tápot, azzal tökéletes! Kicsit méregettem, nyugalmi helyzetben, nappali fénynél IR nélkül és streamelés nélkül mindösszes 130 mA-t vesz csak fel. Full terhelés akkor van amikor sötétben az IR bekapcsol és ráindítok egy live streamelést is, de ekkor is csak 380 mA-t vesz fel. Viszont a profi tápról stabilan működik, míg a gyári saját tápjáról ami 12V 1000 mA-nek van hirdetve meg folyton rebootolgat.
De mennyire gáz lehet már az az 1A-esnek hirdetett gyári táp, hogy 380 mA-t nem képes rendesen leadni?
Majd megpróbálok még beszerezni megfelelő csatlakozókat, hogy rá tudjak mérni a gyári táp feszültségére full terhelésnél, kíváncsi leszek mennyire esik le a fesz. Egyenlőre nem akarom szétbarmolni, amíg nem indítok reklamációt és nem egyezünk meg a Banggood-al egy új tápban.
Amúgy ezzel a kamerával kapcsolatban több olyan véleményt is olvastam, hogy az RTSP stream működik, de csak korlátozott ideig, folyton megszakad bizonyos időnként. Lehet, hogy másoknak is ilyen trágya tápot küldtek és azért vannak ilyen gondok vele?
Amúgy most már úgy néz ki, hogy firmware frissítés után és rendes táppal használva nagyon tuti kis kamera lesz ez, megérte az árát!
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Nálam pl. ezeket:
Új hozzászólás Aktív témák
Állásajánlatok
Cég: Promenade Publishing House Kft.
Város: Budapest
Cég: Ozeki Kft.
Város: Debrecen