ByFly. Обсуждение.

странно, это точно с 1.06.2010 (или с момента подключения в июне)? потому что раньше даже на ТП 600/512 и иже с ними тарифицировали в течение месяца и лишь в по окончании расчетного периода возвращали списанные средства за непревуалирующий трафик. это также может быть связано с http://www.onliner.by/news/11.06.2010/15.36

Alex-manutd:

странно, это точно с 1.06.2010 (или с момента подключения в июне)?

тэкс, а тут поподробнее. Я так понимаю, что мне выдается 6Гб на месяц, то есть 30 дней. То есть, я подключился 19 мая и 6 гигов мне до 19 июня? Так ведь? По крайней мере при подключении мне утверждали, что так.

Не так. С 19 мая по 31 мая - 6 Гб и с 01 июня по 30 июня 6Гб.

одни и те же вопросы.

скучно уже даже читать.

косяк видимо сайта какой-то, тоже зашел и нету

Dexterboom:

Вопрос, как выпросить модем с wifi?

А как ты просишь? интересно.

Хитрый БолТ:

Народ, отсутствие инета (минский р-н) связано с теми работами, которые будут "в ночь на понедельник"? Соединения платное и гостевое есть, но только трафик через них не идет. Началось вчера вечером - перестали пинговатся некоторые гостевые ресурсы (в частности ftp.mgts.by) а сегодня уже все умерло....

Во-первых похоже не только минский район, но и Витебская область. Во вторых проблема не с соединением, а с тем, что не работают DNS сервера (ftp.byfly.by тоже не работает). Поэтому в настройках платного соединения в свойствах TCP/IP вместо белорусских DNS напишите 8.8.8.8 и 8.8.4.4 - это гуглевские dns и выходите только через платное соединение - тогда все заработает.

P.S. Гостевое работать не будет, т.к. через него доступны только байфлаевские dns - а они не работают. если подключите гостевое и платное - то не будут работать гостевые ресурсы, т.к. роутинги на них прописаны через гостевое - а там днс не работает.

Не знаю кому как, а мне периодические разрывы PPPoE на byfly не дают покоя. Казалось бы, наличие исправной по всем характеристикам линии, отсутствие ошибок ADSL и рабочий модем не должны вызывать каких либо сбоев в работе PPPoE на byfly, но к сожалению, есть некие третьи, неведомые силы. Звонки в техподдержку и продолжительные беседы на тему "А почему?" ни к чему не привели. В принципе на текущий момент в моём, да и не только в моём, случае из разряда необъяснимых остаются беспричинные разрывы и невозможность подключиться после разрыва PPPoE соединения в течение 10 минут, т.к. якобы логин и пароль для подключения неверны. Последний глюк носит некий непостоянный характер и скорее редок, но периодически вылазит, т.е. после разрыва соединения можно подключиться чуть ли не сразу, а в некоторых случаях только через 10 минут. Эта ошибка явно связана с настройкой провайдерского оборудования и ПО. Скорее всего эта проблема провайдеру известна, но она периодически всплывает, а они её фиксят, а потом всё повторяется опять. Проблема похожа на зависание PPPoE сессии, которое провайдером фиксируется почему-то только через 10 минут, в то время как для проверки активности PPPoE соединения используется LCP протокол, который в случае БТК настроен на 5 секундные интервалы. PPPoE сервер БТК при активном соединении посылает т.н. Эхо запрос (Echo-Request), на что Ваш ПК (модем) посылает Эхо ответ (Echo-Reply), подтверждая свою работоспособность. В моём случае, ПК, настроеный в режиме бриджа, реагирует в течение 16 мс, исправно посылая Echo-Reply. Но, что самое интересное, разрыв, судя по отловленным пакетам LCP протокола с использованием снифера Microsoft Network Monitor 3.31641.0, инициируется БТК!

Приведу лог с параметром LCP в качестве фильтра пакетов (мой модем с затёртым нулями МАС адресом):

код выделить все

