Долго грузятся странички в любом браузере

aivs	# 11 лет, 1 месяц назад
Темы: 62 Сообщения: 261 Участник с: 31 октября 2006	Видимо после какого то из апдейтов возникла проблема, в любом браузере долго грузятся странички, прежде чем пойдет загрузка проходит несколько секунд, постоянно. ping тоже думает, но ответ не более 7 мс, pacman тоже думает, все сетевыве приложения сначало долго думают, и только потом начинают работать, скорость скачивания нормальная. Рядом стоит тоже арчевский компьютер, но его я редко обновляю и там все ок, макбук подключенный к тому же роутеру по wifi так же мгновенно открывает страницы. На больном компе в /etc/resolv.conf тоже самое что и на маке и на соседнем арче. Подскажите куда копать?

# 11 лет, 1 месяц назад

Сообщения: 261

Участник с: 31 октября 2006

Видимо после какого то из апдейтов возникла проблема, в любом браузере долго грузятся странички, прежде чем пойдет загрузка проходит несколько секунд, постоянно.
ping тоже думает, но ответ не более 7 мс, pacman тоже думает, все сетевыве приложения сначало долго думают, и только потом начинают работать, скорость скачивания нормальная.
Рядом стоит тоже арчевский компьютер, но его я редко обновляю и там все ок, макбук подключенный к тому же роутеру по wifi так же мгновенно открывает страницы.
На больном компе в /etc/resolv.conf тоже самое что и на маке и на соседнем арче.
Подскажите куда копать?

aivs	# 11 лет, 1 месяц назад
Темы: 62 Сообщения: 261 Участник с: 31 октября 2006	Еще что странно на больной машине вывод ifconfig такой: [[email protected] rc.d]# ifconfig eth0 Link encap:Ethernet HWaddr 1C:6F:65:91:B6:8D inet addr:10.0.5.137 Bcast:10.0.5.255 Mask:255.255.255.0 inet6 addr: fe80::1e6f:65ff:fe91:b68d/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:530829 errors:0 dropped:1212 overruns:0 frame:0 TX packets:479385 errors:0 dropped:1 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:392465264 (374.2 Mb) TX bytes:60603997 (57.7 Mb) Interrupt:41 Base address:0xc000 А на соседней машине [[email protected] ~]# ifconfig eth0 Link encap:Ethernet HWaddr 90:E6:BA:AA:AD:EB inet addr:192.168.1.100 Bcast:192.168.1.255 Mask:255.255.255.0 inet6 addr: fe80::92e6:baff:feaa:adeb/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 RX packets:26278 errors:0 dropped:179 overruns:0 frame:0 TX packets:9404 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:9009758 (8.5 Mb) TX bytes:1091815 (1.0 Mb) Interrupt:21 Base address:0x4000 Почему у втрой машины правильный ip 192.168.1.100, а у другой 10.0.5.137, это внешний адрес, хотя должен быть 192.168.1.101 и если постучаться на 192.168.1.101 то зайти на него можно.

aivs

# 11 лет, 1 месяц назад

Темы: 62

Сообщения: 261

Участник с: 31 октября 2006

Еще что странно на больной машине вывод ifconfig такой:

[[email protected] rc.d]# ifconfig 
eth0      Link encap:Ethernet  HWaddr 1C:6F:65:91:B6:8D  
          inet addr:10.0.5.137  Bcast:10.0.5.255  Mask:255.255.255.0
          inet6 addr: fe80::1e6f:65ff:fe91:b68d/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:530829 errors:0 dropped:1212 overruns:0 frame:0
          TX packets:479385 errors:0 dropped:1 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:392465264 (374.2 Mb)  TX bytes:60603997 (57.7 Mb)
          Interrupt:41 Base address:0xc000

А на соседней машине

[[email protected] ~]# ifconfig 
eth0      Link encap:Ethernet  HWaddr 90:E6:BA:AA:AD:EB  
          inet addr:192.168.1.100  Bcast:192.168.1.255  Mask:255.255.255.0
          inet6 addr: fe80::92e6:baff:feaa:adeb/64 Scope:Link
          UP BROADCAST RUNNING MULTICAST  MTU:1500  Metric:1
          RX packets:26278 errors:0 dropped:179 overruns:0 frame:0
          TX packets:9404 errors:0 dropped:0 overruns:0 carrier:0
          collisions:0 txqueuelen:1000 
          RX bytes:9009758 (8.5 Mb)  TX bytes:1091815 (1.0 Mb)
          Interrupt:21 Base address:0x4000

Почему у втрой машины правильный ip 192.168.1.100, а у другой 10.0.5.137, это внешний адрес, хотя должен быть 192.168.1.101 и если постучаться на 192.168.1.101 то зайти на него можно.

