Nieprawidłowy adres IP w aplikacji klienckiej

Awatar użytkownika
Goral64
Posty: 294
Rejestracja: pt gru 27, 2019 6:22 pm

czw sty 23, 2020 7:50 am

fracz pisze:
czw sty 23, 2020 7:37 am
Coś więcej na ten temat?
priv
RPi4: Supla Cloud + Supla Scripts + Proxy + Let's Encrypt
1x MEW-01, 1x LIW-01, 2x SBW-02, 2x PNW-01, 1x ROW-01, 1x ROW-02, 1x ROW-04m,
1x Sonoff BRIDGE RF 433 (FW by Duch__)
This is only the beggining...
Awatar użytkownika
Goral64
Posty: 294
Rejestracja: pt gru 27, 2019 6:22 pm

czw sty 23, 2020 1:37 pm

Wygląda na to, że błąd nie wynika z ustawień sieci.
Adres do tabeli supla_client zapisuje się prawidłowo. Nie śledziłem dokładnie kodu źródłowego ale wychodzi na to, że coś nie tak jest z funkcją intToIp() która dla IP większego niż 127.255.255.255 zwraca zawsze 127.255.255.255

Wygląda na to, że skrypt pobraną wartość traktuje jako signed int zamiast unsigned int i obcina wszystko powyżej wartości 2147483647 (127.255.255.255).
RPi4: Supla Cloud + Supla Scripts + Proxy + Let's Encrypt
1x MEW-01, 1x LIW-01, 2x SBW-02, 2x PNW-01, 1x ROW-01, 1x ROW-02, 1x ROW-04m,
1x Sonoff BRIDGE RF 433 (FW by Duch__)
This is only the beggining...
Awatar użytkownika
fracz
Posty: 1832
Rejestracja: pt paź 28, 2016 10:56 pm
Lokalizacja: Rybna

czw sty 23, 2020 4:43 pm

Póki co nie wiem. Ja mam też "duże" adresy i tak jak Przemek pokazywał - wyświetlają się ok.

Dam znać jak sprawdzę to dokładniej.

https://github.com/SUPLA/supla-cloud/issues/349
Awatar użytkownika
Goral64
Posty: 294
Rejestracja: pt gru 27, 2019 6:22 pm

czw sty 23, 2020 5:04 pm

Może to zależy od platformy, na której uruchomiony jest serwer? Może to wina środowiska raspbiana na RPi4B?
RPi4: Supla Cloud + Supla Scripts + Proxy + Let's Encrypt
1x MEW-01, 1x LIW-01, 2x SBW-02, 2x PNW-01, 1x ROW-01, 1x ROW-02, 1x ROW-04m,
1x Sonoff BRIDGE RF 433 (FW by Duch__)
This is only the beggining...
Awatar użytkownika
Goral64
Posty: 294
Rejestracja: pt gru 27, 2019 6:22 pm

czw sty 23, 2020 11:15 pm

No cóż, odpowiem sam sobie. @fracz już nie musisz szukać. Przyczyna leży po stronie RPi4B, który u mnie ma na pokładzie procesor 32 bitowy arm7l.
Tak więc ten błąd mają wszyscy na 32 bitowych procesorach oraz na 64 bitowych z zainstalowanym 32 bitowym PHP (XAMPP 32 bit na Win 64bit). Czyli dla nas, 32 bitowców, pożądane by było, gdyby adres IP przechowywany był w kropkowej postaci ;)
RPi4: Supla Cloud + Supla Scripts + Proxy + Let's Encrypt
1x MEW-01, 1x LIW-01, 2x SBW-02, 2x PNW-01, 1x ROW-01, 1x ROW-02, 1x ROW-04m,
1x Sonoff BRIDGE RF 433 (FW by Duch__)
This is only the beggining...
Awatar użytkownika
klew
Posty: 854
Rejestracja: czw cze 27, 2019 12:16 pm

