We're attempting to use Zend_Ldap to authenticate users to our website using the subscriber's LDAP server. We have a couple clients already setup and working but when we added a new client the connection just hung and after 30 minutes(!) we received the following (less than helpful) error:
0x51 (Can't contact LDAP server): ldap://x.x.x.x
The only other debugging step I know is to use ldapsearch. If I do just ldapsearch -h x.x.x.x nothing happens for a very long time (I don't feel like waiting 30 minutes but I'm guessing I'll get the "Can't connect to LDAP server" error) and if I run it using -d5 I get the following output.
ldap_create
ldap_url_parse_ext(ldap://x.x.x.x)
ldap_extended_operation_s
ldap_extended_operation
ldap_send_initial_request
ldap_new_connection 1 1 0
ldap_int_open_connection
ldap_connect_to_host: TCP x.x.x.x:389
ldap_new_socket: 3
ldap_prepare_socket: 3
ldap_connect_to_host: Trying x.x.x.x:389
ldap_pvt_connect: fd: 3 tm: -1 async: 0
ldap_open_defconn: successful
ldap_send_server_request
ber_scanf fmt ({it) ber:
ber_scanf fmt ({) ber:
ber_flush2: 31 bytes to sd 3
ldap_result ld 0x7f9ad5666410 msgid 1
wait4msg ld 0x7f9ad5666410 msgid 1 (infinite timeout)
wait4msg continue ld 0x7f9ad5666410 msgid 1 all 1
** ld 0x7f9ad5666410 Connections:
* host: x.x.x.x port: 389 (default)
refcnt: 2 status: Connected
last used: Mon Jul 13 09:14:44 2015
** ld 0x7f9ad5666410 Outstanding Requests:
* msgid 1, origid 1, status InProgress
outstanding referrals 0, parent count 0
ld 0x7f9ad5666410 request count 1 (abandoned 0)
** ld 0x7f9ad5666410 Response Queue:
Empty
ld 0x7f9ad5666410 response count 0
ldap_chkResponseList ld 0x7f9ad5666410 msgid 1 all 1
ldap_chkResponseList returns ld 0x7f9ad5666410 NULL
ldap_int_select
<20+ minute delay>
read1msg: ld 0x7f9ad5666410 msgid 1 all 1
ber_get_next
ldap_err2string
ldap_start_tls: Can't contact LDAP server (-1)
ldap_free_request (origid 1, msgid 1)
ldap_free_connection 1 1
ldap_free_connection: actually freed
The client's LDAP server is Windows Server 2008 R2 and we're using Ubuntu 12.04.4 LTS with ldapsearch from OpenLDAP 2.4.28.
Any suggestions on what to troubleshoot next? My guess is it's somewhere in the clients network but I want to check my end as much as possible before I start asking them.
Update:
I added:
ldap_set_option(NULL, LDAP_OPT_DEBUG_LEVEL, 7);
to my php script and got the same output as what was returned from ldapsearch.
The long and the short of it is that the client's firewall was set to allow the connection but it was set with a different protocol so the deep packet inspection was knocking it down. Hopefully if this every happens to someone else this will be helpful.
Related
I have a Raspberry PI with this GSM hat, and I want to connect to the mobile network with it. I have tried a couple of combinations of the gprs file to achieve this, but none of them would work.
I tried to go trough the provided instructions on the wiki.
That resulted in an error:
Script /usr/sbin/chat -v -f /etc/chatscripts/gprs finished (pid 1569), status = 0x3
When I start the connection with this command: pppd call gprs &
I get this if I check the /var/log/syslog file:
pppd[991]: pppd 2.4.7 started by pi, uid 0
chat[994]: abort on (BUSY)
chat[994]: abort on (VOICE)
chat[994]: abort on (NO CARRIER)
chat[994]: abort on (NO DIALTONE)
chat[994]: abort on (NO DIAL TONE)
chat[994]: abort on (NO ANSWER)
chat[994]: abort on (DELAYED)
chat[994]: abort on (ERROR)
chat[994]: abort on (+CGATT: 0)
chat[994]: send (AT^M)
chat[994]: timeout set to 12 seconds
chat[994]: expect (OK)
chat[994]: alarm
chat[994]: Failed
pppd[991]: Script /usr/sbin/chat -v -f /etc/chatscripts/gprs finished (pid 993), status = 0x3
pppd[991]: Connect script failed
The /etc/ppp/peers/gprs file:
#!/bin/bash
user "myusername#realm"
connect "/usr/sbin/chat -v -f /etc/chatscripts/gprs"
#/dev/modem
/dev/ttyS0
# Speed of the serial line.
115200
nocrtscts
debug
ipcp-accept-local
ipcp-accept-remote
# Assumes that your IP address is allocated dynamically by the ISP.
noipdefault
# Try to get the name server addresses from the ISP.
usepeerdns
# Use this connection as the default route.
defaultroute
# Makes pppd "dial again" when the connection is lost.
persist
# Do not ask the remote to authenticate.
noauth
Also I changed the pin in the /etc/chatscripts/gprs file:
# +CPIN provides the SIM card PIN
OK "AT+CPIN=1234"
Have you tried putting the APN of the service provider in the third line of the gprs file? The details come along when you purchase the SIM card.
It should be something like:
connect "/usr/sbin/chat -v -f /etc/chatscripts/gprs -T APN"
You may find an example in the following link:
https://www.rhydolabz.com/wiki/?p=16325
I'm using the Raspberry Pi 4 and trying to have an Internet access using the A9G GSM/GPRS+GPS Module.
At first I have install ppp with sudo apt-get install ppp screen elinks
I have create a file with name rnet in path /etc/ppp/peers/rnet:
# My APN internet.vodafone.gr
connect "/usr/sbin/chat -v -f /etc/chatscripts/gprs -T internet.vodafone.gr"
# Communication port:
/dev/ttyS0
# Baudrate
9600
# Assumes that your IP address is allocated dynamically by the ISP.
noipdefault
# Try to get the name server addresses from the ISP.
usepeerdns
# Use this connection as the default route to the internet.
defaultroute
# Makes PPPD "dial again" when the connection is lost.
persist
# Do not ask the remote to authenticate.
noauth
# No hardware flow control on the serial link with GSM Modem
nocrtscts
# No modem control lines with GSM Modem
local
In file gprs in path /etc/chatscripts/gprs I have add the line that need my "MY_4_DIGIT_PIN":
ABORT BUSY
ABORT VOICE
ABORT "NO CARRIER"
ABORT "NO DIALTONE"
ABORT "NO DIAL TONE"
ABORT "NO ANSWER"
ABORT "DELAYED"
ABORT "ERROR"
# cease if the modem is not attached to the network yet
ABORT "+CGATT: 0"
"" AT
TIMEOUT 12
OK ATH
OK ATE1
# +CPIN provides the SIM card PIN
OK AT+CPIN="MY_4_DIGIT_PIN"
# +CFUN may allow to configure the handset to limit operations to
# GPRS/EDGE/UMTS/etc to save power, but the arguments are not standard
# except for 1 which means "full functionality".
#OK AT+CFUN=1
OK AT+CGDCONT=1,"IP","\T","",0,0
OK ATD*99#
TIMEOUT 22
CONNECT ""
So when I'am trying to starts up the rnet file:
sudo pon rnet
I get this error message in syslog (cat /var/log/syslog | grep pppd):
Oct 14 18:14:22 raspberrypi pppd[3063]: pppd 2.4.7 started by pi, uid 0
Oct 14 18:14:35 raspberrypi pppd[3063]: Connect script failed
Oct 14 18:15:06 raspberrypi pppd[3063]: Connect script failed
Oct 14 18:15:37 raspberrypi pppd[3063]: Connect script failed
...
When I am trying to run the below AT commands, the module seems to be work fine and be able to connected to network:
AT
OK
AT+CPIN?
+CPIN:READY
OK
AT+CREG?
+CREG: 1,1
OK
AT+CGATT?
+CGATT:1
OK
AT+COPS?
+COPS: 0,2,"20205"
AT+CGACT?
+CGACT: 1, 1
AT+HTTPGET="http://www.example.com/"
OK
HTTP/1.1 200 OK
...
So I can't understand if I have have writing something wrong in file rnet or is something else that I am not doing it right. If you have any idea please help me.
The problem was that my A9G Module, was not getting enough power.
Therefore, check if your A9G Module is turned on, before starting the process
and make sure that you have disabled login shell to be accessible over serial,
and also you have enabled the serial interface.
I am following the simple TCP example found here: https://docs.julialang.org/en/v1/manual/networking-and-streams/#A-simple-TCP-example-1. The code can be seen below (I modified that from the link slightly):
using Sockets
using Printf
# listen will create a server waiting for incoming connections on the specified
# port (in this case it will be localhost::2000)
#async begin
server = listen(2000)
x :: Int = 1
while true
sock = accept(server)
#printf "Connection number %d\n" x
x += 1
end
end
for i = 1:10
connect(2000)
end
When I execute the commands within the REPL it works correctly producing the following output:
julia> #async begin
server = listen(2000)
x :: Int = 1
while true
sock = accept(server)
#printf "Connection number %d\n" x
x += 1
end
end
Task (runnable) #0x00000001169d06d0
julia> for i = 1:10
connect(2000)
end
Connection number 1
Connection number 2
Connection number 3
Connection number 4
Connection number 5
Connection number 6
Connection number 7
Connection number 9
Connection number 10
However, when I try to place these commands in a file:
using Sockets
using Printf
# listen will create a server waiting for incoming connections on the specified
# port (in this case it will be localhost::2000)
#async begin
server = listen(2000)
x :: Int = 1
while true
sock = accept(server)
#printf "Connection number %d\n" x
x += 1
end
end
for i = 1:10
connect(2000)
end
and run using julia <scriptName> or (from within the REPL) include("<scriptName>") I get the following error message:
ERROR: LoadError: IOError: connect: connection refused (ECONNREFUSED)
Stacktrace:
[1] wait_connected(::TCPSocket) at /Users/julia/buildbot/worker/package_macos64/build/usr/share/julia/stdlib/v1.3/Sockets/src/Sockets.jl:520
[2] connect at /Users/julia/buildbot/worker/package_macos64/build/usr/share/julia/stdlib/v1.3/Sockets/src/Sockets.jl:555 [inlined]
[3] connect at /Users/julia/buildbot/worker/package_macos64/build/usr/share/julia/stdlib/v1.3/Sockets/src/Sockets.jl:541 [inlined]
[4] connect at /Users/julia/buildbot/worker/package_macos64/build/usr/share/julia/stdlib/v1.3/Sockets/src/Sockets.jl:537 [inlined]
[5] top-level scope at <pathToFile>:18
[6] include at ./boot.jl:328 [inlined]
[7] include_relative(::Module, ::String) at ./loading.jl:1105
[8] include(::Module, ::String) at ./Base.jl:31
[9] include(::String) at ./client.jl:424
[10] top-level scope at REPL[1]:1
in expression starting at <pathToFile>:17
How would I run this program from a script? I am fairly new to Julia and to sockets so apologies if this is an easy question!!
You're getting an error because connect will fail if listen has not yet had time to run. As you discovered, introducing a small pause between your server and client sides fixes the issue; let's try and explain this in more details.
In the REPL-based, interactive version, as soon as the server task is created using #async, control goes back to the REPL, which performs blocking operations (such as waiting for new commands to be entered in the command line). This gives the scheduler an opportunity to yield control to the newly created task. The call to listen appears early in it, ensuring that whenever control reaches the client side again - and calls to connect are executed - the server is listening.
In the script version, the server task gets created and scheduled, but the scheduler does not have any opportunity to actually run it, since the main task does not perform any blocking call before running connect. Therefore no-one is listening to the socket when the connection is performed, and the call fails. However, any blocking call put in this place will give an opportunity for the scheduler to run the server task. This includes sleep (of arbitrarily small amounts of time, as you noted), but also any function performing I/O: a simple println("hello") would have worked too.
I would think a cleaner way to fix things would be to ensure that the call to listen is performed first, by running it synchronously beforehand:
using Sockets
using Printf
# listen will create a server waiting for incoming connections on the specified
# port (in this case it will be localhost::2000)
server = listen(2000)
#async begin
x = 1
while true
sock = accept(server)
#printf "Connection number %d\n" x
x += 1
end
end
for i = 1:10
connect(2000)
end
Now you're left with another problem: when the client loop terminates, all calls to connect have been issued, but not necessarily all corresponding calls to accept have had time to run. This means that you're likely to get truncated output such as:
Connection number 1
Connection number 2
Connection number 3
Connection number
You'd need further coordination between your tasks to correct this, but I suspect this second problem might be only related to the MWE posted here, and might not appear in your real use case.
For example, presumably the server is meant to send something to the client. The read-write operations performed on sockets in this case naturally synchronizes both tasks:
using Sockets
using Printf
# listen will create a server waiting for incoming connections on the specified
# port (in this case it will be localhost::2000)
server = listen(2000)
#async begin
x = 1
while true
sock = accept(server)
msg = "connection number $x\n"
print("Server sent: $msg")
write(sock, msg)
x += 1
end
end
for i = 1:10
sock = connect(2000)
msg = readline(sock)
println("Client received: $msg")
end
The above example correctly yields a complete (untruncated) output:
Server sent: Connection number 1
Client received: Connection number 1
Server sent: Connection number 2
Client received: Connection number 2
...
Server sent: Connection number 10
Client received: Connection number 10
So I've figured this out I believe. The server and client either need to be separated between two files, OR, a pause command (seems to be okay with an arbitrarily small pause command) needs to be in between the server and client side:
#!/Applications/Julia-1.3.app/Contents/Resources/julia/bin/julia
using Sockets
using Printf
# listen will create a server waiting for incoming connections on the specified
# port (in this case it will be localhost::2000)
port = 2000
#async begin
server = listen(IPv6(0),port)
x::Int = 1
while true
sock = accept(server)
#printf "Connection number %d\n" x
x += 1
end
end
sleep(1E-10)
for i = 1:10
connect(port)
end
This is now working as expected!
I have some JOBs running on SQL Server 2000, which are calling stored procedures or queries against remote SQL Servers (different editions).
The JOB calls a DTS, and is the DTS who does the remote connection and executes the Stored Procedure or gets a query results from the remote server.
This has been working without errors for years. I don't know why during the last month, I'm having randomly errors on these kind of jobs... I've read some other posts and seems to be related to a security issue, but I repeat, the most of times the jobs are working, only some runs are failing with the error.
Executed as user: SERVER\user. DTSRun: Loading... DTSRun: Executing...
DTSRun OnStart: DTSStep_DTSDynamicPropertiesTask_2 DTSRun OnError:
DTSStep_DTSDynamicPropertiesTask_2, Error = -2147467259 (80004005)
Error string: Login timeout expired Error source: Microsoft OLE DB
Provider for SQL Server Help file: Help context: 0
Error Detail Records: Error: -2147467259 (80004005); Provider Error: 0 (0)
Error string: Login timeout expired Error source: Microsoft OLE DB Provider for SQL Server
Help file: Help context: 0 DTSRun OnFinish:
DTSStep_DTSDynamicPropertiesTask_2 DTSRun: Package execution complete.
Process Exit Code 1. The step failed.
I really don't know what to check. After reboot the server the problems are still there. Any help from you guys would be appreciated.
EDIT 2019-02-14 16:15 -------------------------------------------------------------------------------------------
One of the solutions I found has been to change the Remote Login Timeout property from the default 20 seconds to 30 seconds, or to 0 (Zero means without timeout), by executing the next code:
sp_configure 'remote login timeout', 30 --Or 0 seconds for infinite
go
reconfigure with override
go
From: https://support.microsoft.com/es-es/help/314530/error-message-when-you-execute-a-linked-server-query-in-sql-server-tim
I've tried this solution changing it to 30 seconds, but with the same result. Of course I didn't set it to 0 for obvious reasons, the timeouts are there for something. And also tried 300 seconds (5 minutes to make a login!) and still the same.
EDIT 2019-02-25 11:25 -------------------------------------------------------------------------------------------
Very similar to my problem, still not solved...
https://www.sqlservercentral.com/Forums/Topic1727739-391-1.aspx
For the moment I have a temp solution, and it is to increase the Connect Timeout on the Connection object.
It was blank (probably using its default value).
Since I changed this property (Connection Object > Advanced... > Connect Timeout) to 300 I'm not having the problems on these DTS. I leaved 2 DTS without the change to ensure I continued having the problem, and these are the only ones which continue having the problem. The changed ones are working fine now.
I am trying to import 25 packets from the incoming bay on my vob server.
An lspacket of each of the packet shows that the packets are fragments from 1 to 25.
Here's an example:
multitool lspacket sync_XXX_12977
Packet is: /clearcase/shipping/ms_ship/incoming/sync_XXX_12977
Packet type: Update
Packet fragment: 1 of 25
...
multitool lspacket sync_XXX_12977_6
Packet is: /clearcase/shipping/ms_ship/incoming/sync_XXX_12977_6
Packet type: Update
Packet fragment: 6 of 25
...and so on upto _25.
So to import all the fragments/packets at once, I did a syncreplica -import [all packets from sync_XXX_12977 to sync_XXX_12977_25].
With this I get an error like:
multitool: Error: Unable to write file "/var/tmp/syncs04042": No space left on device.
Can anyone please help me with this?
Also, I should mention that incoming packets for other vobs seem to have lesser number of fragments, and they are successfully imported by the scheduled sync_receive.
I'm not sure why this error is coming only for packets for this particular vob. Could it be because of larger number of fragments?
Here is some more info about the error:
multitool: Error: Vob server operation "Create Container" failed.
Additional information may be available in the vob_log on host "VOBserver.qwerty.com"
multitool: Error: Unable to create a container in vob "/vobs/products", because group "root" not in vob's group list.
multitool: Error: Unable to replay oplog entry 927736: Not owner.
927736:
op= checkin
replica_oid= 9c863907.23ca11e2.9baf.00:01:83:db:e4:2d (ABC_SW)
oplog_id= 659061
op_time= 2014-06-06T07:18:47Z create_time= 2014-07-31T09:18:01Z
version_oid= 8426e33c.ed4b11e3.931b.00:01:83:db:e4:2d (*no view*)
event comment= "created by clearfsimport"
data size= 116 data= 0x12e108
------------
ver_oid= 8426e33c.ed4b11e3.931b.00:01:83:db:e4:2d (*no view*)
ver_num= 1
ver_fstat= ino: 0; type: 1; mode: 00
usid: DONTCARE
gsid: DONTCARE
nlink: 0; size: 130017856
atime: Thu Jan 1 05:30:00 1970
mtime: Fri Jun 6 12:48:14 2014
ctime: Fri Jun 6 12:48:14 2014
ckout_ver_oid= 8426e33c.ed4b11e3.931b.00:01:83:db:e4:2d (*no view*)
I checked vob's properties using lsvob -long and desc: the vob owner and group are CC admin and ccgrp.
If those packets are particularly big, that might explain the "No space left on device" message.
The first check is to do a:
cd /var/tmp
df -h .
And check what space you have left to work.
Once that disk space issue is fixed, you should:
get the primary group of the vob (cleartool descr -l vob:/vobs/products)
check that id -a (for ccadmin) returns that group as primary group (meaning the first group displayed by that command should be the one of the vob)