Тут стоит заняться диагностикой.

В первую очередь, проверить отсутствие «железных» проблем: карта-патчкорд, патчкорд-розетка, кабель, коммутатор/роутер, не исключены ли шалости на портах коммутатора/роутера. Неплохо б увидеть описание сети. Что имелось в виду под «с админ места работает» — локальная консоль или сетевой доступ? Что происходит при попытке попинговать с машины соседей? Что происходит при попытке попинговать через arping? Если переключить в другой порт коммутатора, повторяется ли поведение? Возможно, есть смысл попытать карту по ethtool.

Смотрим журналы (dmesg, /var/log/syslog, /var/log/messages) на предмет чего-либо интересного от сетевой карты. Обращать внимание на eth и имя драйвера.

Делимся описанием железки, от рута

# lspci -knns $(lspci | grep -i ether)

# lspci -knns номер_слота_из_1_колонки

Мне вот тоже не понятна формулировка «Стал слетать драйвер», может поясните в чем это выражается?
«Перезапускал через rc.d\inet1» и помогало?
«Наконец переставил сетевуху» другую(аналогичную) установили?

До зтого такого не происходило

с той же картой или с другими?

уже 4-ая машина с таким линуксом и таким типом карты

остальные тоже слетают?

Когда слетает карта, машина (сервер) извне не доступна, а с админ места работает в полном объеме.

Так, может все же машина работает, а проблемы дальше. Соединение рвется и не восстанавливается.

сетевая карта

1. локальная консоль, подключена напрямую к серверу

2. Пинг не идет не к ней ни от нее.

3. карта ставилась физически другая, но модель та же

4. про 4-ю машину - имелось ввиду, что линукс и ПО (база данных) и сетевая карта одного типа стояли на предыдущих машинах, т.е. эта вся система работает без изменений в операционке уже 10 лет (третья машина и сетевые карты реалтек 8139) и такого не было.

5. Возможно нужно поменять патч-корд (я его действительно лет 8 не менял) и переключить на другой порт коммутатора.

6. В журналах ничего от сетевухи нет. Правда есть подозрение по работе сети.

В сети доменная структура. Стоит ЕРПИ, документооборот,два сервера 1С (бухгалтерия и предметная база), почтовый сервер, прокси. маска сети офигенная 255.255.000.000, хотя машин не больше 200, а сеть перегружена, т.к.1С работает как файл-сервер, а моя на линуксе клиент сервер и летает. На обычном asus P5, 1 гиг , 250 Г wd , работает до 60 человек.

Так что спасибо за подсказки, попробую первоочередно по линии коммутации - кабель поменять и порт коммутатора.

3. карта ставилась физически другая, но модель та же
и сетевые карты реалтек 8139

Вы точно уверены что 8139 прямо-прямо точно такая же? Включая rev ? И даже если так, уже писал здесь (Нестабильная работа putty, Squid, r8169 (комментарий)), что попадал на подбор разных дров к одинаковым rev. Вот честно, я бы просто ее поменял на что-то нормальное.

сетевая карта

То что карта из одной серии и rev не уверен.Я уже писал, что я уже более 10 ти лет использую только такую сетевуху. У меня ядро старое и выбора нет. На предыдущем блоке карта проработала 5 лет и тких сбоев не было. Предыдущий блок в сентябре во время отпуска 2 недели проработал как дубль сервера и ничего подобного с картами на обоих блоках не было. Перейти на другое ядро сложно,т.к.надо оттранслировать переходник от SCO в LINUX - iBSC2. При помощи iBSC2-совместимого модуля практичеки совместима с SCO, SVR3 и SVR4 на двоичном уровне.

У меня ядро старое и выбора нет.

Выбор есть. Как минимум поставить другую сетевку. Хоть 3com старенький.
ЗЫ У мню тоже есть тех. система где я без надобности не собираюсь обновлять все включая ведро.

3сом

Есть у меня карта 3С905с-ТХ-М Ирландская, но нет драйвера такого в ядре.

Есть только 3с509 и 3с59х - эти две уже отработали 10 лет.

Могу представить логи из ф. messages. В нем находятся записи от 22 по

утро 27 февраля. Все выходные карта работала нормально. Запись от 23

февраля получена от обращения пользовательской машины за почтой на сервер и

до 8.47 27 февраля все работало и только в 9.16 пришлось выполнить

rc.inet1

-------------------------------------------------------- Последние входы 22 февраля

Feb 22 17:23:55 linmed ftpd[28247]: PORT

Feb 22 17:23:55 linmed ftpd[28247]: LIST

Feb 22 17:41:29 linmed — MARK --

Feb 22 17:42:12 linmed ftpd[28247]: PORT

Feb 22 17:42:12 linmed ftpd[28247]: LIST -d dog.txt

Feb 22 17:55:21 linmed ftpd[28247]: lost connection to 192.168.148.17

[192.168.148.17]

