We are developing a RPC system with client in ubuntu system and server in Solaris system.
Currently we are struck at this error: "RPC: Unknown Protocol"
can some one help us with this?
Change "visible" to "tcp" in clnt_create() call.
Run your program with strace to see if you are missing any critical files. In my case, it made me realize that I was missing libnss_files and libnss_dns libraries, and the problem went away once I added them.
Related
So I want to build avahi for linux arm device, but currently my kernel doesn't support ipv6.
Is it possible if I want disable ipv6 feature on avahi? What ./configure command argument do I need?
Also I will provide more information if you need.
Thank you.
I looked inside the configure file in the avahi source-code, but I didn't find something that related to IPv6.
I solved my problem with building another toolchain that support IPv6. It was successfully build the avahi, but maybe I need disable IPv6 in avahi-daemon.conf instead because my kernel doesn't support IPv6.
Thank you.
Update:
I was successfully running avahi-daemon binary to publish a service. If I set use-ipv6 in avahi-daemon.conf to yes, it will still running, but I am getting this message:
socket() failed: Address family not supported by protocol
Failed to create IPv6 socket, proceeding in IPv4 only mode
socket() failed: Address family not supported by protocol
So I will set use-ipv6 to no instead, and of course the message disappear.
I am working custom platform based on x86_64 running 3.10 kernel,
Recently I found an issue related to GARP. It seems like no GARP
packets are being sent out when an Interface is made up. But I also
noticed that only when I use "arping" tool only then it sends out any
GARP packet.
I also try setting the net variable "arp_notify" then I see the
arp_send() function is being called after that I am unable to track
further.
Could you please help me, what could be issue, Is it a valid
expectation that during interface up the linux kernel should send out
GARP packet? If so, am I missing any kernel configuration related to
it?
Thanks in Advance.
I have an embeeded system that I like to add zeroconf to it. The aim is:
Auto assign an IP to itself if there is no dhcp available.
It respond to mdns request and identify itself correctly.
It responds to dns-ds and broadcast its capability correctly.
Is there any library that can help me on this?
I found Avahi (http://avahi.org/) but it seems there is no development on it for some years. Is it still a good solution?
My device has Linux 2.x on it.
Avahi seems to be the de-facto standard implementation of Zeroconf for Linux and it is used pretty much everywhere. The last release is from 2012 but this does not mean it is dead -- it may just mean that it is mature and stable enough and there has been no need for additional releases yet.
The situation is this: I have a USB device (a custom device I'm trying to talk to) with two endpoints, one writing to the device, one reading from the device. Both are bulk transfers. Every communication transaction takes the form of (1) Write a command to the device (2) Read the response. I'm using libusb (version 0.1 rather than the 1.0 beta) to actually perform the communications.
On Windows, all is well. I can connect the device, claim the interface and communicate happily. However, in Ubuntu (a standard Hardy desktop install), whilst I can connect to the device and write to it, all read operations fail with the error "error submitting URB: Invalid argument" reported from libusb (error code -22).
If I check /var/log/messages I see a warning message logged for the same time as the read was attempted: "sysfs: duplicate filename 'usbdev4.3_ep81' can not be created" - which tallies with the device (it is indeed on that bus and it's endpoint 81 I'm trying to read from).
So... anyone seen a similar problem using libusb, or have any idea how to fix it?
Turns out it was a misconfiguration in the descriptors on the device itself. lsusb -v showed an extra interface which was never used, which had a single isochronous endpoint 0x81. Since this was never used (and had never been tested as far as I could see, so quite possibly not even defined correctly) I removed it from the device descriptors completely (in the firmware).
And now I have a fully working device. Why linux refused to read from the device but Windows worked fine I don't know, but it definitely sent me on a wild goose chase.
I haven't used libusb in quite some time -- but the sysfs error indicates that this is likely to be a kernel problem rather than a libusb one, so I'd start by trying to track that one down. (Not much point in trying to work with libusb until you're sure your kernel is talking to the device correctly).
Does the patch at http://kerneltrap.org/mailarchive/linux-usb-devel/2007/10/17/345922 apply to your kernel? (If so, does it fix the issue?)
I had to do some hacking to udev rules to get the device created with the right permissions for libusb to work. Like so:
SUBSYSTEM=="usb" ATTRS{idVendor}=="0a81", ATTRS{idProduct}=="0701", \
MODE="0666" SYMLINK+="missile_launcher"
(This was an usb missile launcher I was writing a driver for.
Also this snippet was required to not clash with the kernel.
if(LIBUSB_HAS_DETACH_KERNEL_DRIVER_NP)
{
// Detach kernel driver (usbhid) from device interface. (Linux hack)
usb_detach_kernel_driver_np(launcher, 0);
usb_detach_kernel_driver_np(launcher, 1);
}
I'm not sure how this relates to your problem, but atleast there are two possible points of failure that might be involved.
You can try WinDriver it's a commercial tool but have free full function evaluation (somehow time limited). You can check with WinDriver and if problem is reproducible it's might be device or your protocol fault. You did not give enough information to determine or analyze.
Attempt to send a message through a socket failed with WinSock error 10038. After around 40 seconds, messages are received successfully from the same socket and subsequently the send() is also succeeding in the same socket. This behaviour has been witnessed in Windows Server 2003. Is this any known behaviour with WinSock and Windows Server 2003?
Winsock error 10038 means "An operation was attempted on something that is not a socket".
Little trick to find info about error codes (usefull for all sorts of windows error codes):
Open a command prompt
Type "net helpmsg 10038"
What language is your application written in? If it's C/C++, could it be that you are using an invalid socket handle?
Thanks so much to a_mole for the idea of checking for layered winsock providers. We are having problems with some of our PC's and TimesTen DB. When we try to setup and ODBC Client DSN, we get a 10038 error. On examining the netsh output from the affected PC's, we found that they have Embassy Trust Suite by Wave Systems installed. Evidently Dell pre-installed this on some of their PC's. Anyway, on uninstalling this software, the problem has been solved.
Thanks again
Lou
Not a platform issue, I can guarantee that. Most likely, whatever variable you are using to access the socket handle is not thread-safe and is being used in the send() call before the actual socket is created.
Another possible cause is the presence of layered winsock providers. "netsh winsock show" at a cmd prompt will show you the installed providers and you can try removing any non-microsoft ones.