Вынужден пользоваться ноутом ASUS X58C с интегрированной сетевухой Silicon Integrated Systems 191 Gigabit Ethernet Adapter. Модуль с драйвером загружен, интерфейс поднимается, но пинги не идут, кроме как на свой IP.
Пробовал под ядром 2.6.26-1-686 из Debian Lenny Testing и свежесобранным 2.6.29.4 — разницы нет. Под виндой же работает нормально.
Подключение — обычный NAT, только MAC приходится прописывать той сетевухи, которой раньше пользовался, т.к. проверка IP по MAC.
Пробовал, как где-то советовали, прописать размер MTU меньше 1500, конкретно 1400 (и 400 тоже пробовал) — не помогает.
Содержимое /etc/network/interfaces:
auto lo
iface lo inet loopback
auto eth0
iface eth0 inet static
address 172.16.116.247
netmask 255.255.254.0
gateway 172.16.116.1
hwaddress ether 00:30:4f:51:89:2c
mtu 1400
В чем может быть проблема? Может, в поддельном MAC-адресе? (Под виндой, напомню, работает.)
Последние комментарии
-
OlegL, 17 декабря в 15:00 →
Перекличка
21
-
REDkiy, 8 июня 2023 года в 9:09 →
Как «замокать» файл для юниттеста в Python?
2
-
fhunter, 29 ноября 2022 года в 2:09 →
Проблема с NO_PUBKEY: как получить GPG-ключ и добавить его в базу apt?
6
-
Иванн, 9 апреля 2022 года в 8:31 →
Ассоциация РАСПО провела первое учредительное собрание
1
-
Kiri11.ADV1, 7 марта 2021 года в 12:01 →
Логи catalina.out в TomCat 9 в формате JSON
1
ecobeing.ru
/sbin/ifconfig -a
/sbin/route
В студию.
Эх, хотел их сразу запостить, да пост был бы слишком длинным…
$ /sbin/config -a
eth0 Link encap:Ethernet HWaddr 00:30:4f:51:89:2c
inet addr:172.16.116.247 Bcast:172.16.117.255 Mask:255.255.254.0
inet6 addr: fe80::230:4fff:fe51:892c/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1400 Metric:1
RX packets:7871 errors:0 dropped:0 overruns:0 frame:0
TX packets:22 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:503080 (491.2 KiB) TX bytes:1684 (1.6 KiB)
Interrupt:19 Base address:0xdead
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:4 errors:0 dropped:0 overruns:0 frame:0
TX packets:4 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:280 (280.0 B) TX bytes:280 (280.0 B)
$ /sbin/route -n
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
172.16.116.0 0.0.0.0 255.255.254.0 U 0 0 0 eth0
0.0.0.0 172.16.116.1 0.0.0.0 UG 0 0 0 eth0
$ dmesg | grep eth
[ 3.023713] Driver ’sd' needs updating — please use bus_type methods
[ 3.024423] sda:<4>Driver ’sr' needs updating — please use bus_type methods
[ 7.480391] eth0: GMII mode.
[ 7.480438] eth0: Enabling Auto-negotiation.
[ 31.516841] ADDRCONF(NETDEV_UP): eth0: link is not ready
[ 40.956009] eth0: mii ext = 0000.
[ 40.972009] eth0: mii lpa = 45e1 adv = 01e1.
[ 40.972059] eth0: link on 100 Mbps Full Duplex mode.
[ 40.972360] ADDRCONF(NETDEV_CHANGE): eth0: link becomes ready
[ 41.076007] eth0: mii ext = 0000.
[ 41.092008] eth0: mii lpa = 45e1 adv = 01e1.
[ 41.092054] eth0: link on 100 Mbps Full Duplex mode.
[ 51.616013] eth0: no IPv6 routers present
А что именно не пингуется? default route?
Ещё неплохо бы посмотреть на вывод iptables -L
Ну да. Пингуется только свой IP 172.16.116.247, ну и 127.x.x.x.
Пусто:
$ sudo /sbin/iptables -L
Chain INPUT (policy ACCEPT)
target prot opt source destination
Chain FORWARD (policy ACCEPT)
target prot opt source destination
Chain OUTPUT (policy ACCEPT)
target prot opt source destination
Вроде были баги в драйвере sis190, например:
http://bugzilla.kernel.org/show_bug.cgi?id=11073
http://bugzilla.kernel.org/show_bug.cgi?id=12090
http://bugzilla.kernel.org/show_bug.cgi?id=11926
но не похоже, что дело в них. Link status вроде правильно определяется.
Вот еще:
$ lspci | grep eth
00:04.0 Ethernet controller: Silicon Integrated Systems [SiS] 191 Gigabit Ethernet Adapter (rev 02)
02:00.0 Ethernet controller: Atheros Communications Inc. AR242x 802.11abg Wireless PCI Express Adapter (rev 01)
(беспроводной интерфейс не используется и отключен)
$ sudo /usr/sbin/mii-diag -v
Using the default interface 'eth0\′.
mii-diag.c:v2.11 3/21/2005 Donald Becker (becker@scyld.com)
http://www.scyld.com/diag/index.html
Using the new SIOCGMIIPHY value on PHY 1 (BMCR 0×3100).
The autonegotiated capability is 01e0.
The autonegotiated media type is 100baseTx-FD.
Basic mode control register 0×3100: Auto-negotiation enabled.
You have link beat, and everything is working OK.
This transceiver is capable of 100baseTx-FD 100baseTx 10baseT-FD 10baseT.
Able to perform Auto-negotiation, negotiation complete.
Your link partner advertised 45e1: Flow-control 100baseTx-FD 100baseTx 10baseT-FD 10baseT, w/ 802.3X flow control.
End of basic transceiver information.
libmii.c:v2.11 2/28/2005 Donald Becker (becker@scyld.com)
http://www.scyld.com/diag/index.html
MII PHY #1 transceiver registers:
3100 786d 0000 8201 01e1 45e1 0001 0000
0000 0000 0000 0000 0000 0000 0000 0000
000c 01c0 0000 0000 0000 0000 0000 0000
0000 00f9 0000 0000 0000 0000 0000 0000.
Basic mode control register 0×3100: Auto-negotiation enabled.
Basic mode status register 0×786d … 786d.
Link status: established.
Capable of 100baseTx-FD 100baseTx 10baseT-FD 10baseT.
Able to perform Auto-negotiation, negotiation complete.
Vendor ID is 00:00:20:--:--:--, model 32 rev. 1.
No specific information is known about this transceiver type.
I’m advertising 01e1: 100baseTx-FD 100baseTx 10baseT-FD 10baseT
Advertising no additional info pages.
IEEE 802.3 CSMA/CD protocol.
Link partner capability is 45e1: Flow-control 100baseTx-FD 100baseTx 10baseT-FD 10baseT.
Negotiation completed.
Еще вкрапления из вывода dmesg:
и через полсекунды:
Может быть, дело все же в MAC-адресе? Идти завтра перерегистрироваться?
Вот еще:
$ sudo /usr/sbin/ethtool -k eth0
Согласно ifconfig, mac у тебя такой, как ты указал. NetMask у тебя такая и задумана, а то несколько странновато выглядит?
Я заметил. Меня волнует, корректно ли будет работать драйвер, инициализированный с учетом реального MAC’а, с поддельным. На эти мысли меня навели вкрапления из dmesg из моего последнего поста. Смотрел исходник drivers/net/sis190.c, но понял мало, а изучать железячные стандарты времени нет.
Да, так и задумана. А что странного в 9-битной подсети вместо 8-битной?
Просто очень редко встречается.
Поробуй tcpdump запустить, но думаю ты ничего не увидишь.
Всё, проблема снята. Перерегистрировался с реальным MAC’ом, и соединение появилось. Наконец-то пишу из-под Линукса ))). (Правда, чтоб в Интернет ходить, пришлось у VPN-соединения (PPTP) снизить MTU с 1460 до 1456 — я фигею с этой жизни…)
Всё же интересно, почему не удавалось соединиться под локальным MAC. В Интернете пишут, что в Линуксе с этим проблем нет. Баг в железке/драйвере? Или что-то с кофигурированием?