Перейти к содержимому
Local
banderlog

sgauth на openwrt-роутере запустил, но...

Рекомендованные сообщения

Доброго времени суток!

 

Я подключен в Харькове к одной конторе-монополисту в монем районе проживания.

У меня есть роутер с wifi - TP-Link WR741ND, для которого никто не хочет ставить галочку 'always online', потому задача стояла запустить sgauth на нем.

 

Вкратце: я перепрошил роутер под openwrt, и с помощью тулчейна openwrt собрал под его архитектуру (atheros ar71xx или mips) sgauth.

После того как я залил на роутер sgauth, libstdc++.so.6, libpthread.so.0 (библиотеки взяты из тулчейна), я смог-таки запустить авторизатор.

 

Однако, авторизация не проходит и в top висит 'sgauth Offline'. Порты вроде как открыты.

 

root@OpenWrt:~# netstat -tulpn | grep sgaut
tcp		0	  0 127.0.0.1:5580		  0.0.0.0:*			   LISTEN	 14631/sgauth.10
netstat: /proc/net/tcp6: No such file or directory
udp		0	  0 0.0.0.0:5554			0.0.0.0:*						   14631/sgauth.10
udp		0	  0 0.0.0.0:5555			0.0.0.0:*						   14631/sgauth.10
netstat: /proc/net/udp6: No such file or directory

 

ACCEPT	 udp  --  192.168.59.3		 192.168.66.96	   udp spts:5554:5556 dpts:5554:5556
ACCEPT	 udp  --  192.168.66.96		192.168.59.3		udp spts:5554:5556 dpts:5554:5556

 

192.168.59.3 - сервак sg; 192.168.66.96 - мой ip

 

Версия sgauth - 2.12.6

 

Что бы это могло быть и как с этим бороться?

 

PS: есть ли способ заставить его давать выхлоп о текущей ситуации, типа verbose или debug mode?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

2.12.6 это такая древность, он вполне может и не работать с современными версиями Stargazer. Попробуйте собрать ту которая идет в комплекте со Stargazer.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

я конечно попробую, но этот же самый sgauth собранный под arch_i686 прекрасно авторизируется с сервером и все работает

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Я собрал под openwrt две версии sgauth - 2.12.6 и та что идет в составе stargazer последней версии. Они обе запускаются на роуте но инета нет.

 

Собранные на ноутбуке обе дают инет. Проверил, подключив ноутбук в wan роутера, wireshark и sniffit грят что пакеты с роутера уходят, с правильного 5554 порта. Когда sgauth запущен, то 5554 порт открыт - проверял nmap. Wireshark утверждает что пакеты уходят c 5554 порта на 192.168.59.3:5555 - сервак, а приходят с 192.168.66.1:5554 (gw) на 5555 порт. При этом у gw и сервака одинаковый mac.

При этом, sniffit видит такую картину на любой версии sgauth, а wireshark не видит приходящие пакеты, если запущена старая версия.

 

Привязки по маку нет, но я на всякий случай копировал свой. Пробовал даже hostname своеже передирать. В iptables открыто все что можно: http://pastebin.com/SnY9rLyL

 

Как проверить, находясь за роутером, приходят ли ему пакеты на 5554 порт от сервака я не знаю.

 

ЧЯДН? Идеи, мысли, соображения?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Сделал flush всем таблицам в iptable, поставил tcpdump, листинги всех 4х бинарников:

 

1. Новый на буке:

sudo tcpdump -i eth0 udp port 5555
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
21:51:29.702272 IP 192.168.66.96.5554 > 192.168.59.3.5555: UDP, length 96
21:51:44.691084 IP 192.168.66.1.5555 > 192.168.66.96.5554: UDP, length 200
21:51:44.709485 IP 192.168.66.96.5554 > 192.168.59.3.5555: UDP, length 64
21:51:59.712488 IP 192.168.66.1.5555 > 192.168.66.96.5554: UDP, length 384
21:51:59.731777 IP 192.168.66.96.5554 > 192.168.59.3.5555: UDP, length 64
21:51:29.687486 IP 192.168.66.1.5555 > 192.168.66.96.5554: UDP, length 384
...

 

2.Старый на буке:

sudo tcpdump -i eth0 udp port 5555 -n
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes
21:52:54.544171 IP 192.168.66.96.5554 > 192.168.59.3.5555: UDP, length 64
21:52:54.549032 IP 192.168.66.1.5555 > 192.168.66.96.5555: UDP, length 192
21:52:54.566144 IP 192.168.66.96.5554 > 192.168.59.3.5555: UDP, length 64
21:52:54.570003 IP 192.168.66.1.5555 > 192.168.66.96.5555: UDP, length 368
21:52:54.588008 IP 192.168.66.96.5554 > 192.168.59.3.5555: UDP, length 64
21:53:09.576636 IP 192.168.66.1.5555 > 192.168.66.96.5555: UDP, length 368
21:53:09.596958 IP 192.168.66.96.5554 > 192.168.59.3.5555: UDP, length 64
....

 

3.Новый на роутере:

tcpdump: listening on eth1, link-type EN10MB (Ethernet), capture size 65535 bytes
19:38:04.306452 IP 192.168.66.96.5554 > 192.168.59.3.5555: UDP, length 96
19:38:04.309377 IP 192.168.66.1.5555 > 192.168.66.96.5554: UDP, length 264

 

4.Старый на роутере

19:41:59.259789 IP 192.168.66.96.5554 > 192.168.59.3.5555: UDP, length 64
19:41:59.265685 IP 192.168.66.1.5555 > 192.168.66.96.5554: UDP, length 256

 

бинари с роутера получают только 1 пакет с сервера и на этом прекращают свою деятельность.

причем этот пакет имеет не такаю длину, как первый ответный пакет на буке

 

ЗЫ: данные авторизации проверял\перепроверял\копировал файлы напрямую

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

думаю что UDP, length 256 это пакет с ошибкой о которой сообщает сервер нет варианта подцепить терминал и посмотреть оутпут пклиента на роутере ?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Похоже на ошибку авторизации. Что в этот момент пишется в лог сервера?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

нет варианта подцепить терминал и посмотреть оутпут пклиента на роутере ?

терминал на роутере есть, а sgauth никакого выхлопа не дает, кроме настроек с которыми он запущен

я ненашел никаких verbose или debug mode

 

Похоже на ошибку авторизации. Что в этот момент пишется в лог сервера?

 

хотелось бы знать. сервак-то у провайдера стоит. я конечо у них логи попрошу, но скорее всего меня пошлют.

 

UPD: послали

Проц на роутере Atheros AR7240 rev2 гугол грит что это таки big endian

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Еще можно зайти на веб-интерфейс авторизатора и посмотреть что он там пишет

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

А лог сборки нового sgauth можно увидеть?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

