W dniu 25.06.2025 o 10:49, J.F pisze:
[...]
>>> Dlaczego kamery miałyby wysyłać do siebie dane?
>>
>> Bo nie rozumiesz idei? :)
>
> A jaka ta idea?

Połączenie P2P, obojętnie czy to kamera-kamera czy kamera-komp czy
komp-komp :)

>> Bez doświadczenia, można pisać więcej bredni :) Pisz dalej...a kamerki
>> na P2P zapewne będą uradowane tym, że nie mają prawa działać a jednak
>> działają :)
>
> Niewątpliwie działają, ale czy wiemy całkowicie jak ?

To se poszukaj, jak tak bardzo chcesz drążyć temat :)


--
Pixel(R)??
Albo PiS albo Polska

do góry

On Wed, 25 Jun 2025 11:20:51 +0200, ʅǝxᴉꓒ®🇵🇱 wrote:
> W dniu 25.06.2025 o 11:10, ʅǝxᴉꓒ®🇵🇱 pisze:
>> Przeglądarki można użyć głównie do konfiguracji a nie samego podglądu.
>> Idea przeglądarki to w sumie "stary trop" bo kiedyś tylko to było pod
>> ręką i nie było apek, smartfonów, Linuxa, Chrome, Firefox...Dlatego
>> zaczęto od Internet Explorer który to umożliwiał. Linuxiarzom właśnie
>> najbardziej to przeszkadzało, bo pozbawieni IE nie mogli korzystać z
>> ActiveX i wylewali kubły pomyj na producentów kamer. Podobnie jest teraz
>> z apkami bo pod Linuxa nie są rozwijane, pomimo tego, że odeszło się już
>> od ActiveX bo IE umarł był :)
>>
> Muszę jednak dopisać, że w najnowszych wersjach oprogramowania, wraca
> się do przeglądarki ograniczając możliwość konfiguracji urządzeń z
> poziomu apki.
> Apka teraz służy do podłączeń np P2P i wyświetlania live, odtwarzania,
> zapisu na kompie ale nie do konfiguracji.
> Stało się to dlatego, że ktoś w końcu podjął decyzję i zmieniono
> oprogramowanie w urządzeniach, rezygnując z ActiveX...ale ciekawa
> sprawa, że od samego początku oprogramowanie kamer, rejestratorów jest
> na Linuksie ale do lepszej obsługi tego Linuksa wymagany był Windows z
> ActiveX.

kamery, rejestratory, vpn, serwery - widać łatwiej się je robi na
linuxie.

Ale klient chce obejrzeć na swoim Windows :-)

Dawniej nie było wyjscia - potrzebny był ActiveX do przeglądarki,
teraz przeglądarki mają "video" wbudowane, choć niekoniecznie takie,
jakie pasuje do kamer nadzoru.

A może MS zapanował w końcu nad kodekami ... albo telekonferencje
zrobiły się modne ...

> Tutaj masz to opisane:
> https://dahuawiki.com/SmartPSS

J.

do góry

On 6/25/25 01:12, ??x??(R)?? wrote:
> W dniu 25.06.2025 o 01:53, ??x??(R)?? pisze:
>
>>> Z przeglądarką tak nie pójdzie.
>>
>> Nie, nie pójdzie ale jeśli pomiędzy przeglądarką postawisz SERWER
>> (aplikacja), który zestawi to połączenie, to przeglądarka bez problemu
>> to obsłuży z adresu localhost :)...wystawionego na odpowiednim porcie
>> dla przeglądarki :) na danym kompie. Tak to działa. Wiem doskonale, że
>> tego nie robiłeś, to skąd masz mieć wiedzę?
>
> Masz prtscr :)
> https://imgur.com/GFxLWsX  Spójrz na adres w przeglądarce :)
>
>
>

No cudownie... postawiłeś sobie po środku SERWER, który jest de facto
VPNem i on to zestawił "p2p"

