#1
Posted 18 February 2019 — 03:06 PM
Hi there Commanders,
I am playing Zero hour true the ultimate collection by Origin.
I am getting the «waiting for probe response» problem again.
First, a friend and me tried it at my place and it didnt work.( with his laptop) On the same day the same friend tried it at home, no problem (with the same laptop)
So then I tried everything that Dominator suggested: https://www.gamerepl…news_id=1012910
So it worked for a couple of times, then it didnt worked, then i put out the FW of my router and Windows and DMZ and it worked for 2 games.
Now it doenst work at all; waiting for probe response is back 100 %
running Windows 10, using the ziggo connectbox by cable (router)
error log file:
«
«
—— C&C:Online Launcher Start ——
Game: Zero Hour
Zero Hour Install Path: C:Program Files (x86)Origin GamesCommand and Conquer Generals Zero HourCommand and Conquer Generals Zero Hour
Started game with: «generals.exe «C:Program Files (x86)Origin GamesCommand and Conquer Generals Zero HourGenerals.exe» «
Caught CREATE_PROCESS_DEBUG_EVENT from Zero Hour. Detaching…
ERROR: game.dat process not found.
—— C&C:Online Launcher Start ——
Game: Zero Hour
Zero Hour Install Path: C:Program Files (x86)Origin GamesCommand and Conquer Generals Zero HourCommand and Conquer Generals Zero Hour
Started game with: «generals.exe «C:Program Files (x86)Origin GamesCommand and Conquer Generals Zero HourGenerals.exe» «
Caught CREATE_PROCESS_DEBUG_EVENT from Zero Hour. Detaching…
ERROR: game.dat process not found.
«
Using server nntest.cnc-online.net:30000
Bound to local port 63250
Bound to local alternate port 63251
Resolving hostname ‘nntest.cnc-online.net’…
Resolved server host to be ‘37.247.49.213’
Sending client INIT from port 63250 to nntest.cnc-online.net:30000
Received server INIT [408718]
Our public address is 213.93.153.87:63250
Sending client INIT2 [408718] from port 63251 to nntest.cnc-online.net:30000
Received server INIT2 [408718]
Our alternate public address is 213.93.153.87:63251
Sending cient START [408718] from port 63251 to nntest.cnc-online.net:30000
Received server START [408718]
Server extra port is 40000
Sending client PING [408718] from port 63250 to nntest.cnc-online.net:40000
Received server PING(2) [408718]
Received server PING(3) [408718]
Received server PING(4) [408718]
===========
SUCCESS
===========
Received 3 pings from nntest.cnc-online.net:40000.
NAT negotiation works with your router and connection.
==> You do not have to use port forwarding.
Press any key to continue . . .
«
Please guys help me out, the only thing I am thinking of is to buy an another router.
I really want to kick some asses, esspecially the friend of mine because he is having quality time with you guys training.
Big Thanks in advance and looking forward to your comments,
THobieAss
- Quote
- MultiQuote
- Edit
- Report Abuse
- Back to top
#2
ToxicShock
ToxicShock
-
- Division Leaders
-
- 9,683 posts
Gamereplays.org Staff
- Location:London, England
- Projects:Shatabrick C&C Player Database
- I have blue text?
- Division:C&C:Online
- Job:C&C:Online Leader
Posted 19 February 2019 — 03:27 PM
What settings did you use to set up the DMZ (did you do it by the MAC address or your local IP address)?
- Back to top
#3
Thobieass
Posted 21 February 2019 — 05:41 PM
The IP adress, thanks for responding.
Just have played one game after setting off the FWs, then a second thrid and fourth game did not worked!
- Back to top
#4
Thobieass
Posted 26 February 2019 — 06:44 PM
Oké……
I just played 3 games in a row, then did the NAT and sen delay, then i was able to play again 3 games and now the same shit happens!
PLease does somebody has a solution????
- Back to top
#5
popoduff
Posted 26 February 2019 — 07:33 PM
I had this problem for sooooo long. What made it work for me was settings in windows firewall:
1) select advanced settings
2) select incoming rules (my win is not in english — you might have to interpret these steps to your win language)
there you find 2 listings named Command & Conquer Generals: Zero Hour and 2 listings named Generals. For all 4 listings individually you need to right-click each one and do these steps:
1) select Properties
2) select Advanced
3) Allow edge traversal in the drop-down menu
On router i have forwarded the ports zero hour use, firewall still up. Ingame options i have no port number in the firewall port override box, because it’s already fixed in router and windows firewall. This fixed the problem on my win7 and on my brothers win10.
Edited by popoduff, 26 February 2019 — 07:39 PM.
- Back to top
#6
Thobieass
Posted 28 February 2019 — 07:03 PM
I had this problem for sooooo long. What made it work for me was settings in windows firewall:
1) select advanced settings
2) select incoming rules (my win is not in english — you might have to interpret these steps to your win language)
there you find 2 listings named Command & Conquer Generals: Zero Hour and 2 listings named Generals. For all 4 listings individually you need to right-click each one and do these steps:
1) select Properties
2) select Advanced
3) Allow edge traversal in the drop-down menu
On router i have forwarded the ports zero hour use, firewall still up. Ingame options i have no port number in the firewall port override box, because it’s already fixed in router and windows firewall. This fixed the problem on my win7 and on my brothers win10.
You are the shit and the bomb Popoduff, Just had a little zip of the bong to celebrate 
thnx a lot
- Back to top
#7
Thobieass
Posted 01 March 2019 — 08:34 AM
Best Answer
This ia also a change that could had helped me out:
search : «services»
select: «UPnP Device Host»
properties
startintype : automatic
Attached Thumbnails
Edited by Thobieass, 01 March 2019 — 08:34 AM.
- Back to top
#8
fi.30
Posted 21 April 2020 — 11:58 AM
nothing helped me here, still same problem!
- Back to top
#9
fi.30
Posted 21 April 2020 — 12:01 PM
i dont get it if i already forwarded the ports in my router and firewall allows the 4 generals that i have..why it still disconnecting..i guess ill need to insert the ports in the advanced settings in firewall..altho i have it in options showing the port 29900 and everything looks fine…i used to play before once every 6 7 games, now i cannot play at all! very weird!
- Back to top
#10
fi.30
Posted 22 April 2020 — 09:20 PM
I had this problem for sooooo long. What made it work for me was settings in windows firewall:
1) select advanced settings
2) select incoming rules (my win is not in english — you might have to interpret these steps to your win language)
there you find 2 listings named Command & Conquer Generals: Zero Hour and 2 listings named Generals. For all 4 listings individually you need to right-click each one and do these steps:
1) select Properties
2) select Advanced
3) Allow edge traversal in the drop-down menu
On router i have forwarded the ports zero hour use, firewall still up. Ingame options i have no port number in the firewall port override box, because it’s already fixed in router and windows firewall. This fixed the problem on my win7 and on my brothers win10.
I did this too, still same problem! the override is not empty btw
- Back to top
I know it’s early (WIP), but I thought I’d mention that the program will only get an AP Probe Response if someone is joining the network. If the target is already associated to the AP, it needs to get deauthed before listening for a Probe Response.
You’re right, that’s why I have step 5 in main(), with deauth jamming on the real AP channel.
While jamming with deauth on real AP channel, my fake AP is beaconing continuously on fake channel so that the client sees it and probe requests it. But that is not working. Client keeps probe requesting the real AP on jammed channel. That’s the part I can’t figure out.
Maybe I shouldn’t wait for a probe request, and directly send probe responses on fake channel ? I’ll give it a try.
Answer is here : https://hackerone.com/reports/286740
The adversary uses Channel Switch Announcements to force victims into connecting to the cloned AP on channel 1.
I need to us CSA
Have to find the CSA struct. Maybe in hostapd repo ieee.h somewhere.
i see it need wlan1 and wlan0
I would like to ask waln0 is the external network card, then what is waln1?
think you very much!
You need two wifi cards that can be used in monitor mode. If you only have one, you need to purchase another one (awus036h for example). But this PoC is WIP, so not working for now.
I use a laptop, if I use a laptop with its own wireless network card and an external card, can you?
And my wireless network card is 8187
thank you very much
I saw you updated csa, then want to ask you, this poc can be achieved, use it to attack it,Or is it just a vulnerability verification
谢谢，那您的意思是现在这个poc是可以使用的，还是在完善之中?，我的英语很糟糕，请原谅
It’s not finished. It will be finished when I remove «WIP» tag from project name (see TODO list in the Readme)
Thank you very much, my leader wanted me to study this vulnerability, but I have absolutely no contact with this protocol, I prefer web security, but spent the day yesterday studying https://github.com/vanhoefm/krackattacks- Test-ap-ft in the tool, they found only poc, until encountered your project, I am pleased to meet you, if you can become friends
Succeeded to have a Key Reinstallation from the client, but it seems very unstable. Need to work out how to make it more accurate.
Does the target ap have to have csa enabled in order to get an ap probe response?
I’m not sure I got your question. Target AP doesn’t need to have anything enabled. Client has to understand CSA requests though.
ok im just trying to understand this better, so for the ap probe response to work correctly, someone needs to join the targets ap thats why there is a jammer. Could it be the jammer that doesnt kick everyone off the ap long enough for you to catch the response probe?
For example, i had a few cases where i couldnt get a handshake thru regular means like sending deauth to target ap with aireplay so i had to use mdk3 instead to capture a handshake. Im not sure why but i suspected it to be because of the anti-ap packet spoof feature.
Could it be the jammer that doesnt kick everyone off the ap long enough for you to catch the response probe?
I’m only kicking the targeted client, and it’s working, it’s just unstable, as I said before 😉
Unfortunately I don’t have much time to spend on this project. I’ll try to improve it later though
Hello,
Thank you for sharing. I saw that and it has plenty of useful information, but it’s neither implementing MitM not crypto attack.
Useful paper is channel-base MitM for those who wanna try to make this script work better.
Haha, this agreement is not very understand, I wish you an early completion of your exploit
I enforce it, an error occurred that «Could not retreive an AP Probe response“.What should I do next?
Is it possible to use the code for WPA-TKIP?
@Tomotaa : It might be necessary to force AP Probe Response with a manual deauth
@sergeyzapor : It is not the same thing, and TKIP is already vulnerable to some easier and well known vulnerabilities/attacks. An example here
@sergeyzapor The poc is Imperfect.So It’s hard to attack successfully.Also the
author did not update it.
Are there any plans to update this PoC to increase stability? Would be really great!
Are there any plans to update this? Last updating is long times ago~ I hope it can be finished,pls~
Hi, no i don’t have time to update it. But please feel free to do so !
I would like to ask if it is necessary to save AP Probe response.
Зарегистрирован: 01 янв 1970, 03:00
Сообщения: 909
Re: Проверка на стабильность канала
К сожалению, пока не могу убедиться ни в том, ни другом. А вот вы ещё писали:
Micha3d писал(а):
ICMP Echo Operation — операция посылки одного ICMP пакета
ICMP Jitter Operation — операция запуска серии ICMP пакетов
Это чисто логически или где-то явно написано?
И ещё:
Micha3d писал(а):
Timeout — максимальное время на выполнение операции (проверки), в нашем случае время которое роутер ждет пока придет ответ на icmp запрос
Видел в документации данное определение, но если timeout — «время которое роутер ждет пока придет ответ на icmp запрос», то что же такое threshold?!
Я для себя вынужден был объяснить два данных параметра так: threshold — время ожидания ответа на единичный пинг, timeout — длительность всей процедуры проверки.
И вот тут, чтобы это имело хоть какой-то смысл пингов должно быть несколько. Тогда получим общую длительность пингования в виде timeout, и предела ожидания ответа на каждый пинг в виде threshold.
Вы извините, что я настаиваю, но пока что-то не склеивается.
Black-Dragon
Зарегистрирован: 01 янв 1970, 03:00
Сообщения: 909
Re: Проверка на стабильность канала
Лучшее, что нашел, это:
Цитата:
Threshold sets the rising threshold that generates a reaction event and stores history information for an IP SLAs operation.
Threshold is used to activate a response to IP SLA violation, e.g. send SNMP trap or start seconday SLA operation.
Timeout is the maximum time required for SLA operation to complete
Timeout sets the amount of time an IP SLAs operation waits for a response from its request packet.
configure the sla based on:
Frequency > Timeout > Threshold.
Но так и не понял, по человечески, что такое threshold?
Black-Dragon
Зарегистрирован: 01 янв 1970, 03:00
Сообщения: 909
Re: Проверка на стабильность канала
Цитата:
Timeout is the maximum time required for SLA operation to complete — for example the timeout waiting for probe response.
Threshold is boundary value measured over the operation RESULT (e.g. RTT, or jitter value collected during the opearation). Crossing threshold usually means SLA contract violation. Note that these two values apply to DIFFERENT objects.
Timeout is directly used to restart the operation. Threshold is used to activate a response to IP SLA violation, e.g. send SNMP trap or start seconday SLA operation.
You should configure the sla based on Frequency > Timeout > Threshold.
Q. What does the term threshold and timeout in IP SLA operation mean?
A. Threshold sets the rising threshold that generates a reaction event and stores history information for an IP SLAs operation.
Timeout sets the amount of time an IP SLAs operation waits for a response from its request packet.
Example:
If you configure Timeout > Threshold, you can see the RTT and if the RTT exceed Threshold, it is a failure.
If you configure Threshold > Timeout, if the RTT exceed timeout but less than Threshold, it won’t show the RTT but it is still a failure.
So failure is RTT exceed either Timeout or Threshold.
Ну, наконец-то.
Threshold нужен нам для оценки «качества», он не связан с удалением маршрутов и т.п. Просто дополнительная функция, чтобы мы заодно знали, выполняет ли провайдер обязательства по качеству (типа максимально допустимые задержки пинга, величина джитера и т.п.).
Ок. С этим ясно. Но кто-нибудь может железно подтвердить, что каждые «Frequency» секунд запускается только один пинг (если пользуем IP SLA ICMP Echo Operations)?
Black-Dragon
Зарегистрирован: 01 янв 1970, 03:00
Сообщения: 909
Re: Проверка на стабильность канала
Micha3d
Положим пинг идет один за время, специфицированное параметром Frequency (надеюсь, так и есть). Вернемся к основным вопросам.
Если пинг один, то событием будет пропадание ровно одного пинга! И здесь всё станет однозначным.
Теперь по «delay down up».
Положим конфиг у нас таков:
Цитата:
track 10 ip sla 1 reachability
delay down 10 up 30
…
ip route 0.0.0.0 0.0.0.0 a1.b1.c1.d1 track 10
ip route 0.0.0.0 0.0.0.0 a2.b2.c2.d2 4
ip route 192.5.5.241 255.255.255.255 a1.b1.c1.d1 name To_RootDNS_ISP1-SLA
…
ip sla 1
icmp-echo 192.5.5.241 source-interface FastEthernet1
timeout 1000
threshold 300
frequency 1
ip sla schedule 1 life forever start-time now
Что дает «delay down 10»? Десять событий неполучения ответа подряд должны свершиться (=> 10 пингов подряд должны потеряться), чтобы маршрут удалился?
Если потеряются только 9 подряд, а 10-й пройдет то маршрут останется как был, а счетчик сбросится?
«delay up» 30, ни одного из 30 подряд событий неполучения ответа не должно случиться (=> 30 пингов подряд должны пройти), чтобы маршрут вернулся?
Можно ссылку на документ, где это нормальным языком написано. Уж больно хорошо всё получается. 
Кстати, спасибо за помощь! 
791
Зарегистрирован: 01 янв 1970, 03:00
Сообщения: 21
Re: Проверка на стабильность канала
Black-Dragon писал(а):
Можно ссылку на документ, где это нормальным языком написано. Уж больно хорошо всё получается.
http://www.cisco.com/en/US/docs/ios/ips … _echo.html
http://www.cisco.com/en/US/docs/ios/ipa … p_eot.html
frequency — однозначно частота проверки в секундах, так в документации и на практике у меня так работает )))
Кстати в первом своем посте я был не прав, прошу модераторов удалить мой первый пост.
Согласно документу Configuring Enhanced Object Tracking с сайта cisco.com
http://www.cisco.com/en/US/docs/ios/ipa … p_eot.html
1. track object-number ip sla operation-number state
IP SLA Return Code OK -> Track State Up
IP SLA Return Code (all other return codes) -> Track State Down
2. track object-number ip sla operation-number reachability
IP SLA Return Code OK or OverThreshold -> Track State Up
IP SLA Return Code (all other return codes) -> Track State Down
Black-Dragon
Зарегистрирован: 01 янв 1970, 03:00
Сообщения: 909
Re: Проверка на стабильность канала
Micha3d писал(а):
frequency — однозначно частота проверки в секундах, так в документации и на практике у меня так работает )))
Да я и не возражаю против секунд. Я не уверен в количестве пакетов. Скажем по ICMP Path Jitter я нашел, что по умолчанию посылается 20 пакетов. Хотя, тот факт, что по ICMP Echo ничего нигде не написано, свидетельствует о том, что там что-то очевидное и неизменяемое (для ICMP Path Jitter есть num-packets). А это 1.
Цитата:
IP SLA Return Code OK or OverThreshold -> Track State Up
Правильно ли я понимаю, что под OverThreshold подразумевается случай, когда ответ пришел до истечения времени timeout, но превысил значение threshold?
Также прошу однозначно ответить на вопросы из моего последнего поста по delay down up. Я понимаю, что ответ для вас очевиден, но хочу получить официальный ответ.
791
Зарегистрирован: 01 янв 1970, 03:00
Сообщения: 21
Re: Проверка на стабильность канала
Официальный ответ может дать только CISCO 
Все верно, OverThreshold подразумевается случай, когда ответ пришел до истечения времени timeout, но превысил значение threshold. Порог threshold видимо только для сбора статистики.
delay — задержка изменения состояния трэкинга (Track State)
Т.е. как только наступило событие для изменения состояния трэкинга включается счетчик по истечению которого состояние трэкинга изменится.
Если за время отсчета событие изменится на противоположное то ничего не произойдет и счетчик сбросится.
Или еще так — наступившее событие должно превысить задержку на изменение состояния трэкинга! Может так понятнее 
Black-Dragon
Зарегистрирован: 01 янв 1970, 03:00
Сообщения: 909
Re: Проверка на стабильность канала
Micha3d писал(а):
Или еще так — наступившее событие должно превысить задержку на изменение состояния трэкинга! Может так понятнее
Э-ээ, нет-нет, так мне вообще не понятно, уж лучше первый вариант (хотя и там не все полностью корректно, извиняюсь за буквоедство):
Micha3d писал(а):
как только наступило событие для изменения состояния трэкинга включается счетчик по истечению которого состояние трэкинга изменится.
Если за время отсчета событие изменится на противоположное то ничего не произойдет и счетчик сбросится.
Событий много (происходят каждый Frequency секунд и длятся не более timeout миллисек).
По первому варианту правильнее так:
Цитата:
измененное состояние трекинга, вызванное наступлением единичного события, должно сохраняться (благодаря целой череде эквивалентных с точки зрения значения трекинга событий) до истечения задержки, специфицированной параметром delay down (если сейчас состояние up) или delay up (если сейчас состояние down)
Состояние трекинга меняется сразу, оно просто не сообщается «куда надо» до истечения специфицированной нами задержки.
Цитата:
delay {up seconds [down seconds] | [up seconds] down seconds} — (Optional) Specifies a period of time (in seconds) to delay communicating state changes of a tracked object.
Спасибо.
Fedia
Супермодератор
Зарегистрирован: 01 окт 2008, 12:24
Сообщения: 4437
Re: Проверка на стабильность канала
..а Вы говорите «времени нет»!
Вот уже и разобрались Еще оформить — и публикация.
Это не сложно. Зато потом есть к чему вернуться и других отослать!
Black-Dragon
Зарегистрирован: 01 янв 1970, 03:00
Сообщения: 909
Re: Проверка на стабильность канала
Fedia писал(а):
Вот уже и разобрались Еще оформить — и публикация.Это не сложно. Зато потом есть к чему вернуться и других отослать!
Я себе всегда заметки делаю, такие, чтобы потом достаточно быстро разобраться. В ближайшие несколько дней постараюсь немного детализировать и пошлю вам.
Делать думаю так: формулировка задачи, потом решение, причем с объяснением решения.
Решать буду две (с половиной) задачи:
1. резервирование каналов, используя автопереключение методом IP SLA ICMP Echo Operations
1.5. Решение нюансов, связанных с NAT через разные интерфейсы и DNS серверами провайдеров (они ведь обязательно возникнут у читателей, лучше тут же расписать их решение)
2. Балансировка нагрузки с автоотключением нестабильнойнеисправной линии.
Просто идея прошла, ведь если не использовать Administrative distance или ещё что-то для изменения равноправности маршрутов, то будем иметь одновременную работу мпо двум каналам. В этом случае становится интересной автоматическое распознавание и отключение нестабильнойнеисправной линии и обратное включение. Тут просто надо SLA-ить оба маршрута.
Нормально?
Fedia
Супермодератор
Зарегистрирован: 01 окт 2008, 12:24
Сообщения: 4437
Re: Проверка на стабильность канала
Отлично!
Black-Dragon
Зарегистрирован: 01 янв 1970, 03:00
Сообщения: 909
Re: Проверка на стабильность канала
Fedia
По первой части написал, готово.
Когда стал писать по проблеме с DNS серверами (это когда по IP SLA канал переключается просто замечательно, но DNS запросы клиентов всё ещё отсылаются на DNS основного провайдера), осознал, что у меня самого не совсем правильно настроено.
Да, у меня прописаны статические маршруты до DNS серверов провайдеров. Но, насколько я понимаю есть такой нюанс:
— при недоступности самого провайдера, рутер будет сразу рапортовать о недоступности основной DNS и моя кеширующая DNS начнет опрашивать резервный DNS. — Ок.
— если же до провайдера соединение есть, а у него нет подключения к Интернет, тогда будут проблемы. Ведь DNS сервер основного прова будет доступен, но не сможет разрешать имена!
Я правильно понимаю?
В этой ситуации, Lomax советовал сделать IP SLA, по которому статические маршруты до DNS серверов основного провайдера будут уходить в Null 0. Вопрос, можно ли использовать тот же IP SLA track, что и для «переключения линий»?
Если да, то достаточно ли будет этого, как советовал Lomax:
Код:
ip route DNS1 255.255.255.255 GW1 track 10 name ISP1-DNS
ip route DNS1 255.255.255.255 Null 0 250
Т.е. просто при удалении основного маршрута по умолчанию, отправляем в небытие статический маршрут до DNS основного провайдера. (Что есть Null, сейчас пойду читать, пока не совсем понимаю, но сознаю, что нам не маршрут надо удалить, а сервер сделать недоступным).
Есть ещё варианты:
— использовать общедоступные DNS сервера (обязательно укажу)
— отключатьвключать интерфейс по EEM по той же IP SLA (IMHO, слишком усложняется, лучше по варианту Lomax).
Подсобите.
Fedia
Супермодератор
Зарегистрирован: 01 окт 2008, 12:24
Сообщения: 4437
Re: Проверка на стабильность канала
Зарегистрируйся в блогах, публикуй статью — первую половинку.
Про ДНС мне кажется либо городить систему проверки по нескольким ДНСам (или ресурсам) через обоих провайдеров и писать сложный ЕЕМ (типа, ДНС прова работает, а через этот канал ДНС глобальный — нет), либо посчитать вероятность такого сложного события ничтожной и в крайнем случае шатдаунить неугодный интерфейс вручную.
imperorr
Зарегистрирован: 01 янв 1970, 03:00
Сообщения: 4526
Re: Проверка на стабильность канала
Я не понимаю проблемы днс, можно же использовать корневые сервера?
Fedia
Супермодератор
Зарегистрирован: 01 окт 2008, 12:24
Сообщения: 4437
Re: Проверка на стабильность канала
Можно. Но по условию задачи требуется использовать провайдерские (где-то выше было написано)
А еще я разок чуть не убился, выискивая несуществующую ошибку в настройках, проверяя инет пингом 8.8.8.8, как обычно. Так вот, эта зараза пинговалась с ужасной задержкой и с потерями 60-80%… А весь остальной инет работал прекрасно, но пока я до этого допер, успел поволноваться
Black-Dragon
Зарегистрирован: 01 янв 1970, 03:00
Сообщения: 909
Re: Проверка на стабильность канала
По интерфейсу Null0 почитал.
IMHO, вариант Lomax вполне рабочий. Два стат маршрута, один в нул, но с большей Admin distance. Первый, нормальный, маршрут SLA-им и убираем по тому же событию, остается маршрут в нул, т.е. трафик дропается и получаем недостижимость сервера.
Fedia писал(а):
Зарегистрируйся в блогах, публикуй статью — первую половинку.
Сначала должен иметь на руках полное решение, а потом можно и порезать. Таков характер.
Fedia писал(а):
Про ДНС мне кажется либо городить систему проверки по нескольким ДНСам (или ресурсам) через обоих провайдеров и писать сложный ЕЕМ (типа, ДНС прова работает, а через этот канал ДНС глобальный — нет), либо посчитать вероятность такого сложного события ничтожной и в крайнем случае шатдаунить неугодный интерфейс вручную.
Кажется, вы меня не поняли. По какому событию убирать маршрут я определился давно — по пингу одного из корневых DNS серверов Интернета. У меня так и нормально работает.
Речь идет о том, что:
Black-Dragon писал(а):
по IP SLA канал переключается просто замечательно, но DNS запросы клиентов всё ещё отсылаются на DNS основного провайдера.
Так вот, задача в том, чтобы сделать основной DNS (т.е. DNS сервер основного провайдера) тоже недостижимым (на случай, если связь с провом есть, но вот у прова нет соединения с Интернет), и заставить DNS-резолвер в сети клиента ходить на вторичный DNS. Почитав по статмаршрутам на Null0, я пришел к выводу, что предложенный Lomax вариант, в данной ситуции, наиболее простой.
Весь вопрос у меня в том, можно ли использовать один и тот же IP SLA track для отслеживания и удаления сразу нескольких статических маршрутов? Сам никаких идеологических препятствияй не вижу.
P.S. BTW, если делать не удаление маршрутов, а шатдаун инетрфейса до основного прова (т.е. IP SLA ICMP Echo Ops + EEM), то проблема с DNS автоматом решается сама!
В связи с этим ещё один вопрос, если у нас есть настройки NAT для обоих провов, первым идет NAT для основного провайдера, и мы гасим физический интерфейс, NAT для второго прова заработает сам или все равно нужны соответствующие рут-мапы? 
imperorr
Зарегистрирован: 01 янв 1970, 03:00
Сообщения: 4526
Re: Проверка на стабильность канала
Так вроде нужна очистка NAT сессий?
Fedia
Супермодератор
Зарегистрирован: 01 окт 2008, 12:24
Сообщения: 4437
Re: Проверка на стабильность канала
Black-Dragon писал(а):
Весь вопрос у меня в том, можно ли использовать один и тот же IP SLA track для отслеживания и удаления сразу нескольких статических маршрутов? Сам никаких идеологических препятствияй не вижу.
Да, можно. И даже лучше.
Black-Dragon писал(а):
P.S. BTW, если делать не удаление маршрутов, а шатдаун инетрфейса до основного прова (т.е. IP SLA ICMP Echo Ops + EEM), то проблема с DNS автоматом решается сама!
В связи с этим ещё один вопрос, если у нас есть настройки NAT для обоих провов, первым идет NAT для основного провайдера, и мы гасим физический интерфейс, NAT для второго прова заработает сам или все равно нужны соответствующие рут-мапы?
Нет, не заработает. НАТ не привязан к состоянию интерфейса, особенно если он не в адрес интерфейса, а в пул адресов из подсети данного интерфейса.
НАТ в любом случае надо рисовать с рут-мапами.
Black-Dragon
Зарегистрирован: 01 янв 1970, 03:00
Сообщения: 909
Re: Проверка на стабильность канала
Fedia
Спасибо.
Постараюсь сегодня закончить.
Считаю, что неплохо бы сначала вам посмотреть, уже потом публиковать. Я пошлю вам на мейл вордовским файлом, обсудим и потом уже разместим. Ок?
Black-Dragon
Зарегистрирован: 01 янв 1970, 03:00
Сообщения: 909
Re: Проверка на стабильность канала
Fedia
Новая проблема, положим нам надо сделать так, чтобы всё работало, как я хочу:
Код:
ip route DNS1 255.255.255.255 GW1 track 10 name To Primary DNS
ip route DNS1 255.255.255.255 Null0 254 name To Make Primary DNS Dead
А что если ДНС сервер рутера находится в одной подсети с нами (соответствующим внешним интерфейсом рутера)? Его же прибить невозможно?! (Только отключив интерфейс).
Так или что-то можно сделать?
Ilya
Зарегистрирован: 20 окт 2009, 18:55
Сообщения: 962
Re: Проверка на стабильность канала
Black-Dragon писал(а):
Fedia
Новая проблема, положим нам надо сделать так, чтобы всё работало, как я хочу:
Код:
ip route DNS1 255.255.255.255 GW1 track 10 name To Primary DNS
ip route DNS1 255.255.255.255 Null0 254 name To Make Primary DNS Dead
А что если ДНС сервер рутера находится в одной подсети с нами (соответствующим внешним интерфейсом рутера)? Его же прибить невозможно?! (Только отключив интерфейс).
Так или что-то можно сделать?
маршрут /32
Black-Dragon
Зарегистрирован: 01 янв 1970, 03:00
Сообщения: 909
Re: Проверка на стабильность канала
Если я правильно вас понял, то у меня такой и прописан:
Цитата:
ip route DNS1 255.255.255.255 GW1 track 10 name To Primary DNSip
Т.е. это будет работать по-любому?
Или в этом случае надо чуток поменять (вместо шлюза провайдера свой интерфейс):
Цитата:
ip route DNS1 255.255.255.255 FastEthernet1 track 10 name To Primary DNSip
Lomax
Зарегистрирован: 01 янв 1970, 03:00
Сообщения: 1834
Re: Проверка на стабильность канала
Нееееет!!!!! Маршрутизация в Ethernet приводит меня в ярость и я хочу кого то убить
Никогда больше так не делайте
Ilya
Зарегистрирован: 20 окт 2009, 18:55
Сообщения: 962
Re: Проверка на стабильность канала
каюсь, ответ скорее всего пойдет напрямую… но это редкость.
Black-Dragon
Зарегистрирован: 01 янв 1970, 03:00
Сообщения: 909
Re: Проверка на стабильность канала
Lomax
Я уже догадываюсь почему — ARP!
Однако, тут конкретный маршрут, на один единственный хост, а не дефолт-рут через интерфейс.
Кстати, а если писать маршрут указав и интерфейс, и ip адрес шлюза, тогда ведь мы обеспечим протекание трафика только через данный интерфейс, но избежим проблемы с ARP!? Так или нет?
Ilya писал(а):
каюсь, ответ скорее всего пойдет напрямую… но это редкость.
А нельзя ли чего-либо придумать?
Задача вкратце такова: есть хост в той же подсети, что и внешний интерфейс рутера, мы хотим по какому-либо событию сделать именно и только данный хост недостижимым. Как это можно сделать?
Hello,
I’m using DSL internet. Few days ago I started using router Sagemcom fast 2704 and connect my laptop via wifi (I used usb adsl-modem before). All seemed alright. But than I realize that something is wrong with something.
I started suspect wifi linux driver as cause of trouble but now I’m not so sure about it.
My problem: when I am connected to hidden wifi AP from time to time (irregular) my connection is dropped.
I didn’t now what’s wrong before I checked logs. This is what I saw:
Code: Select all
Feb 27 13:38:48 hpcompaq-6720s kernel: [ 51.361177] wlan0: authenticated
Feb 27 13:38:48 hpcompaq-6720s kernel: [ 51.364076] wlan0: associate with <mac address> (try 1/3)
Feb 27 13:38:48 hpcompaq-6720s kernel: [ 51.368619] wlan0: RX AssocResp from <mac address> (capab=0x411 status=0 aid=1)
Feb 27 13:38:48 hpcompaq-6720s kernel: [ 51.370115] wlan0: associated
Feb 27 13:38:48 hpcompaq-6720s kernel: [ 51.370158] IPv6: ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
Feb 27 13:39:23 hpcompaq-6720s kernel: [ 86.028079] hda-intel: IRQ timing workaround is activated for card #0. Suggest a bigger bdl_pos_adj.
Feb 27 13:41:01 hpcompaq-6720s kernel: [ 183.575165] ISO 9660 Extensions: Microsoft Joliet Level 3
Feb 27 13:41:01 hpcompaq-6720s kernel: [ 183.585556] ISO 9660 Extensions: RRIP_1991A
Feb 27 13:44:59 hpcompaq-6720s kernel: [ 421.613096] perf samples too long (2504 > 2500), lowering kernel.perf_event_max_sample_rate to 50000
Feb 27 13:48:09 hpcompaq-6720s kernel: [ 612.340047] ieee80211 phy0: wlan0: No probe response from AP <mac address> after 500ms, disconnecting.
Feb 27 13:48:09 hpcompaq-6720s kernel: [ 612.408739] cfg80211: Calling CRDA to update world regulatory domain
Feb 27 13:48:09 hpcompaq-6720s kernel: [ 612.532703] cfg80211: World regulatory domain updated:
Feb 27 13:48:09 hpcompaq-6720s kernel: [ 612.532711] cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
Feb 27 13:48:09 hpcompaq-6720s kernel: [ 612.532716] cfg80211: (2402000 KHz - 2472000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
Feb 27 13:48:09 hpcompaq-6720s kernel: [ 612.532720] cfg80211: (2457000 KHz - 2482000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
Feb 27 13:48:09 hpcompaq-6720s kernel: [ 612.532725] cfg80211: (2474000 KHz - 2494000 KHz @ 20000 KHz), (300 mBi, 2000 mBm)
Feb 27 13:48:09 hpcompaq-6720s kernel: [ 612.532729] cfg80211: (5170000 KHz - 5250000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
Feb 27 13:48:09 hpcompaq-6720s kernel: [ 612.532733] cfg80211: (5735000 KHz - 5835000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
Feb 27 13:48:13 hpcompaq-6720s kernel: [ 615.609070] wlan0: authenticate with <mac address>
Feb 27 13:48:13 hpcompaq-6720s kernel: [ 615.610892] wlan0: send auth to <mac address> (try 1/3)
Feb 27 13:48:13 hpcompaq-6720s kernel: [ 615.693783] wlan0: authenticated
Feb 27 13:48:13 hpcompaq-6720s kernel: [ 615.696133] wlan0: associate with <mac address> (try 1/3)
Feb 27 13:48:13 hpcompaq-6720s kernel: [ 615.810408] wlan0: RX AssocResp from <mac address> (capab=0x411 status=0 aid=1)
Feb 27 13:48:13 hpcompaq-6720s kernel: [ 615.812696] wlan0: associated
Feb 27 13:50:09 hpcompaq-6720s kernel: [ 732.404117] ieee80211 phy0: wlan0: No probe response from AP <mac address> after 500ms, disconnecting.
Feb 27 13:50:09 hpcompaq-6720s kernel: [ 732.449732] cfg80211: Calling CRDA to update world regulatory domain
Feb 27 13:50:09 hpcompaq-6720s kernel: [ 732.531205] cfg80211: World regulatory domain updated:
Feb 27 13:50:09 hpcompaq-6720s kernel: [ 732.531215] cfg80211: (start_freq - end_freq @ bandwidth), (max_antenna_gain, max_eirp)
Feb 27 13:50:09 hpcompaq-6720s kernel: [ 732.531222] cfg80211: (2402000 KHz - 2472000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
Feb 27 13:50:09 hpcompaq-6720s kernel: [ 732.531228] cfg80211: (2457000 KHz - 2482000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
Feb 27 13:50:09 hpcompaq-6720s kernel: [ 732.531234] cfg80211: (2474000 KHz - 2494000 KHz @ 20000 KHz), (300 mBi, 2000 mBm)
Feb 27 13:50:09 hpcompaq-6720s kernel: [ 732.531239] cfg80211: (5170000 KHz - 5250000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
Feb 27 13:50:09 hpcompaq-6720s kernel: [ 732.531244] cfg80211: (5735000 KHz - 5835000 KHz @ 40000 KHz), (300 mBi, 2000 mBm)
Feb 27 13:50:10 hpcompaq-6720s kernel: [ 733.225501] iwl3945 0000:10:00.0: Microcode SW error detected. Restarting 0x82000008.
Feb 27 13:50:10 hpcompaq-6720s kernel: [ 733.225523] iwl3945 0000:10:00.0: Loaded firmware version: 15.32.2.9
Feb 27 13:50:10 hpcompaq-6720s kernel: [ 733.225561] iwl3945 0000:10:00.0: Start IWL Error Log Dump:
Feb 27 13:50:10 hpcompaq-6720s kernel: [ 733.225568] iwl3945 0000:10:00.0: Status: 0x000202E4, count: 1
Feb 27 13:50:10 hpcompaq-6720s kernel: [ 733.225574] iwl3945 0000:10:00.0: Desc Time asrtPC blink2 ilink1 nmiPC Line
Feb 27 13:50:10 hpcompaq-6720s kernel: [ 733.225812] iwl3945 0000:10:00.0: SYSASSERT (0x5) 0000052787 0x008B6 0x0035E 0x00320 0x00000 267
Feb 27 13:50:10 hpcompaq-6720s kernel: [ 733.225812]
Feb 27 13:50:10 hpcompaq-6720s kernel: [ 733.225831] iwl3945 0000:10:00.0: Error Reply type 0x00000001 cmd UNKNOWN (0x40) seq 0x0000 ser 0x00400000
Feb 27 13:50:10 hpcompaq-6720s kernel: [ 733.227646] iwl3945 0000:10:00.0: Can't stop Rx DMA.
Feb 27 13:50:10 hpcompaq-6720s kernel: [ 733.227937] ieee80211 phy0: Hardware restart was requested
Feb 27 13:50:10 hpcompaq-6720s kernel: [ 733.312247] wlan0: authenticate with <mac address>
Feb 27 13:50:10 hpcompaq-6720s kernel: [ 733.312298] wlan0: send auth to <mac address> (try 1/3)
Feb 27 13:50:10 hpcompaq-6720s kernel: [ 733.320744] wlan0: authenticated
Feb 27 13:50:10 hpcompaq-6720s kernel: [ 733.324115] wlan0: associate with <mac address> (try 1/3)
Feb 27 13:50:10 hpcompaq-6720s kernel: [ 733.528087] wlan0: associate with <mac address> (try 2/3)
Feb 27 13:50:11 hpcompaq-6720s kernel: [ 733.732079] wlan0: associate with <mac address> (try 3/3)
Feb 27 13:50:11 hpcompaq-6720s kernel: [ 733.792083] iwl3945 0000:10:00.0: Queue 0 stuck for 433792 ms.
Feb 27 13:50:11 hpcompaq-6720s kernel: [ 733.792095] iwl3945 0000:10:00.0: On demand firmware reload
Feb 27 13:50:11 hpcompaq-6720s kernel: [ 733.792503] ieee80211 phy0: Hardware restart was requested
Feb 27 13:50:11 hpcompaq-6720s kernel: [ 733.936093] wlan0: association with <mac address> timed out
Feb 27 13:50:14 hpcompaq-6720s kernel: [ 737.169093] wlan0: authenticate with <mac address>
Feb 27 13:50:14 hpcompaq-6720s kernel: [ 737.174526] wlan0: send auth to <mac address> (try 1/3)
Feb 27 13:50:14 hpcompaq-6720s kernel: [ 737.376067] wlan0: send auth to <mac address> (try 2/3)
Feb 27 13:50:15 hpcompaq-6720s kernel: [ 737.580099] wlan0: send auth to <mac address> (try 3/3)
Feb 27 13:50:15 hpcompaq-6720s kernel: [ 737.649202] wlan0: authenticated
Feb 27 13:50:15 hpcompaq-6720s kernel: [ 737.652108] wlan0: associate with <mac address> (try 1/3)
Feb 27 13:50:15 hpcompaq-6720s kernel: [ 737.662002] wlan0: RX AssocResp from <mac address> (capab=0x411 status=0 aid=1)
Feb 27 13:50:15 hpcompaq-6720s kernel: [ 737.665999] wlan0: associated
I google internet by looking how to solve problem but all information which I found not helped. I tried to use parameters to modules driver (iwl3945, mac80211) — not helped. I tried to use ndiswrapper — no luck with found and start working Windows XP driver.
I even tried ‘solution’ from this post http://forums.linuxmint.com/viewtopic.p … 45#p793436 but I think that if that works on Mint 16 it doesn’t work on LMDE because when the driver iwl3945 is loading all dependency modules are loads too (if I correct read modinfo).
So I started thinking that maybe it’s a problem with kernel.
I boot up LiveCD Mint 13. Disconnection didn’t happend for an hour. Only this messages shows up on kern.log many times:
Code: Select all
Feb 27 11:29:40 mint kernel: [ 409.368754] wlan0: associated
Feb 27 11:29:40 mint kernel: [ 409.371285] ADDRCONF(NETDEV_CHANGE): wlan0: link becomes ready
Feb 27 12:03:22 mint kernel: [ 2431.606216] iwl3945 0000:10:00.0: Microcode SW error detected. Restarting 0x82000008.
Feb 27 12:03:22 mint kernel: [ 2431.606228] iwl3945 0000:10:00.0: Loaded firmware version: 15.32.2.9
Feb 27 12:03:22 mint kernel: [ 2431.606268] iwl3945 0000:10:00.0: Start IWL Error Log Dump:
Feb 27 12:03:22 mint kernel: [ 2431.606275] iwl3945 0000:10:00.0: Status: 0x000202E4, count: 1
Feb 27 12:03:22 mint kernel: [ 2431.606281] iwl3945 0000:10:00.0: Desc Time asrtPC blink2 ilink1 nmiPC Line
Feb 27 12:03:22 mint kernel: [ 2431.606519] iwl3945 0000:10:00.0: SYSASSERT (0x5) 0000058227 0x008B6 0x0035E 0x00320 0x00000 267
Feb 27 12:03:22 mint kernel: [ 2431.606522]
Feb 27 12:03:22 mint kernel: [ 2431.606539] iwl3945 0000:10:00.0: Error Reply type 0x00000001 cmd UNKNOWN (0x88) seq 0x0034 ser 0x00880000
Feb 27 12:03:22 mint kernel: [ 2431.611191] iwl3945 0000:10:00.0: Can't stop Rx DMA.
Feb 27 12:03:22 mint kernel: [ 2431.611279] ieee80211 phy0: Hardware restart was requested
Feb 27 12:05:25 mint kernel: [ 2553.694943] iwl3945 0000:10:00.0: Microcode SW error detected. Restarting 0x82000008.
Feb 27 12:05:25 mint kernel: [ 2553.694958] iwl3945 0000:10:00.0: Loaded firmware version: 15.32.2.9
Feb 27 12:05:25 mint kernel: [ 2553.694998] iwl3945 0000:10:00.0: Start IWL Error Log Dump:
Feb 27 12:05:25 mint kernel: [ 2553.695005] iwl3945 0000:10:00.0: Status: 0x000202E4, count: 1
Feb 27 12:05:25 mint kernel: [ 2553.695012] iwl3945 0000:10:00.0: Desc Time asrtPC blink2 ilink1 nmiPC Line
Feb 27 12:05:25 mint kernel: [ 2553.695250] iwl3945 0000:10:00.0: SYSASSERT (0x5) 0000209643 0x008B6 0x00274 0x0031C 0x04EA2 116
Feb 27 12:05:25 mint kernel: [ 2553.695253]
Feb 27 12:05:25 mint kernel: [ 2553.695289] iwl3945 0000:10:00.0: Error Reply type 0x00000005 cmd REPLY_TX (0x1C) seq 0x025D ser 0x00740000
Feb 27 12:05:25 mint kernel: [ 2554.192089] iwl3945 0000:10:00.0: Error sending REPLY_RATE_SCALE: time out after 500ms.
Feb 27 12:05:25 mint kernel: [ 2554.192102] iwl3945 0000:10:00.0: Error setting HW rate table: FFFFFF92
Feb 27 12:05:25 mint kernel: [ 2554.200570] iwl3945 0000:10:00.0: Can't stop Rx DMA.
Feb 27 12:05:25 mint kernel: [ 2554.200841] ieee80211 phy0: Hardware restart was requested
Feb 27 12:33:21 mint kernel: [ 4230.424625] iwl3945 0000:10:00.0: Microcode SW error detected. Restarting 0x82000008.
Feb 27 12:33:21 mint kernel: [ 4230.424633] iwl3945 0000:10:00.0: Loaded firmware version: 15.32.2.9
Feb 27 12:33:21 mint kernel: [ 4230.424668] iwl3945 0000:10:00.0: Start IWL Error Log Dump:
Feb 27 12:33:21 mint kernel: [ 4230.424673] iwl3945 0000:10:00.0: Status: 0x000202E4, count: 1
Feb 27 12:33:21 mint kernel: [ 4230.424676] iwl3945 0000:10:00.0: Desc Time asrtPC blink2 ilink1 nmiPC Line
Feb 27 12:33:21 mint kernel: [ 4230.424909] iwl3945 0000:10:00.0: SYSASSERT (0x5) 0000010684 0x008B6 0x0035E 0x00320 0x00000 267
Feb 27 12:33:21 mint kernel: [ 4230.424911]
Feb 27 12:33:21 mint kernel: [ 4230.424925] iwl3945 0000:10:00.0: Error Reply type 0x00000001 cmd UNKNOWN (0x88) seq 0x0034 ser 0x00880000
Feb 27 12:33:21 mint kernel: [ 4230.429339] iwl3945 0000:10:00.0: Can't stop Rx DMA.
Feb 27 12:33:21 mint kernel: [ 4230.429437] ieee80211 phy0: Hardware restart was requested
I even tried on SolusOS LiveCD. The same. Wifi works except the messages same as above from Mint 13. But disconnection from AP did not take place.
On Mint 13 from LiveCD kernel is:
Code: Select all
uname -a
Linux mint 3.2.0-23-generic #36-Ubuntu SMP Tue Apr 10 20:41:14 UTC 2012 i686 i686 i386 GNU/Linux
I’m trying find solutions or workaround for 2 days now.
Any working solutions would be appreciated.
Thank You.
My installed System information:
Code: Select all
uname -r -v
3.11-2-686-pae #1 SMP Debian 3.11.8-1 (2013-11-13)
lsb_release -a
No LSB modules are available.
Distributor ID: LinuxMint
Description: LMDE MATE Edition
Release: 1
Codename: debian
inxi -CNnMxz
Machine: System: Hewlett-Packard product: HP Compaq 6720s version: F.0D
Mobo: Hewlett-Packard model: 30D8 version: KBC Version 83.0E
Bios: Hewlett-Packard version: 68MDU Ver. F.0D date: 11/04/2008
CPU: Dual core Intel Pentium Dual CPU T2310 (-MCP-) cache: 1024 KB flags: (lm nx pae sse sse2 sse3 ssse3) bmips: 5852.06
Clock Speeds: 1: 1467.00 MHz 2: 800.00 MHz
Network: Card-1: Intel PRO/Wireless 3945ABG [Golan] Network Connection driver: iwl3945 ver: in-tree:s bus-ID: 10:00.0
IF: wlan0 state: up mac: <filter>
Card-2: Intel 82562GT 10/100 Network Connection driver: e1000e ver: 2.3.2-k port: 4020 bus-ID: 00:19.0
IF: eth0 state: down mac: <filter>
Last edited by LockBot on Wed Dec 28, 2022 7:16 am, edited 1 time in total.
Reason: Topic automatically closed 6 months after creation. New replies are no longer allowed.