Is there a SO_BINDTODEVICE equivalent or workaround for LuaSocket?
I've tried:
ifconfig to fetch the inet addr of my interface (e.g. ethA 1.1.1.1) + setpeername("1.1.1.1", 0). When I tcpdump on "ethA", I don't see my packet. Not too sure what the difference between bind versus bindtodevice is - I thought bindtodevice was just a shortcut to fetch the ip address from the interface name but that doesn't seem to be the case.
local udp = socket.udp()
udp:settimeout(1)
udp:setsockname("1.1.1.1", 0)
udp:setpeername("2.2.2.2", 12345)
udp:send(query)
The ip-multicast-if from https://tst2005.github.io/lua-socket/udp.html which was the only thing that mentioned interface in the documentation didn't seem to work.
local udp = socket.udp()
udp:setoption("ip-multicast-if", "1.1.1.1")
udp:settimeout(1)
udp:setsockname("*", 0) -- I've also tried "1.1.1.1" here and it didn't work.
udp:setpeername("2.2.2.2", 12345)
udp:send(query)
I see that it may be an option for luaposix, but I don't have that package and I don't want to bring in an additional dependency just for this.
Related
I am trying to move my organisation from Centos7 to Centos8 and Rocky linux which have network manager. Due to the multi-homed system I am trying to setup scriping to autoconnect since out of the box NM loses connectivity but I am a bit stuck.
If I try to run For example
nmcli c modify ens3 "IP4.DNS[0]" "8.8.8.8"
I get the Error: invalid or not allowed setting 'IP4': 'IP4' not among [connection, 802-3-ethernet (ethernet), 802-1x, dcb, sriov, ethtool, match, ipv4, ipv6, hostname, tc, proxy]. From what I understand NM is unable to modify these settings but I not understand why, or who set them up. I suspect it is somewhere in cloud init or in the dhcp-reply ??
nmcli connection show ens3 | grep IP4
IP4.ADDRESS[1]:136.ZZ.XX.XXX/23
IP4.GATEWAY:136.ZZ.YY.YY
...
IP4.DOMAIN[1]:openstacklocal
[root#chkorocky syck]# nmcli c show ens3 | grep ipv4
ipv4.method: auto
ipv4.dns: --
ipv4.dns-search: --
ipv4.addresses: --
ipv4.gateway: --
Is there anyway to understand where these extra attributes come from? Somehow ipv4.XX do not get set up at all but instead other variables with similar names allow NM to work ?
I'm debugging a 3rd-party network application and trying to figure out why it reports errors when calling setsockopt with IP_ADD_MEMBERSHIP to set up a multicast group. The application is in C++, but I've written an MWE in python that replicates the same syscalls:
import socket
import struct
ETH0_IP = "192.168.88.85"
ETH0_1_IP = "192.168.88.254"
MULTICAST_IP = "224.0.0.7"
s = socket.socket(socket.AF_INET, socket.SOCK_DGRAM, socket.IPPROTO_UDP)
ip = socket.inet_aton(ETH0_IP)
s.setsockopt(socket.IPPROTO_IP, socket.IP_MULTICAST_IF, ip)
group = struct.pack("4s4s", socket.inet_aton(MULTICAST_IP), ip)
s.setsockopt(socket.IPPROTO_IP, socket.IP_ADD_MEMBERSHIP, group)
# s.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEADDR, 1)
# s.setsockopt(socket.SOL_SOCKET, socket.SO_REUSEPORT, 1)
s2 = socket.socket(socket.AF_INET, socket.SOCK_DGRAM, socket.IPPROTO_UDP)
ip2 = socket.inet_aton(ETH0_1_IP)
s2.setsockopt(socket.IPPROTO_IP, socket.IP_MULTICAST_IF, ip2)
group2 = struct.pack("4s4s", socket.inet_aton(MULTICAST_IP), ip2)
# the second group is added to the first socket so that we can only bind to one socket and read data from it
s.setsockopt(socket.IPPROTO_IP, socket.IP_ADD_MEMBERSHIP, group2)
At the second IP_ADD_MEMBERSHIP call I get error OSError: [Errno 98] Address already in use.
I found out this only happens when ETH0_1_IP is a subinterface of ETH_0_IP. And I'm not sure if this is expected. If it is, is there a way to actually detect this situation and discard subinterfaces of already bound interfaces? Further, would my multicast socket receive data sent to the subinterface if registration for it fails with the above error?
For the sake of completeness:
$ cat /etc/network/interfaces
auto lo
iface lo inet loopback
iface lo inet6 loopback
auto eth0:1
iface eth0:1 inet static
address 192.168.88.254
netmask 255.255.240.0
Linux is tracking your alias interface as the same interface and so rejecting the attempt to re-use the interface.
In a bit more detail, I have run your code successfully on CentOS 7 using two separate physical interfaces with no changes. If I then change the code to use an alias on the same physical address, it fails with the same error that you see.
Digging a little further, I see that if I dump the interface indeces (using SIOCGIFINDEX) for the physical adaptor and the alias, they do indeed have the same index.
If you want to use Python to check this for yourself, have a quick look at https://gist.github.com/firaxis/0e538c8e5f81eaa55748acc5e679a36e for some code (missing imports of ctypes and socket) and then try something like this:
print(Interface(name="eth0").index)
print(Interface(name="eth0:1").index)
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 want to Use honeyd to setup a virtual host with the following specification:
• Operating System: Linux
• Ethernet MAC Address: 00:00:24:22:8c:14
• IP Address: 10.10.10.2
• Open Ports: 22
so I instlled honeyd on ubuntu 1204 vm; then changed etc/honeypot/honeyd.conf as below:
create default
set default default tcp action block
set default default udp action block
set default default icmp action block
create linux
set linux personality "Linux 2.4.20"
set linux default tcp action reset
add linux tcp port 22 open
set linux ethernet "00:00:24:22:8c:14"
bind 10.10.10.2 linux
and the file honeyd.conf in etc/default/ like below:
RUN="yes"
INTERFACE= "eth0"
NETWORK= 10.10.10.2
OPTIONS="--disable-webserver"
when i run the honeyd using command : 'honeyd start'
sometimes it shows this error:
honeyd: ip-open: operation not permitted
and other times it shows this one:
honeyd: interface_expandips: Invalid network range: start
what should i do?
Thanks
If you run honeyd without sudo you will receive the first error message. The second one occurs when running it with sudo.
Looks like you didn't specify a network range in the config file at /etc/default. 10.10.10.2 is an IP address. Not a range. You probably want something like:
NETWORK= 10.10.10.0/24
in your config file,
my error removed after i changed my vmware nat dhcp setting. it is in tab edit>virtual network editor.. > nat> dhcp setting.
the range must include the ip address i want to use.
:)
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.