Bug 682337 - assumes all network devices are named ethX or trX
assumes all network devices are named ethX or trX
Product: Fedora
Classification: Fedora
Component: amtu (Show other bugs)
Unspecified Unspecified
unspecified Severity unspecified
: ---
: ---
Assigned To: Steve Grubb
Fedora Extras Quality Assurance
Depends On:
Blocks: 682334 682339
  Show dependency treegraph
Reported: 2011-03-04 16:24 EST by Bill Nottingham
Modified: 2014-03-16 23:26 EDT (History)
4 users (show)

See Also:
Fixed In Version:
Doc Type: Bug Fix
Doc Text:
Story Points: ---
Clone Of:
: 682339 (view as bug list)
Last Closed: 2012-05-14 11:49:41 EDT
Type: ---
Regression: ---
Mount Type: ---
Documentation: ---
Verified Versions:
Category: ---
oVirt Team: ---
RHEL 7.3 requirements from Atomic Host:
Cloudforms Team: ---

Attachments (Terms of Use)
Patch... just read all devices with proper addresses (949 bytes, patch)
2011-03-04 16:24 EST, Bill Nottingham
no flags Details | Diff

  None (edit)
Description Bill Nottingham 2011-03-04 16:24:52 EST
Created attachment 482379 [details]
Patch... just read all devices with proper addresses

Description of problem:

Network devices can have arbitrary names, and due to http://fedoraproject.org/wiki/Features/ConsistentNetworkDeviceNaming, will have different names in Fedora 15.

amtu assumes all devices are ethX or trX.

Version-Release number of selected component (if applicable):


How reproducible:

Via source code inspection
Comment 1 Steve Grubb 2011-06-24 15:03:21 EDT
Not sure this patch is adequate. The system could have tunnels and bridges and other things that amtu should not touch. How do you identify just ethernet and tokenring interfaces in the new naming scheme?
Comment 2 Bill Nottingham 2011-06-24 15:42:19 EDT
What is amtu verifying about the adapter that makes a bridge or bonded adapter invalid?
Comment 3 Steve Grubb 2011-06-24 16:07:39 EDT
The code is just to check that the basic security assumptions are met, meaning you have lossless IO. There is a programming note that the test does not work for async network devices. So, I think the code looks for ethernet and tokenring knowing they are not async.
Comment 4 Bill Nottingham 2011-06-24 16:16:20 EDT
Probably keying off of the header type (/sys/class/net/<device>/type, see include/linux/if_arp.h for the list) is best then?
Comment 5 Steve Grubb 2012-05-14 11:49:41 EDT
Applied patch.

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