banderlog ~/TEMP/stg-2.408-rc2/projects/sgauth $ make
make -C /home/banderlog/TEMP/stg-2.408-rc2/projects/sgauth/../../stglibs
make[1]: Вход в каталог `/home/banderlog/TEMP/stg-2.408-rc2/stglibs'
make[1]: Цель `all' не требует выполнения команд.
make[1]: Выход из каталога `/home/banderlog/TEMP/stg-2.408-rc2/stglibs'
for file in ./main.cpp ./settings_impl.cpp ./web.cpp; do
 echo "`/home/banderlog/TEMP/tp_link/staging_dir/toolchain-mips_r2_gcc-4.3.3+cs_uClibc-0.9.30.1/usr/bin/mips-openwrt-linux-uclibc-g++ -I/home/banderlog/TEMP/tp_link/build_dir/toolchain-mips_r2_gcc-4.3.3+cs_uClibc-0.9.30.1/uClibc-0.9.30.1/include/ -DARCH_BE -DLINUX -I ../../stglibs/conffiles.lib/include -I ../../stglibs/ia.lib/include -I ../../stglibs/crypto.lib/include -I ../../stglibs/common.lib/include -I ../../include -MM $file` Makefile" >> deps ;
 echo -e 't$(CXX) -c $< -I/home/banderlog/TEMP/tp_link/build_dir/toolchain-mips_r2_gcc-4.3.3+cs_uClibc-0.9.30.1/uClibc-0.9.30.1/include/ -DARCH_BE -DLINUX -I ../../stglibs/conffiles.lib/include -I ../../stglibs/ia.lib/include -I ../../stglibs/crypto.lib/include -I ../../stglibs/common.lib/include -I ../../include' >> deps ;
done
make -C /home/banderlog/TEMP/stg-2.408-rc2/projects/sgauth/../../stglibs
make[1]: Вход в каталог `/home/banderlog/TEMP/stg-2.408-rc2/stglibs'
make[1]: Цель `all' не требует выполнения команд.
make[1]: Выход из каталога `/home/banderlog/TEMP/stg-2.408-rc2/stglibs'
/home/banderlog/TEMP/tp_link/staging_dir/toolchain-mips_r2_gcc-4.3.3+cs_uClibc-0.9.30.1/usr/bin/mips-openwrt-linux-uclibc-g++ -c main.cpp -I/home/banderlog/TEMP/tp_link/build_dir/toolchain-mips_r2_gcc-4.3.3+cs_uClibc-0.9.30.1/uClibc-0.9.30.1/include/ -DARCH_BE -DLINUX -I ../../stglibs/conffiles.lib/include -I ../../stglibs/ia.lib/include -I ../../stglibs/crypto.lib/include -I ../../stglibs/common.lib/include -I ../../include
/home/banderlog/TEMP/tp_link/staging_dir/toolchain-mips_r2_gcc-4.3.3+cs_uClibc-0.9.30.1/usr/bin/mips-openwrt-linux-uclibc-g++ -c settings_impl.cpp -I/home/banderlog/TEMP/tp_link/build_dir/toolchain-mips_r2_gcc-4.3.3+cs_uClibc-0.9.30.1/uClibc-0.9.30.1/include/ -DARCH_BE -DLINUX -I ../../stglibs/conffiles.lib/include -I ../../stglibs/ia.lib/include -I ../../stglibs/crypto.lib/include -I ../../stglibs/common.lib/include -I ../../include
/home/banderlog/TEMP/tp_link/staging_dir/toolchain-mips_r2_gcc-4.3.3+cs_uClibc-0.9.30.1/usr/bin/mips-openwrt-linux-uclibc-g++ -c web.cpp -I/home/banderlog/TEMP/tp_link/build_dir/toolchain-mips_r2_gcc-4.3.3+cs_uClibc-0.9.30.1/uClibc-0.9.30.1/include/ -DARCH_BE -DLINUX -I ../../stglibs/conffiles.lib/include -I ../../stglibs/ia.lib/include -I ../../stglibs/crypto.lib/include -I ../../stglibs/common.lib/include -I ../../include
/home/banderlog/TEMP/tp_link/staging_dir/toolchain-mips_r2_gcc-4.3.3+cs_uClibc-0.9.30.1/usr/bin/mips-openwrt-linux-uclibc-g++ main.o settings_impl.o web.o -I/home/banderlog/TEMP/tp_link/build_dir/toolchain-mips_r2_gcc-4.3.3+cs_uClibc-0.9.30.1/uClibc-0.9.30.1/include/ -L/home/banderlog/TEMP/tp_link/build_dir/toolchain-mips_r2_gcc-4.3.3+cs_uClibc-0.9.30.1/uClibc-0.9.30.1/lib/ -Wl,-E -L ../../stglibs/conffiles.lib -L ../../stglibs/ia.lib -L ../../stglibs/crypto.lib -L ../../stglibs/common.lib -o sgauth -lstgconffiles -lstgia -lstgcrypto -lstgcommon -lpthread -static

 

библиотеки чего то не хотят собираться вместе с sgauth и я их собираю отдельно, например:

banderlog ~/TEMP/stg-2.408-rc2/stglibs/ia.lib $ make
/home/banderlog/TEMP/tp_link/staging_dir/toolchain-mips_r2_gcc-4.3.3+cs_uClibc-0.9.30.1/usr/bin/mips-openwrt-linux-uclibc-g++ -I/home/banderlog/TEMP/tp_link/build_dir/toolchain-mips_r2_gcc-4.3.3+cs_uClibc-0.9.30.1/uClibc-0.9.30.1/include/ -DARCH_BE -fPIC -I ../../include -I . -I ./include -I ../crypto.lib/include -I ../common.lib/include -DLINUX -DSTG_TIME -c ia.cpp
ar rc libstgia.a ia.o
ranlib libstgia.a

 

Еще можно зайти на веб-интерфейс авторизатора и посмотреть что он там пишет

 

нельзя, мне пришлось закомментить int WEB::SendReply() компилятору не нравилось gettext