Hole punching jest mi doskonale znany ale to nie wystarcza. Po to
powstały też takie technologie jak ICE(+STUN) no i TURN bo nie zawsze
się da się przedostać przez fierewalle.
W przypadku symmetric NAT (czyli taki jak prawie każdy router SOHO robi)
szansa wytworzenia dziury w dwóch NATach jest mała (ale jest)
Dokładnie w tym temacie siedzę zawodowo od 25 lat wiec mi nie pierdol że
wynalazłeś jakiś chiński cudowny patent, który rozwiązuje wszystkie
problemy NATów.

c.

do góry

W dniu 25.06.2025 o 09:52, J.F pisze:

> Pewnie można zaryzykować. albo sprawdzic kilka kolejnych, na wypadek,
> gdyby ktos się wciął.
>
> Ale trafi na "dobry" router, co wylosuje, i d* :-)
>

No to się inicjuje więcej połączeń z jednej strony i wielokrotnie trafić
z drugiej strony. Na tej publikacji co podał kolega Cezar jest przykład:
256 zainicjowane połączenia i 1024 próby daje paradoksalnie 98% szans na
powodzenie.
Ciekawa sprawa jest z "simultaneous transmission trick" - nie wiem o co
chodzi, ale chyba nie o adresy multicastowe, bo to raczej też nie realne.
Teoretycznie gdyby wysłać pakiet do serwera uzgadniającego p2p i
następnie zmusić jakoś system, żeby użył tego samego socketu - czyli de
facto zmusić do przydzielenia takiego samego portu wyjściowego i
następnie wysłać do docelowego peera to bylibyśmy w domu.
Ale nie wiem czy tędy droga - może kolega Cezar nam wyjaśni skoro
twierdzi że w tym siedzi.

--
Mirek

do góry

W dniu 25.06.2025 o 17:55, cezar pisze:
> On 6/25/25 01:12, ??x??(R)?? wrote:
>> W dniu 25.06.2025 o 01:53, ??x??(R)?? pisze:


>> https://imgur.com/GFxLWsX  Spójrz na adres w przeglądarce :)
>>
>>
>>
>
> No cudownie... postawiłeś sobie po środku SERWER, który jest de facto
> VPNem i on to zestawił "p2p"
>

banał:
ssh -L 31761:<adres-kamery>:80 <user>@<adres-do-czego-mam-dostęp>

--
Mirek

do góry

W dniu 24.06.2025 o 15:57, ??x??(R)?? pisze:

> Kurwa. NIE. Milion klientów może być podłączonych do jednego serwera na
> jednym IP i mogą tworzyć milion VPN z tego serwera. Pojąłeś w końcu?

NIE. Milion jednocześnie nie może.

--
Mirek

do góry

On 6/25/25 21:31, Mirek wrote:
> W dniu 25.06.2025 o 09:52, J.F pisze:
>
>> Pewnie można zaryzykować. albo sprawdzic kilka kolejnych, na wypadek,
>> gdyby ktos się wciął.
>>
>> Ale trafi na "dobry" router, co wylosuje, i d* :-)
>>
>
> No to się inicjuje więcej połączeń z jednej strony i wielokrotnie trafić
> z drugiej strony. Na tej publikacji co podał kolega Cezar jest przykład:
> 256 zainicjowane połączenia i 1024 próby daje paradoksalnie 98% szans na
> powodzenie.
> Ciekawa sprawa jest z "simultaneous transmission trick" - nie wiem o co
> chodzi, ale chyba nie o adresy multicastowe, bo to raczej też nie realne.
> Teoretycznie gdyby wysłać pakiet do serwera uzgadniającego p2p i
> następnie zmusić jakoś system, żeby użył tego samego socketu - czyli de
> facto zmusić do przydzielenia takiego samego portu wyjściowego i
> następnie wysłać do docelowego peera to bylibyśmy w domu.
> Ale nie wiem czy tędy droga - może kolega Cezar nam wyjaśni skoro
> twierdzi że w tym siedzi.
>

to jest typowe "hole punching"

Peery wysyłają do siebie pakiety po UDP w tym samym czasie (a raczej w
małych odstępach czasowych), mając nadzieje że firewalle zakwalifikują
ję jako odpowiedzi na wysłane pakiety i otworzą kanał do transmisji po UDP.

