Изпечатай

[johnfound]

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

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

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

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

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

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

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

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

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

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

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

[runtime]

Да ти кажа честно без човек да е на място и да анализира ситуацията надали ще се намери отговор, но ще се опитам да те насоча поне според моята гледна точка:

1. На входните точки разрешена ли е WDS?
2. Всеизвестен факт е проблема на Ubuntu дериватите с Network Manager-a. Пробвай да рестартираш демона след като загуби връзка. Или да направиш настройката през конзолата и да го српеш.
3. Спри power мениджмънта на wifi като го блеклистнеш в config.d
4. Чувал съм и проблеми с N стандарта при някои мрежови контролери, за това, че може да пробваш и да го спреш и него на клиента. тук

Тези AP как са настроени? Възможно ли е да имат някакво правило, което да дропи клиенти с слаб сигнал? Или при определени условия?

За несъвместимости, които посочваш е абсурдно да се говори! Поне според мен

Добре е все пак и да извадиш някаква информация от системния лог след като се дропи връзката да видим какво се случва.

[deant01]

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

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

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

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

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

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

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

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

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

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

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

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

[go_fire]

Твоя проблем звучи, като идеалния кандидат за Elwix и вградения в него MQTT. Той точно за тази задача е правен и кипял в много битки. Е не е ГНУ/Линукс, но в случая е по-доброто решение.

[johnfound]

а може ли да споделиш и за какви разстояния става въпрос между точките за достъп? Както и какви прегради има по пътя. Това е МНОГО важно за безжичните мрежи. Да на говорим, че ако се ползва сравнително ефтин "домашен" хардуеър, то дори и на близки разстояния не може да се разчита за работа. Освен това, може би не е добър вариант да се ползва 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.

[runtime]

Дай dmesg да видим

Аз лично бих пуснал WDS.

[10101]

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

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

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

[johnfound]

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

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

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

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

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

[jet]

Сложи на един от тези набедени клиенти UPS. Може проблема да е в захранването. В индустриална среда има много смущения по захранването.

[Slevin_]

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

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

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

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

Предполагам, че се използва cisco wlan controler, който менажира точките за достъп.
Ако случаят е такъв, то във WLAN контролера при WLAN настройките му, има опция DHCP Required.
която принуждава клиентите да извършват DHCP request / renew, всеки път при асоцииране към AP, това покрива и случая с роуминга.
Тук обаче, някой wifi клиенти не се съобразяват с това(не е имплементиранa тази екстра)  докато не изтече lease time, като по този начин не се допуска трафик от и за тях.

Ако администраторите на  wlan controler изключат DHCP Required, то проблема би трябвало да се реши

Поздрави!

П.С. Това би се потвърдило и в текущата ситуация, при клиент който е изгубил връзката да  извършиш:

Код:

dhclient  -r wlan0
dhclient  wlan0

[growchie]

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

[johnfound]

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

[growchie]

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

[runtime]

Ммм даа... Пробвай да замениш драйвера 1-во. Вероятно е от него. Ако не се оправи има още една ситуация в която може да се получи това защото грешния МАК адрес в случая не е на интерфейса, а на профила и ме навява и на друга мисъл 

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 да не я отразява...

[johnfound]

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

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