I thought I would try out SDP on our infiniband hardware.
However, when I try to add AF_INET_SDP as the first argument to socket() I get the following error:
"Address family not supported by protocol".
Originally I had:
#define AF_INET_SDP 26
But after doing some reading, noticed a patch applied some time back to change this value to 27.
When set to 26 I get the error:
"Error binding socket: No such device"
Has anyone managed to get SDP working on Ubuntu 12.04? what did you do to get it up and running?
I have installed libsdp1 and libsdpa-dev
Using the LD_PRELOAD method on iperf I also get the first error:
LD_PRELOAD=libsdp.so iperf -s
dir: /tmp/libsdp.log.1000 file: /tmp/libsdp.log.1000/log
socket failed: Address family not supported by protocol
bind failed: Bad file descriptor
Therefore I assume 27 is the correct domain number.
SDP hasn't been accepted on the mainline linux kernel. On recent fedora, they don't ship it, neither the user space libsdp.
If you still want to experiment, Matt is right, the module in question is 'ib_sdp'.
try modprobe ib_sdp and run your example again.
Related
I'm writing a small c program to make tape status and seek requests via
ioctl(int fd, long int request, &io_buf)
but after trial and plenty of error, ioctl is returning -1 with the errno message "Invalid Argument"
I'm on Linux and running my program as sudo. The device I want to issue requests to is an optical drive, connected via SCSI. I've tried tape status and seek requests by passing requests (MTIOCGET or MTIOCTOP, respectively) to ioctl.
Code snippet for tape status function where fd is the file descriptor of the device returned by open() and mtgetbuf is an instance of the mtget struct from sys/mtio.h
stat = ioctl(fd, MTIOCGET, &mtgetbuf);
if (stat == -1)
{
perror("error on ioctl MTIOCGET request: ")
return EXIT_FAILURE;
}
Similar code snippet for seek tape function except mtopbuf is an instance of the mtop structure and MTSEEK is the defined op code for the seek operation, also in sys/mtio.h
mtopbuf.mt_op = MTSEEK;
stat = ioctl(fd, MTIOCTOP, &mtopbuf);
if (stat == -1)
{
perror("error on ioctl MTIOCGET request: ")
return EXIT_FAILURE;
}
Instead of invalid argument error messages and a return of -1, I would have expected a successful return from ioctl and the respective structure instances, mtgetbuf and mtopbuf, to have their members populated with data provided by the device.
I.e. A successful ioctl() command with the MTIOCGET request would return into the mtgetbuf mt_type member a value of either MT_ISSCSI1, MT_ISSCSI2, or MT_ISUNKNOWN (I don't believe it is any of the other defined values for other vendor-specific devices).
Note: I'm aware of the linux/mtio.h header file and I have tried including that in place of sys/mtio.h but the outcome is the same.
I've recently had success issuing requests to a block device using the SCSI Generic Linux driver (SG). There are three header files (below) that have provided op codes, structures used to pass and retrieve data from the device, among other information.
SCSI SG Header files:
/usr/include/scsi/scsi.h
/usr/include/scsi/scsi_ioctl.h
/usr/include/scsi/sg.h
A combination of online resources were instrumental in understanding how to package, send, and receive requests:
1) The TLDP SCSI Generic (sg) HOW-TO guide is a font of information on communicating to SCSI devices via the SG driver. A link to it is provided here. It explains in detail various commands that can be issued, how to package the commands by creating an instance of the sg_io_hdr_t structure, as well as a programming example to send a SCSI INQUIRY command which returns basic vendor information of the device. There are also status and sense codes for error handling and understanding unsuccessful SCSI requests.
2) Seagate's SCSI Command Reference Manual was helpful at times to understand the structure of bytes/bits in a SCSI command. Typically the op code occupied the first byte and the remaining bytes were zeros. The op codes in this reference manual were defined between those three header files mentioned above.
I have been able to send successful INQUIRY and GET_SG_VERSION_NUMBER requests and most likely have been able to send SEEK(6), READ_CAPACITY(10), and REZERO_UNIT commands. I say most likely because -1/errno values are not being returned and no information is being passed back into the sense buffer which is an indication of warnings/errors (either SCSI, host adapter, or driver status codes).
Hope this answers OPs question.
I want to use mongodb c driver in my project, I'm on Windows 7 so built it with command :
scons --m32 --c99
My problem is I can't make the Connecting example work :
#include <stdio.h>
#define MONGO_HAVE_STDINT
#include "mongo.h"
int main() {
mongo conn[1];
int status = mongo_client( conn, "127.0.0.1", 27017 );
printf("status %d, err %d", status, conn->err);
mongo_destroy( conn );
return 0;
}
Whether mongod is running on my machine or not, the output of executing the exe is :
$ ./mongodb_example.exe
status -1, err 3
Error 3 corresponds to MONGO_CONN_ADDR_FAIL error code (An error occured while calling getaddrinfo()).
Any suggestion about how to connect successfully ?
Updates:
version is mongodb-mongo-c-driver-v0.8.1-0-g8f27c0f
So there are two things you need to do to make this work:
When building with scons, you need to make sure you that you enable the "standard-env" target like so:
scons --m32 --standard-env
Secondly in your code and in addition to the MONGO_HAVE_STDINT that you already have, make sure you call mongo_init_sockets() before establishing a connection. This is required on windows.
#include <stdio.h>
#define MONGO_HAVE_STDINT
#include "mongo.h"
int main() {
mongo_init_sockets();
mongo conn[1];
int status = mongo_client( conn, "192.168.2.7", 27017 );
printf("status %d, err %d", status, conn->err);
mongo_destroy( conn );
return 0;
}
So the first part resolves the issue with getaddrinfo() there is an implementation included in the "standard environment". And the second part is a necessary "winsock" initialization that is required on Windows platforms. In the test files this is implemented with a defined macro.
Also make sure you are using a Python 2.7 32bit (not 64bit) as well. Not too sure how valid that is on a current scons release, but it doesn't hurt to be sure.
Some of this is in the documentation you may have missed here, as is the fairly apt description of the mongo_init_sockets() function in the API documentation. Of course, looking at the test files in the distribution did not hurt.
And a little pain for me, as I don't normally build C programs on Windows.
You can get the exact reason of the mongo failure if you print
conn->errcode
conn->errstr
The errcode is the equivalent of errno in linux or GetLastError in Windows.
The errstr will contain the same as a string. So you shall see something like getaddrinfo failed with error <the return status of getaddrinfo>
There could be multiple reasons why getaddrinfo might fail in your system. You can get these values from the man page man gai_strerror (errstr should report this)
EAI_AGAIN temporary failure in name resolution
EAI_BADFLAGS invalid value for ai_flags
EAI_BADHINTS invalid value for hints
EAI_FAIL non-recoverable failure in name resolution
EAI_FAMILY ai_family not supported
EAI_MEMORY memory allocation failure
EAI_NONAME hostname or servname not provided, or not known
EAI_OVERFLOW argument buffer overflow
EAI_PROTOCOL resolved protocol is unknown
EAI_SERVICE servname not supported for ai_socktype
EAI_SOCKTYPE ai_socktype not supported
EAI_SYSTEM system error returned in errno
I haven't used the mongodb c driver, so this is just a guess. From the tutorial, it looks like you skipped the initialization step:
http://api.mongodb.org/c/current/tutorial.html
mongo conn[1];
mongo_init( conn );
...
mongo_client( conn, "127.0.0.1", 27017 );
I have written one client application , which uses the mdnsreponder for some service discovery . I have one requirement that my client IP will get change very frequently. whenever there is a change in the IP I need to do the discovery again .
So I have written simple test application which will change the IP for every 1 min and do the discovery .
Everything works fine but after few IP changes(some 7-10 times changed) it gives below socket error .
(below is the error code of sendto socket function in the mdnsresponder code)
mdnsplatformsend udp got error 22 .
After that my request will not put it on the interface with new IP.
Again I have to restart my application, then only it works...
Can somebody help to figure out the problem, why does it stop after a few trials?
Please re check the parameters of sendto function that you are passing. This error can be occurred when the socket binding is lost. That means the address where the socket is bound has changed or invalid. The error can also be caused because of wrong size of the address structure that you are passing.
I apparently inadvertently changed some setting so all SCPI commands sent to my device that include a question mark throw a -110 (Command Header Error) as documented here:
-110 Command Header Error - Indicates there is a syntax error in the command. In this case two colons between SENSE and VOLT.Example " :SENSE::VOLT:RANGE 10"
All other commands (when used properly, of course) work fine.
Because of the error, my guess is that there's something wrong with how my computer is sending non-letters?
Note: I'm sending commands using #echo "READ?" > /dev/ttyS0. I still receive a reply using cat /dev/ttyS0 but I get a beep and error. (Same error occurs in my C code)
Just figured out the solution!
It appears that somehow (perhaps the blue screen I had yesterday on the Windows where I was running my linux VM from) the settings for ttyS0 were reset so that there was software flow control for sending data but not receiving. Thus, my transmissions didn't work with either no flow control or xon_xoff.
To fix this, I set no flow control on my external serial device and ran stty -F /dev/ttyS0 -ixon on the linux box.
Alternatively, I could have set flow control on the serial device to xon_xoff and ran stty -F /dev/ttyS0 ixoff on the linux box.
I compile snmptrap as a "stand alone" application to run on an enbedded device.
Sending trap with IPv4 works like a charm, but when using an IPv6 address as the destination, the following is showing in the logs:
tdomain: tdomain_transport_full("snmptrap", "udp6:[fd64:3ef5:bb33::2]", 0, "[NIL]", "[NIL]")
tdomain: Found no domain from specifier "udp6"
I compiled my net-snmp (v5.7.2) libraries with
--enable-ipv6
--with-mib-modules="mibII/ipv6 host notification snmpv3mibs"
--with-transports="UDPIPv6 TCPIPv6"
And excecute the commandline app as:
snmptrap -v 1 -M ./mibs/ -c public 'udp6:[fd64:3ef5:bb33::2]' '1.2.
3.4.5.6' '172.16.11.144' 6 99 '55' 1.11.12.13.14.15 s "teststring"
Can anyone point me in the right direction for solving this?
Cheers,
Frank
Make sure the Ipv6[fd64:3ef5:bb33::2] address is reachable, and you have successfully compiled the net-snmp library using --ipv6 enable,
After compilation you have instructed the snmpd to use both udp and udp6 protocol.
you can debug the SNMP protocol using Wireshark
Alternately you can try other client as well to send the IPv6 pdu to make sure your client is sending the right data.