I have written a small script to check port status using q. It checks for the ports and runs an email if connection is refused, which works fine. Then I used an optional timeout for a port so it would not hang there waiting. Though it comes back with the comment "timeout" if a port is timed out, it also seems to kick me out of the function and does not get into sendemail[] part.
ProcessChecks:{[port]
V:{#[value;("hopen (`::",(string x),";5000)");enlist]} [port];
.keh.V:V; :
mail_body:(string V)," at .z.T time: ",(string .z.T);
.keh.mail:mail_body;
$[-6h=type V;"port accepted";SendEmail2[mail_body;"connection refused port: ",(string port)]];
The name space .keh.mail does not change and SendEmail2[] does not get sent, which is just a unix mailx command.
I will get .keh.V = "timeout"
.keh.mail = " at .z.T time whatever the time is"
5000 is 5 second wait time and its introduction causes the problem.
Your issue is being caused by a stray : in the third line of your script. This is causing your function to return early. Try the following:
ProcessChecks:{[port]
V:{#[value;("hopen (`::",(string x),";5000)");enlist]} [port];
.keh.V:V;
mail_body:(string V)," at .z.T time: ",(string .z.T);
.keh.mail:mail_body;
$[-6h=type V;"port accepted";SendEmail2[mail_body;"connection refused port: ",(string port)]];
}
Related
I want to simulate test cross-platform connection failures / timeouts, starting with blocking connect()s:
#!/usr/bin/python3
import socket
s = socket.socket()
endpoint = ('localhost', 28813)
s.bind((endpoint))
# listen for connections, accept 0 connections kept waiting (backlog)
# all other connect()s should block indefinitely
s.listen(0)
for i in range(1,1000):
c = socket.socket()
c.connect(endpoint)
# print number of successfully connected sockets
print(i)
On Linux, it prints "1" and hangs indefinitely (i.e. the behavior I want).
On Windows (Server 2012), it prints "1" and aborts with a ConnectionRefusedError.
On macOS, it prints all numbers from 1 to 128 and then hangs indefinitely.
Thus, I could accept the macOS ignores the backlog parameter and just connect enough sockets for clients to block on new connections.
How can I get Windows to also block connect() attempts?
On Windows, the SO_CONDITIONAL_ACCEPT socket option allows the application to have the incoming connections wait until it's accept()ed. The constant (SO_CONDITIONAL_ACCEPT=0x3002) isn't exposed in the Python module, but can be supplied manually:
s.bind(endpoint)
s.setsockopt(socket.SOL_SOCKET, 0x3002, 1)
s.listen(0)
It's so effective that even the first connect is kept waiting.
On macOS, backlog=0 is reset to backlog=SOMAXCONN, backlog=1 keeps all connections except the first waiting.
I have written a program in golang to make request about 2000qps to different remote ip with local port randomly selected by linux, and close request immediately after connection established, but still encounter bind: address already in use error periodically
what I have done:
net.ipv4.ip_local_port_range is 15000-65535
net.ipv4.tcp_tw_recycle=1 net.ipv4.tcp_tw_reuse=1 net.ipv4.tcp_fin_timeout=30
above is sockstat:
sockets: used 1200 TCP: inuse 2302 orphan 1603 tw 40940 alloc 2325 mem 201
I don't figure it out why this error still there with kernel selecting available local port,will kernel return a port in use ?
This is a good answer from 2012:
https://serverfault.com/questions/342741/what-are-the-ramifications-of-setting-tcp-tw-recycle-reuse-to-1#434669
As of 2018, tcp_tw_recycle exists only in the sysctl binary, is otherwise gone from the kernel:
https://github.com/torvalds/linux/search?utf8=%E2%9C%93&q=tcp_tw_recycle&type=
tcp_tw_reuse is still in use as described in the above answer:
https://github.com/torvalds/linux/blob/master/net/ipv4/tcp_ipv4.c#L128
However, while a TCP_TIMEWAIT_LEN is in use:
https://github.com/torvalds/linux/search?utf8=%E2%9C%93&q=TCP_TIMEWAIT_LEN&type=
the value is hardcoded:
https://github.com/torvalds/linux/blob/master/include/net/tcp.h#L120
and tcp_fin_timeout refers to a different state:
https://github.com/torvalds/linux/blob/master/Documentation/networking/ip-sysctl.txt#L294
One can relatively safely change the local port range to 1025-65535.
For kicks, if there were a situation where this client was talking to servers and network under my control, I would build a new kernel with a not-to-spec TCP_TIMEWAIT_LEN, and perhaps also fiddle with tcp_max_tw_buckets:
https://github.com/torvalds/linux/blob/master/Documentation/networking/ip-sysctl.txt#L379
But doing so in other circumstances- if this client is behind a NAT and talking to common public servers- will likely be disruptive.
I am attempting to send a broadcast packet to a certain port, but it seems that the code gives some weird errors for which I can't find a fix.
I've tried using net.socket:connect() and then calling the "send()" method, which didn't work, then I said that I should use the net.socket:on('connection') and send there, since I suppose net.socket:connect() isn't synchronous. But that gave a weird error too...
For this code:
function sendBroadcastPacket()
bip = wifi.sta.getbroadcast()
srv = net.createConnection(net.UDP,0)
print('Trying to connect on: ', bip)
srv:connect('9001', bip)
srv:send("Broadcast packet from: "..NODE_ID, function(sent)
print("Broadcasted packet! "..sent)
end)
end
I receive the following error:
PANIC: unprotected error in call to Lua API (init.lua:24: attempt to
call method 'connect' (a nil value))
Line 24 is the srv:connect line.
After that I tried listening for the connection event first, to see if it worked that way:
function sendBroadcastPacket()
bip = wifi.sta.getbroadcast()
srv = net.createConnection(net.UDP,0)
print('Trying to connect on: ', bip)
srv:on('connection', function(sck, c)
sck:send("Broadcast packet from: "..NODE_ID, function(sent)
print("Broadcasted packet! "..sent)
end)
end)
srv:connect('9001', bip)
end
I receive the following error:
PANIC: unprotected error in call to Lua API (init.lua:24: invalid
callback name)
Line 24 is the srv:on('connection') line.
What seems to be happening here? There aren't many google results, since a lot of other people use the Arduino-IDE version(btw, is that still nodemcu or do you need a different firmware for the ESP8266?).
I am getting a broadcast IP, and it connects to the AP. I didn't post here the wifi connection part because it works, I've used it to test mqtt and http connections which worked.
The build I'm using, Lua 5.1.4 on SDK 2.1.0(116b762), has the net module included.
Your attempts all failed because you don't seem to consider that UDP is a connection-less protocol. Hence, there's no connect() or on('connection'... for UDP.
The first attempt failed because send() needs to be called on a socket and not on the connection. The second failed because the connection callback name is only available for TCP, not for UDP.
Try something like this:
function sendBroadcastPacket()
local port = 9001
local bip = wifi.sta.getbroadcast()
print(string.format("Broadcasting to %s:%d", bip, port))
net.createUDPSocket():send(port, bip, "foo bar")
end
Documentation: https://nodemcu.readthedocs.io/en/latest/en/modules/net/#netudpsocket-module
I have created a TCP socket at one end of my application. Say the end is 1. This socket closes after about 10sec. Now the other side of my application (end 2) is allowed to connect to the above created socket. Im coding this socket app in python, so suppose my end 2 is trying to connect to the TCP socket, but the socket no longer exists, my program terminates because of some exception. I dont want that to happen. It's like there is a while loop in my end 2. So if a connection is not available it goes back and wait.
Are you handling the exception correctly ..
try:
s.connect((host,port))
except socket.error, (value,message):
if s:
s.close()
print "Could not open socket: " + message
"""Code to handle a retry"""
On getting an error .. you can retry by doing a bind and listen again.. Also you need to have retry count ..say 5 and then perhaps exit.
The precedence section in chapter 9.3.1 tells me that I should apply the special cases first and then the general ones.
[General]
*.host[0].waitTime = 5ms # specifics come first
*.host[3].waitTime = 6ms
*.host[*].waitTime = 10ms # catch-all comes last
I have following lines in the omnetpp.ini file:
**.server[*].tcpApp[0].port = 1000
**.pods[0..1].**.server[*].tcpApp[0].port = 80
**.pods[2..3].**.server[*].tcpApp[0].port = 21
This code works, but every server has 1000 when checking the parameter and not the special cases 80 and 21. So I want it to look like that:
**.pods[0..1].**.server[*].tcpApp[0].port = 80
**.pods[2..3].**.server[*].tcpApp[0].port = 21
**.server[*].tcpApp[0].port = 1000
Yet, this creates an error, which consists of a null pointer exception in the TCP module of the StandardHost module my server is build on.
In the ned file, the parameter is declared like this:
int port = default(1000); // port number to listen on
Leaving that catch-all line out causes the error too. Only taking the last line above the other two makes it possible to let the simulation run through.
An example for the port parameter can be found in TCPServerHostApp.ned from INET. I want to assign different ports for different services which should run on the servers.
What is your advice for me, to apply those parameters correctly? Is there an error in the way I set the parameters, or do I need to set the ports somewhere during the initialization process myself (which would make no sense to me)?
Edit:
The karma system does not allow me to answer the question yet, so here is the cause of my problem:
Well, the problem was at another place. When connecting a new socket with connect(ipaddr, port), I got the wrong port from the job request message.
At the traffic generation module, I read the wrong port for connection to the server, which caused an error, as the port being used was always the default = 1000 instead of 80 or 21.
The servers expected 80 or 21, causing a crash when the socket tried to connect with port 1000.
Just want to add this here as well, so everybody sees I found the error.
Well, the problem was at another place. When connecting a new socket with connect(ipaddr, port), I got the wrong port from a job request message.
At the traffic generation module, I read the wrong port for connection to the server, which caused an error, as the port being used was always the default (= 1000) instead of 80 or 21.
The servers expected 80 or 21, causing a crash, when the socket tried to connect with 1000.