Автор Тема: перешел на гигабит, но альт против((  (Прочитано 3417 раз)

Оффлайн valobasoff

  • Участник
  • *
  • Сообщений: 413
В общем ситуация такая, в свиче есть 2 гигабитных порта, в одном сервер, решил подоткнуть во второй рабочую станцию, но не тут-то было...альт не захотел так работать, тупо не получает адрес через dhcp, если получить на 100мб и переткнуть на гигабит, всё работает. Винда в этом гигабите, на этом же компе работает без проблем. Можно что-то подкрутить ?
дистр ШМ 6.0,
# lspci -k
02:00.0 Ethernet controller: Marvell Technology Group Ltd. 88E8056 PCI-E Gigabit Ethernet Controller (rev 14)
        Subsystem: Lenovo Device 303a
        Kernel driver in use: sky2
        Kernel modules: sky2

# service network restart
Computing interface groups: .. 2 interfaces found
Processing /etc/net/vlantab: empty.
Stopping group 1/realphys (1 interfaces)
        Stopping eth0: RTNETLINK answers: No such process
...OK
Stopping group 0/virtual (1 interfaces)
        Stopping lo: .OK
Computing interface groups: .. 2 interfaces found
Starting group 0/virtual (1 interfaces)
        Starting lo: ....OK
Starting group 1/realphys (1 interfaces)
        Starting eth0: ...eth0: dhcpcd 4.0.15 starting
eth0: hardware address = 00:1e:90:a5:b5:e0
eth0: executing `/lib/dhcpcd/dhcpcd-run-hooks', reason PREINIT
eth0: broadcasting for a lease
eth0: sending DHCP_DISCOVER with xid 0x5bb844a9, next in 3.57 seconds
eth0: sending DHCP_DISCOVER with xid 0x5bb844a9, next in 8.14 seconds
eth0: sending DHCP_DISCOVER with xid 0x5bb844a9, next in 16.39 seconds
eth0: sending DHCP_DISCOVER with xid 0x5bb844a9, next in 32.25 seconds
eth0: timed out
eth0: executing `/lib/dhcpcd/dhcpcd-run-hooks', reason FAIL
!.OK
Processing /etc/net/vlantab: empty.

# ethtool eth0
Settings for eth0:
        Supported ports: [ TP ]
        Supported link modes:   10baseT/Half 10baseT/Full
                                100baseT/Half 100baseT/Full
                                1000baseT/Half 1000baseT/Full
        Supports auto-negotiation: Yes
        Advertised link modes:  10baseT/Half 10baseT/Full
                                100baseT/Half 100baseT/Full
                                1000baseT/Half 1000baseT/Full
        Advertised pause frame use: No
        Advertised auto-negotiation: No
        Speed: 1000Mb/s
        Duplex: Full
        Port: Twisted Pair
        PHYAD: 0
        Transceiver: internal
        Auto-negotiation: on
        MDI-X: Unknown
        Supports Wake-on: pg
        Wake-on: g
        Current message level: 0x000000ff (255)
        Link detected: yes
« Последнее редактирование: 09.12.2013 17:43:23 от ruslandh »

Оффлайн asy

  • alt linux team
  • ***
  • Сообщений: 8 368
В общем ситуация такая, в свиче есть 2 гигабитных порта, в одном сервер, решил подоткнуть во второй рабочую станцию, но не тут-то было...альт не захотел так работать, тупо не получает адрес через dhcp, если получить на 100мб и переткнуть на гигабит, всё работает.
Выглядит, как бред. Софт, который всё это делает, вообще не в курсе про скорость. Разве что какой-то сумасшедший баг в драйвере sky2 (во что не очень верится), или какой-то фильтр на коммутаторе. Что за коммутатор, и что умеет ?
если получить на 100мб и переткнуть на гигабит
Это на разных портах ? А если 1GbE порт на коммутаторе переключить на 100M ?
« Последнее редактирование: 09.12.2013 19:18:27 от asy »

Оффлайн valobasoff

  • Участник
  • *
  • Сообщений: 413
3com4200
Протоколы динамической маршрутизации   IGMP v1, IGMP v2
Поддержка стандартов   Auto MDI/MDIX, IEEE 802.1p (Priority tags), IEEE 802.1q (VLAN), IEEE 802.1d (Spanning Tree)
кроме пароля и ip адреса ничего не менялось в настройках.
как делал, висел у меня компьютер в 48 порту(100), переткнул в 49(1000) сетка отключилась, но через некоторое время снова заработала.  service network restart, и всё, сети нет. Попробовал ограничить 100мбитами 49 порт, не помогает. адрес всё равно не получает. Похоже все же коммутатор, на винде возможно ип вручную был прописан)), вспомнил что в прошлом году ещё столкнулся с этим, почему видимо и переехал в другой порт.не было времени разбираться, может завтра удастся что-нибудь выяснить.

Оффлайн asterix81

  • Участник
  • *
  • Сообщений: 150
3com4200
Протоколы динамической маршрутизации   IGMP v1, IGMP v2
Поддержка стандартов   Auto MDI/MDIX, IEEE 802.1p (Priority tags), IEEE 802.1q (VLAN), IEEE 802.1d (Spanning Tree)
кроме пароля и ip адреса ничего не менялось в настройках.
как делал, висел у меня компьютер в 48 порту(100), переткнул в 49(1000) сетка отключилась, но через некоторое время снова заработала.  service network restart, и всё, сети нет. Попробовал ограничить 100мбитами 49 порт, не помогает. адрес всё равно не получает. Похоже все же коммутатор, на винде возможно ип вручную был прописан)), вспомнил что в прошлом году ещё столкнулся с этим, почему видимо и переехал в другой порт.не было времени разбираться, может завтра удастся что-нибудь выяснить.

