Bug 443302 - Wrong default MTU for Silicon Integrated Systems [SiS] 190 Gigabit Ethernet Adapter causes 99% of network connections to fail
Summary: Wrong default MTU for Silicon Integrated Systems [SiS] 190 Gigabit Ethernet A...
Status: CLOSED NOTABUG
Alias: None
Product: Fedora
Classification: Fedora
Component: NetworkManager   
(Show other bugs)
Version: rawhide
Hardware: i686
OS: Linux
low
high
Target Milestone: ---
Assignee: Dan Williams
QA Contact: Fedora Extras Quality Assurance
URL:
Whiteboard:
Keywords:
Depends On:
Blocks:
TreeView+ depends on / blocked
 
Reported: 2008-04-20 13:08 UTC by Janne Enberg
Modified: 2008-04-22 19:40 UTC (History)
2 users (show)

Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-04-22 14:11:20 UTC
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
CRM:
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---


Attachments (Terms of Use)
lspci -vvv output (17.48 KB, text/plain)
2008-04-20 13:08 UTC, Janne Enberg
no flags Details
lsmod output (2.82 KB, text/plain)
2008-04-20 13:09 UTC, Janne Enberg
no flags Details
dmesg output (23.16 KB, text/plain)
2008-04-20 13:09 UTC, Janne Enberg
no flags Details

Description Janne Enberg 2008-04-20 13:08:38 UTC
Description of problem:

The MTU value selected by default for Silicon Integrated Systems [SiS] 190
Gigabit Ethernet Adapter is wrong and has to be manually changed to fix networking.

Fixed by adding the following line to /etc/rc.local

ifconfig eth0 mtu 1492


Version-Release number of selected component (if applicable):
Figured this out with 9-Preview installed from CDs, propably caused my problems
with trying to do a netinstall for 9-Beta and rawhide earlier.

How reproducible:
Always

Steps to Reproduce:
1. Install Fedora 9
2. 
3.
  
Actual results:
The default MTU for the ethernet device is wrong, thus downloading data over
network fails with 99% of cases.

Expected results:
The default MTU for the ethernet device is correct and downloading data over
network works.

Additional info:
No idea under which "component" this belongs to really.

Comment 1 Janne Enberg 2008-04-20 13:08:38 UTC
Created attachment 303052 [details]
lspci -vvv output

Comment 2 Janne Enberg 2008-04-20 13:09:08 UTC
Created attachment 303053 [details]
lsmod output

Comment 3 Janne Enberg 2008-04-20 13:09:34 UTC
Created attachment 303054 [details]
dmesg output

Comment 4 Dan Williams 2008-04-22 14:11:20 UTC
Janne: you should probably put MTU=1492 into your
/etc/sysconfig/network-scripts/ifcfg-eth0 file.  This is probably a situation
unique to your network; an MTU of 1492 is usually seen in VPN setups or other
cases where the traffic is again wrapped by VPN or 802.1x or whatever.

Comment 5 Janne Enberg 2008-04-22 16:59:54 UTC
Thanks for telling me the correct place for setting the MTU..

Anyways, this is not a VPN setup or anything similar.
Just a "normal" lan behind a nat router.

I have never had to set MTU on any of the other boxes I have in here, no matter
if they were running linux, freebsd, openbsd, macosx, windows, skyos or anything
else.

Also the same NIC worked fine with xp and kubuntu without any MTU settings.

Considering the above this is most propably a bug with the kernel module, but
since I only have a slight idea of what MTU is and none about how to track the
bug, I cannot be certain of the source.

Also since I found the MTU fix from google by searching for 'linux "Silicon
Integrated Systems [SiS] 190 Gigabit Ethernet Adapter"' and several other people
were having problems with it, I doubt this is in any way related to my network.


Comment 6 Dan Williams 2008-04-22 18:28:43 UTC
could be path MTU discovery not working or something like that?  that's more of
a TCP stack issue though.

Comment 7 Janne Enberg 2008-04-22 19:40:46 UTC
Just checked and the other linux boxes atleast use MTU 1500 in the network, why
this one now requires 1492 is beyond my ability to comprehend.

Also as I stated in the initial additional info, I don't really have a clue of
under which "component" this should've been reported under.


Note You need to log in before you can comment on or make changes to this bug.