openbmc / phosphor-networkd

Apache License 2.0
17 stars 48 forks source link

VLAN is not created via ipmitool or curl command #33

Closed warp5tw closed 1 year ago

warp5tw commented 4 years ago

Hi:

I'm trying to create a VLAN link like eth1.1 via ipmitool but it doesn't work as expected. The curl command to create a VLAN link in the phosphor-networkd readme doesn't work either.

The ipmitool command given is "ipmitool -I lanplus -C 17 -p 623 -U root -P 0penBmc -H ${bmc_ip} lan set 1 vlan id 1".

The curl command given is "curl -k -H "X-Auth-Token: $token" -H "Content-Type: application/json" -X POST -d '{"data":["eth1",1] }' https://${bmc}/xyz/openbmc_project/network/action/VLAN".

The phosphor-network-manager is aborted and then restarted.

Here are some journal logs.

Jan 01 00:01:22 phosphor-network-manager[369]: terminate called after throwing an instance of 'std::system_error' Jan 01 00:01:22 phosphor-network-manager[369]: what(): if_nametoindex: No such device Jan 01 00:01:22 systemd[802]: systemd-coredump@0-801-0.service: PrivateNetwork=yes is configured, but the kernel does not support network namespaces, ignoring. Jan 01 00:01:23 systemd[1]: xyz.openbmc_project.Network.service: Main process exited, code=dumped, status=6/ABRT Jan 01 00:01:23 systemd[1]: xyz.openbmc_project.Network.service: Failed with result 'core-dump'.

After tracing the code in phosphor-network, the if_nametoindex function can't locate the index mapped to the VLAN interface inside the EthernetInterface::ifIndex function and then it throws an error. However, the VLAN link (eth1.1 here as an example) doesn't exist for the time being.

If I used the ip link command to create the VLAN link in OpenBMC debug console before inputting the curl command, then inputting the curl command works. I'm not sure that it's the right way to do because it seems to me that it's the curl command's job to create a VLAN link instead of inputting the ip link command manually.

Is there some configuration I missed? For now, the line "EthernetInterfaceIntf::nameservers(getNameServerFromResolvd())" is commented temporarily in the EthernetInterface::EthernetInterface constructor and the curl command creates the desired VLAN link.

Thank you.

Regards, Tyrone

Ramkosh commented 4 years ago

Hi, I think my partially abandoned change was supposed to fix this. I'll revisit it sometime soon.

warp5tw commented 4 years ago

Hi, I think my partially abandoned change was supposed to fix this. I'll revisit it sometime soon.

Hi @Ramkosh :

Thank you for your feedback.

The commit id of the phosphor-networkd I work on is 6f9a2ee25cf8061072602cfa29c4363f7745b367.

Here are steps I try to create a VLAN interface (eth1.2) based on eth1. Eth1 is a physical interface on the bmc and exists before creating a VLAN on it.

  1. export token=curl -k -H "Content-Type: application/json" -X POST https://${bmc}/login -d '{"username" : "root", "password" : "0penBmc"}' | grep token | awk '{print $2;}' | tr -d '"'

  2. curl -k -H "X-Auth-Token: $token" -H "Content-Type: application/json" -X POST -d '{"data":["eth1",2] }' https://${bmc}/xyz/openbmc_project/network/action/VLAN

Below is what I traced after the phosphor-networkd aborted.

EthernetInterface::createVLAN in ethernet_interface.cpp is called and it creates a pointer to the class phosphor::network::VlanInterface. phosphor::network::VlanInterface inherits from phosphor::network::EthernetInterface in turn and calls the phosphor::network::EthernetInterface constructor when the VlanInterface pointer is created.

Inside the EthernetInterface constructor, the code EthernetInterfaceIntf::nameservers(getNameServerFromResolvd()) executes and it causes the phosphor-networkd to abort. In the EthernetInterface::getNameServerFromResolvd function, it calls EthernetInterface::ifIndex to identify the index mapped to the interface.

EthernetInterface::ifIndex uses if_nametoindex to resolve the index mapped to the variable interfaceName and the interfaceName's value is eth1.2, which doesn't exist for the time being.

I'm not sure that if I apply the change correctly but the abort still remains after applying it.

I'm not sure that EthernetInterfaceIntf::nameservers(getNameServerFromResolvd()) could work as expected under the condition that the VLAN interface doesn't exist in advance where the function requires.

Thank you again.

Regards, Tyrone

wak-google commented 1 year ago

I believe this should be fixed, please retest and open again