Bug #1760
open
Странное поведение при включении опций поведения прокси
0%
Description
В общем, надо разобраться, что конкретно делают и на что и как влияют, а на что не влияют вот эти вот две опции: 
То есть, подробно, как именно изменится поведение при их включении и отключении. как они между собой связаны, нужно ли включать первую опцию, если включена вторая?
А теперь, собственно, проблемки. они тесно связаны с азотом.
Если актвирована опция "Включить глобально", то при изменении xmpp-аккаунта, требующем реконнекта, он не может приконнектится сам автоматом, вываливаю в варнинг.лог
[18.10.2014 11:34:52.311] [0x7fac433fe040] [380] QAbstractSocket::connectToHost() called when already looking up or connecting/connected to "81.7.6.103"
в логе ксукса:
сб окт 18 11:34:52 2014 SENT <presence type="unavailable"><status>Я на связи!</status><priority>4</priority><c xmlns="http://jabber.org/protocol/caps" hash="sha-1" node="http://leechcraft.org/azoth" ver="pAQQvKcA0utN+UfWqMunLktHKdo="/></presence> сб окт 18 11:34:52 2014 SENT </stream:stream> сб окт 18 11:34:52 2014 SENT </stream:stream> сб окт 18 11:34:52 2014 INFO Connecting to 81.7.6.103:5222 сб окт 18 11:34:52 2014 DEBUG Socket disconnected
если деактивировать опцию "Включить глобально", то реконнектит успешно.
Далее, если после этого вручную законнектиться, то в ростере у этого аккаунта не буде самококонтакта:
Немного дебага:
==> .leechcraft/warning.log <==
[18.10.2014 11:34:52.311] [0x7fac433fe040] [380] QAbstractSocket::connectToHost() called when already looking up or connecting/connected to "81.7.6.103"
==> .leechcraft/debug.log <==
[18.10.2014 11:41:00.946] [0x7fac433fe040] [381] virtual QIcon LeechCraft::IconThemeEngine::GetIcon(const QString&, const QString&) no icon for "" "" "oxygen" ("/home/demo/.leechcraft/icons", "/usr/local/share/icons", "/usr/share/icons", ":/icons")
[18.10.2014 11:41:00.947] [0x7fac433fe040] [382] virtual QIcon LeechCraft::IconThemeEngine::GetIcon(const QString&, const QString&) no icon for "" "" "oxygen" ("/home/demo/.leechcraft/icons", "/usr/local/share/icons", "/usr/share/icons", ":/icons")
[18.10.2014 11:41:00.947] [0x7fac433fe040] [383] virtual QIcon LeechCraft::IconThemeEngine::GetIcon(const QString&, const QString&) no icon for "" "" "oxygen" ("/home/demo/.leechcraft/icons", "/usr/local/share/icons", "/usr/share/icons", ":/icons")
[18.10.2014 11:41:00.947] [0x7fac433fe040] [384] virtual QIcon LeechCraft::IconThemeEngine::GetIcon(const QString&, const QString&) no icon for "" "" "oxygen" ("/home/demo/.leechcraft/icons", "/usr/local/share/icons", "/usr/share/icons", ":/icons")
[18.10.2014 11:41:00.947] [0x7fac433fe040] [385] virtual QIcon LeechCraft::IconThemeEngine::GetIcon(const QString&, const QString&) no icon for "" "" "oxygen" ("/home/demo/.leechcraft/icons", "/usr/local/share/icons", "/usr/share/icons", ":/icons")
[18.10.2014 11:41:00.947] [0x7fac433fe040] [386] virtual QIcon LeechCraft::IconThemeEngine::GetIcon(const QString&, const QString&) no icon for "" "" "oxygen" ("/home/demo/.leechcraft/icons", "/usr/local/share/icons", "/usr/share/icons", ":/icons")
[18.10.2014 11:41:00.947] [0x7fac433fe040] [387] virtual QIcon LeechCraft::IconThemeEngine::GetIcon(const QString&, const QString&) no icon for "" "" "oxygen" ("/home/demo/.leechcraft/icons", "/usr/local/share/icons", "/usr/share/icons", ":/icons")
[18.10.2014 11:41:00.948] [0x7fac433fe040] [388] virtual QIcon LeechCraft::IconThemeEngine::GetIcon(const QString&, const QString&) no icon for "" "" "oxygen" ("/home/demo/.leechcraft/icons", "/usr/local/share/icons", "/usr/share/icons", ":/icons")
[18.10.2014 11:41:00.948] [0x7fac433fe040] [389] virtual QIcon LeechCraft::IconThemeEngine::GetIcon(const QString&, const QString&) no icon for "" "" "oxygen" ("/home/demo/.leechcraft/icons", "/usr/local/share/icons", "/usr/share/icons", ":/icons")
[18.10.2014 11:41:12.445] [0x7fac433fe040] [390] virtual bool QXmppRosterManager::handleStanza(const QDomElement&)
[18.10.2014 11:41:12.445] [0x7fac433fe040] [391] virtual void QXmppRosterIq::parseElementFromChild(const QDomElement&) "item" "" "lctu0@jabbim.cz"
[18.10.2014 11:41:12.445] [0x7fac433fe040] [392] virtual void QXmppRosterIq::parseElementFromChild(const QDomElement&) "item" "" "lctu2@leechcraft.org"
[18.10.2014 11:41:12.445] [0x7fac433fe040] [393] virtual void QXmppRosterIq::parseElementFromChild(const QDomElement&) "item" "" "lctu4@leechcraft.org"
[18.10.2014 11:41:12.445] [0x7fac433fe040] [394] virtual void QXmppRosterIq::parseElementFromChild(const QDomElement&) parsed 3 items
[18.10.2014 11:41:12.446] [0x7fac433fe040] [395] virtual bool QXmppRosterManager::handleStanza(const QDomElement&) got roster IQ items 3 true
[18.10.2014 11:41:12.446] [0x7fac433fe040] [396] virtual bool QXmppRosterManager::handleStanza(const QDomElement&) inserting item "lctu0@jabbim.cz"
[18.10.2014 11:41:12.446] [0x7fac433fe040] [397] virtual bool QXmppRosterManager::handleStanza(const QDomElement&) inserting item "lctu2@leechcraft.org"
[18.10.2014 11:41:12.446] [0x7fac433fe040] [398] virtual bool QXmppRosterManager::handleStanza(const QDomElement&) inserting item "lctu4@leechcraft.org"
[18.10.2014 11:41:12.446] [0x7fac433fe040] [399] QStringList QXmppRosterManager::getRosterBareJids() const ("lctu0@jabbim.cz", "lctu2@leechcraft.org", "lctu4@leechcraft.org")
[18.10.2014 11:41:12.450] [0x7fac433fe040] [400] QStringList QXmppRosterManager::getRosterBareJids() const ("lctu0@jabbim.cz", "lctu2@leechcraft.org", "lctu4@leechcraft.org")
[18.10.2014 11:41:12.450] [0x7fac433fe040] [401] QStringList QXmppRosterManager::getRosterBareJids() const ("lctu0@jabbim.cz", "lctu2@leechcraft.org", "lctu4@leechcraft.org")
[18.10.2014 11:41:12.450] [0x7fac433fe040] [402] QStringList QXmppRosterManager::getRosterBareJids() const ("lctu0@jabbim.cz", "lctu2@leechcraft.org", "lctu4@leechcraft.org")
[18.10.2014 11:41:13.397] [0x7fac433fe040] [403] void LeechCraft::Azoth::Xoox::EntryBase::SetClientVersion(const QString&, const QXmppVersionIq&) "Azoth2" "Gentoo/Linux x86_64 3.16.3-gentoo #1 SMP PREEMPT Sun Oct 5 05:12:41 MSK 2014"
[18.10.2014 11:41:13.869] [0x7fac433fe040] [404] void LeechCraft::Azoth::Xoox::EntryBase::SetClientVersion(const QString&, const QXmppVersionIq&) "Azoth2" "Gentoo/Linux x86_64 3.16.3-gentoo #1 SMP PREEMPT Sun Oct 5 05:12:41 MSK 2014"
[18.10.2014 11:41:14.559] [0x7fac433fe040] [405] void LeechCraft::Azoth::Xoox::EntryBase::SetClientVersion(const QString&, const QXmppVersionIq&) "Azoth6" "Gentoo/Linux x86_64 3.16.3-gentoo #1 SMP PREEMPT Sun Oct 5 05:12:41 MSK 2014"
[18.10.2014 11:41:17.451] [0x7fac433fe040] [406] QStringList QXmppRosterManager::getRosterBareJids() const ("jt@brauchen.info", "lctu1@draugr.de", "lctu2@leechcraft.org", "lctu3@leechcraft.org", "lctu4@leechcraft.org")
[18.10.2014 11:41:17.451] [0x7fac433fe040] [407] QStringList QXmppRosterManager::getRosterBareJids() const ("jt@brauchen.info", "lctu1@draugr.de", "lctu2@leechcraft.org", "lctu3@leechcraft.org", "lctu4@leechcraft.org")
[18.10.2014 11:41:17.452] [0x7fac433fe040] [408] QStringList QXmppRosterManager::getRosterBareJids() const ("jt@brauchen.info", "lctu1@draugr.de", "lctu2@leechcraft.org", "lctu3@leechcraft.org", "lctu4@leechcraft.org")
[18.10.2014 11:41:17.453] [0x7fac433fe040] [409] QStringList QXmppRosterManager::getRosterBareJids() const ("jt@brauchen.info", "lctu1@draugr.de", "lctu2@leechcraft.org", "lctu3@leechcraft.org", "lctu4@leechcraft.org")
[18.10.2014 11:41:17.453] [0x7fac433fe040] [410] QStringList QXmppRosterManager::getRosterBareJids() const ("jt@brauchen.info", "lctu1@draugr.de", "lctu2@leechcraft.org", "lctu3@leechcraft.org", "lctu4@leechcraft.org")
[18.10.2014 11:41:17.453] [0x7fac433fe040] [411] QStringList QXmppRosterManager::getRosterBareJids() const ("lctu0@jabbim.cz", "lctu2@leechcraft.org", "lctu4@leechcraft.org")
[18.10.2014 11:41:17.454] [0x7fac433fe040] [412] QStringList QXmppRosterManager::getRosterBareJids() const ("lctu0@jabbim.cz", "lctu2@leechcraft.org", "lctu4@leechcraft.org")
[18.10.2014 11:41:17.454] [0x7fac433fe040] [413] QStringList QXmppRosterManager::getRosterBareJids() const ("lctu0@jabbim.cz", "lctu2@leechcraft.org", "lctu4@leechcraft.org")
STR:
0. В свойствах аккуанта xmpp прописан IP хоста.
1. Активировать опцию поведения прокси "Включить глобально", если не была активной.
2. Изменить ресурс онлайн аккаунта.
3. Подключить аккаунт принудительно.
Expected result:
Actual result:
System information:
LeechCraft 0.6.70-1184-gb7df80c
Built with Qt 4.8.5, running with Qt 4.8.5
Running on: Gentoo/Linux x86_64 3.16.3-gentoo #1 SMP PREEMPT Sun Oct 5 05:12:41 MSK 2014
Updated by 0xd34df00d about 10 years ago
Первая опция включает прокси для, собственно, менеджера сетевых соединений — это класс, через который большинство личкрафтов скачивает всякое по хттп.
Вторая — для всего остального, вроде того же Xoox. Это объясняет, почему первая опция на него не влияет.
Updated by Mellon about 10 years ago
(>_<)
Ну... если ты уж так... то ок. тогда будем клещами вытягивать.
1. Что есть менеджер сетевых соединений? Что работает через него, а что нет?
2. Если активировать "Включить глобально", то все соединения инициируемые в личкрафтах будут перехвачены?
3. Уточни, что будет, если активировать "Включить глобально", но деактивировать "Включить для общего менеджера.."?
4. Что будет если ни одна из этих опций не активирована?
5. Как соотносятся настройки xproxy к настройкам прокси приложения в настройках ядра личкрафтов?
6. Приведи пример, когда может потребоваться деактивация как одной из них, так и обеих настроек поведения прокси.
Вопросы 1-5 направлены на выяснение логики работы плагина и его возможностей.
Вопрос 6 предназначен для выяснения необходимости этих настроек вообще, так как они не совсем очевидны и, по-ходу, изрядно вводят в заблуждение о его возможностях. То есть, включая этот плагин, пользователь уверен, что все соединения проходят через него, а при активации тех двух опций, ты как бы гарантируешь, что абсолютно все соединения будут перехвачены. Но, насколько я помню, это совсем не так.
Вот у меня и есть предложение изначально применять максимально возможное в пределах архитектуры личкрафтов перенаправление соединений. И оставить только одну опцию "Включить перехват сокетов" при включении которого будет осуществляться гарантированное заворчаивание всех соединений на прокси путем перехвата всех сетевых сокетов, но при этом без гарантий успешной работы перехватываемого плагина. Как бы глобально, так глобально, но потом не жаловаться.
Updated by 0xd34df00d about 10 years ago
Mellon wrote:
(>_<)
Ну... если ты уж так... то ок. тогда будем клещами вытягивать.
А, сорь.
1. Что есть менеджер сетевых соединений? Что работает через него, а что нет?
Через него работает (почти) весь HTTP.
2. Если активировать "Включить глобально", то все соединения инициируемые в личкрафтах будут перехвачены?
Гарантируется это только для соединений в Qt. То есть, торренты в libtorrent будут пользоваться своим собственным прокси из торрентонастроек. Если бы у меня был, например, плагин-FTP-клиент на curl, то там было бы аналогично.
Торренты и прочие плагины с некутишной сетью можно заставить поддерживать эти прокси, но это требует ручной работы со стороны автора плагина. Это не в смысле лени, а в смысле (отсутствия) гарантий.
3. Уточни, что будет, если активировать "Включить глобально", но деактивировать "Включить для общего менеджера.."?
Ничего. Вторая опция — надмножество первой.
4. Что будет если ни одна из этих опций не активирована?
Прокси не будут использоваться.
5. Как соотносятся настройки xproxy к настройкам прокси приложения в настройках ядра личкрафтов?
Хм. Скорее всего, оверрайдят. А вообще надо из ядра выпилить настройки, думаю.
6. Приведи пример, когда может потребоваться деактивация как одной из них, так и обеих настроек поведения прокси.
Когда ты ездишь между Лондоном и Москвашкой, в Москвашке у тебя РКН и rublacklist.net, а в Ландоне швабодный интернет. Можно просто снять галочки и наслаждаться полноценным интернетом без проксей.
Вопросы 1-5 направлены на выяснение логики работы плагина и его возможностей.
Вопрос 6 предназначен для выяснения необходимости этих настроек вообще, так как они не совсем очевидны и, по-ходу, изрядно вводят в заблуждение о его возможностях. То есть, включая этот плагин, пользователь уверен, что все соединения проходят через него, а при активации тех двух опций, ты как бы гарантируешь, что абсолютно все соединения будут перехвачены. Но, насколько я помню, это совсем не так.
Верно, см. выше.
Вот у меня и есть предложение изначально применять максимально возможное в пределах архитектуры личкрафтов перенаправление соединений. И оставить только одну опцию "Включить перехват сокетов" при включении которого будет осуществляться гарантированное заворчаивание всех соединений на прокси путем перехвата всех сетевых сокетов, но при этом без гарантий успешной работы перехватываемого плагина. Как бы глобально, так глобально, но потом не жаловаться.
Идея с глобальным перехватом всех сокетов хороша, но я не уверен, что это можно сделать достаточно платформонезависимо.
Updated by 0xd34df00d about 10 years ago
Олсо, только что открыл туннель через ssh -D port otherhost и добавил в XProxy правило на заворачивание всего трафика на SOCKS5-прокси на localhost:port, азотх работает.
Updated by Mellon about 10 years ago
Ничего. Вторая опция — надмножество первой.
В смысле ничего? то есть прокси будут отключены?
Можно просто снять галочки и наслаждаться полноценным интернетом без проксей.
Ок. Тогда может быть оставить только одну галочку "Включить xproxy"?
Updated by 0xd34df00d about 10 years ago
В смысле ничего? то есть прокси будут отключены?
Нет, скорее первая кнопка ни на что не влияет, если включена вторая.
Ок. Тогда может быть оставить только одну галочку "Включить xproxy"?
А если мне xproxy нужен только для того, чтобы заворачивать список хостов из rublacklist.net на ssh-тунyель куда-нибудь, не трогая не-http-траффик? Зачем мне вообще тогда тратить такты процессора на перехват вообще всех кутишных соединений?
Updated by Mellon about 10 years ago
Идея с глобальным перехватом всех сокетов хороша, но я не уверен, что это можно сделать достаточно платформонезависимо.
http://code.google.com/p/badvpn/source/browse/#svn/trunk/tun2socks
http://code.google.com/p/badvpn/wiki/tun2socks
например?
Нет, скорее первая кнопка ни на что не влияет, если включена вторая.
Вот оно что...
А если мне xproxy нужен только для того, чтобы заворачивать список хостов из rublacklist.net на ssh-тунyель куда-нибудь, не трогая не-http-траффик? Зачем мне вообще тогда тратить такты процессора на перехват вообще всех кутишных соединений?
Это уже более конструктивно.
Ок, по крайней мере, щас более-менее ясно что к чему...
Ну а касательно азота, у тебя не воспроизводится?
Updated by 0xd34df00d about 10 years ago
Mellon wrote:
Идея с глобальным перехватом всех сокетов хороша, но я не уверен, что это можно сделать достаточно платформонезависимо.
http://code.google.com/p/badvpn/source/browse/#svn/trunk/tun2socks
http://code.google.com/p/badvpn/wiki/tun2socks
например?
Предлагаешь взять их реализацию? Не факт, что получится, надо поковырять их сорсы. А их много.
Впрочем, если я найду реализацию под линукс и фрибсд, этого хватит, наверное. Странно хотеть/ожидать полноценной анонимности и секурности под маком и виндой.
Ну а касательно азота, у тебя не воспроизводится?
Неа, относительно отлично коннектится. У тебя точно какие прокси не перехватывают его соединения?
Updated by Mellon about 10 years ago
Ок. повыяснял ещё немного.
Да, с прямым коннектом к SOCKS proxy — ок. норм
Но у меня там стоит HTTP proxy. А вот с ним вот эта проблемка, да.
Updated by 0xd34df00d about 10 years ago
Неудивительно, что тогда не коннектится.
Впрочем, не уверен, что это баг, вполне себе ожидаемое поведение. Вомзожно, стоило бы проверять, http ли прокси, и не заворачивать в него коннекты при соединении не по хттп-протоколу, но я не уверен, что это имеет смысл или не ограничит излишне пользователя.
Updated by Mellon about 10 years ago
А что не так с HTTP proxy? Оно же вручную норм коннектит. Более того, там SSL/TLS во все поля. прокси передает эти соединения далее в неизменном виде.
Updated by Mellon about 10 years ago
Ещё более того, этот прокси (privoxy) передает далее не трогая любой неHTTP трафик.
Updated by Mellon almost 10 years ago
- Priority changed from Normal to Low
Ответы получены.
Gроблема по-прежнему присутствует, а именно не пересоединяет, если, например
ср фев 11 01:34:17 2015 SENT </stream:stream> ср фев 11 01:34:17 2015 INFO Connecting to 185.31.209.21:5222 ср фев 11 01:34:17 2015 DEBUG Socket disconnected ср фев 11 01:34:17 2015 SENT <presence to="leechcraft@conference.leechcraft.org/Mellon" type="unavailable"/>