web.o: In function `WEB::SendReply()':
web.cpp:(.text+0x508): undefined reference to `gettext'
web.cpp:(.text+0x584): undefined reference to `gettext'
web.cpp:(.text+0x600): undefined reference to `gettext'
web.cpp:(.text+0x67c): undefined reference to `gettext'
web.cpp:(.text+0x7c4): undefined reference to `gettext'
web.o:web.cpp:(.text+0x888): more undefined references to `gettext' follow

в common.cpp закоментено iconv.h и несколько строк с ним связанных, они все равно шли после #if defined(FREE_BSD) || defined(FREE_BSD5) || defined(WIN32)

с ним такая фигня:

banderlog ~/TEMP/stg-2.408-rc2/stglibs/common.lib $ make
In file included from common.cpp:48:
/home/banderlog/TEMP/tp_link/build_dir/toolchain-mips_r2_gcc-4.3.3+cs_uClibc-0.9.30.1/uClibc-0.9.30.1/include/iconv.h:27:2: error: #error Attempted to include iconv.h when uClibc was built without locale support.
deps:1: *** пропущен разделитель.  Останов.

Изменено пользователем banderlog

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Что там big endian - я уже понял. А почему при сборке не выполнен build?

И еще, хочется увидеть Makefile.conf после build. Он лежит в ../.. относительно каталога проекта.

 

И еще, зачем закомменчены строки которые следуют после #if defined(FREE_BSD) ? Они все равно не будут участвовать в процессе компиляции.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

А почему при сборке не выполнен build?

И еще, хочется увидеть Makefile.conf после build. Он лежит в ../.. относительно каталога проекта.

 

build был выполнен, но он же bash скрипт о собирает данные о моей домашней системе на ноутбуке.

а я компилю тулчейном для роутера MIPS

 

я подредактировал Makefile.conf под роутер

 

OS=linux
STG_TIME=yes
DIR_BUILD=/home/banderlog/TEMP/stg-2.408-rc2/projects/sgauth
DIR_LIB=$(DIR_BUILD)/../../lib
DIR_LIBSRC=$(DIR_BUILD)/../../stglibs
DIR_INCLUDE=$(DIR_BUILD)/../../include
ARCH=be
DEFS= -DLINUX
STG_LIBS=crypto.lib common.lib conffiles.lib ia.lib
LIB_THREAD=-lpthread
SHELL=/bin/bash
CXX=/home/banderlog/TEMP/tp_link/staging_dir/toolchain-mips_r2_gcc-4.3.3+cs_uClibc-0.9.30.1/usr/bin/mips-openwrt-linux-uclibc-g++
CXXFLAGS= -I/home/banderlog/TEMP/tp_link/build_dir/toolchain-mips_r2_gcc-4.3.3+cs_uClibc-0.9.30.1/uClibc-0.9.30.1/include/ -DARCH_BE
CFLAGS= -DARCH_BE
LDFLAGS= -I/home/banderlog/TEMP/tp_link/build_dir/toolchain-mips_r2_gcc-4.3.3+cs_uClibc-0.9.30.1/uClibc-0.9.30.1/include/ -L/home/banderlog/TEMP/tp_link/build_dir/toolchain-mips_r2_gcc-4.3.3+cs_uClibc-0.9.30.1/uClibc-0.9.30.1/lib/
PREFIX=/
BIN_MODE=0755
DATA_MODE=0644
DIR_MODE=0755
OWNER=root
#commonlib - error Attempted to include iconv.h when uClibc was built without locale support.

 

библиотеки собираются теперь нормально:

banderlog ~/TEMP/stg-2.408-rc2/projects/sgauth $ make clean
rm -f deps sgauth *.o tags *.*~ .OS
rm -f .OS
rm -f .store
rm -f .db.sql
rm -f core*
rm -f css.h
make -C /home/banderlog/TEMP/stg-2.408-rc2/projects/sgauth/../../stglibs clean
make[1]: Вход в каталог `/home/banderlog/TEMP/stg-2.408-rc2/stglibs'
make clean -C crypto.lib
make[2]: Вход в каталог `/home/banderlog/TEMP/stg-2.408-rc2/stglibs/crypto.lib'
rm -f deps libstgcrypto.a *.o *.a *.so tags *.*~
make[2]: Выход из каталога `/home/banderlog/TEMP/stg-2.408-rc2/stglibs/crypto.lib'
make clean -C common.lib
make[2]: Вход в каталог `/home/banderlog/TEMP/stg-2.408-rc2/stglibs/common.lib'
rm -f deps libstgcommon.a *.o *.a *.so tags *.*~
make[2]: Выход из каталога `/home/banderlog/TEMP/stg-2.408-rc2/stglibs/common.lib'
make clean -C conffiles.lib
make[2]: Вход в каталог `/home/banderlog/TEMP/stg-2.408-rc2/stglibs/conffiles.lib'
rm -f deps libstgconffiles.a *.o *.a *.so tags *.*~
make[2]: Выход из каталога `/home/banderlog/TEMP/stg-2.408-rc2/stglibs/conffiles.lib'
make clean -C ia.lib
make[2]: Вход в каталог `/home/banderlog/TEMP/stg-2.408-rc2/stglibs/ia.lib'
rm -f deps libstgia.a *.o *.a *.so tags *.*~
make[2]: Выход из каталога `/home/banderlog/TEMP/stg-2.408-rc2/stglibs/ia.lib'
make[1]: Выход из каталога `/home/banderlog/TEMP/stg-2.408-rc2/stglibs'
banderlog ~/TEMP/stg-2.408-rc2/projects/sgauth $ make
make -C /home/banderlog/TEMP/stg-2.408-rc2/projects/sgauth/../../stglibs
make[1]: Вход в каталог `/home/banderlog/TEMP/stg-2.408-rc2/stglibs'
make  -C crypto.lib
make[2]: Вход в каталог `/home/banderlog/TEMP/stg-2.408-rc2/stglibs/crypto.lib'
make[2]: Выход из каталога `/home/banderlog/TEMP/stg-2.408-rc2/stglibs/crypto.lib'
make[2]: Вход в каталог `/home/banderlog/TEMP/stg-2.408-rc2/stglibs/crypto.lib'
/home/banderlog/TEMP/tp_link/staging_dir/toolchain-mips_r2_gcc-4.3.3+cs_uClibc-0.9.30.1/usr/bin/mips-openwrt-linux-uclibc-g++ -DARCH_BE -fPIC -I ../../include -I . -I ./include -DLINUX -DSTG_TIME -c ag_md5.c
/home/banderlog/TEMP/tp_link/staging_dir/toolchain-mips_r2_gcc-4.3.3+cs_uClibc-0.9.30.1/usr/bin/mips-openwrt-linux-uclibc-g++ -DARCH_BE -fPIC -I ../../include -I . -I ./include -DLINUX -DSTG_TIME -c blowfish.c
ar rc libstgcrypto.a ag_md5.o blowfish.o
ranlib libstgcrypto.a
make[2]: Выход из каталога `/home/banderlog/TEMP/stg-2.408-rc2/stglibs/crypto.lib'
make  -C common.lib
make[2]: Вход в каталог `/home/banderlog/TEMP/stg-2.408-rc2/stglibs/common.lib'
make[2]: Выход из каталога `/home/banderlog/TEMP/stg-2.408-rc2/stglibs/common.lib'
make[2]: Вход в каталог `/home/banderlog/TEMP/stg-2.408-rc2/stglibs/common.lib'
/home/banderlog/TEMP/tp_link/staging_dir/toolchain-mips_r2_gcc-4.3.3+cs_uClibc-0.9.30.1/usr/bin/mips-openwrt-linux-uclibc-g++ -I/home/banderlog/TEMP/tp_link/build_dir/toolchain-mips_r2_gcc-4.3.3+cs_uClibc-0.9.30.1/uClibc-0.9.30.1/include/ -DARCH_BE -fPIC -I ../../include -I . -I ./include -DLINUX -DSTG_TIME -c common.cpp
/home/banderlog/TEMP/tp_link/staging_dir/toolchain-mips_r2_gcc-4.3.3+cs_uClibc-0.9.30.1/usr/bin/mips-openwrt-linux-uclibc-g++ -I/home/banderlog/TEMP/tp_link/build_dir/toolchain-mips_r2_gcc-4.3.3+cs_uClibc-0.9.30.1/uClibc-0.9.30.1/include/ -DARCH_BE -fPIC -I ../../include -I . -I ./include -DLINUX -DSTG_TIME -c strptime.cpp
ar rc libstgcommon.a common.o strptime.o
ranlib libstgcommon.a
make[2]: Выход из каталога `/home/banderlog/TEMP/stg-2.408-rc2/stglibs/common.lib'
make  -C conffiles.lib
make[2]: Вход в каталог `/home/banderlog/TEMP/stg-2.408-rc2/stglibs/conffiles.lib'
make[2]: Выход из каталога `/home/banderlog/TEMP/stg-2.408-rc2/stglibs/conffiles.lib'
make[2]: Вход в каталог `/home/banderlog/TEMP/stg-2.408-rc2/stglibs/conffiles.lib'
/home/banderlog/TEMP/tp_link/staging_dir/toolchain-mips_r2_gcc-4.3.3+cs_uClibc-0.9.30.1/usr/bin/mips-openwrt-linux-uclibc-g++ -I/home/banderlog/TEMP/tp_link/build_dir/toolchain-mips_r2_gcc-4.3.3+cs_uClibc-0.9.30.1/uClibc-0.9.30.1/include/ -DARCH_BE -fPIC -I ../../include -I . -I ./include -DLINUX -DSTG_TIME -c conffiles.cpp
ar rc libstgconffiles.a conffiles.o
ranlib libstgconffiles.a
make[2]: Выход из каталога `/home/banderlog/TEMP/stg-2.408-rc2/stglibs/conffiles.lib'
make  -C ia.lib
make[2]: Вход в каталог `/home/banderlog/TEMP/stg-2.408-rc2/stglibs/ia.lib'
make[2]: Выход из каталога `/home/banderlog/TEMP/stg-2.408-rc2/stglibs/ia.lib'
make[2]: Вход в каталог `/home/banderlog/TEMP/stg-2.408-rc2/stglibs/ia.lib'
/home/banderlog/TEMP/tp_link/staging_dir/toolchain-mips_r2_gcc-4.3.3+cs_uClibc-0.9.30.1/usr/bin/mips-openwrt-linux-uclibc-g++ -I/home/banderlog/TEMP/tp_link/build_dir/toolchain-mips_r2_gcc-4.3.3+cs_uClibc-0.9.30.1/uClibc-0.9.30.1/include/ -DARCH_BE -fPIC -I ../../include -I . -I ./include -I ../crypto.lib/include -I ../common.lib/include -DLINUX -DSTG_TIME -c ia.cpp
ar rc libstgia.a ia.o
ranlib libstgia.a
make[2]: Выход из каталога `/home/banderlog/TEMP/stg-2.408-rc2/stglibs/ia.lib'
make[1]: Выход из каталога `/home/banderlog/TEMP/stg-2.408-rc2/stglibs'
for file in ./main.cpp ./settings_impl.cpp ./web.cpp; do
 echo "`/home/banderlog/TEMP/tp_link/staging_dir/toolchain-mips_r2_gcc-4.3.3+cs_uClibc-0.9.30.1/usr/bin/mips-openwrt-linux-uclibc-g++ -I/home/banderlog/TEMP/tp_link/build_dir/toolchain-mips_r2_gcc-4.3.3+cs_uClibc-0.9.30.1/uClibc-0.9.30.1/include/ -DARCH_BE -DLINUX -I ../../stglibs/conffiles.lib/include -I ../../stglibs/ia.lib/include -I ../../stglibs/crypto.lib/include -I ../../stglibs/common.lib/include -I ../../include -MM $file` Makefile" >> deps ;
 echo -e 't$(CXX) -c $< -I/home/banderlog/TEMP/tp_link/build_dir/toolchain-mips_r2_gcc-4.3.3+cs_uClibc-0.9.30.1/uClibc-0.9.30.1/include/ -DARCH_BE -DLINUX -I ../../stglibs/conffiles.lib/include -I ../../stglibs/ia.lib/include -I ../../stglibs/crypto.lib/include -I ../../stglibs/common.lib/include -I ../../include' >> deps ;
done
make -C /home/banderlog/TEMP/stg-2.408-rc2/projects/sgauth/../../stglibs
make[1]: Вход в каталог `/home/banderlog/TEMP/stg-2.408-rc2/stglibs'
make  -C crypto.lib
make[2]: Вход в каталог `/home/banderlog/TEMP/stg-2.408-rc2/stglibs/crypto.lib'
make[2]: Цель `all' не требует выполнения команд.
make[2]: Выход из каталога `/home/banderlog/TEMP/stg-2.408-rc2/stglibs/crypto.lib'
make  -C common.lib
make[2]: Вход в каталог `/home/banderlog/TEMP/stg-2.408-rc2/stglibs/common.lib'
make[2]: Цель `all' не требует выполнения команд.
make[2]: Выход из каталога `/home/banderlog/TEMP/stg-2.408-rc2/stglibs/common.lib'
make  -C conffiles.lib
make[2]: Вход в каталог `/home/banderlog/TEMP/stg-2.408-rc2/stglibs/conffiles.lib'
make[2]: Цель `all' не требует выполнения команд.
make[2]: Выход из каталога `/home/banderlog/TEMP/stg-2.408-rc2/stglibs/conffiles.lib'
make  -C ia.lib
make[2]: Вход в каталог `/home/banderlog/TEMP/stg-2.408-rc2/stglibs/ia.lib'
make[2]: Цель `all' не требует выполнения команд.
make[2]: Выход из каталога `/home/banderlog/TEMP/stg-2.408-rc2/stglibs/ia.lib'
make[1]: Выход из каталога `/home/banderlog/TEMP/stg-2.408-rc2/stglibs'
/home/banderlog/TEMP/tp_link/staging_dir/toolchain-mips_r2_gcc-4.3.3+cs_uClibc-0.9.30.1/usr/bin/mips-openwrt-linux-uclibc-g++ -c main.cpp -I/home/banderlog/TEMP/tp_link/build_dir/toolchain-mips_r2_gcc-4.3.3+cs_uClibc-0.9.30.1/uClibc-0.9.30.1/include/ -DARCH_BE -DLINUX -I ../../stglibs/conffiles.lib/include -I ../../stglibs/ia.lib/include -I ../../stglibs/crypto.lib/include -I ../../stglibs/common.lib/include -I ../../include
/home/banderlog/TEMP/tp_link/staging_dir/toolchain-mips_r2_gcc-4.3.3+cs_uClibc-0.9.30.1/usr/bin/mips-openwrt-linux-uclibc-g++ -c settings_impl.cpp -I/home/banderlog/TEMP/tp_link/build_dir/toolchain-mips_r2_gcc-4.3.3+cs_uClibc-0.9.30.1/uClibc-0.9.30.1/include/ -DARCH_BE -DLINUX -I ../../stglibs/conffiles.lib/include -I ../../stglibs/ia.lib/include -I ../../stglibs/crypto.lib/include -I ../../stglibs/common.lib/include -I ../../include
/home/banderlog/TEMP/tp_link/staging_dir/toolchain-mips_r2_gcc-4.3.3+cs_uClibc-0.9.30.1/usr/bin/mips-openwrt-linux-uclibc-g++ -c web.cpp -I/home/banderlog/TEMP/tp_link/build_dir/toolchain-mips_r2_gcc-4.3.3+cs_uClibc-0.9.30.1/uClibc-0.9.30.1/include/ -DARCH_BE -DLINUX -I ../../stglibs/conffiles.lib/include -I ../../stglibs/ia.lib/include -I ../../stglibs/crypto.lib/include -I ../../stglibs/common.lib/include -I ../../include
/home/banderlog/TEMP/tp_link/staging_dir/toolchain-mips_r2_gcc-4.3.3+cs_uClibc-0.9.30.1/usr/bin/mips-openwrt-linux-uclibc-g++ main.o settings_impl.o web.o -I/home/banderlog/TEMP/tp_link/build_dir/toolchain-mips_r2_gcc-4.3.3+cs_uClibc-0.9.30.1/uClibc-0.9.30.1/include/ -L/home/banderlog/TEMP/tp_link/build_dir/toolchain-mips_r2_gcc-4.3.3+cs_uClibc-0.9.30.1/uClibc-0.9.30.1/lib/ -Wl,-E -L ../../stglibs/conffiles.lib -L ../../stglibs/ia.lib -L ../../stglibs/crypto.lib -L ../../stglibs/common.lib -o sgauth -lstgconffiles -lstgia -lstgcrypto -lstgcommon -lpthread -static

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

зачем закомменчены строки которые следуют после #if defined(FREE_BSD) ? Они все равно не будут участвовать в процессе компиляции.

 

пардон, закоменчены все строки, юзающие iconv

 

#include <iconv.h>

и строки 915-947

iconv_t handle = iconv_open(to.c_str(),
					    from.c_str());

if (handle == iconv_t(-1))
   {
   if (errno == EINVAL)
    {
    printfd(__FILE__, "IconvString(): iconv from %s to %s failedn", from.c_str(), to.c_str());
    delete[] outBuf;
    delete[] inBuf;
    return source;
    }
   else
    printfd(__FILE__, "IconvString(): iconv_open errorn");

   delete[] outBuf;
   delete[] inBuf;
   return source;
   }

size_t res = iconv(handle,
			   &srcPos, &inBytesLeft,
			   &dstPos, &outBytesLeft);

if (res == size_t(-1))
   {
   printfd(__FILE__, "IconvString(): '%s'n", strerror(errno));

   iconv_close(handle);
   delete[] outBuf;
   delete[] inBuf;
   return source;
   }

и 953

iconv_close(handle);

 

если закоментить инклуд iconv без них то:

 

banderlog ~/TEMP/stg-2.408-rc2/stglibs/common.lib $ make
/home/banderlog/TEMP/tp_link/staging_dir/toolchain-mips_r2_gcc-4.3.3+cs_uClibc-0.9.30.1/usr/bin/mips-openwrt-linux-uclibc-g++ -I/home/banderlog/TEMP/tp_link/build_dir/toolchain-mips_r2_gcc-4.3.3+cs_uClibc-0.9.30.1/uClibc-0.9.30.1/include/ -DARCH_BE -fPIC -I ../../include -I . -I ./include -DLINUX -DSTG_TIME -c common.cpp
common.cpp: In function 'std::string IconvString(const std::string&, const std::string&, const std::string&)':
common.cpp:915: error: 'iconv_t' was not declared in this scope
common.cpp:915: error: expected `;' before 'handle'
common.cpp:918: error: 'handle' was not declared in this scope
common.cpp:935: error: 'handle' was not declared in this scope
common.cpp:937: error: 'iconv' was not declared in this scope
common.cpp:943: error: 'iconv_close' was not declared in this scope
common.cpp:953: error: 'iconv_close' was not declared in this scope
make: *** [common.o] Ошибка 1

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