Problem jest oczywiście z tym że nie wiadomo jaki src port da firewall
pakietowi wychodzącemu, dlatego zestawia się N połączeń żeby zwiększyć
szanse na trafienie.

Oczywiście do tego potrzebny jest jakiś koordynator - NP połączenie po
TCP do jakiegoś serwera, które wymienia informację pomiędzy peerami. To
połączenie nie jest używane później do przekazywania właściwych danych.



Tutaj na prędce napisałem klienta
https://smalldev.tools/share-bin/v1ZAJVmQ

i serwer do wymiany IP

https://smalldev.tools/share-bin/hTCznAFu


U mnie nawiązuje otwiera firewalle po kilku sekundach ale są raczej
głupawe, bo przydzielają porty źródłowe sekwencyjnie



c.

do góry

On Wed, 25 Jun 2025 23:08:47 +0200, Mirek wrote:
> W dniu 24.06.2025 o 15:57, ʅǝxᴉꓒ®🇵🇱 pisze:
>> Kurwa. NIE. Milion klientów może być podłączonych do jednego serwera na
>> jednym IP i mogą tworzyć milion VPN z tego serwera. Pojąłeś w końcu?
>
> NIE. Milion jednocześnie nie może.

Chyba moĹźe.


J.

do góry

On Wed, 25 Jun 2025 23:00:20 +0200, Mirek wrote:
> W dniu 25.06.2025 o 17:55, cezar pisze:
>> On 6/25/25 01:12, ʅǝxᴉꓒ®🇵🇱 wrote:
>>> W dniu 25.06.2025 o 01:53, ʅǝxᴉꓒ®🇵🇱 pisze:
>
>>> https://imgur.com/GFxLWsX  Spójrz na adres w przeglądarce :)
>>>
>> No cudownie... postawiłeś sobie po środku SERWER, który jest de facto
>> VPNem i on to zestawił "p2p"
>>
>
> banał:
> ssh -L 31761:<adres-kamery>:80 <user>@<adres-do-czego-mam-dostęp>

Moment moment ... gdzies tu musi być "publiczny" adres IP.


J.

do góry

On Wed, 25 Jun 2025 16:55:22 +0100, cezar wrote:
> On 6/25/25 01:12, ʅǝxᴉꓒ®🇵🇱 wrote:
>> W dniu 25.06.2025 o 01:53, ʅǝxᴉꓒ®🇵🇱 pisze:
>>
>>>> Z przeglądarką tak nie pójdzie.
>>>
>>> Nie, nie pójdzie ale jeśli pomiędzy przeglądarką postawisz SERWER
>>> (aplikacja), który zestawi to połączenie, to przeglądarka bez problemu
>>> to obsłuży z adresu localhost :)...wystawionego na odpowiednim porcie
>>> dla przeglądarki :) na danym kompie. Tak to działa. Wiem doskonale, że
>>> tego nie robiłeś, to skąd masz mieć wiedzę?
>>
>> Masz prtscr :)
>> https://imgur.com/GFxLWsX  Spójrz na adres w przeglądarce :)
>>
> No cudownie... postawiłeś sobie po środku SERWER, który jest de facto
> VPNem i on to zestawił "p2p"
>
> Hole punching jest mi doskonale znany ale to nie wystarcza. Po to
> powstały też takie technologie jak ICE(+STUN) no i TURN bo nie zawsze
> się da się przedostać przez fierewalle.
> W przypadku symmetric NAT (czyli taki jak prawie kaĹźdy router SOHO robi)
> szansa wytworzenia dziury w dwóch NATach jest mała (ale jest)
> Dokładnie w tym temacie siedzę zawodowo od 25 lat wiec mi nie pierdol że
> wynalazłeś jakiś chiński cudowny patent, który rozwiązuje wszystkie
> problemy NATĂłw.

Hi hi - chinski patent może świetnie działać z routerkami TP-Link i
innymi chinskimi :-)
A kto se kupił lepszy ... to niech teraz molestuje support, że mu
kamery nie działają.
Może się skończyć tak, że chinczycy sprzedadzą tym "lepszym" swój
patent :-)

J.

do góry