I have a problem in my C client, where I implemented a client gsoap program to invoke a web service.
Everything works fine on a Windows PC, but when I publish my code on a linux-based POS device, I receive the following error:
"setsockopt SO_SNDBUF failed in tcp_connect()"
Where should I start to debug this error, what could be the cause?
the errornum returned is 2
The code section that generates the error : (in stdsoap2.c)
if (setsockopt(sk, SOL_SOCKET, SO_SNDBUF, (char*)&len, sizeof(int))){
soap->errnum = soap_socket_errno(sk);
soap_set_sender_error(soap,
tcp_error(soap),
"setsockopt SO_SNDBUF failed in tcp_connect()",
SOAP_TCP_ERROR);
soap->fclosesocket(soap, sk);
#ifdef WITH_IPV6
freeaddrinfo(ressave);
#endif
return SOAP_INVALID_SOCKET;
}
How big is the len argument? It's possible that the value works on Windows, but is rejected by linux for some reason. Take a look at the actual values being submitted and see if they look reasonable.
You can also try reducing this down to a very small program that just sets up a socket and tries to replicate the call to setsockopt() and see if it still fails with the SO_SNDBUF size the main program is trying to use.
well it turned out to be very simple one!!
i just had to build the c/c++ files using the binaries dedicated for linux....
gsoap(wsdl2h,soapcpp2)
windows build uses winsock and linux build uses standard sockets
and the sockets on the 2 systems are differentes!
thats why i was receiving the socket error.
hope this help others, getting this socket error msg..
Related
I have used Eclipse, Jython & Pydev for a long time. Upgrading as and when new releases arrived. All has worked very well until recently when the Pydev code completion started marking common items such as dir or print as 'undefined variable'. But the program ran correctly.
The error log showed:
'The python client still hasn't connected back to the eclipse java vm (will retry..)'
'Attempt: 2 of 5 failed, trying again...(socket connected still null)'
and more attempts to 5 out of 5
'Error connecting to python process(most likely cause for failure is firewall blocking...misconfigured network)'
Also, attempting to create a live jython console CTRL+ALT+ENTER gives the following error:
'Create interactive Console' has encountered a problem
Error initializing console.
Unexpected error connecting to console.
Failed to receive suitable Hello response from pydevconsole. Last msg received: Console already exited with value: 1 while waiting for an answer.
I have spent a lot of time looking for answers here and elsewhere that have included suggestions to check:
Mixed 32/64 bit installs; Firewall problems; IPV4 preference; localhost entries; path issues and others: all I've checked out with no success so far.
Software is Windows 10, Eclipse 4.21.0, Pydev 9.1.0.2021, Java JDK 11.0.13, Jython 2.7.2
I should be most grateful for any further help on this problem.
Many thanks
Well, you get that message because PyDev does spawn a shell and communicate with it for collecting code-completion results and the same happens for the interactive console.
Now, in both cases it seems like the socket communication is being prevented in your use case (as the messages states, the usual culprit is some firewall -- or possibly an anti-virus -- or some network misconfiguration).
Unfortunately, it's really hard for me to diagnose this as it's pretty much machine-dependent (all I can say is that I checked things here and Jython is working well, so, the issue lies in some misconfiguration on your machine).
I actually have plans to stop requiring that socket communication (for getting the completions from a shell) and using stdin/stdout (https://www.brainwy.com/tracker/PyDev/1183), but this still isn't done.
As Jython does run for you, you can try to create a simple server to verify a connection works.
i.e.: Create an echo_server.py with:
import socket
if __name__ == '__main__':
HOST = '127.0.0.1'
PORT = 65432
s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.bind((HOST, PORT))
s.listen(1)
conn, addr = s.accept()
print('Connected by', addr)
data = conn.recv(1024)
conn.sendall(data)
print('Echo server finished')
and a client.py with:
import socket
if __name__ == '__main__':
HOST = '127.0.0.1'
PORT = 65432
s = socket.socket(socket.AF_INET, socket.SOCK_STREAM)
s.connect((HOST, PORT))
s.sendall(b'Hello, world')
data = s.recv(1024)
print('Received %r' % (data,))
Then run the server part and then the client part and check if that does work properly for you.
I have an issue,there is a piece of code which is in tcl opens a client socket in Linux. Because of my tests the socket is connection timed out after 2 hours. I'm looking for commands in tcl to keep alive the opened socket. So far I have got setsockopt,SO_KEEPALIVE all of these are in C language. Can someone help me how do we keep alive sockets in tcl.
I tried with setsockopt but it didn't worked as it is in C.I looked at tcp_keepalive_time,tcp_keepalive_intrvl,tcp_keepalive_probes which are in order 7200,75,9. I tried to modify those parameters but I dont have user permissions(admin restrictions).
if [catch {socket $use_host $use_port} comIdW] {
error "Error: Unable to connect to host $use_host port $use_port: $comIdW"
}
fconfigure $comIdW -buffering none -translation binary
set comIdR $comIdW
# I added following code based on my understanding
set optval 1
set optlen [llength $optval]
seetsockopt($comIdW,SOL_SOCKET,SO_KEEPALIVE,$optval,$optlen)
puts "SO_KEEPALIVE is ($optval ? "ON" : "OFF"))"
I wanted to keep this channel alive, it might be good If I can ping after 30 minutes of channel open
tried with setsockopt but it didn't worked as it is in C
There is currently no built-in way of setting at the script level the SO_KEEPALIVE on a socket controlled by Tcl as a Tcl channel (fconfigure). See also TIP#344.
I bought a HotPi a while ago, and decided to use it. So I followed the procedure to configure the IR and after a few hours I was able to IR signals on my Raspberry 1.
But my purpose here is to send IR signals, which I tried, without any luck.
So this is the command I try to do (just for test):
irsend SEND_START devinput KEY_POWER ; sleep 3
And this is what lircd tells me:
lircd-0.9.4c[907]: Notice: accepted new client on /var/run/lirc/lircd
lircd-0.9.4c[907]: Info: Cannot configure the rc device for /dev/lirc0
lircd-0.9.4c[907]: Error: invalid send buffer
lircd-0.9.4c[907]: Error: this remote configuration cannot be used to transmit
lircd-0.9.4c[907]: Error: error processing command: SEND_START devinput KEY_POWER
lircd-0.9.4c[907]: Error: transmission failed
lircd-0.9.4c[907]: Info: removed client
Edit:
It seems I'm not using the good drivers. According to the HotPi documentation, I'm suppose to use lirc-rpi, which I'm suppos to install with
sudo modprobe lirc-rpi
Which, at least, doesn't return an error. But trying to configure the interface tells me that the driver doesn't exist:
pi#raspberrypi:~ $ mode2 --driver lirc-rpi --device /dev/lirc0
Driver `lirc-rpi' not found. (Missing -U/--plugins option?)
Available drivers:
accent
alsa_usb
asusdh
atilibusb
atwf83
audio
audio_alsa
awlibusb
bte
bw6130
commandir
creative
creative_infracd
default
devinput
dfclibusb
dsp
dvico
ea65
file
ftdi
ftdi-exp
ftdix
girs
i2cuser
irlink
irtoy
livedrive_midi
livedrive_seq
logitech
macmini
mouseremote
mouseremote_ps2
mp3anywhere
mplay
mplay2
pcmak
pinsys
pixelview
samsung
sb0540
silitek
slinke
sonyir
srm7500libusb
tira
tira_raw
udp
uirt2
uirt2_raw
usb_uirt_raw
usbx
zotac
Here is no info what lirc version you are using. There are vast differences between the legacy 0.9.0 still used in some distros and modern lirc.
That said, the logs seems pretty clear. You are using the devinput driver, right? This driver does not support sending data, reflecting the fact that also the kernel doesn't.
You then need to use another driver - first stop might be the default one. If/when using this other driver, you need another lircd.conf.
Please refer to http://lirc.org/html/configuration-guide.html
EDIT: Ah, lirc-0.9.4c says the log. Sorry, my bad. The reply should still be valid, though.
When you record the remote, use:
irrecord -d /dev/lirc0 -f name.conf
The -f uses raw mode. This then worked for me on the transmit side, before I got same error as you.
I'm trying to communicate with an AD9913 evaluation board (Analog Devices), which has a Cypress FX-2 USB controller. I wrote a fully functional Python library which works flawlessly on Windows 7 (using a driver generated through libusb-win32-1.2.6.0's inf-wizard.exe), but now I try to run the same software from a Raspberry Pi 3 with Raspbian Jessie and cannot seem to write or read.
The following minimal example works on Windows 7:
import os
os.environ['PYUSB_DEBUG'] = 'debug'
import usb.core
print "usb.core file:", usb.core.__file__
# get device
dev = usb.core.find(idVendor=0x0456, idProduct=0xEE25)
if dev is None:
raise ValueError("Device not found")
dev.set_configuration()
# get the firmware version
print "Write: ", dev.write(0x01, [0x00])
print "Read: ", dev.read(0x81, 7)
The ouput here is:
usb.core file: C:\Python27\lib\site-packages\usb\core.pyc
Write: 1
Read: array('B', [1, 0])
However, on the Raspberry several problems occur. First, the product ID is 0xEE24 (which I found out through dmesg), and second, the code example above gives
usb.core file: /usr/local/lib/python2.7/dist-packages/usb/core.pyc
Write:
Traceback (most recent call last):
File "usbtesting_minimal_linux.py", line 29, in <module>
print "Write: ", dev.write(0x01, [0x00])
File "/usr/local/lib/python2.7/dist-packages/usb/core.py", line 948, in write
self.__get_timeout(timeout)
File "/usr/local/lib/python2.7/dist-packages/usb/backend/libusb1.py", line 824, in bulk_write
timeout)
File "/usr/local/lib/python2.7/dist-packages/usb/backend/libusb1.py", line 920, in __write
_check(retval)
File "/usr/local/lib/python2.7/dist-packages/usb/backend/libusb1.py", line 595, in _check
raise USBError(_strerror(ret), ret, _libusb_errno[ret])
usb.core.USBError: [Errno 5] Input/Output Error
I'm executing the script by calling sudo python minimal_example.py, otherwise (as expected) I get usb.core.USBError: [Errno 13] Access denied (insufficient permissions). (For the testing described above, I removed the udev rules I added to allow access to my regular user account, and rebooted and replugged the device afterwards.)
I also noticed that on Windows, Configuration 1 (which is the only configuration) as revealed by adding
cfg = dev.get_active_configuration()
to aforementioned example script, has only one Interface 0, where as on Linux Interface 0 has no endpoints, but there are additional interfaces Interface 0, 1, Interface 0, 2 and Interface 0,3, the first of which is identical to the sole interface shown by Windows.
Detaching kernel drivers as described in this post -- which given my current understanding as a USB novice should not be necessary here -- does not resolve the problem.
I suspect that the issue stems from a difference between the Windows/libusb and Linux implementation/backend of the USB communication (already hinted at by the fact that the productID shown is different for the very same piece of hardware attached), which might require some changes to the way I'm writing to the USB endpoint.
I'm happy to provide more information if needed and welcome all hints and suggestions.
Most likely, this error caused by the firmware is not uploaded. Usually speaking, FX-2 USB controller does not save the firmware.
Although I still cannot communicate with the device on the Raspberry Pi, the Error 5 problem is resolved by explicitly selecting a suitable alternate setting with proper endpoints, e.g.
dev.set_interface_altsetting(interface = 0, alternate_setting = 1)
Then read/write requests no longer fail with Error 5, but with a timeout error (which is Error 110 for libusb1 and None for libusb0).
I now suspect that there is a problem with how the device is detected by the operating system, since not only the productID changes between Windows and Linux, but also wMaxPacketSize for the endpoints I'm interested in is given as 64 bytes on Windows and 512 bytes on Linux.
Once I'm further along in my troubleshooting, I will either open a new question and add the link as a comment to this answer (or post the whole solution here in case I can solve everything right away).
I apologize if I'm a bit low on details here, but the main issue is actually trying to find the problem with my code. I'm updating an older extension of my own that was based on the Language Server example (https://code.visualstudio.com/docs/extensions/example-language-server). I've run into an issue where when I run the client part of my code using F5, and the debug window fires, I get:
The CSSLint Language Client server crashed 5 times in the last 3 minutes. The server will not be restarted.
Ok... so... here's the thing. The problems view in my extension client code shows nothing. DevTools for that Code window shows nothing.
The problems view for my server code shows nothing. DevTools, ditto.
For the Extension Developer Host instance, DevTools does show this:
messageService.ts:126 The CSSLint Language Client server crashed 5 times in the last 3 minutes. The server will not be restarted.e.doShow # messageService.ts:126
But I can't dig into the details to find a bug. So the question is - assuming that my server code is failing, where exactly would the errors be available?
Here is what I usually do to track server crashes down (I assume your server is written in JavaScript / TypeScript).
Use the following server options:
let serverModule = "path to your server"
let debugOptions = { execArgv: ["--nolazy", "--debug=6009"] };
let serverOptions = {
run: { module: serverModule, transport: TransportKind.ipc },
debug: { module: serverModule, transport: TransportKind.ipc, options: debugOptions}
};
Key here is to use the TransportKind.ipc. Errors that happen in the server and printed to stdio will then show in the output channel associated to your server (the name of the output channel is the name passed to the LanguageClient)
If you want to debug the server startup / initialize sequence you can change the debugOptions to:
let debugOptions = { execArgv: ["--nolazy", "--debug-brk=6009"] };
If the extension is started in debug mode (e.g. for example launched from VS Code using F5) then the LanguageClient automatically starts the server in debug mode. If the extension is started normally (for example as a real extension in VS Code) then the server is started normally as well.
To make this all work you need a latest version of the LSP node npm module both for server can client (e.g. 2.6.x)