Feb 22 17:55:21 linmed ftpd[28247]: FTP session closed

Feb 22 18:18:08 linmed in.telnetd[28325]: connect from 192.168.152.226

Feb 22 18:41:29 linmed — MARK --

Выходные дни

Feb 23 15:41:31 linmed — MARK --

Feb 23 15:44:30 linmed in.pop3d[30692]: connect from 192.168.148.128

Feb 23 15:44:30 linmed in.pop3d[30692]: Servicing u36 @ 192.168.148.128

Feb 23 16:01:31 linmed — MARK --

Feb 27 06:41:31 linmed — MARK --

Пон. 27

Feb 27 06:55:49 linmed in.pop3d[3130]: connect from 192.168.148.17

Feb 27 06:57:04 linmed in.telnetd[3131]: connect from 192.168.151.117

Feb 27 07:00:39 linmed in.telnetd[3159]: connect from 192.168.148.17

Feb 27 07:04:09 linmed in.telnetd[3191]: connect from 192.168.148.77

Feb 27 07:07:10 linmed wu.ftpd[3233]: connect from 192.168.148.77

Feb 27 07:07:13 linmed ftpd[3233]: USER ira

Feb 27 07:07:13 linmed ftpd[3233]: PASS password

Feb 27 07:07:13 linmed ftpd[3233]: FTP LOGIN FROM 192.168.148.77

[192.168.148.77], ira

Feb 27 08:38:17 linmed sendmail[4727]: connect from 192.168.148.27

Feb 27 08:38:50 linmed sendmail[4386]: NOQUEUE: [192.168.148.19] did not issue

MAIL/EXPN/VRFY/ETRN during connection to stdin

Feb 27 08:39:03 linmed in.pop3d[4728]: connect from 192.168.148.253

Feb 27 08:43:28 linmed in.telnetd[4806]: connect from 192.168.152.111

Feb 27 08:44:15 linmed sendmail[4477]: NOQUEUE: [192.168.148.27] did not issue

MAIL/EXPN/VRFY/ETRN during connection to stdin

Feb 27 08:44:21 linmed in.telnetd[4858]: connect from 192.168.148.191

Feb 27 08:44:36 linmed sendmail[4497]: NOQUEUE: [192.168.148.27] did not issue

MAIL/EXPN/VRFY/ETRN during connection to stdin

Feb 27 08:44:49 linmed sendmail[4591]: NOQUEUE: [192.168.148.27] did not issue

MAIL/EXPN/VRFY/ETRN during connection to stdin

Feb 27 08:45:29 linmed sendmail[4727]: NOQUEUE: [192.168.148.27] did not issue

MAIL/EXPN/VRFY/ETRN during connection to stdin

Feb 27 08:45:47 linmed sendmail[4732]: NOQUEUE: [192.168.148.27] did not issue

MAIL/EXPN/VRFY/ETRN during connection to stdin

Feb 27 08:45:54 linmed sendmail[4805]: NOQUEUE: [192.168.148.27] did not issue

MAIL/EXPN/VRFY/ETRN during connection to stdin

Feb 27 08:45:59 linmed sendmail[4496]: NOQUEUE: [192.168.148.19] did not issue

MAIL/EXPN/VRFY/ETRN during connection to stdin

Feb 27 08:46:16 linmed sendmail[4625]: NOQUEUE: [192.168.148.19] did not issue

MAIL/EXPN/VRFY/ETRN during connection to stdin

Feb 27 08:46:26 linmed sendmail[4729]: NOQUEUE: [192.168.148.19] did not issue

MAIL/EXPN/VRFY/ETRN during connection to stdin

Feb 27 08:46:38 linmed sendmail[4800]: NOQUEUE: [192.168.148.19] did not issue

MAIL/EXPN/VRFY/ETRN during connection to stdin

Feb 27 08:47:38 linmed sendmail[4498]: NOQUEUE: [192.168.148.19] did not issue

MAIL/EXPN/VRFY/ETRN during connection to stdin

Последние входы в машину

message servera при отсутствии связи

Feb 27 09:01:31 linmed — MARK --

Feb 27 09:07:30 linmed telnetd[4858]: ttloop: read: No route to host

Feb 27 09:16:03 linmed mc: /dev/gpmctl: Connection refused

Feb 27 09:32:00 linmed mc: /dev/gpmctl: Connection refused

Feb 27 09:35:02 linmed mc: /dev/gpmctl: Connection refused

Feb 27 09:45:59 linmed mc: /dev/gpmctl: Connection refused

Feb 27 09:46:17 linmed mc: /dev/gpmctl: Connection refused

После перезапуска rc.inet1 - shell script boots up the base INET system

Feb 27 09:46:27 linmed sendmail[5173]: connect from 192.168.148.27

Feb 27 09:46:42 linmed sendmail[5174]: connect from 192.168.148.19

Feb 27 09:46:54 linmed in.telnetd[5177]: connect from 192.168.148.176

