priv
Nieprawidłowy adres IP w aplikacji klienckiej
Widzimy się na Supla Offline Party Season 2
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).
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).
Widzimy się na Supla Offline Party Season 2
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
Dam znać jak sprawdzę to dokładniej.
https://github.com/SUPLA/supla-cloud/issues/349
Może to zależy od platformy, na której uruchomiony jest serwer? Może to wina środowiska raspbiana na RPi4B?
Widzimy się na Supla Offline Party Season 2
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
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
Widzimy się na Supla Offline Party Season 2
Pewnie wystarczy podmienić metody, które operują na int, na takie, które pracują na unsinged int.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
Widzimy się na Supla Offline Party vol. 2
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(......
[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(......
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
Jest też kilka śmiechowych rozwiązań rzutujących tą wartość do floata przed konwersją. Ogarniemy
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.Keeping it as a varchar is a bad idea. It should be determined why the GUI reads this int incorrectly.
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ę
Widzimy się na Supla Offline Party Season 2
W nagrodę Twój adres zostanie w źródłach Supli na zawsze