Добре де, а кой драйвър се ползва? Свободния или несвободния такъв? В конкретния случай си асоцииран към едно АП а да кажем на кратко се очаква да си в друго.

Това трябва да е драйвера:

Код:

wlan0: Broadcom BCM4359 802.11 Hybrid Wireless Controller 6.30.223.271 (r587334)

Компютрите са стационарни, тоест от моята гледна точка би трябвало да са свързани с едно AP. Обаче към всяко AP в даден момент могат да се свързват и много други мобилни клиенти – IP телефони. Дали това се отразява на работата на нашите стационарни клиенти и как именно е доста отвъд моите знания.

Последно от IT отдела казаха, че са направили някакви настройки така че картата да не се опитва да сменя AP-тата, но и да има промяна, то тя е чисто количествена. Като че ли малко по-рядко започнаха да се дисконектват устройствата.

ERROR @wl_cfg80211_get_station : Wrong Mac address, mac = e0:d1:73:29:e0:39   profile =00:81:c4:f8:e4:49

Към момента е закачено към АП с мак: e0:d1:73:29:e0:39
А се очаква да бъде АП с мак: 00:81:c4:f8:e4:49

И двата МАК адреса са на CISCO.

И не че нещо ама този израз "WiFi Мрежата е изградена от AP-та разхвърляни из цеховете и управлявани от централен "контролер"" ме кара да си мисля, че сте се опитвали да изградите инфраструктура,а не сте разрешили WDS. А това е критично важно когато клиента асоциира от АП в АП. Виж WDS Bridge и roaming client. Но това все пак зависи от това как сте организирали нещата!

Друг вариант е контролера да не праща  disconnect команда при преминаване от зона в зона. Или broadlink-a да не я отразява...

Нямам си никаква идея какво е това WDS и как се готви. Но както казах, инфраструктурата е неприкосновена и няма как да бъде променяна. Във всеки случай, мобилните IP телефони на CISCO работят със същата WiFi мрежа и работят (почти) без проблеми. Това означава ли, че WDS е разрешено?

Ми на първо четене това излиза - http://askubuntu.com/questions/249566/wrong-mac-address-error-in-virtual-console Бъглив драйвер от броудком.

Това го открихме, но на тънките клиенти е инсталиран последната версия на драйвера. Просто няма с какво да ъпдейтваме.

Ето изхода на dmesg на един от клиентите, на който мрежата беше изчезнала изцяло и се възстанови чак след като рестартирахме компютъра. Може и да имаше начин да я пуснем без рестарт, но както казах моите способности са само като за 3-ка.

"Дисконета обикновено касае само едни от клиентите. Останалите си работят нормално през това време. Тоест мрежата си функционира."

Тоест имаме клиент Х който редовно  се дисконектва и в продължение на 20-30 мин не конектва към AP-to или все по един плачещ ?

Спомена при промяна на AP-to, това може ли да се потвърди на 100% ?
АP-те са абсолютно еднакви като хард софт?

В момента работят 6 клиента (планирани са около 60). Всеки от тях от време на време губи връзка. Не е много често и е в случаен момент от времето. Е, или не сме хванали някаква зависимост. Лично никой не е присъствал, а когато се дисконектне, няма как да го видим и дистанционно. Информацията е от логове.

Това, че се случва когато превключва AP-тата е информация от нашия IT отдел. Колко е достоверна не мога да кажа. Но хората там не са супер гении в Линукс и WiFi мрежи. Просто нормални IT специалисти – умерено квалифицирани (главно Win) и умерено мързеливи.

а може ли да споделиш и за какви разстояния става въпрос между точките за достъп? Както и какви прегради има по пътя. Това е МНОГО важно за безжичните мрежи. Да на говорим, че ако се ползва сравнително ефтин "домашен" хардуеър, то дори и на близки разстояния не може да се разчита за работа. Освен това, може би не е добър вариант да се ползва NetworkManager, ако го ползваш изобщо. Това е само още едно място, където нещо може да се обърка.

Трудно ми е да преценя точно разстоянията, но ние използваме вече съществуващата безжична мрежа и нямаме възможност да я променяме. Във всеки случай, в зоната в която са компютрите, телефоните работят ако не отлично, то много добре. Апаратурата е изцяло на CISCO и няма нищо общо с "домашна".

Ето какво ми връща iwconfig на една от машините:

Frequency: 5.22GHz; Bit Rate: 52Mb/s; Link Quality = 38/70; Signal level = -72dBm; Tx-power=200dBm

За по-горните. Сега проверих. N стандарта е изключен, както и power save режимите. WDS не е разрешен. NetworkManager няма инсталиран. Има някаква програма на HP: "hptc-network-mgr" от която се настройват мрежовите връзки.

