Jump to content

IgaX

Forum Members
  • Posts

    950
  • Joined

  • Last visited

  • Days Won

    3

Posts posted by IgaX

  1. да там вариантов как грязи.

    если диск доступен по ip роутера, например, в проводнике:

    \\192.168.1.1\

    - то в полку вопрошающих есть ли жизнь на Марсе и почему раньше работал master browser, - прибыло;

    если выше не помогает, но помогает в консоли винды под админом:

    ipconfig /release
    ipconfig /renew

    - то любое ПО на клиенте могло накосячить и это неудивительно, ведь ~ 3/5 разработчиков ждет отдельное спа в нижнем мире;

    можно еще контрольным:

    netsh winsock reset

    потом уже думать, что м.б. из-за ntfs особые права доступа на самом диске, почитать kb, напрячь хэлпдеск (им ведь за это платят вроде) и все в таком духе, но в условиях задачи проблемы наступили при G2->G3 и соль, вероятнее, в этом; хотя после описанных в задаче лекарств, возможно, светит и полная децимация винды с реинкарнацией (так быстрее чем выверять все возможности).

  2. 6 часов назад, Mamay сказал:

    Хомячки сами сие захотели, вот вам реализация мечт

    Огласите весь список, пожалуйста =)

    1 час назад, Mamay сказал:

    Тусить на форуме бухгалтеров, не имея понятия о дебетах и кредитах, простите не комильфо. 

    Эта аптека - как констатация сюрреализма защищаемой Вами реальности =)

  3. 54 минуты назад, iocsha сказал:

    Как я понял оборудование  отличное  от яблочных работать не будет корректно .  На зеvле  устройств под андройд гораздо , на порядки больше яблочных  ,почему сначала под них разрабатывается  все новые фишки ?

    Все зависит от антенн клиентов. Даже в яблоках. Расстояния итп. Попадется антенна, ломающая моск, например, контрольному зацементированному соотношению в прошивке кинетика, и получите пинг-понг. Логично. Заслуженно.

    5-й ифон:

    Скрытый текст

    image1.jpg

    3-й ипад:

    Скрытый текст

    1000w

    Акценты не те.

    В ведройдах чаще всего поможет - "Always allow Wi-Fi Roam Scans":

    Скрытый текст

    Screenshot_20160414-192203.png

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

  4. Еще могут тариф втихаря вернуть на базовый без предупреждения об объявлении войны сжирая балансы и, что характерно, в ЛК эта операция даже будет не видна. Баги продолжают имплантироваться повсеместно, упорно и с особым садизмом .. а гипножабы делают остальное.

  5. А если, например, возьмем Airport Extreme AC

    Country Code: US

    Channel: 36-48
    MTPL: 17 dBm

    повыше:

    Channel: 52-144
    MTPL: 24 dBm

    и еще повыше:

    Channel: 149-165
    MTPL: 30 dBm

    и как бы не смотря на глуховатость - с Airport Extreme AC яблоко будет лучше выкачивать в UNII-3 на 161-м.

    ***
    так что требуйте все каналы и правильные настройки для US и проверяйте по краям: 36 vs 161 .. и серединку заодно .. мало ли на Кинетике весь сок там :)

  6. 5 минут назад, r13 сказал:

    ставьте openwrt

    так замуровали, демоны :D

    по идее, тут придумать/добавить фичу беспроводного контроллера на базе наших топов не должно быть сложно.

    базовый подход описан детально (фз на скок реализуемо в нашем ядре):
    https://blog.fem.tu-ilmenau.de/archives/1002-HowTo-enable-WiFi-roaming-with-hostapd-and-VLANs.html

    просто понимание того, что тот же базовый код для Band Steering был доступен еще вроде в 2015-м, а нам сейчас предлагают это как новую фичу, да еще и без возможности подстройки .. и на "пилинг" )) уходят недели .. лично меня это уже бесит )) .. но я "зануда", поэтому с моей стороны не аргумент.

    хочется, чтобы железо раскрыло свой потенциал, только и всего.

  7. Поскольку в упор на это не обращают внимание, то отдельный баг-репорт.

    При выборе регуляторного домена United States должны быть доступны все каналы.

    Скрытый текст

    WiFi%20channel%20bonding%20-%20part%202%

    Доступны хотя бы через CLI, если в web-gui некому вбить. А то весь U-NII-2C вырезан.

    И остальное по мелочи.

    Для проверки - в:

    more temp:RT2860APi.dat

    Должно быть:

    CountryRegionABand=7
    CountryCode=US
    IEEE80211H=1
    RDRegion=FCC

    Предвидя контр-аргументы, сообщаю: нахожусь в воображаемом мире, в наличии как минимум телепорт и за окном Манхэттен. Предложения вернуться в реальность не принимаются, т.к. не относятся к правильности настроек регуляторного домена United States.

    Либо дайте удобный доступ к настройкам всем пользователям.
    А сказки для ньюфагов, один фиг, на всех патронов не хватит. :)

    ***
    (все события и персонажи вымышлены, любые совпадения случайны).

    • Thanks 5
  8. 27 минут назад, r13 сказал:

    Отстрел как раз идет предупредив, также как сейчас уже реализовано на последних драфтах на 2х диапазонниках. 

    Может, человек на зарплате. Не протестует ведь, что нет возможности править пороговые значения Band Steering и поэтому "может как привести к положительному, так и отрицательному результату". :D 

    Для андройдов подстройку зарыли в "Developer options" (и то не везде доступна). Опция: "Always allow Wi-Fi Roam Scans" в секции "Debugging".

    Либо прямая правка по образу:
    https://forum.xda-developers.com/showpost.php?p=46134045&postcount=15357

    Либо играем в орлянку с секьюрити приложениями типа:
    https://play.google.com/store/apps/details?id=com.pintacdesign.bestwifi
    https://play.google.com/store/apps/details?id=com.heleron.wifiroamingfix

    Или пробуем тюнить (но опять же, на вкус и цвет):
    https://play.google.com/store/apps/details?id=org.wahtod.wififixer
    https://play.google.com/store/apps/details?id=com.brilliapps.wifiandmorefixer

    ***
    А так, по идее, тема для слияния с этой.

    ***
    И отделу маркетинга на заметку: кол-во установок приложений говорит о том, что все же нужная фича.

  9. 2 часа назад, Sergey Zozulya сказал:

    Неправильно это в корне - решать подобные проблемы таким способом

    Угу. Просто если уж стараемся ровняться на Cisco, то заодно бы использовать похожий функционал. На сколько я понял, Cisco TAC запрашивает дампы в т.ч. такого плана для решения проблем с беспроводными клиентами. Железо у нас хорошее, по идее, потянет и незаметно для пользователя.

    Скрытый текст

    https://wireless.wiki.kernel.org/en/users/documentation/modes

    Monitor mode

    Monitor mode is a passive-only mode, no packets are transmitted. All incoming packets are handed over to the host computer completely unfiltered. This mode is useful to see what's going on on the network.

    With mac80211, it is possible to have a network device in monitor mode in addition to a regular device, this is useful to observe the network whilst using it. However, not all hardware fully supports this as not all hardware can be configured to show all packets while in one of the other operating modes, monitor mode interfaces always work on a “best effort” basis.

    With mac80211, it's also possible to transmit packets in monitor mode, which is known as packet injection. This is useful for applications that wish to implement MLME work in userspace, for example to support nonstandard MAC extensions of IEEE 802.11.

     

  10. @Sergey Zozulya

    Обновленная ссылка по железу тут:
    https://wikidevi.com/wiki/List_of_Wi-Fi_Device_IDs_in_Linux

    Как пример:
    https://wikidevi.com/wiki/Rt2800usb

    Важные моменты: Monitor mode и Packet injection (крайнее, по идее, позволяет делать очень многое) + обращаем внимание на "Limitations / unimplemented functionality NOS" и на остальное. Внизу страницы список потенциальных девайсов.

    Поиск не так чтобы легко и просто, но "supported":

    Monitor mode
    Packet injection

    Например, если хотим abgn+ac на Atheros, где по идее точно "Monitor mode: supported", то примерно так.

    Потом, видимо, поиск в сетевых из серии Nix, вроде полегче найти, особенно редкости. Если не выйдет, то в сторону зарубежных.

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

  11. 1 час назад, r13 сказал:

    Озадачил момент что устройство в 23:16:25 выкинули а обратно не взяли (видимо телефон спал и пропустил deauth как это описывал уже @Padavan)

    Deauth обрубает жестко, это не относится к тому, что обратно не взяли. И вообще здесь, по идее, правильнее, чтобы использовался Disassociation без повторной авторизации (и это лучше делают настройки драйвера).

    Кроме того, соответствующий фрейм, конечно, может потеряться из-за того, что свет Венеры отразился от верхних слоёв атмосферы, и считаться пропущенным, но если все настроено правильно, то все данные для спящего клиента буферизуются, поэтому особо не аргумент, виноваты могут быть оба и остальное. И немного подробнее про Power Save.

  12. Так сказать, revenons à nos moutons ...

    ip arp 192.168.1.1 5c:d9:98:66:2a:80

    - ситуацию не меняет, все так же жарит, на данный момент: каждые 3-4 сек.

    Возможно, немного расскажет:

    more proc:net/arp
    
    IP address       HW type     Flags       HW address            Mask     Device
    192.168.2.2      0x1         0x6         e0:46:9a:33:45:58     *        br0
    192.168.2.46     0x1         0x2         40:e2:30:72:0e:cd     *        br0
    192.168.1.1      0x1         0x6         5c:d9:98:66:2a:80     *        apcli0

    Как видим, есть статика с флагом 0x6 на интерфейсе apcli0 (WifiMaster0/WifiStation0), в т.ч. для проверки есть еще одна статика с таким же флагом на br0.

    Есть некоторые вопросы по флагу 0х6.

    Ближайший исходник ничего не говорит про флаг 0х6 .. инет противоречив, но есть упоминание:

    Between the arp command and the kernel's arp_req_set() function, the arp_flags field is set to ATF_PERM | ATF_COM = 0x6.

    - т.е. похоже, что флаг "или/или" .. что слегка подтверждает слухи о глюках в arp-е начиная с linux 2.2 или как-то так.

    Есть еще одно интересное упоминание здесь:

    Скрытый текст

    Notice the ARP flag of "0x6". The ASIC ARP entry with flag 0x6 is MAC-cache related entry. It is caused by arp lookup failure when installing the session. The session will try to use the source MAC address of incoming packet, but it is not necessary for using this mac address. We can get the MAC address when the reply packet arrives by sending an ARP packet to the source host.

    Т.е. какая-то неудача, в копилку слухов выше.

    Данные тут, возможно, подтверждают, но тоже нет уверенности из-за счетчиков (и те ли данные):

    more proc:net/stat/arp_cache
    
    entries   allocs   destroys hash_grows lookups  hits      res_failed  rcv_probes_mcast rcv_probes_ucast  periodic_gc_runs forced_gc_runs unresolved_discards
    00000008  00000229 00000000 00000002   0004eeb8 0004ecb9  0000035d    00000000         00000000          00000000         00000000       0000001d
    00000008  00000063 00000284 00000000   0000c788 0000c73b  00000005    00000000         00000000          00006886         00000000       00000000

    Интересно выглядит решение:

    Скрытый текст

    So as a workaround, use the command "set flow reverse-route clear-text always", then reset the firewall. The the duplicate ASIC ARP entry will never happen. This command will disable MAC caching on the ASIC.

    Нам это, похоже, не грозит до multiWAN, но ближайшая похожая команда из этой серии:

    set net.ipv4.conf.apcli0.rp_filter 0

    (при условии, что включено флагами 1 или 2)

    Почему м.б. "оно" .. есть такое мнение:

    Скрытый текст

    So in other words, when a machine with reverse path filtering enabled recieves a packet, the machine will first check whether the source of the recived packet is reachable through the interface it came in.

    Но т.к. у нас, возможно, какие-то проблемы с arp, то м.б. на apcli0 как раз постоянно и идет проверка на reachable.

    Все тихо уже давно, мысленный эксперимент выше.
    Возможно, кто-нибудь из сообщества разбирается в Linux Kernel и сможет прокомментировать или подсказать решение?

    Спасибо.

  13. 1 час назад, ydzhus сказал:

    увеличивать частоту = увеличивать пагубное влияние на себя, оно того стоит?

    По мне, главное, с мощностью не переборщить и рядом с подушкой на всякий не ставить (а то еще кошмары будут) :)

    Фз, на сколько правдиво, но в целом логично:
    https://myfamilydoctor.ru/vreden-li-wi-fi-dlya-zdorovya/

    А так никогда нет уверенности в power levels устройств по LNA и PA на каналах. Никто в открытую не говорит. По яблоку и то данные с FCC утащили вроде. По логике все это влияет на энергопотребление/тепловыделение и может в т.ч. повышать риск самовозгорания мобильных клиентов и негативно влиять на общее впечатление (а может им просто хочется поменять чутка цифры и продать то же самое только в профиль). Очень любят кивать на EEPROM, по факту же это занятие делает бессмысленным наличие eFUSE. В общем, мысль о том, что нам, честным фраерам, постоянно втирают дичь, - не покидает :)

  14. 9 минут назад, ydzhus сказал:

    Нужно выбрать по возможности максимально меньший номер канала.

    https://en.wikipedia.org/wiki/U-NII

    Немножко все поменялось, хоть и есть некоторые неточности:
    https://en.wikipedia.org/wiki/List_of_WLAN_channels

    Максимально меньший .. мм .. не думаю :)

    10 минут назад, ydzhus сказал:

    Чем выше частота, тем больше излучаемая мощность сигнала

    Угу, поэтому если покрытие 5 ГГц не устраивает - желательно уйти в р-н 149-го канала, но надо смотреть как клиент себя будет чувствовать.

×
×
  • Create New...