А можно увидеть выхлоп tcpdump с ключами -s0 -X для обоих случаев работы нового авторизатора (запуск с роутера, запуск с ноутбука)?

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

sgauth из 2.408-rc2 собранный без -static с Makefile

  1 OS=linux
  2 STG_TIME=yes
  3 DIR_BUILD=/home/banderlog/TEMP/stg-2.408-rc2[bOOK]/projects/sgauth
  4 DIR_LIB=$(DIR_BUILD)/../../lib
  5 DIR_LIBSRC=$(DIR_BUILD)/../../stglibs
  6 DIR_INCLUDE=$(DIR_BUILD)/../../include
  7 ARCH=le
  8 DEFS= -DLINUX
  9 STG_LIBS=crypto.lib common.lib conffiles.lib ia.lib 
10 LIB_THREAD=-lpthread
11 SHELL=/bin/bash
12 CXXFLAGS= -I/usr/local/include -DARCH_LE
13 CFLAGS= -DARCH_LE
14 LDFLAGS= -I/usr/local/include -L/usr/local/lib
15 PREFIX=/
16 BIN_MODE=0755
17 DATA_MODE=0644
18 DIR_MODE=0755
19 OWNER=root

 

выхлоп с ноутбука: http://pastebin.com/5M0VXNmW

