RTL8153 Compile

r1

@geant90 I would ping @borzel to see if he knows about this behavior. Your #ifconfig shows correct info, can assign ip and works fine but XCP-NG-Center says its disconnected.
You say #xe pif-* works fine.

XCP-NG-Center gets data from XAPI, the same API used by xe, so it would be a very rare case that the info produced is mismatching.

Can you share screenshot of Host NICs from

XCP-NG-Center
#xsconsole -> Display NICS
#xe pif-param-list

BTW, did you try XOA product, its a web based alternative to XCP-NG-Center with added automated functions?

geant90

@r1

[root@CNP-MOBILE ~]# xe pif-param-list uuid=f4cab341-1f20-d9e6-4164-627debe5f03f
uuid ( RO)                       : f4cab341-1f20-d9e6-4164-627debe5f03f
                     device ( RO): side-373-eth0
                        MAC ( RO): 50:3e:aa:85:a7:ac
                   physical ( RO): true
                    managed ( RO): true
         currently-attached ( RO): true
                        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): 4f2d9638-59ae-6ce7-b36d-fea5eeb13d01
         network-name-label ( RO): Pool-wide network associated with side-373-eth0
                  host-uuid ( RO): af183f35-2629-4472-9538-90c2b37dca85
            host-name-label ( RO): CNP-MOBILE
      IP-configuration-mode ( RO): Static
                         IP ( RO): 192.168.91.92
                    netmask ( RO): 255.255.255.0
                    gateway ( RO): 192.168.91.1
    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): <unknown>
               io_write_kbs ( RO): <unknown>
                    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):
               other-config (MRW): management_purpose: Extra
       igmp-snooping-status ( RO): disabled

Heres the picture of NIC
xscone Display + xcenter

I know about XOA, use it at work. For this test machine I built a fresh XenServer 7.6 As I hope to get it working as natural as possible. That way if it works in XS it'll work in XCP-NG and XOA. As again goal is so it works for everywhere after a script shell install.
Do you happen to have a usb nic woring in xen? Screen shots for comparison?

r1

@geant90 so its XAPI itself that does not recognize the interface being online.

Whats the #ethtool -i ethX and ethtool ethX output look like?

Usually on pif-scan the interface (if online) should get registered. And does #dmesg shows that interface is now online when you plug a LAN into it?

geant90

@r1

[root@CNP-MOBILE ~]# ethtool -i side-373-eth0
driver: r8152
version: v2.10.00 (2018/03/16)
firmware-version:
bus-info: usb-0000:00:14.0-1
supports-statistics: yes
supports-test: no
supports-eeprom-access: no
supports-register-dump: no
supports-priv-flags: no

[root@CNP-MOBILE ~]# ethtool side-373-eth0
Settings for side-373-eth0:
        Supported ports: [ MII ]
        Supported link modes:   10baseT/Half 10baseT/Full
                                100baseT/Half 100baseT/Full
                                1000baseT/Full
        Supported pause frame use: No
        Supports auto-negotiation: Yes
        Advertised link modes:  10baseT/Half 10baseT/Full
                                100baseT/Half 100baseT/Full
                                1000baseT/Full
        Advertised pause frame use: Symmetric Receive-only
        Advertised auto-negotiation: Yes
        Link partner advertised link modes:  10baseT/Half 10baseT/Full
                                             100baseT/Half 100baseT/Full
                                             1000baseT/Half 1000baseT/Full
        Link partner advertised pause frame use: No
        Link partner advertised auto-negotiation: Yes
        Speed: 1000Mb/s
        Duplex: Full
        Port: MII
        PHYAD: 32
        Transceiver: internal
        Auto-negotiation: on
        Supports Wake-on: pumbg
        Wake-on: g
        Current message level: 0x00007fff (32767)
                               drv probe link timer ifdown ifup rx_err tx_err tx_queued intr tx_done rx_status pktdata hw wol
        Link detected: yes
[root@CNP-MOBILE ~]#

Hmm just noticed for my other interface that works fine where it says Ports for the result of #ethtool under the USB#Gig NIC it says MII and the other working NIC says Twisted pair!?!? I know what a MII but could it be that? Anyone has working media interface to rule that out?

r1

Ah! You will have to do a #interface-rename operation to rename your side-373-eth0 to eth1, then XAPI will recognize it. Can you try it, I don't have exact command around but you can check with its help or code.

geant90

@r1

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!

geant90

@r1 @borzel

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'

olivierlambert

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

r1

@geant90 awesome I'm sure the relevant team shall bring a resolution.

stormi

Here's the source: https://github.com/xcp-ng-rpms/interface-rename

geant90

@r1 @olivierlambert @stormi

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.

geant90

Check it out

Fully Functional

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.

olivierlambert

So you did modified the script? Can you share it somewhere? (so we could test it and include it for future update)

geant90

@olivierlambert

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.

olivierlambert

Okay, keep us posted then Thanks for your contribution!

geant90

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.

geant90

@olivierlambert @r1 @stormi

Any one knows the file location for usb vendor and product ID?

Nevermind found it!

geant90

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 ~]#

olivierlambert

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!

geant90

@olivierlambert

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 MAC

for 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