@go_fire - Операционната система не дават да се сменя. Трябва да е както си е заводски от HP.

Предисторията е такава: В завода в който работя трябва да се изгради система за събиране на информация, която се състои от примерно 60 компютъра, работещи в полето, които изпращат информация до сървър, който от своя страна я изпраща до централната база данни. Всичко това работи по TCP и използва специфичен протокол.

За да опростим инсталацията на работните места, решихме да използваме WiFi за връзка на клиентите към мрежата. Иначе опроводяването на всички клиенти ще се получи много сложно и неудобно.

Обемите информация, които се обменят са нищожни.

Клиентите са "тънки клиенти" T520 на HP, работещи на силно орязан Линукс от семейството на Убунту.

Обаче възникна един много неприятен ефект – периодично, клиентите се дисконектват от мрежата и не могат да се конектнат в продължение на много дълго време – случва се и по 20..30 минути. Самият дисконект не е проблем – програмите са така написани, че данните да се буферират и не могат да се изгубят.

Дисконета обикновено касае само едни от клиентите. Останалите си работят нормално през това време. Тоест мрежата си функционира.

Обаче, времето за което не може да се възстанови връзката е наистина голямо, а докато няма връзка, работниците не получават обратна връзка, за това, че техните действия имат някакъв ефект. В резултат работят в дискомфорт и недоволство.

WiFi Мрежата е изградена от AP-та разхвърляни из цеховете и управлявани от централен "контролер" (каквото и да значи това). Настройките са спуснати от "горе" (от хора, които не са много компетентни в компютрите, но пък са истински арийци!) и отговарят на всички корпоративните политики, ентерпрайз идеологии и евроатлантически ценности. Там едва ли нещо може да бъде даже гледано накриво, камо ли променяно.

IT отдела разбира само от Windows и си обяснява всички проблеми с аргументи като – "несъвместимост" на хардуера (cisco vs HP), софтуера (Win vs Linux), драйверите за WiFi (щото Линукс) и др. под. Впрочем, според тях, пропадането на връзката ставала, когато клиента се прехвърля от едно AP на друго, поради някаква причина.

Моите знания и умения в сисадминството на Линукс системи са като за 3+.

Та въпросът ми е: Някакви идеи откъде да го започна? Каква  може да е причината за подобни проблеми? Ако не може да се оправи стабилността на мрежата (то не е и чак толкова нужно), може ли да се направи по-бързо да се възстановява връзката?

Както и да е. Мога ли да му кажа на сървъра да просто да листне съдържанието на директория?

Ако питаш за моите скриптове - то такава функционалност просто не съм писал, защото не ми е нужна.

Ако въобще за скрипт написан на асемблер - то да, разбира се, при това е сравнително просто. Използваш системните функции на Linux за да прочетеш директорията (sys_getdents) и след това формираш HTML кода както си искаш и го изпращаш на STDOUT-a (sys_write).

Има разбира се подробности но това е главното, просто трябва да имаш представа за CGI протокола (е, или FastCGI или SCGI, ако искаш да използваш тях).

Не зная, как извън упражнението, може да се хване някой да прави сайт на асемблер. По-скоро се чудя за причината за това. Асемблер се слага там, където трябва скорост на изпълнение. Сайта няма да ми зареди по-бързо, ако е направен на този език. В интернет, колко бързо ще ти зареди страницата важи почти само от преносната среда. Изключая разбира се сървъри, които обработват безумно много заявки в секунда.

Поправка. Приветствам работата ви. Сетих се, че това може чудесно да работи на платки от рода на Pi Ама кода на асемблер не беше ли пряко свързан с архитектурата? 

Асемблер се използва освен за скорост, още и заради ниското потребление на сървърни ресурси - памет и процесорно време. Да, времето за зареждане на всеки отделен потребител малко се влияе от времето за изпълнение на сървърния скрипт, но нещата стават съвсем различни, когато потребителите са много. Сървъра е винаги най-натоварената част на системата, просто защото той е един, а клиентите са много. В този случай, при хиляди връзки и бавен сървърен софтуер, влиянието върху всеки един потребител става много силно.

Погледнато от тази страна, примерно удвояването на производителността на сървърната част на софтуера означава, че едно и също натоварване ще се поеме от двойно по-малко сървъри. (А това са двойно по-ниски разходи, по-малко енергия, по-висока надеждност и т.н.)
Същото важи и за консумираната памет.

А на асемблер, икономията е далеч по-голяма от двойна. Не мога да сравнявам директно, ако вярвам на данните от провайдера, консумираната памет на работещ енджин AsmBB с един потребител е примерно 1.2MB. Примерно подобни скриптове на PHP консумират 20MB. Ако някой може да цитира консумацията на памет примерно на SMF (този форум) да не се окаже и доста по-висока, заради връзките към MySQL.