Natrio	# 11 лет, 1 месяц назад
Темы: 47 Сообщения: 4763 Участник с: 08 января 2011	У меня было недавно нечто подобное. Как показало расследование, арч-пакет с pppd содержал скрипт, который принудительно и без разрешения переписывал мой /etc/resolv.conf , и вместо моего локального DNS там оказывались 2 DNS провайдера, первый из которых не отвечал, и потому при любом запросе на разрешение адресов сначала около секунды ожидался ответ от первого, а потом шел запрос ко второму. Пришлось нейтрализовывать подлянку мэйнтейнеров пакета ppp, после чего всё нормализовалось. Поэтому имеет смысл проверить пинг по айпи (без DNS), и отзывчивость ваших DNS путём прямого обращения к каждому из них по-отдельности. Это делается командой dig @ай.пи.dns.сервера домен Команда dig содержится в пакете dnsutils . P.S. На счёт странных IP – проверяйте, не включено ли у вас получение адреса по DHCP. Адреса интерфейсов достоверно можно узнать только командой ip address (или короче ip ad). ifconfig показывает вам НЕ ВСЁ, он не видит дополнительные IP-адреса, если им не присвоены т.н. “алиасы”, вроде eth0:1 и т.д.

Natrio

# 11 лет, 1 месяц назад

Темы: 47

Сообщения: 4763

Участник с: 08 января 2011

У меня было недавно нечто подобное. Как показало расследование, арч-пакет с pppd содержал скрипт, который принудительно и без разрешения переписывал мой /etc/resolv.conf , и вместо моего локального DNS там оказывались 2 DNS провайдера, первый из которых не отвечал, и потому при любом запросе на разрешение адресов сначала около секунды ожидался ответ от первого, а потом шел запрос ко второму.

Пришлось нейтрализовывать подлянку мэйнтейнеров пакета ppp, после чего всё нормализовалось.

Поэтому имеет смысл проверить пинг по айпи (без DNS), и отзывчивость ваших DNS путём прямого обращения к каждому из них по-отдельности.
Это делается командой dig @ай.пи.dns.сервера домен
Команда dig содержится в пакете dnsutils .

P.S.
На счёт странных IP – проверяйте, не включено ли у вас получение адреса по DHCP.
Адреса интерфейсов достоверно можно узнать только командой ip address (или короче ip ad).
ifconfig показывает вам НЕ ВСЁ, он не видит дополнительные IP-адреса, если им не присвоены т.н. “алиасы”, вроде eth0:1 и т.д.

aivs	# 11 лет, 1 месяц назад
Темы: 62 Сообщения: 261 Участник с: 31 октября 2006	У меня по dhcp все устройства получают ip, сейчас поправил /etc/rc.conf, чтобы использовать статический ip, /etc/resolv.conf оставил без изменений, все полетело, но это не решение проблемы, все таки хочется знать почему такое произошло.

Natrio	# 11 лет, 1 месяц назад
Темы: 47 Сообщения: 4763 Участник с: 08 января 2011	Насколько видно из дампов ifconfig, он считал основным IP именно тот, неправильный, с подсетью, изолированной от вашей настоящей подсети. Ваш правильный айпи тоже присутствовал, но как второй и невидимый для ifconfig. Если хотите узнать – верните всё как было, перезагрузите, и проверьте ваши айпи не через ifconfig, а через ip address, как я сказал. Дальше можно запустить tcpdump и смотреть, что происходит с пакетами и их адресами во время задержки.

Natrio

# 11 лет, 1 месяц назад

Темы: 47

Сообщения: 4763

Участник с: 08 января 2011

Насколько видно из дампов ifconfig, он считал основным IP именно тот, неправильный, с подсетью, изолированной от вашей настоящей подсети. Ваш правильный айпи тоже присутствовал, но как второй и невидимый для ifconfig.

Если хотите узнать – верните всё как было, перезагрузите, и проверьте ваши айпи не через ifconfig, а через ip address, как я сказал.

Дальше можно запустить tcpdump и смотреть, что происходит с пакетами и их адресами во время задержки.

sleepycat	# 11 лет, 1 месяц назад
Темы: 98 Сообщения: 3291 Участник с: 19 июля 2011	еще раз посмотри нет ли ситуации с присутвием 2ух точек которые могут раздавать dhcp. Лозунг у них был такой: "Познание бесконечности требует бесконечного времени". С этим я не спорил, но они делали из этого неожиданный вывод: "А потому работай не работай — все едино". И в интересах неувеличения энтропии Вселенной они не работали. (с)

sleepycat

# 11 лет, 1 месяц назад

Темы: 98

Сообщения: 3291

Участник с: 19 июля 2011

еще раз посмотри нет ли ситуации с присутвием 2ух точек которые могут раздавать dhcp.

Лозунг у них был такой: "Познание бесконечности требует бесконечного времени". С этим я не спорил, но они делали из этого неожиданный вывод: "А потому работай не работай — все едино". И в интересах неувеличения энтропии Вселенной они не работали. (с)

aivs	# 11 лет, 1 месяц назад
Темы: 62 Сообщения: 261 Участник с: 31 октября 2006	Точка выдачи адресов одна, по ip ad когда комп получал адрес по dhcp ip=192.168.1.101, и также по статике. Может dhcp клиент неправильно както адрес просит?..