Для роутера собран с Makefile что я показывал и с ключом -static, прописанным в Makefile что в projects/sgauth/

$(CXX) $^ $(LDFLAGS) -o $(PROG) $(LIBS) -static

выхлоп с роутера: http://pastebin.com/eJcaVNSj

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

100% из за разницы в edian отсылается иначе зашифрованный пакет соединения , после расшифровки сервер не получает правильной инфы о заголовке и у нехо выходит не та версия протокола или вообще неизвестный протокол

 

там при инициализации матрицы шифрования это играет большую роль

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

100% из за разницы в edian отсылается иначе зашифрованный пакет соединения , после расшифровки сервер не получает правильной инфы о заголовке и у нехо выходит не та версия протокола или вообще неизвестный протокол

 

там при инициализации матрицы шифрования это играет большую роль

 

я вижу, да :ph34r: пакеты от сервера одинаковы, от буки и роутера нет.

 

мне бы патчик T_T

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Вот я выхлопы покурю и будет патчик.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

в патчах не мастак .. но если мне не изменяет память .. тебе копать надо в blowfish.cpp там endian воздействует на блоки кодирования в функциях block2bytes и byte2block там их тупо можно перевернуть.. думаю поможет

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Нет, копать надо в другую сторону. blowfish уже перекопан, когда я добивался авторизации с обычных компов на BE-сервере. Думал что тогда все перекопал, а оказывается не все...

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

К стати, block2byte там появились как раз в результате перекапывания. Если посмотреть на их код то можно заметить что он как раз зависит от endianess.

Поделиться сообщением


Ссылка на сообщение
Поделиться на других сайтах

Создайте аккаунт или войдите в него для комментирования

Вы должны быть пользователем, чтобы оставить комментарий

Создать аккаунт

Зарегистрируйтесь для получения аккаунта. Это просто!

Зарегистрировать аккаунт

Войти

Уже зарегистрированы? Войдите здесь.