Аз не мога да провеждам много сериозни тестове, но когато тествах AsmBB (най-евтиния споделен хостинг) някои момчета от bgdev.org се отзоваха и го понатовариха доста с апачи бенча и чрез постване с ботове (преди да пусна защитата от ботове, сега вече не става), но така и не можаха да го съборят - сайта си обработваше заявките без проблеми.

Да, сайта е супер статичен и изглежда като изваден от 1995г. и ако трябва малко да пораздвижиш сайта - например с база данни отзад и/или търсачка не дай си боже количка за пазаруване, капчи, форми, контрол на версии етц. дето са базови за един сайт и т.н. ще стане много весело.
Като proof of concept е даже много интересно.

Това за кой сайт става въпрос??? Ако за AsmBB, то нещо не си догледал.Там си има база данни, търсачка и регистрация и обработка на потребителите с права и т.н. Нищо не пречи да се направи и количка за пазаруване, но нали се сещаш, че за форум просто не е нужно.

Чакай, как така СХ. Те дават само php/perl и май python. Или ти си си наел server, а не домуване?

Не е така. Има си и CGI и FastCGI. Не е нает сървър, а най-евтиния споделен - 5лв на месец, Супер-нещо-си-там. (на мене даже по-евтино ми излезе, защото издебнах промоция. )

Здрасти Джон,

Тъкмо онзи ден те споменах и ти взе, че се появи с много силно включване. Този договор за разпространение, който цитираш, май от ФСС го бяха яко оплюли. Ако е същият, ама мисля, че е той. Не ми се проверява сега, ама, ако искаш, ще проверя.

Ти твоята страница на нея ли си мигрирал? Гледам, че изглежда по-различно и коментарите са отстрани. Или просто си си човъркал собствената система.

Затова и избягах от Artistic лиценза. Преди 1..2 години реших да изчистя проблемните места и мигрирах към EUPL и стандартен BSD за където трябва.

Моята страница asm.info си е все още на MiniMagAsm, просто смених дизайна. Това е лесно - сменя се само шаблона за страниците и малко CSS файлове (сравни например със тази страница, която е със същия енджин, но с друг дизайн).

А новия енджин за който написах - AsmBB не е CMS, а е форум - там производителността и мащабируемостта са изключително важни, тъй като системата може да се ползва от много потребители не само за четене, но и за писане. Безопасността е на порядък по-добра, данните се пазят в ACID база данни (SQLite) и сървъра трябва да може да обработва голямо количество връзки едновременно.

Затова и там се използва FastCGI. (От който протокол, впрочем съм във възторг. Супер гъвкаво нещо и много удобен за поддържане именно на асемблер).

И моят сайт и демо инсталацията на форума се хостват на най-евтиния споделен хостинг на superhosting. Пиша го за да можете да оцените производителността.

Ето и една тема с 15000 поста, постнати от бот като тест. Може да се види, че времето за обработка на заявките е все още съвсем приемливо.

Може ли повече информация какво точно имаш в предвид под

съветвах да го пратиш за разглеждане от ФСС или ФСС Европа.

Постовете над последния ми пост са от 2013г. Въпросната забележка касае MiniMagAsm, която беше пусната под модифициран Artistic лиценз. Този лиценз наистина има известни несъобразности, но не са актуални, тъй като напоследък използвам главно стандартен EUPL, а с него не може да има проблеми, тъй като е разработван от купчина адвокати от ЕС.

И сега, няколко години по-късно можем да си продължим темата.

Тъй като закона на Мур вече не действа особено добре, цените за хостинг никой не смята да ги намалява, а изискванията към уеб приложенията нарастват, то въпросът с производителността на сървърния софтуер стои все още открит.

Програмирането на асемблер е една от алтернативите.

Първо, вече има пълноценен и много мощен уеб сървър написан на асемблер - rwasa, написан от един австралийски другар.

От моя страна, тъй като системата MiniMagAsm, описана по-горе, има някои проблеми с мащабируемостта и мрежовата производителност (заради използването на CGI интерфейс) реших да напиша фреймуърк който да работи през FastCGI.

Резултата от тази работа стана форум енджина AsmBB (демо инсталация), написан изцяло на асемблер и притежаващ прекрасна мащабируемост и много ниско потребление на ресурси. 

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

Кода разбира се е отворен: http://asm32.info/fossil/repo/asmbb и се разпространява под лиценза EUPL (GPL съвместим).

b2l - преди 30 години, такива разработки, като на zxz се правеха от 13..14 годишни деца. На неговата възраст, аз специално конструирах роботи и пишех компилатори. Така че, очевидно от мене може да се научи много. Това се отнася и до тебе - липсва ти известно възпитание, което би трябвало да промениш.