czw sty 23, 2020 11:45 pm

Goral64 pisze:
czw sty 23, 2020 11:15 pm
No cóż, odpowiem sam sobie. @fracz już nie musisz szukać. Przyczyna leży po stronie RPi4B, który u mnie ma na pokładzie procesor 32 bitowy arm7l.
Tak więc ten błąd mają wszyscy na 32 bitowych procesorach oraz na 64 bitowych z zainstalowanym 32 bitowym PHP (XAMPP 32 bit na Win 64bit). Czyli dla nas, 32 bitowców, pożądane by było, gdyby adres IP przechowywany był w kropkowej postaci ;)
Pewnie wystarczy podmienić metody, które operują na int, na takie, które pracują na unsinged int.
Awatar użytkownika
pzygmunt
Posty: 8449
Rejestracja: wt sty 19, 2016 9:26 am
Lokalizacja: Paczków
Kontaktowanie:

czw sty 23, 2020 11:54 pm

PHP jak i Java nie mają typu bez znaku. Dlatego php na 32-bitowej maszynie gubi się z tą wartością z uwagi na to, że PHP_INT_MAX jest równy 2147483647.

[EDIT]
https://www.php.net/manual/en/function.long2ip.php

Note:
On 32-bit architectures, casting integer representations of IP addresses from string to integer will not give correct results for numbers which exceed PHP_INT_MAX.

Można też bezpośrednio przeczytać z bazy w formie string-a za pomocą
SELECT INET_NTOA(......
Awatar użytkownika
fracz
Posty: 1832
Rejestracja: pt paź 28, 2016 10:56 pm
Lokalizacja: Rybna

pt sty 24, 2020 7:06 am

Czyli to problem po stronie clouda. Powinno się dać to naprawić zrzucając zadanie konwersji na bazę danych, tak jak sugeruje Przemek.

Jest też kilka śmiechowych rozwiązań rzutujących tą wartość do floata przed konwersją. Ogarniemy :)
Awatar użytkownika
Goral64
Posty: 294
Rejestracja: pt gru 27, 2019 6:22 pm

pt sty 24, 2020 7:09 am

Keeping it as a varchar is a bad idea. It should be determined why the GUI reads this int incorrectly.
Jak już wspomniałem wczoraj, poświęciłem trochę czasu i zainstalowałem sobie lokalnie wersję deweloperską supla-cloud i prześledziłem kod podczas wykonania. Frontend działa prawidłowo, ale dostaje od backendu maksymalną wartość 2147483647 jeśli system jest 32 bitowy. Ta wartość pojawia się przy normalizowaniu danych pobranych z bazy, gdzie string np. "2447123623" jest rzutowany do integer i na 64 bitach wynik jest 2447123623 czyli prawidłowo a na 32 bitach wynik jest 2147483647 czyli błędny.
Nie każdy ma dostęp do 64 bitowego systemu.
Wydaje się rozsądnym aby pójść na kompromis i w bazie nadal trzymać to pod postacią int(10) ale odczytywać to funkcją SQL INET_NTOA() ale wymaga to zmiany także we Frontendzie.
Tak wiec przyczyna rozpoznana, teraz trzeba poczekać na stosowną poprawkę, za którą z góry dziękuję :)
RPi4: Supla Cloud + Supla Scripts + Proxy + Let's Encrypt
1x MEW-01, 1x LIW-01, 2x SBW-02, 2x PNW-01, 1x ROW-01, 1x ROW-02, 1x ROW-04m,
1x Sonoff BRIDGE RF 433 (FW by Duch__)
This is only the beggining...
Awatar użytkownika
fracz
Posty: 1832
Rejestracja: pt paź 28, 2016 10:56 pm
Lokalizacja: Rybna

pt sty 24, 2020 10:03 am

W nagrodę Twój adres zostanie w źródłach Supli na zawsze :lol:
ODPOWIEDZ