Войти сейчас

  • Сейчас на странице   0 пользователей

    Нет пользователей, просматривающих эту страницу.

  • Похожие публикации

    • Автор: bot
      Тестирование Linux на DROP сетевых пакетов. Разные методы и их эффективность. Тесты синтетические, но от этого не становятся менее интересными. Пример от Cloudflare.
       
      Для иллюстрации производительности методов будут продемонстрированы некоторые цифры. Тесты синтетические, т.е. не на реальной сети с реальными пользователями и трафиком, так что не воспринимайте цифры слишком серьезно. Будет использоваться один из Intel серверов c 10Gbps сетевым интерфейсом. Детали железа не особо важны, т.к. тесты будут показывать вопросы, связанные с операционкой, а не с ограничениями по железу.
       
      Что происходит при тестировании:
      передача большого количества мелких UDP пакетов, достигая уровня в 14Mpps этот трафик направляется на единственный CPU на сервере измеряется количество пакетов, обработанных ядром на этом CPU  
      Мы не пытаемся максимизировать ни скорость приложения в юзерспейсе (userspace), ни количество пакетов. Вместо этого мы пытаемся показать узкие места самого ядра.
       
      Синтетический трафик пытается максимально нагрузить conntrack - используется рандомный IP адрес источника и порт. Tcpducmp будет выглядеть примерно следующим образом:
      $ tcpdump -ni vlan100 -c 10 -t udp and dst port 1234 IP 198.18.40.55.32059 > 198.18.0.12.1234: UDP, length 16 IP 198.18.51.16.30852 > 198.18.0.12.1234: UDP, length 16 IP 198.18.35.51.61823 > 198.18.0.12.1234: UDP, length 16 IP 198.18.44.42.30344 > 198.18.0.12.1234: UDP, length 16 IP 198.18.106.227.38592 > 198.18.0.12.1234: UDP, length 16 IP 198.18.48.67.19533 > 198.18.0.12.1234: UDP, length 16 IP 198.18.49.38.40566 > 198.18.0.12.1234: UDP, length 16 IP 198.18.50.73.22989 > 198.18.0.12.1234: UDP, length 16 IP 198.18.43.204.37895 > 198.18.0.12.1234: UDP, length 16 IP 198.18.104.128.1543 > 198.18.0.12.1234: UDP, length 16 На другой стороне все пакеты будут направлены на одну очередь прерываний (RX), т.е. на один CPU. Делается это через ethtool:
      ethtool -N ext0 flow-type udp4 dst-ip 198.18.0.12 dst-port 1234 action 2  
      Оценочное тестирование всегда довольно сложное. Когда мы готовили тесты, мы обнаружили, что любые активные сырые сокеты (raw socket) сильно влияют на производительность. Это вполне очевидно, но легко не учесть. Перед тестами убедитесь, что у вас не запущен, к примеру, tcpdump.
      $ ss -A raw,packet_raw -l -p|cat Netid State Recv-Q Send-Q Local Address:Port p_raw UNCONN 525157 0 *:vlan100 users:(("tcpdump",pid=23683,fd=3))  
      В конце концов мы отключили Intel Turbo Boost:
      echo 1 | sudo tee /sys/devices/system/cpu/intel_pstate/no_turbo Это классная функция, и увеличивает производительность по крайней мере на 20%, но она также очень сильно влияет на разброс показаний при замерах. Со включенным бустом разброс достигал +-1.5%. С выключенным - 0.25%.
       

       

      1. Отброс/DROP пакетов в приложении

      Начинаем с доставки пакетов к приложению и отбрасывании их уже с помощью него. Чтобы убедиться, что файервол не влияет на это делаем так:
      iptables -I PREROUTING -t mangle -d 198.18.0.12 -p udp --dport 1234 -j ACCEPT iptables -I PREROUTING -t raw -d 198.18.0.12 -p udp --dport 1234 -j ACCEPT iptables -I INPUT -t filter -d 198.18.0.12 -p udp --dport 1234 -j ACCEPT Код приложения - обычный цикл, который получает данные и сразу же их отбрасывает (в юзерспейсе):
      s = socket.socket(AF_INET, SOCK_DGRAM) s.bind(("0.0.0.0", 1234)) while True: s.recvmmsg([...]) Код приложения: https://github.com/cloudflare/cloudflare-blog/blob/master/2018-07-dropping-packets/recvmmsg-loop.c
      $ ./dropping-packets/recvmmsg-loop packets=171261 bytes=1940176 Тут мы получаем жалкие 175kpps:
      $ mmwatch 'ethtool -S ext0|grep rx_2' rx2_packets: 174.0k/s Железо нам дает 14Mpps, но мы не можем обработать это ядром на одном CPU с одной очередью прерываний. mpstat это подтверждает:
      $ watch 'mpstat -u -I SUM -P ALL 1 1|egrep -v Aver' 01:32:05 PM CPU %usr %nice %sys %iowait %irq %soft %steal %guest %gnice %idle 01:32:06 PM 0 0.00 0.00 0.00 2.94 0.00 3.92 0.00 0.00 0.00 93.14 01:32:06 PM 1 2.17 0.00 27.17 0.00 0.00 0.00 0.00 0.00 0.00 70.65 01:32:06 PM 2 0.00 0.00 0.00 0.00 0.00 100.00 0.00 0.00 0.00 0.00 01:32:06 PM 3 0.95 0.00 1.90 0.95 0.00 3.81 0.00 0.00 0.00 92.38 Как видите, код приложения не является узким местом, используя 27% системы + 2% юзерспейса на CPU #1, в то время как SOFTIRQ на CPU #2 сжирает 100% ресурсов.
      Кстати, использовать recvmmsg(2) довольно важно в наши пост-Спектровые дни (Spectre + Meltdown все же помнят?). Системные вызовы теперь требуют больше ресурсов. Мы используем ядро 4.14 с KPTI и retpolines:
      $ tail -n +1 /sys/devices/system/cpu/vulnerabilities/* ==> /sys/devices/system/cpu/vulnerabilities/meltdown <== Mitigation: PTI ==> /sys/devices/system/cpu/vulnerabilities/spectre_v1 <== Mitigation: __user pointer sanitization ==> /sys/devices/system/cpu/vulnerabilities/spectre_v2 <== Mitigation: Full generic retpoline, IBPB, IBRS_FW  
       
      2. Отключение conntrack

      Мы специально выбрали рандомные IP адреса и порты при тестировании для того чтобы нагрузить conntrack. Это можно проверить, посмотрев на заполненность conntrack таблицы:
      $ conntrack -C 2095202 $ sysctl net.netfilter.nf_conntrack_max net.netfilter.nf_conntrack_max = 2097152 И, конечно же, conntrack будет кричать в dmesg:
      [4029612.456673] nf_conntrack: nf_conntrack: table full, dropping packet [4029612.465787] nf_conntrack: nf_conntrack: table full, dropping packet [4029617.175957] net_ratelimit: 5731 callbacks suppressed Для ускорения наших тестов, давайте его отключим:
      iptables -t raw -I PREROUTING -d 198.18.0.12 -p udp -m udp --dport 1234 -j NOTRACK Запускаем тест:
      $ ./dropping-packets/recvmmsg-loop packets=331008 bytes=5296128 Теперь наше приложение получает 333kpps вместо 175kpps.
      P.S. с SO_BUSY_POLL можно добиться 470kpps, но об этом в другой раз.
       
       
      3. BPF дропание на сокете

      Далее мы подумали - зачем этот трафик вообще нужен на юзерспейсе? Мы можем с помощью setsockopt(SO_ATTACH_FILTER) присоединить классический BPF фильтр к SOCK_DGRAM сокету и отбрасывать пакеты на уровне ядра (kernel space).
      Код: https://github.com/cloudflare/cloudflare-blog/blob/master/2018-07-dropping-packets/bpf-drop.c
       
      Тест:
      $ ./bpf-drop packets=0 bytes=0 С таким подходом (у классического BPF схожая производительность с eBPF) у нас получилось 512kpps. При этом экономится CPU, т.к. не нужно дергать приложение в юзерспейсе.
       

      4. DROP с помощью iptables после роутинга

      В качестве следующего теста мы решили отбрасывать пакеты в цепочке INPUT в iptables:
      iptables -I INPUT -d 198.18.0.12 -p udp --dport 1234 -j DROP Conntrack отключен в предыдущем правиле. Эти два правила в файерволе дали нам 608kpps.
      $ mmwatch 'iptables -L -v -n -x | head' Chain INPUT (policy DROP 0 packets, 0 bytes) pkts bytes target prot opt in out source destination 605.9k/s 26.7m/s DROP udp -- * * 0.0.0.0/0 198.18.0.12 udp dpt:1234  

      5. DROP с помощью iptables в таблице PREROUTING

      Т.е. отбрасываем пакеты пока они не попали в роутинг:
      iptables -I PREROUTING -t raw -d 198.18.0.12 -p udp --dport 1234 -j DROP Получаем 1.688mpps
      Довольно существенный прирост при использовании таблички "raw".
      Не совсем понятно почему такой прирост, возможно потому, что у нас сложный роутинг или баг в настройке сервера.
       

      6. DROP с помощью nftables перед conntrack

      Т.к. iptables доживает свои дни, то теперь можно пользоваться nftables.
      Видео, объясняющее почему nftrack лучше: https://www.youtube.com/watch?v=9Zr8XqdET1c
      nft add table netdev filter nft -- add chain netdev filter input { type filter hook ingress device vlan100 priority -500 \; policy accept \; } nft add rule netdev filter input ip daddr 198.18.0.0/24 udp dport 1234 counter drop nft add rule netdev filter input ip6 daddr fd00::/64 udp dport 1234 counter drop Счетчики можно пронаблюдать так:
      $ mmwatch 'nft --handle list chain netdev filter input' table netdev filter { chain input { type filter hook ingress device vlan100 priority -500; policy accept; ip daddr 198.18.0.0/24 udp dport 1234 counter packets 1.6m/s bytes 69.6m/s drop # handle 2 ip6 daddr fd00::/64 udp dport 1234 counter packets 0 bytes 0 drop # handle 3 } } Получили 1.53mpps. Это немного медленнее iptables, хотя должно быть наоборот. В любом случае nftables рулит.
       

      7. Отбрасывание пакетов в tc ingress

      Неожиданным фактом стало то, что tc (traffic control) ingress обрабатывается перед PREROUTING. Т.е. можно управлять трафиком еще раньше.
      Синтаксис довольно неудобный, поэтому рекомендуется использовать скрипт: https://github.com/netoptimizer/network-testing/blob/master/bin/tc_ingress_drop.sh
      tc qdisc add dev vlan100 ingress tc filter add dev vlan100 parent ffff: prio 4 protocol ip u32 match ip protocol 17 0xff match ip dport 1234 0xffff match ip dst 198.18.0.0/24 flowid 1:1 action drop tc filter add dev vlan100 parent ffff: protocol ipv6 u32 match ip6 dport 1234 0xffff match ip6 dst fd00::/64 flowid 1:1 action drop проверяем:
      $ mmwatch 'tc -s filter show dev vlan100 ingress' filter parent ffff: protocol ip pref 4 u32 filter parent ffff: protocol ip pref 4 u32 fh 800: ht divisor 1 filter parent ffff: protocol ip pref 4 u32 fh 800::800 order 2048 key ht 800 bkt 0 flowid 1:1 (rule hit 1.8m/s success 1.8m/s) match 00110000/00ff0000 at 8 (success 1.8m/s ) match 000004d2/0000ffff at 20 (success 1.8m/s ) match c612000c/ffffffff at 16 (success 1.8m/s ) action order 1: gact action drop random type none pass val 0 index 1 ref 1 bind 1 installed 1.0/s sec Action statistics: Sent 79.7m/s bytes 1.8m/s pkt (dropped 1.8m/s, overlimits 0 requeues 0) backlog 0b 0p requeues 0 Получили 1.8mppps на одном CPU.
       

      8. XDP_DROP

      https://prototype-kernel.readthedocs.io/en/latest/networking/XDP/
      С помощью XDP - eXpress Data Path мы можем запустить eBPF код прямо в сетевом драйвере. Т.е. перед тем как skbuff выделяет память.
       
      Обычно в XDP две части:
      eBPF код, загруженный в ядро юзерспейсный загрузчик, который загружает код в нужную сетевую карту и управляет им  
      Написание загрузчика довольно трудное занятие, поэтому мы решили воспользоваться новой iproute2 фичей:
      ip link set dev ext0 xdp obj xdp-drop-ebpf.o https://cilium.readthedocs.io/en/latest/bpf/#iproute2
      Исходник программы: https://github.com/cloudflare/cloudflare-blog/blob/master/2018-07-dropping-packets/xdp-drop-ebpf.c
      Программа парсит IP пакеты и ищет заданные параметры: IP транспорт, UDP протокол, сеть, порт:
      if (h_proto == htons(ETH_P_IP)) { if (iph->protocol == IPPROTO_UDP && (htonl(iph->daddr) & 0xFFFFFF00) == 0xC6120000 // 198.18.0.0/24 && udph->dest == htons(1234)) { return XDP_DROP; } } XDP программа должна быть скомпилена с современным clang, который умеет делать BPF байткод. После этого загружаем и проверяем XDP программу:
      $ ip link show dev ext0 4: ext0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 xdp qdisc fq state UP mode DEFAULT group default qlen 1000 link/ether 24:8a:07:8a:59:8e brd ff:ff:ff:ff:ff:ff prog/xdp id 5 tag aedc195cc0471f51 jited И смотрим цифры в статистике интерфейса (ethtool -S)
      $ mmwatch 'ethtool -S ext0|egrep "rx"|egrep -v ": 0"|egrep -v "cache|csum"' rx_out_of_buffer: 4.4m/s rx_xdp_drop: 10.1m/s rx2_xdp_drop: 10.1m/s Итого получаем 10Mpps на одном CPU.
       

       

       
      Источник: cloudflare
    • Автор: bot
      Быстрая установка, безопасная работа, простота обновления, невероятная легкость использования и поддержки, - все эти свойства snap-приложений представляют огромный шаг вперед для разработки и установки ПО на Linux. Начиная с Ubuntu, а сейчас уже получив распространение и в Arch Linux, Debian, Fedora, Gentoo Linux и openSUSE, такие приложения дают множество преимуществ по сравнению с традиционными пакетами ПО. В отличие от стандартных пакетов ПО, snap-приложения:
      Более простые для разработки программистами; Быстрее устанавливаются; Автоматически обновляются; Автономны; Изолированы от других приложений; Более безопасны; Стабильны (их работа не нарушается другими приложениями);  

      Итак, что же такое snap-приложения?
      Изначально, snap-приложения были разработаны компанией Canonical для использования в Ubuntu. Этот сервис должен был называться "snappy", сама технология "snapcraft", фоновый процесс - “snapd” а пакеты - “snaps”, однако все это стало новым способом подготовки и установки приложений для Linux. Есши вы считаете, что приставка “snap” говорит о некоторой упрощенности в разработке приложений и процессе их установки? Это абсолютно так!
       
      Snap-приложения кардинально отличаются от других пакетов Linux. Другие пакеты в основном представляют собой архивы файлов, которые при установке помещают файлы в несколько директорий (/usr/bin, /usr/lib, и пр.). К тому же, другие инструменты и библиотеки, от которых зависит пакет, также необходимо установить или обновить, иначе возможен конфликт с более ранней версией. Snap-приложение, напротив, устанавливается как один независимый файл, включающий необходимые библиотеки и другие нужные файлы.  Его работа не будет влиять на работу других приложений, или менять какие-либо ресурсы, от которых также зависят и другие приложения.
       
      При разработке snap-приложения, все источники, необходимые для его работы, включаются в один файл. Такое приложение также изолированно от всей системы, обеспечивая тем самым то, что при изменении snap-приложения, остальные файлы системы не будут подвергаться каким-либо изменениям. Это также затрудняет доступ других программ к данным такого приложения.
       
      Другим важным отличием является то, что snap-приложения не могут являться частью пакетов программ, они рассматриваются и устанавливаются по отдельности, поговорим об этом чуть подробнее.
      Snap-приложения начали свое существования как Клик-пакеты (Click packages) - новый формат пакетов, разработанный для Ubuntu Mobile - а затем уже стали snap-приложениями.
       

      Как работают snap-приложения?
      Snap-приложения работают посредством множества дистрибутивов Linux таким образом, который иногда называют “дистро-агностикой” “distro-agnostic” , он дает разработчикам выйти за рамки своих представлений о совместимости ПО и предварительно установленных библиотек системы. Пакет snap-приложения уже содержит все, что ему нужно для запуска – сжатое, готовое к использованию. По сути, такими (сэатыми) они и остаются. Это позволяет им занимать мало места на диске, не смотря на их автономность.
      Работа таких приложений относительно незаметна. Ваша система может иметь несколько таких программ, а вы даже не будете знать об этом, например, если они входили в дистрибутивы, о которых мы говорили ранее.
       
      Если все же такие приложения присутствуют в вашей системе, для того, чтобы их найти вам нужно будет прописать в строке поиска /snap/bin. Если вы используете для работы оболочку bash users, эта строка будет добавлена автоматически.
      $ echo $PATH /home/shs/bin:/usr/local/bin:/usr/sbin:/sbin:/bin:/usr/games:/snap/bin Проблемы не возникнут даже при автоматическом обновлении. Запущенное snap-приложение продолжает свою работу даже во время обновления. Просто, более новая версия станет активна при следующем запуске.
       

      Почему такие приложения более безопасны?
      Одной из причин повышения безопасности является то, что эти программы имеют существенно более ограниченный доступ к ОС, чем стандартные пакеты ПО. Они находятся в песочницах и контейнерах и не имеют широкого доступа к системе.
       

      Как snap-приложения помогают разработчикам?
       
      Они проще в разработке.
      Snap-приложения позволяют разработчикам больше не думать о необходимости разработки множества дистрибутивов и версий, которые могут понадобиться пользователям. Они просто помещают в пакет snap-приложение и все, что может понадобиться для его работы.
       
      Упрощение длительного процесса разработки
      С точки зрения разработчиков, запускать приложения в разработку довольно трудно. Сообщество открытого кода способно на такое только в ответ на давление по поводу выпуска новых релизов. К тому же, разработчики могут использовать новые библиотеки, не принимая во внимание то, что целевой дистрибутив ссылается на более старые библиотеки. И, даже если они пока новички в разработке snap-приложений, наверстать упущенное они смогут уже за неделю. Говорят, что обучение разработке snap-приложений намного легче, чем изучение новых языков. И, конечно, компаниям, выполняющим поддержку дистрибутива не будет нужно проводить каждое приложение через процесс разработки. Таким образом, выигрывают все.
       
      Пользу snap-приложений также оценят и системные администраторы, особенно то, что эти программы на наносят вред системе и не приводят к необходимости разбираться в дебрях поддержки.
       

      Имеет ли ваша система snap-приложения?
      Ваша система может иметь несколько таких программ, а вы даже не будете знать об этом, например, если они входили в дистрибутивы, о которых мы говорили ранее.
      Проверка работы:
      $ ps -ef | grep snapd root 672 1 0 Jun22 ? 00:00:33 /usr/lib/snapd/snapd где лежит запускающий файл:
      $ which snap /usr/bin/snap какие snap запущены:
      $ snap list Name Version Rev Tracking Developer Notes canonical-livepatch 8.0.2 41 stable canonical - core 16-2.32.8 4650 stable canonical core minecraft latest 11 stable snapcrafters -
      Куда установлены snap'ы?
      Обычно это /var/lib/snapd/snaps. Пакеты поставляются как файлы со .snap расширением
      $ sudo find / -name "*.snap" /var/lib/snapd/snaps/canonical-livepatch_39.snap /var/lib/snapd/snaps/canonical-livepatch_41.snap /var/lib/snapd/snaps/core_4571.snap /var/lib/snapd/snaps/minecraft_11.snap /var/lib/snapd/snaps/core_4650.snap  
      Установка snap'а
      $ sudo snap install hello hello 2.10 from 'canonical' installed $ which hello /snap/bin/hello $ hello Hello, world!  
      проверяем:
      $ snap list Name Version Rev Tracking Developer Notes canonical-livepatch 8.0.2 41 stable canonical - core 16-2.32.8 4650 stable canonical core hello 2.10 20 stable canonical - minecraft latest 11 stable snapcrafters - Для удаления есть snap remove
      Для обновления - snap refresh
      Для списка доступных - snap find
       

      Небольшая предыстория
      Идея snap-приложений родилась у Марка Ричарда Шаттерворта (Mark Richard Shuttleworth), основателя и директора компании Canonical Ltd., выпустившей операционную систему Ubuntu на основе Linux-based и имеющей десятилетия опыта работы с ней. Одной из составляющих мотивации был уход от возможных ошибок при установке – впервые эти программы были использованы на телефонах. Упрощение процесса разработки, простота техподдержки и повышение безопасности системы не оставили шансов забросить эту идею.
       
      источник: networkworld
    • Автор: bot
      Стартап работающий в области Wi-Fi-роутеров пытается перевернуть наше представление о работе домашнего Wi-Fi: они пытаются превратить его в услуги, предоставляемые по абонплате. Такой план поступил от компании Plume, одной из компаний, которая за последние несколько лет немало заработала на растущей популярности сетевых Wi-Fi-систем, в которых используется несколько роутеров для обеспечения лучшего покрытия. Plume начала свою работу в конце 2016 года, и с тех пор занималась продажей роутеров конечному потребителю. Но после двух заявлений, которые сделала компания, можно сказать, что в ее деятельности грядут перемены.



      Во-первых, Plume выводит на рынок более производительный, трехполосный роутер с названием SuperPod. (Их стандартный роутер называется Plume Pod.) Он немного больше и намного дороже, и по сути, больше он ничем не отличается, ведь большинство сетевых систем предлагают как двухполосные, так и трехполосные решения в этой области.

      Самое большое изменение состоит в бизнес модели Plume, которая в настоящее время претерпевает огромные изменения. Раньше, при покупке роутера Plume router (или нескольких таких роутеров, если вы планировали бы настроить сетевую систему) вы бы купили его, и пошли бы своей дорогой, также как и в подобном случае с любым другим роутером. Но, теперь все будет по-другому.



      Теперь, вам будет нужно стать абонентом услуг адаптивного WiFi от Plume еще даже до того, как вы купили роутер. И, как только у вас появятся роутеры от Plume, вам будет нужно стать их абонентом, иначе ваши роутеры не будут работать. (Владельцы Plume Pod уже добавлены в эту систему.)

      Абонентские услуги Plume будут стоить 60 долл. США в год, или вы сможете приобрести пожизненное абонентское обслуживание за 200 долл. США. Одним из наиболее заметных моментов будет снижение цены на роутеры Plume, а также гарантия в течение оплаченного года (пожизненные абоненты сразу же получают гарантию на 5 лет). Сейчас Plume продают свои роутеры в комплекте по три штуки за 179 долл. США. Став абонентом, вы сможете получить такой комплект из трех роутеров (в него входит два двухполосных и один трехполосный роутер) за 39 долл. США, по очень большой скидке. Все равно еще пока это получается дороговато, особенно, если вы захотите купить еще роутеры (особенно трехполосные), но это все равно дешевле, чем покупать такие роутеры в другом месте.



      По меньшей мере, это недорого поначалу. В Plume надеются, что вы будете постоянно платить по 60 долл. США в год для обеспечения работы своих роутеров. В дополнение к скидке на аппаратную часть, абоненты также получат доступ к услугам родительского контроля, продуктам безопасности, проверки скорости и активного управления.

      Мы продолжаем спрашивать главу компании Plume о том, что же такое «активное управление», нам до сих пор это не понятно. В качестве аргумента компания использует то, что сейчас мы подключаем к роутерам все больше и больше устройств – от компьютеров до телефонов, потоковых телеприставок, наушников и гаджетов для смартфонов, - согласовать их работу становится все сложнее, и это требует дополнительных усилий для обеспечения бесперебойной работы. Однако, неужели это что-то такое, за что необходимо платить абонплату? Почему роутеры не могут сами оптимизировать Wi-Fi, как было всегда?

      Конечно, в утверждении от Plume есть доля правды, но все это больше кажется теоретическим. Да, продукты для безопасности очень важны. Но мы не понимаем, что из этих функций «активного управления» выходит за рамки основных функций роутера. Ведь не будут же сотрудники Plume сидеть и работать над микро-управлением нашими Wi-Fi каналами.

      Несмотря на то, что глава Plume, Фари Дайнер (Fahri Diner), в телефонном разговоре две недели назад сказал нам, что компания не будет отбирать роутеры у покупателей, если кто-то откажется платить, представители компании после выхода данной статьи заявили, что это не будет проблемой. Фактически, абонплата нужна для поддержания работы роутера. Поэтому, если кто-то перестает платить, его роутеры перестают работать.

      Г-н Дайнер говорит, что хочет запустить множество дополнительных услуг, которые будут входить в абонплату, чтобы пользователи были рады оставаться его абонентами «Наши намерения и надежды сводятся к принятию простого решения», говорит он по телефону.  «Если клиент не стремится к обновлениям, он не будет обращаться к нам в силу цены. Они будут недовольны нами то по одной причине, то по другой».

      Plume не единственная компания, которая перенесла модель абонентских услуг на роутеры, но она сделала это уникальным способом. Например, компания Eero, начала предлагать услуги по абонентской плате, за которую роутеры получали дополнительные функции — в первую очередь, дополнительные функции безопасности — но эти роутеры прекрасно работают и без этих функций. Компания Luma, которая может быть уже и не работает, тоже предлагала услуги по абонплате, тоже в основном сосредоточенные на безопасности.

      Кажется, что услуги по абонплате неизбежно придут к большинству роутеров. Мы редко покупаем новые устройства, а абонплата позволяет таким компаниям зарабатывать деньги.  Подход компании Plume довольно интересный, он заключается в том, что оборудование купить относительно не накладно, но вот выйти из системы довольно сложно. Но неясным остается то, какой смысл находят в этом пользователи. Если такие функции доступны в другом месте и без абонплаты, зачем тогда выбирать роутер, за который нужно будет постоянно платить?

      Обновление от 12 июня 12:10PM ET: После публикации статьи, представитель компании Plume связался с нами и сообщил, что компания произвела некоторые изменения в своей политике за время, прошедшее с момента нашего телефонного разговора с Г-ном Дайнером. Фактически, компания будет взимать абонплату с пользователей Plume Pods, чтобы они продолжали работать.



      Источник: verge
       

      Тем, кто дочитал до этого момента: почему бы не предоставлять клиентам роутеры по подписке?
      Я понимаю, что есть роутер за 1грн и всё прочее. Но тут немного другая система.
      Клиенты платят за услугу Wi-Fi в доме. Компания берет на себя обязательства по обеспечению беспроводного доступа всех устройств клиента в его доме. Подписываем договор с клиентом (или доп соглашение к основному по доступу в интернет), он оплачивает часть стоимости необходимого оборудования, а остальное будет оплачивать по подписке. Управление устройством осуществляется оператором. То, что хочет менять клиент, он может делать через специальный портал, где будет добавлять устройства домашние или гостевые, нарезать скорость на отдельные устройства, запрещать доступ каким-то устройствам к каким-то сайтам.

      При грамотном подходе всё это делается автоматом через написанный софт, а оператор получает только геморрой с мониторингом и деньги.

      Оператор будет уверен в выбранном роутере, будет обновлять софт по мере необходимости. Плюс дополнительный доход от абонентов и разгрузка коллцентров.
    • Автор: Sadovoy
      Продам двух диапазонные маршрутизаторы ASUS RT-N66U(RT-N66U, RT-N66W) с гигабитными портами в рабочем состоянии.
      Комплектация: оригинальная коробка, документация и диск, роутер, подставка, три съемные антенны, оригинальный блок питания под американскую вилку, переходник под наши розетки. Все маршрутизаторы с американского рынка с увеличенной мощностью сигнала и большим радиусом действия.

      Максимальная скорость Wi-Fi 450 Мбит/с
      Частота работы Wi-Fi 2,4 ГГц и 5ГГц
      Максимальная скорость LAN портов 1 Гбит/с
      Поддержка протоколов PPPoE, IPsec, L2TP, PPTP

      Полные характеристики на сайте.:

      https://www.asus.com/ru/Networking/RTN66U/specifications/
       
      1. б/у черный в полной комплектации 1799грн
      2. новый черный, в запечатанной коробке 2099грн
      3. б/у белый в полной комплектации 1299грн. один LAN порт не работает. в остальном прблем с ним нет. продано
       











    • Автор: fet4
      Привет всем.
      Кто-то использовал бондинг в режиме balance-alb?
      Если да, расскажите конфигурацию? На свитче нужно настраивать агрегацию? 
×