Frame Time offset Source Destination Description
151 375.140625 [00-30-48-93-7A-F1] [00-00-00-00-00-00] LCP:Echo-Request, ID = 248, Length = 8
152 375.140625 [00-00-00-00-00-00] [00-30-48-93-7A-F1] LCP:Echo-Reply, ID = 248, Length = 8
153 379.968750 [00-30-48-93-7A-F1] [00-00-00-00-00-00] LCP:Echo-Request, ID = 249, Length = 8
154 379.984375 [00-00-00-00-00-00] [00-30-48-93-7A-F1] LCP:Echo-Reply, ID = 249, Length = 8
155 385.000000 [00-30-48-93-7A-F1] [00-00-00-00-00-00] LCP:Echo-Request, ID = 250, Length = 8
156 385.015625 [00-00-00-00-00-00] [00-30-48-93-7A-F1] LCP:Echo-Reply, ID = 250, Length = 8
157 390.156250 [00-30-48-93-7A-F1] [00-00-00-00-00-00] LCP:Echo-Request, ID = 251, Length = 8
158 390.171875 [00-00-00-00-00-00] [00-30-48-93-7A-F1] LCP:Echo-Reply, ID = 251, Length = 8
159 395.031250 [00-30-48-93-7A-F1] [00-00-00-00-00-00] LCP:Terminate-Request, ID = 3, Length = 23 <------
160 395.046875 [00-00-00-00-00-00] [00-30-48-93-7A-F1] LCP:Terminate-Ack, ID = 3, Length = 23
161 397.000000 [00-30-48-93-7A-F1] [00-00-00-00-00-00] LCP:Configure-Request, ID = 1, Length = 19
162 397.000000 [00-00-00-00-00-00] [00-30-48-93-7A-F1] LCP:Configure-Request, ID = 0, Length = 17
163 397.015625 [00-00-00-00-00-00] [00-30-48-93-7A-F1] LCP:Configure-Ack, ID = 1, Length = 19
164 397.062500 [00-30-48-93-7A-F1] [00-00-00-00-00-00] LCP:Configure-Reject, ID = 0, Length = 7
165 397.078125 [00-00-00-00-00-00] [00-30-48-93-7A-F1] LCP:Configure-Request, ID = 1, Length = 14
166 397.125000 [00-30-48-93-7A-F1] [00-00-00-00-00-00] LCP:Configure-Ack, ID = 1, Length = 14
167 397.140625 [00-00-00-00-00-00] [00-30-48-93-7A-F1] LCP:Identification, ID = 2, Length = 18
168 397.140625 [00-00-00-00-00-00] [00-30-48-93-7A-F1] LCP:Identification, ID = 3, Length = 21
169 397.187500 [00-30-48-93-7A-F1] [00-00-00-00-00-00] LCP:Echo-Request, ID = 0, Length = 8
170 397.203125 [00-00-00-00-00-00] [00-30-48-93-7A-F1] LCP:Echo-Reply, ID = 0, Length = 8
171 397.343750 [00-30-48-93-7A-F1] [00-00-00-00-00-00] LCP:Protocol-Reject, ID = 2, Length = 16
172 402.187500 [00-30-48-93-7A-F1] [00-00-00-00-00-00] LCP:Echo-Request, ID = 1, Length = 8
173 402.203125 [00-00-00-00-00-00] [00-30-48-93-7A-F1] LCP:Echo-Reply, ID = 1, Length = 8

Особого внимания заслуживает фрейм 159, в детализации которого содержится строка Peer not responding. Таким образом PPPoE сервер БТК считает, что клиент не отвечает и иницирует разрыв сессии. Почему он так считает сложно сказать, такое явление в моём случае наблюдается при максимальной загрузке канала P2P трафиком и особенно при максимально нагруженном исходящем. Ограничение его нагрузки отсрочивает время разрыва. Разрывы не связаны с ограниченностью NAT таблицы в модеме при использовании его в режиме роута, т.к. в бридже на ПК также наблюдаются разрывы и даже чаще. Гостевое подключение не используется. Downstream и Upstream при подключении составляют 2688 и 671 kbps соответственно. Служебный трафик LCP и PPPoE является приоритетным и ему ничто не должно мешать. Может быть причина кроется в некой настройке оборудования БТК, которая проявляется при максимальной нагрузке на канал, может дело в их шейпере, может PPPoE сервер путает клиентов и рвёт не того? В общем можно гадать и гадать. А в БТК тем временем говорят, что у них всё ОК, и что я чуть ли не единственный с такой проблемой в некой группе абонентов на одном оборудовании. К слову, моя АТС 204.

Кстати, интересно скорость поднимут до Гомоседах с 1 июля ? Хотелось бы на Супергомике 4 мегабитика )))

Robmeister:

Кстати, интересно скорость поднимут до Гомоседах с 1 июля ? Хотелось бы на Супергомике 4 мегабитика )))

А в честь чего? Что за дата 1-го июля?

Уверен, что нет.

Тем более уже достоверно известно, что 1-го июля будут снижены цены для провайдеров.

Если и будут какие-то изменения для физ. лиц, то числа 15-го к юбилею БТК.

Не факт правда, что это коснется Домоседов.

Да и вообще. Не надоело фапать на 1-е число каждого месяца?

Может вам еще каждый понедельник цены снижать?

ipto, лично у меня никаких ассоциаций с интернетом по этому поводу не возникает.