Feb 27 09:47:00 linmed in.telnetd[5175]: connect from 192.168.148.7

Feb 27 09:47:03 linmed in.telnetd[5176]: connect from 192.168.148.13

Feb 27 09:48:43 linmed mc: /dev/gpmctl: Connection refused

Feb 27 09:48:46 linmed sendmail[5349]: connect from 192.168.148.27

Feb 27 09:49:06 linmed sendmail[5352]: connect from 192.168.148.19

Feb 27 09:49:21 linmed in.telnetd[5353]: connect from 192.168.152.25

Feb 27 09:49:48 linmed in.telnetd[5385]: connect from 192.168.152.120

Feb 27 09:50:01 linmed in.telnetd[5411]: connect from 192.168.151.201

Feb 27 10:54:06 linmed sendmail[7469]: connect from 192.168.148.27

Feb 27 10:55:31 linmed sendmail[7301]: NOQUEUE: [192.168.148.27] did not issue MAIL/EXPN/VRFY/ETRN during connection to stdin

Feb 27 10:55:45 linmed mc: /dev/gpmctl: Connection refused

Интереснооо... а в следующий раз когда слетит, посмотрите что говорит ip r s, ip a s, ip l в момент не работы и после перезапуска.

А вообще это нормально что у вас народ на телнет массово ломиться ?

И по сетевкам, я не понял пытались менять или нет? Не обязательно на 3com, это я так написал, intel лучше

3com&telnet

3c5 карты уже по 10 лет работали и они isa. 3c9 новая, но нет драйвера в ядре.

По telnet входят из под windows эмулятор терминала (reflection or putty)

Перейти на другое ядро сложно,т.к.надо оттранслировать переходник от SCO в LINUX - iBSC2. При помощи iBSC2-совместимого модуля практичеки совместима с SCO, SVR3 и SVR4 на двоичном уровне.

нифига себе... Эта хрень еще живая !? Я помню как в 95 году какой-то скотский продукт запускали в линуксе с ядром 1.3.хх.

Теоретически в qemu можно запускать старое ядро :)

Но просто так сетевые карты не начинают глючить. Нужно попытаться найти причину.

БП меняли ? А эту сетевую плату в другом компе не тестировали ? Может она исправная, а беда с MB.

Это может быть и окислившиеся контакты в разъёме сетевого кабеля, и высохшие кондёры, и деградация других компонентов на плате. 8139 было дофига ревизий и дофига глючных подделок.

anc правильно подсказал про интелы, (pro100) выпускалась ооочень долго.

Помнится раньше был у меня велосипед, который проверял активность сетевой карты и при необходимости делал рестарт через «mii-tool -R» и/или «mii-tool -r»

А к чему эта сетевая карта подключена ? Что за оборудование ? Если там управляемый коммутатор, то можно посмотреть состояние линка.

3com

1. Неделю стоит другая карта. Проверить которую снял -нужна активная работа через

я так понимаю.

2.МВ asus работает 3 года, предыдующая работала 5лет. Если бы плата, то были

бы другие заморочки. Если контакты разъема - но работает 2 или три дня без отвала,

а на праздники все четыре, но без активной загрузки.

3.Думал через рестарт, но что такое mii-tool. У меня много автоматизации через

PERL -архивация базы, перезагрузка спулера, удаление задания узера, который

локировал запись и другие.

4.Карта подлючена к 48-и входовому коммутатору. Но уменя есть подозрения, что

что-то с сетью, как пришли новый сотрудники. Сеть доменная Windows. Идет

какое-то обновление по сети регулярно,часть адресов динамические, часть

статические. Вопросы с картой возникли где-то в июле и до октября было спокойно,

а потом стали чаще.

что такое mii-tool

man mii-tool :) это предок ethtool

Возможно ethtool имеет этот функционал, но я пока поленился прочитать его ман до конца.

Сеть доменная Windows

езернету глубоко фиолетово на все домены, кроме домена коллизий.

Нужен сбор статистики и желательно с обоих концов кабеля. Часть сетевых карт имеет расширенную статистику доступную через «ethtool -S», на управляемом коммутаторе тоже есть статистика и в случае проблем с каналом там будут видны проблемы. если в «netstat -i» / «ifconfig» / «ip -s li» есть ошибки на приеме, то это повод начать проверять сетевой кабель.

Если проблема усугубляется со временем, значит это деградация канала или оборудования. Дохлых 8139 было достаточно, умирающие кабели/патчкорды - не редкость. Коммутаторы с глючащими портами тоже встречаются.

Если есть свободный коммутатор, то можно через него подключить машину ( через заведомо исправный патчкорд) и тем самым исключив разные проблемы совместимости карта-коммутатор.

8139 - это древний хлам, который может неадекватно реагировать на новомодные фичи в коммутаторах (типа энергосбережения).

Если это не военная тайна, то в какую модель коммутатора подключена машина ?

3сом

TP-LINK