Bug 443302 - Wrong default MTU for Silicon Integrated Systems [SiS] 190 Gigabit Ethernet Adapter causes 99% of network connections to fail
Wrong default MTU for Silicon Integrated Systems [SiS] 190 Gigabit Ethernet A...
Status: CLOSED NOTABUG
Product: Fedora
Classification: Fedora
Component: NetworkManager (Show other bugs)
rawhide
i686 Linux
low Severity high
: ---
: ---
Assigned To: Dan Williams
Fedora Extras Quality Assurance
:
Depends On:
Blocks:
  Show dependency treegraph
 
Reported: 2008-04-20 09:08 EDT by Janne Enberg
Modified: 2008-04-22 15:40 EDT (History)
2 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
Environment:
Last Closed: 2008-04-22 10:11:20 EDT
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 09:08 EDT, Janne Enberg
no flags Details
lsmod output (2.82 KB, text/plain)
2008-04-20 09:09 EDT, Janne Enberg
no flags Details
dmesg output (23.16 KB, text/plain)
2008-04-20 09:09 EDT, Janne Enberg
no flags Details

  None (edit)
Description Janne Enberg 2008-04-20 09:08:38 EDT
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 09:08:38 EDT
Created attachment 303052 [details]
lspci -vvv output
Comment 2 Janne Enberg 2008-04-20 09:09:08 EDT
Created attachment 303053 [details]
lsmod output
Comment 3 Janne Enberg 2008-04-20 09:09:34 EDT
Created attachment 303054 [details]
dmesg output
Comment 4 Dan Williams 2008-04-22 10:11:20 EDT
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 12:59:54 EDT
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 14:28:43 EDT
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 15:40:46 EDT
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.