RTL8153 Compile
-
Man that is exactly what I was thinking about 4-5 hours ago driving to work. I was thinking maybe it has something to do with Xserver only recognizing calling NIC names "ethx" The only reason I had not tried it was because I wanted to ensure functionality before renaming to something persistent. Will keep you posted. Because it does pull the same stats matching from my function NIC. Will attempt after lunch!
-
Ladies and gentlemen we have struck gold.
[root@XenServer-TestNIC ~]# interface-rename --list ERROR [2018-11-05 12:36:24] Can't generate current state for interface '{'Driver': 'r8152', 'Permanent MAC': '50:3E:AA:85:B6:AE', 'Bus Info': 'usb-0000:00:14.0-2', 'BIOS device': {'all_ethN': 'eth1', 'physical': ''}, 'Assigned MAC': '50:3E:AA:85:B6:AE', 'Firmware version': '', 'Driver version': 'v2.10.00 (2018/03/16)', 'Kernel name': 'side-9065-eth1'}' - Unrecognised PCI address 'usb-0000:00:14.0-2' Name MAC PCI ethN Phys SMBios Driver Version Firmware eth0 a0:d3:c1:06:ed:a1 0000:00:19.0[0] eth0 em1 Onboard LAN e1000e 3.4.0.2-NAPI 0.13-4 [root@XenServer-TestNIC ~]#So it looks like it has a problem being a usb device. Time to find out what can be done to over come this.
Unrecognised PCI address 'usb-0000:00:14.0-2'
-
Yayy! It's more clear. The rename script is probably only looking for PCI device, not USB one. Now, we'll have to find where this code is written and improve it
-
@geant90 awesome
I'm sure the relevant team shall bring a resolution. -
Here's the source: https://github.com/xcp-ng-rpms/interface-rename
-
In interface-rename python I see it imports xcp.pci and others. Maybe if it is edited to import usb as well then using an if command we can get it to also recognize a pci address for examaple 'usb-0000:00:14.0-2 (if usb-xxxx:xx:xx:x-x then refer to usb location. Will play around now. For now I wonder if a simple edit to the script would get it working. usb-0000:00:14.0-2 does in fact refer to to the proper pci address of the usb controller @ 00:14.0 I wonder if for reporting purposes using a if command to strip away usb-0000:00:14.0-2 to 0000:00:14.0-2 or possibly 0000:00:14.0 would be enough for it to comply with xapi then with a proper eth name it will report correctly refresh xcenter appropriately. Since it can be matched with permanent MAC it in theory would be able to function as that just displays NIC. Then if that is successful I can see if it would cause conflict with two reporting same PCI location. Which from looking at the script it should not as that is just reporting to the end user usable info which we really don't care as we are aware it is a usb device then could simply find out which to be specific. This does not effect the driver which is already communicating properly and the device is functioning fine it just cannot determine that bus location.
-
Check it out
Going to see if I can get it to call the vendor and device from the usb manu and product ids so it is all pretty and what not.
-
So you did modified the script? Can you share it somewhere? (so we could test it and include it for future update)
-
Did not get to the script yet but I will. I just wanted to be 100 percent sure that the only reason its named side is because that script cannot handle it due to the unknown bus location. If we can get the script to recognize the location then that would likely be the end for all usb nic troubles as it will then be able to properly assign the ethx name for xapi to correctly pick up without any addition user interaction.Thus again putting XCP-NG ahead of the game. As we would not have to put a halt to dynamic naming for interfaces and the nic will be retained through a reboot.
-
Okay, keep us posted then
Thanks for your contribution! -
Anyone knows where is the database for USB vendors and product ids? Would like to put an edit in there to see if that would generate proper info.
-
Any one knows the file location for usb vendor and product ID?
Nevermind found it!
-
Got it showing in lsusb properly now time to figure xapi
[root@CNP-MOBILE ~]# xe pif-param-list uuid=9212a2c9-b68c-9ac6-cb76-d9baa6af2c5e uuid ( RO) : 9212a2c9-b68c-9ac6-cb76-d9baa6af2c5e device ( RO): eth10 MAC ( RO): 50:3e:aa:85:b6:ae physical ( RO): true managed ( RO): true currently-attached ( RO): false MTU ( RO): 1500 VLAN ( RO): -1 bond-master-of ( RO): bond-slave-of ( RO): <not in database> sriov-physical-PIF-of ( RO): sriov-logical-PIF-of ( RO): tunnel-access-PIF-of ( RO): tunnel-transport-PIF-of ( RO): management ( RO): false network-uuid ( RO): 4a3277cb-f48b-47cc-ba69-7d73f02d814f network-name-label ( RO): Pool-wide network associated with eth10 host-uuid ( RO): af183f35-2629-4472-9538-90c2b37dca85 host-name-label ( RO): CNP-MOBILE IP-configuration-mode ( RO): None IP ( RO): netmask ( RO): gateway ( RO): IPv6-configuration-mode ( RO): None IPv6 ( RO): IPv6-gateway ( RO): primary-address-type ( RO): IPv4 DNS ( RO): properties (MRO): gro: on capabilities (SRO): io_read_kbs ( RO): 0.000 io_write_kbs ( RO): 0.000 carrier ( RO): false vendor-id ( RO): vendor-name ( RO): device-id ( RO): device-name ( RO): speed ( RO): 0 Mbit/s duplex ( RO): unknown disallow-unplug ( RW): false pci-bus-path ( RO): 2-1:1.0 other-config (MRW): igmp-snooping-status ( RO): unknown [root@CNP-MOBILE ~]# lsusb Bus 002 Device 002: ID 2357:0601 TP-LINK USB 10/100/1000 LAN Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub [root@CNP-MOBILE ~]# -
Okay great
Can you share with us all the modification you had to made? What can we do to have this integrated in XCP-ng? (ie not a too specific code ideally that would work with other network USB devices)Thanks!
-
Of course. Right now I just got enough information to start the modification on the script which I start tomorrow. In fact, all that is needed to get usbnics working properly in xapi is simply being able to identify usb locations. THAT'S IT! All NICs if you look in the logs are initially named side then because the rename script runs and after properly identifying it assigns a ethxx name which the api will work with. All this would take is an import command and a few if commands. I got the logic down so now it is just about editing, trial and error.
Question regarding:
import sys, logging from optparse import OptionParser, OptionGroup from os.path import join as joinpath, normpath, exists as pathexists from subprocess import Popen try: import cStringIO as StringIO except ImportError: import StringIO import xcp.logger as LOG from xcp.pci import PCI from xcp.net.biosdevname import all_devices_all_names from xcp.net.ip import ip_link_set_name from xcp.net.ifrename.logic import rename from xcp.net.ifrename.macpci import MACPCI from xcp.net.ifrename.static import StaticRules from xcp.net.ifrename.dynamic import DynamicRules from xcp.net.ifrename.util import niceformat from xcp.net.mac import MACfor the import command as my google fu was no help for the above xcp.net and xcp.pci what is it specifically referring to?
What I have that down we simply need to add and import for usb then modify a few existing calls with the first being if device location = usb format then run the modify version of the script that would have the edited fields to pull the proper usb locations etc. For the vendor and device it would be best and most simple if we refer to the usbvidpid list it can simply call the info from an already large existing database which can also be easily updated and/or modified for an entry. Functionality wise all that is needed is those if commands to make a usb location referable. Then any usb NIC (so long as drivers provided) would be truly plug and play and we could use the existing config to chose a specific ethxx name based on MAC so they survive reboots without further editing anything.Got it is referring to the python libary / libs
-
Has there been any more work on this? I'm testing XCP-NG 8 beta and was hoping to try and test out similar usb nic?
-
This post is deleted! -
This post is deleted! -
Here's another willing script tester
-
has enyone get this usb nic to work?
