sshd «listen on all interfaces» behaviour, OSX and Ubuntu
Given an extra loopback interface in the 127.0.0.X ( X > 1 ) range on BoxA (which can be running either OSX or Linux), I want to bind port 22 of this extra loopback interface to a forward SSH tunnel (ie. local port forward) that is pointed at BoxB. On OSX this works fine (strangely, in retrospect). [Taking X = 2 ] after bringing up the loopback alias with ifconfig lo0 alias 127.0.0.2 up , SSH can establish a tunnel with ssh -NfL 127.0.0.2:22:localhost:22 BoxB . Then in a new shell on BoxA, ssh 127.0.0.2 logs me into BoxB. On Ubuntu, I can bring up the loopback alias on BoxA, but when trying to establish the SSH tunnel, ssh complains about not being able to bind (and hence forward) BoxA’s port 22. The subsequent ssh 127.0.0.2 (in a new shell on BoxA) gives a fingerprint warning, which if bypassed, logs me back into BoxA. Makes sense — sshd on BoxA is listening to all interfaces. Looking at the sshd_config in each, both are configured to listen on 0.0.0.0 (and :: for IPv6). lsof for OSX gives:
launchd 1 root 40u IPv6 0xddfcabed61001f0d 0t0 TCP *:ssh (LISTEN) launchd 1 root 41u IPv4 0xddfcabed6100413d 0t0 TCP *:ssh (LISTEN) launchd 1 root 43u IPv6 0xddfcabed61001f0d 0t0 TCP *:ssh (LISTEN) launchd 1 root 44u IPv4 0xddfcabed6100413d 0t0 TCP *:ssh (LISTEN) sshd 1287 0 3u IPv4 21903340 0t0 TCP *:ssh (LISTEN) So both are listening on all interfaces, though I’m not sure why OSX uses 4 processes. In any case, Ubuntu gives the expected behaviour. Why does OSX behave differently? The follow up question of course, is how to make Ubuntu behave like OSX in this regard. While I wish for the sshd_config to have state, wildcards and/or logical operators (e.g. «do not listen on 127.0.0.* ; listen on 127.0.0.1 «) like iptables , it doesn’t seem to be the case.
Difference between INADDR_ANY in Linux and Windows socket programming
Windows and Linux actually behave the same regarding the use of INADDR_ANY . The confusion here is because the two links you provide are being used in different contexts.
When using the bind function to bind to an address/port, specifying INADDR_ANY means that the socket will be able to receive packets on the given port from any interface. However, doing so does not set up anything regarding multicast.
In the context of the IP_ADD_MEMBERSHIP call to setsockopt , setting the interface to INADDR_ANY will have the system join the given multicast group on the default network interface.
The Linux link you gave refers to bind , while the Windows link refers to setsockopt and IP_ADD_MEMBERSHIP .
If you want to join the multicast group on all interfaces, you need to retrieve the list of interfaces on the system and join each one. On Windows, the GetAdaptersAddresses() function will give you the list of interfaces. On Linux, use the getifaddrs() function.
Here’s an example of how to use the GetAdaptersAddresses() function in C:
struct iflist < char name[50]; struct sockaddr_in sin; int isloopback; int ismulti; int ifidx; >; void getiflist(struct iflist *list, int *len) < IP_ADAPTER_ADDRESSES *head, *curr; IP_ADAPTER_UNICAST_ADDRESS *uni; char *buf; int buflen, err, i; buflen = 100000; buf = calloc(buflen, 1); head = (IP_ADAPTER_ADDRESSES *)buf; if ((err = GetAdaptersAddresses(AF_UNSPEC, 0, NULL, head, &buflen)) != ERROR_SUCCESS) < char errbuf[300]; FormatMessage(FORMAT_MESSAGE_FROM_SYSTEM, NULL, err, 0, errbuf, sizeof(errbuf), NULL); printf("GetAdaptersAddresses failed: (%d) %s", err, errbuf); free(buf); return; >for (*len = 0, curr = head; curr; curr = curr->Next) < if (curr->IfType == IF_TYPE_TUNNEL) continue; for (uni = curr->FirstUnicastAddress; uni; uni = uni->Next) < if (curr->OperStatus == IfOperStatusUp) < memset(&list[*len], 0, sizeof(struct iflist)); strncpy(list[*len].name, (char *)curr->AdapterName, sizeof(list[i].name) - 1); memcpy(&list[*len].sin, uni->Address.lpSockaddr, uni->Address.iSockaddrLength); list[*len].isloopback = (curr->IfType == IF_TYPE_SOFTWARE_LOOPBACK); list[*len].ismulti = ((curr->Flags & IP_ADAPTER_NO_MULTICAST) == 0); if (uni->Address.lpSockaddr->sa_family == AF_INET6) < list[*len].ifidx = curr->Ipv6IfIndex; > else < list[*len].ifidx = curr->IfIndex; > (*len)++; > > > free(buf); > your source is completely oblivious of the fact that the internet protocol itself does not know anything about «ports» and «interfaces», the aforementioned statement («listen on all interfaces») doesnt even make any sense, its completely made up but packets to broadcast addresses typically are routed onto multiple interfaces, more on this below:
0.0.0.0 is a special, reserved IPv4 address called «network identifier» — in fact IPv4 adresses which end with 0 typically are reserved — it is typically not usable except for broadcast and network purposes. Operating systems usually reserve 0.0.0.0 for broadcasts within one single transport protocol
Now : these broadcast addresses always receive broadcasts for one single transport protocol via the default route which may point to multiple (or all) network interfaces. What you probably were reading about is something completely different : Multicast — thats yet another can of worms, it is possible to send singular packets to multiple, designated receivers — Microsoft Windows has a default multicast route and Linux typically has to be configured for multicast in order to work (AFAIK) — but you dont want that.
Conclusion : for your purposes, 0.0.0.0 is identical on Windows and Linux — its a broadcast address for your chosen transport protocol, there is no difference
Introduction
By default, MariaDB as a database service will run by listening to any incoming request or connection to the interface. The one available for the listening interface is only the local interface. That local interface is the ‘127.0.0.1’ or normally as ‘localhost’ as an alias. So, how is the MariaDB, the database itself can actually listen and accept for all available interfaces in the server ?. The answer is quite simple. Just modify the MariaDB database configuration file. But there is a need to look out for the actual configuration file. Basically, the main configuration exist in ‘/etc/my.cnf’. But since it is a MariaDB database server, there is another file exist. It exist in the following information exist in the ‘/etc/my.cnf’ :
# # include all files from the config directory # !includedir /etc/my.cnf.d
There are another configuration file exist in the following directory of ‘/etc/my.cnf.d’. The following is the list of the available configuration file of the databases :
[root@localhost my.cnf.d]# ls -al total 24 drwxr-xr-x. 2 root root 67 Oct 11 16:02 . drwxr-xr-x. 77 root root 8192 Oct 11 16:34 .. -rw-r--r--. 1 root root 295 Apr 26 12:37 client.cnf -rw-r--r--. 1 root root 232 Apr 26 12:37 mysql-clients.cnf -rw-r--r--. 1 root root 803 Oct 11 16:02 server.cnf [root@localhost my.cnf.d]#
After checking all of the available configuration files. The configuration is actually exist in the file with the name of ‘server.cnf’. The deciding factor for the line of the configuration exist in the following one :
# These two groups are only read by MariaDB servers, not by MySQL. # If you use the same .cnf file for MySQL and MariaDB, # you can put MariaDB-only options here [mariadb] [mariadb-5.5]
Solution
So, according to the previous information, there are two section of MariaDB. It is pointing out each of it for each different version. In order to configure the right version of MariaDB database server, just execute the following command to check the version of the MariaDB database server first :
[root@localhost my.cnf.d]# mysql --version mysql Ver 15.1 Distrib 5.5.64-MariaDB, for Linux (x86_64) using readline 5.1 [root@localhost my.cnf.d]#
Since it has the version of 5.5.64, it is obvious to put the configuration in the mariadb-5.5 section. Just put the following line in the [mariadb-5.5] section :
Just restart the MariaDB database server to implement the change of the configuration above :
[root@localhost ~]# systemctl restart mariadb [root@localhost ~]#
After restarting the MariaDB database server, check the status of the listening interface for receiving incoming request. Just type the following command :
[root@localhost ~]# netstat -tulpn | grep 3306 tcp 0 0 0.0.0.0:3306 0.0.0.0:* LISTEN 27681/mysqld [root@localhost ~]#
As in the output of the above command execution, it is obvious that it is currently listening in any available interface in the machine. The representation is in the address of ‘0.0.0.0’. It is currently listening in the default port of MariaDB server. It is listening in port 3306.
Ubuntu — dhcp server ‘not configured to listen on any interfaces’
I’m at my wits end on this one; I have tried for hours to get this to work, but I’m stumped. Hope one of you can help. 🙂 I’m trying to get dhcp3-server to work on Ubuntu. It’s installed, and setup correctly to run in rc2,3,4,5.d runlevels. On boot, its init.d script does get run, and in syslog, I get the following:
Oct 18 20:40:37 jez-ubuntu dhcpd: Internet Systems Consortium DHCP Server V3.1.1 Oct 18 20:40:37 jez-ubuntu dhcpd: Copyright 2004-2008 Internet Systems Consortium. Oct 18 20:40:37 jez-ubuntu dhcpd: All rights reserved. Oct 18 20:40:37 jez-ubuntu dhcpd: For info, please visit http://www.isc.org/sw/dhcp/ Oct 18 20:40:37 jez-ubuntu dhcpd: Wrote 2 leases to leases file. Oct 18 20:40:37 jez-ubuntu dhcpd: Oct 18 20:40:37 jez-ubuntu dhcpd: No subnet declaration for eth1 (0.0.0.0). Oct 18 20:40:37 jez-ubuntu dhcpd: ** Ignoring requests on eth1. If this is not what Oct 18 20:40:37 jez-ubuntu dhcpd: you want, please write a subnet declaration Oct 18 20:40:37 jez-ubuntu dhcpd: in your dhcpd.conf file for the network segment Oct 18 20:40:37 jez-ubuntu dhcpd: to which interface eth1 is attached. ** Oct 18 20:40:37 jez-ubuntu dhcpd: Oct 18 20:40:37 jez-ubuntu dhcpd: Oct 18 20:40:37 jez-ubuntu dhcpd: Not configured to listen on any interfaces! Oct 18 20:40:39 jez-ubuntu NetworkManager: (eth0): device state change: 1 -> 2 Oct 18 20:40:39 jez-ubuntu NetworkManager: (eth0): bringing up device. Oct 18 20:40:39 jez-ubuntu NetworkManager: (eth0): preparing device. [. ] As you can see, dhcpd appears to be running before NetworkManager, which is what sets up my eth0 (internet) and eth1 (home network) interfaces. You’d think this had something to do with the rcX.d symlink names, and that dhcpd was named to start before NetworkManager. Not so. My dhcp3-server symlinks are named ‘S99dhcp3-server’ and the Network Manager symlinks are named ‘S50NetworkManager’, so it should be starting before the dhcp server. In addition, if I actually run (as root) from the commandline ‘/etc/init.d/dhcp3-server’. the server runs OK! It only fails at boot! Why does it say it’s not configured to listen on any interfaces? Is the network manager not bringing interfaces eth0 and eth1 up until after all my boot scripts have run? If this is the case, what use is it? Surely other scripts would need these interfaces to be available at boot time? Here’s my /etc/dhcp3/dhcpd.conf file:
subnet 192.168.0.0 netmask 255.255.255.0
# Defaults for dhcp initscript # sourced by /etc/init.d/dhcp # installed at /etc/default/dhcp3-server by the maintainer scripts # # This is a POSIX shell fragment # # On what interfaces should the DHCP server (dhcpd) serve DHCP requests? # Separate multiple interfaces with spaces, e.g. "eth0 eth1". INTERFACES="eth1"