смотреть надо в настройках свитча: если он управляемый,  настройки порта - не позволяют получать широковещательные рассылки  DHCP от сервера

Оффлайн valobasoff

  • Участник
  • *
  • Сообщений: 413
к сожалению я не ошибся, проблема именно на альте, в винду грузанулся, получил адрес и пишу это сообщение. подключал ещё один системник, на нем живет нормально и винда и альт в гигабите, сеть в нём nvidia. Единственное что смущает, почему на моем системнике альт в этом порту не хочет даже на 100мбит работать... настройки порта посмотрел, ничем не отличаются от других. поставил на свиче опцию "IGMP Multicast Filtering" в disabled, не помогло.
$ lspci -k
00:07.0 Bridge: NVIDIA Corporation MCP61 Ethernet (rev a2)
        Subsystem: ASUSTeK Computer Inc. M4N68T series motherboard
        Kernel driver in use: forcedeth
« Последнее редактирование: 12.12.2013 18:39:28 от valobasoff »

Оффлайн asy

  • alt linux team
  • ***
  • Сообщений: 8 368
Тогда надо брать tcpdump/wireshark и сравнивать, что там происходит. Но, всё ещё, считаю, что это - фантастика.

Оффлайн flint1975

  • Участник
  • *
  • Сообщений: 1 443
Не, не фантастика, посмотрите в свиче накопленные ошибки по этому порту. Недавно было такое, проблема была именно в порту, время ожидания dhcp у винды больше и количество попыток получить адрес тоже, (не помню где, но читал на форумах).
В моем случае, починил свич заменой блока трансформаторов гальванической развязки!

Оффлайн asy

  • alt linux team
  • ***
  • Сообщений: 8 368
время ожидания dhcp у винды больше и количество попыток получить адрес тоже
Недавно наблюдал, как кто-то на столько хотел адрес получить (хотя, может, и загрузиться), что запросами "где сервер" 100М порт в потолок забил. :-) Ну и соседям, конечно, досталось... МАС был 3com-овский, уж железка была, или сетевая карта в компьютере - это не знаю.

Оффлайн valobasoff

  • Участник
  • *
  • Сообщений: 413
flint1975 ошибок вроде нет, может на передачу только. другой системник в этом порту заработал нормально и винда и альт, с тем-же дистрибутивом.
похоже придется знакомится с tcpdump/wireshark.

Оффлайн asterix81

  • Участник
  • *
  • Сообщений: 150
А если по простому: кабель проверить, на некоторых свитчах и сетевых картах Гигабит должен быть в аплинке... (cisco например.)

Оффлайн asy

  • alt linux team
  • ***
  • Сообщений: 8 368
на некоторых свитчах и сетевых картах Гигабит должен быть в аплинке... (cisco например.)
Это как ? Нет такого понятия у коммутаторов. Все порты всегда равноправные. "Предназначены для аплинка" - это да. Но никакого "должен". А кабель проверить - это всегда полезно, но, как я понял, это проверялось уже - другой компьютер с Linux подключался же.

Оффлайн ruslandh

  • Поспешай не торопясь !
  • Модератор глобальный
  • *****
  • Сообщений: 32 361
  • Учиться .... Телепатами не рождаются, ими ....
Что-то я не вижу тут dmesg в момент поднятия сети.

Оффлайн asterix81

  • Участник
  • *
  • Сообщений: 150
на некоторых свитчах и сетевых картах Гигабит должен быть в аплинке... (cisco например.)
Это как ? Нет такого понятия у коммутаторов. Все порты всегда равноправные. "Предназначены для аплинка" - это да. Но никакого "должен". А кабель проверить - это всегда полезно, но, как я понял, это проверялось уже - другой компьютер с Linux подключался же.
1) Если управляемый свитч...
2) Сегодняшние сетевые интерфейсы "умеют" "переворачивать" кабель если например соединение прямое, а у вас кабель аплинк.

Оффлайн asy

  • alt linux team
  • ***
  • Сообщений: 8 368
2) Сегодняшние сетевые интерфейсы "умеют" "переворачивать" кабель если например соединение прямое, а у вас кабель аплинк.
Это просто "auto MDI" (то есть, переключение порта MDI/MDI-X; для 1000BASE-T включено в стандарт, правда, в необязательную часть). Если бы у него там такого не было, у него бы "не работало совсем".

Оффлайн flint1975

  • Участник
  • *
  • Сообщений: 1 443
МАС был 3com-овский, уж железка была, или сетевая карта в компьютере - это не знаю.

Скорее сетевуха, в свое время, санрайз напродавал много 3COM сетевух 905 с бутовой флешкой на борту, которые шли как "восстановленные" (сам их покупал, для бездисковых терминалов)
OFFTOP
 После некоторого периода эксплуатации выяснилось (случайно, друг электронщик раскопал), что там восстанавливали :)
Там в одном месте конденсатор стоит 22mkf (в оригинале танталовый) так вот на этих - обычный электролит, т.е. он был заменен. А дело было "не в бобине", там ошибка в прошивке (стоит просто пауза, вместо ожидания 1 на ноге микрухи) и внимание если емкость меньше номинала чуть-чуть то все работает, а если больше - проц сваливается в цикл запросов bootp. А если стоит электролит, у которого ток заряда немного меньше, то паузы как раз хватает :)
Итог: 8 байт кода в прошивке и все работает прекрасно.
PS А электролит со временем теряет емкость и соответственно сетевуха вообще перестает работать!