How to run IPMI tool from the openBMC romulus image. I was successful in running the Hello World program as per the tutorials. I want to run IPMI tool command from the romulus to the BMC of another server. Is there is any method of doing this? As ipmitool command is not included. Is there any way of including it in the romulus Image.
ipmitool is really meant to be used outside of the BMC to control it. So in most use cases you install the ipmitool package on your computer (sudo apt install ipmitool), and then use it to talk to the server.
i.e.:
ipmitool -I lanplus -U root -H <server> -P <password> chassis power status
If you're using QEMU, then I believe you need to hostfwd port 623 for this to work. I personally have not gotten ipmitool to talk to a QEMU session before though.
If you really want ipmitool in your BMC image, then you could add it as a RDEPENDS to the packagegroup file similar to what facebook does in https://github.com/openbmc/meta-facebook/blob/master/meta-tiogapass/recipes-fbtp/packagegroups/packagegroup-fb-apps.bb
Romulus does not have ipmitool in it OpenBMC firmware image, as do some other OpenBMC platforms; not all platforms have the SPI FLASH space supply many utilites. You can use ipmitool from a remote machine to a Romulus like below.
ipmitool -I lanplus -C 17 -p 623 -U root -H <server> -P <password> bmc info
or
ipmitool -I lanplus -C 17 -p 623 -U root -H <server> -P <password> raw 0x06 0x01
I chose to use -C 17 for cipher suite 17 as ipmitool defaults to cipher suite 3 and modern platforms have deprecated cipher suite 3 for security reasons.
Cipher suites 3 and 17 were last 2 suites that had any security strength, and 17 is the stronger (do not read that as strong) and now suite 3 is considered weak.
and here are the ipmitool commands:
usage: ipmitool [options...] <command>
-h This help
-V Show version information
-v Verbose (can use multiple times)
-c Display output in comma separated format
-d N Specify a /dev/ipmiN device to use (default=0)
-I intf Interface to use
-H hostname Remote host name for LAN interface
-p port Remote RMCP port [default=623]
-U username Remote session username
-f file Read remote session password from file
-z size Change Size of Communication Channel (OEM)
-S sdr Use local file for remote SDR cache
-D tty:b[:s] Specify the serial device, baud rate to use
and, optionally, specify that interface is the system one
-4 Use only IPv4
-6 Use only IPv6
-a Prompt for remote password
-Y Prompt for the Kg key for IPMIv2 authentication
-e char Set SOL escape character
-C ciphersuite Cipher suite to be used by lanplus interface
-k key Use Kg key for IPMIv2 authentication
-y hex_key Use hexadecimal-encoded Kg key for IPMIv2 authentication
-L level Remote session privilege level [default=ADMINISTRATOR]
Append a '+' to use name/privilege lookup in RAKP1
-A authtype Force use of auth type NONE, PASSWORD, MD2, MD5 or OEM
-P password Remote session password
-E Read password from IPMI_PASSWORD environment variable
-K Read kgkey from IPMI_KGKEY environment variable
-m address Set local IPMB address
-b channel Set destination channel for bridged request
-t address Bridge request to remote target address
-B channel Set transit channel for bridged request (dual bridge)
-T address Set transit address for bridge request (dual bridge)
-l lun Set destination lun for raw commands
-o oemtype Setup for OEM (use 'list' to see available OEM types)
-O seloem Use file for OEM SEL event descriptions
-N seconds Specify timeout for lan [default=2] / lanplus [default=1] interface
-R retry Set the number of retries for lan/lanplus interface [default=4]
Interfaces:
open Linux OpenIPMI Interface [default]
lan IPMI v1.5 LAN Interface
lanplus IPMI v2.0 RMCP+ LAN Interface
serial-terminal Serial Interface, Terminal Mode
serial-basic Serial Interface, Basic Mode
Commands:
raw Send a RAW IPMI request and print response
i2c Send an I2C Master Write-Read command and print response
spd Print SPD info from remote I2C device
lan Configure LAN Channels
chassis Get chassis status and set power state
power Shortcut to chassis power commands
event Send pre-defined events to MC
mc Management Controller status and global enables
sdr Print Sensor Data Repository entries and readings
sensor Print detailed sensor information
fru Print built-in FRU and scan SDR for FRU locators
gendev Read/Write Device associated with Generic Device locators sdr
sel Print System Event Log (SEL)
pef Configure Platform Event Filtering (PEF)
sol Configure and connect IPMIv2.0 Serial-over-LAN
tsol Configure and connect with Tyan IPMIv1.5 Serial-over-LAN
isol Configure IPMIv1.5 Serial-over-LAN
user Configure Management Controller users
channel Configure Management Controller channels
session Print session information
dcmi Data Center Management Interface
nm Node Manager Interface
sunoem OEM Commands for Sun servers
kontronoem OEM Commands for Kontron devices
picmg Run a PICMG/ATCA extended cmd
fwum Update IPMC using Kontron OEM Firmware Update Manager
firewall Configure Firmware Firewall
delloem OEM Commands for Dell systems
shell Launch interactive IPMI shell
exec Run list of commands from file
set Set runtime variable for shell and exec
hpm Update HPM components using PICMG HPM.1 file
ekanalyzer run FRU-Ekeying analyzer using FRU files
ime Update Intel Manageability Engine Firmware
vita Run a VITA 46.11 extended cmd
lan6 Configure IPv6 LAN Channels
Related
For various reasons, I'm trying to get a Soft-ROCE setup working. The plan is to move to RDMA-capable hardware, later, but for now Soft ROCE is a good choice to get started. I've started with some tutorials on Infiniband APIs, and they mostly make sense. However, I haven't been able to get even a single transaction working in a loopback device.
I created an rxe device using the following command:
# rdma link add rxe_lo type rxe netdev lo
It seems to come up fine, but none of the utilities I run seem to do anything (rping, ibv_rc_pingpong, etc.).
With my loopback device, rping fails like this:
# rping -c -v -a 127.0.0.1
rdma_resolve_route: No such device
If I create Soft ROCE devices on two separate computers, and then run that over the network, rping at least works:
# rdma link add rxe_eno1 type rxe netdev eno1
# # do the same on different computer...
# rping -s -v -a 0.0.0.0
# rping -c -v -a 192.x.y.z # on other computer
Is this a futile attempt, or is there a technical reason why local loopbacks won't work with Soft RDMA? I tried this on an Ubuntu and Fedora system, with the same results.
I am working on an IoT device. I have installed Eclipse Kura in raspberry pi 3
to use it as a gateway. I want to publish a message to Kapua server (installed in the same network) using Kura or directly using the raspberry pi. I have tried both methods.
1- Using Kura
I have followed the given instructions on GitHub Kura Kapua connection tutorial #780. After following these steps I am able to establish the Kura Kapua connection but unable to send data, Example.publisher package is also installed in Kura. I want to create a topic and publish data on that topic.
2- Using MQTT-Client library
I have installed the MQTT-Client library in raspberry pi and use the following commands to publish and subscribe the data.
To Publish :
sudo mosquitto_pub -h "broker-URL" -p "Port" -t "topic" -m "message" -u "user-name"-P "user-pass" -i "client-id"
To subscribe :
sudo mosquitto_pub -h "broker-URL" -p "Port" -t "topic" -u "user-name"-P "user-pass" -i "client-id"
this has the same behavior, It also establishes the connection but unable to create the topic and publish data.When I do the same for localhost it does send the message. I am using two different terminals to publish and subscribe.
Is there any method or example where I can actually send some data and observe at the other end using Kura or MQTT.
General knowledge
Correct connection parameters (if you followed the tutorial you mentioned) are:
-h localhost
-p 1883
-u kapua-broker
-P kapua-password
(not sure the doublequote is required)
Kapua uses has a specific topic format to grant access control over the topics.
The semantic of the format is:
{account-name}/{client-id/{semantic-topic}
Depending on your privileges you can access different levels of topics.
The defaults user kapua-broker allows only to connect, publish and subscribe under:
{kapua-sys}/{connection-client-id}/#
You need more permissions to subscribe to other client-id topics.
The permission required to do that is:
data:view
Your example
First, it seems that you are using the published to subscribe. This is your command.
sudo mosquitto_pub -h "broker-URL" -p "Port" -t "topic" -u "user-name"-P "user-pass" -i "client-id"
Secondly credential, host, usenrname, password, and topic are all wrong (unless you "obscured" them before publishing to SO).
To make your test work you need to use the following commands,
Subscribe
mosquitto_sub -h "localhost" -p "1883" -t "kapua-sys/mosquitto_pub/my/test/topic" -u "kapua-sys" -P "kapua-password" -i "mosquitto_sub"
Publish
mosquitto_pub -h "localhost" -p "1883" -t "kapua-sys/mosquitto_pub/my/test/topic" -m "My test message" -u "kapua-broker" -P "kapua-password" -i "mosquitto_pub"
For the Kura example publisher, I don't know where could be the problem, due to lack of info. I'm assuming you are publishing or subscribing to a topic you cannot access to due to write/read permission on topics.
Hope that this help! :)
I want to connect my raspberry pi 3 via Ethernet to the Interet. The problem is that in my student dorm they use 802.1X as network authentication. I found this tutorial: https://help.ubuntu.com/community/Network802.1xAuthentication and did the steps.
So i modified /etc/wpa_supplicant/wpa_supplicant.conf. It looks like this now:
ctrl_interface=/var/run/wpa_supplicant
eapol_version=2
ap_scan=0
network={
key_mgmt=IEEE8021X
eap=PEAP
identity="loginname"
password="password"
phase1="peaplabel=0"
phase2="auth=MSCHAPV2"
}
But when i run:
sudo wpa_supplicant -c /etc/wpa_supplicant/wpa_supplicant.conf -D wired -i eth0
The output is:
Succesfully initialized wpa_supplicant
ioctl[SIOCGIFFLAGS]: No such device
setsockopt: No such device
ioctl[SIOC{ADD/DEL}MULTI]: No such device
ioctl[SIOCGIFFLAGS]: No such device
wpa_driver_wired_init: Could not get interface flags
eth0: Failed to initialize driver interface
And i dont have a connection.
I've absolute no knowledge about the protocol you ask about, but as far as I know the new raspbian, has changed the names of the network interface "eth0" to enp3s0 or so.
You can verify my assuption by performing sudo ifconfig -a.
Then you get a list off all your interfaces. If "eth0" is not in this list, there should be something like "enpXsY". In this case you just have to change the "eth0" in the command above to the new interface name. E.g.:
sudo wpa_supplicant -c /etc/wpa_supplicant/wpa_supplicant.conf -D wired -i enp0s3
Hope that helps!
I have a system with arch linux running OVS. I also have a controller running in the same box. I have the following setup:-
ovs-vsctl set-controller br-int tcp:192.168.1.201:6633
I was hoping to use tshark( tshark 2.2.8) to capture the openflow using the following command:-
sudo tshark -i br-int -d tcp.port==6633,openflow -O openflow_v4
it dumps all the all the flows that is flowing in the system but no packetIn openflow messages. I did confirm packetIn message was received by the controller. ( pasting the last few lines:-)
EVENT ofp_event->EventOFPPacketIn
packet in 1237689849893337 b8:27:xx:xx:yy:yy:zz ff:ff:ff:ff:ff:ff:3
I also understand from the tshark document that by default it uses the port 6653 for openflow.
tshark -G decodes | grep -i openflow
tcp.port 6653 openflow
However I was in the impression that I can still look for openflow traffic by using the following capture command:-
https://wiki.wireshark.org/OpenFlow
tshark tcp port 6633
This also doesn't work as no events are captured though I can see the controller receiving lots of events..
would greatly appreciate any help here.
My guess would be that you're not listening on the correct interface. Try the following:
sudo tshark -i any -d tcp.port==6633,openflow -O openflow_v4
If that doesn't work, it's possible your controller and switch are not communicating using OpenFlow 1.3. To make sure you see everything, try:
sudo tshark -i any -d tcp.port==6633
Details. Unless there's something particular in your setup, packets from Open vSwitch to the controller and back do not go through the bridge. Since both ends of the communication are on the same host, packets are probably going through the loopback interface:
sudo tshark -i lo -d tcp.port==6633
I was able to reproduce your setup and issue to confirm my answer with Open vSwitch 2.5.2 and Floodlight (master branch). I can see packets passing through on the loopback interface with both tcpdump and tshark.
I was trying to setup an SSH connection with Github following this tutorial:
Testing your SSH connection
I came across the following command:
$ ssh -T git#github.com
# Attempts to ssh to github
Curious, I looked at the ssh manual. It said the following:
-T Disable pseudo-tty allocation.
What is tty allocation? What does tty stand for? Why are we disabling it?I earnestly tried to look it up but I was unable to find even a definition.
As explained in "gitolite: PTY allocation request failed on channel 0", it is important to do ssh test connection with -T, because some server could abort the transaction entirely if a text-terminal (tty) is requested.
-T avoids requesting said terminal, since GitHub has no intention of giving you an interactive secure shell, where you could type command.
GitHub only wants to reply to your ssh request, in order to ascertain that the ssh command does work (you have the right public/private keys, and the public one has been registered to your GitHub account)
PuTTy would be an example of a terminal emulator, serial console and network file transfer application. It supports several network protocols, including SCP, SSH, Telnet and rlogin.
The name "PuTTY" has no definitive meaning, though "tty" is the name for a terminal in the Unix tradition, usually held to be short for Teletype.
Other use-cases for -T (beside testing)
Transferring binary files
Execute commands on a remote server
SSH tunneling: ssh -fnT -L port:server:port user#server (-f for background: you don't want to execute command, don't need a TTY and just want to establish a tunnel)