I installed three operating systems(let's say 3 hosts) in VMware, all with NAT mode. 3 hosts are named centos, centos 1,centos 2.(As the pic shows below)
3 hosts in VMware
The first host's IP address is 192.168.248.132, the second is 192.168.248.136, and we don't need to know third host's IP because it's not related to this issue.
I typed the command "ping 192.168.248.136", and the output on the screen is:
PING 192.168.248.136 (192.168.248.136) 56(84) bytes of data.
64 bytes from 192.168.248.136: icmp_seq=1 ttl=64 time=0.435 ms
64 bytes from 192.168.248.136: icmp_seq=2 ttl=64 time=0.313 ms
64 bytes from 192.168.248.136: icmp_seq=3 ttl=64 time=0.385 ms
This means ping command has succeeded and host no.2(whose IP addr is 192.168.248.136) has received ICMP and replied.
Meanwhile, I typed the command "tcpdump -i ens33" in host no.3. If everything had worked correctly, host no.3 would not have received any data between host no.1 and host no.2, because ICMP is neither broadcast nor multicast, so only host no.1 and 2 can send and receive. Also, host no.3's network interface is not promiscuous mode, so it can only receive it's own frame. The output from host no.3 below can show it is not promiscuous mode.
[root#localhost usr]# ifconfig
ens33: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.248.137 netmask 255.255.255.0 broadcast 192.168.248.255
inet6 fe80::b488:bc2c:3770:a95f prefixlen 64 scopeid 0x20<link>
ether 00:0c:29:0d:dc:86 txqueuelen 1000 (Ethernet)
RX packets 351081 bytes 512917768 (489.1 MiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 34947 bytes 2166260 (2.0 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
flag is 4163<UP,BROADCAST,RUNNING,MULTICAST>, "PROMISC" is not mentioned, so it is not promiscuous mode.
However, after I typed "tcpdump -i ens33" in host no.3, something appeared on the screen:
06:28:11.511233 IP 192.168.248.132 > 192.168.248.136: ICMP echo request, id 3137, seq 5, length 64
06:28:11.511503 IP 192.168.248.136 > 192.168.248.132: ICMP echo reply, id 3137, seq 5, length 64
Host no.3 received the dataflow between no.1 and 2, and this was supposed to be sent to no.2, but no.3 received it.
So here comes the question, why can host no.3 receive packet which was not supposed to be sent to it?
tcpdump by default activates "promiscuous mode" making it able to see anything on the network it is connected to (even if not explicitly sent to it).
the three hosts seem to be connected to a virtual switch that do not isolate the hosts from each other.
Related
I have 2 RPis connected together with an ethernet cable. For the 1st RPi, the wifi is disabled, and it should get the internet connection from the 2nd RPi that is connected to the internet by wifi.
I am using the Network Manager (NM), and I also need that both RPis have static IPs on their eth0 interface:
RPi1 : 192.168.4.115/24 # The RPi that is not connected to wifi
RPi2 : 192.168.4.1/24 # The RPi that is connected to wifi
I configured the static IP of the RPi1 in /etc/dhcpcd.conf. For the RPi2, I used the NM when I configured the shared connection :
# On RPi2
nmcli connection add type ethernet ifname eth0 ipv4.method shared con-name local
nmcli connection modify local ipv4.addresses 192.168.4.1/24
nmcli connection up local
When I check the connection of the RPi2, I have the good IP, and when I ping 1.1.1.1 I have a reply:
pi#raspberrypi2:~ $ ifconfig
eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.4.1 netmask 255.255.255.0 broadcast 192.168.4.255
inet6 fe80::514:af1e:da15:6f80 prefixlen 64 scopeid 0x20<link>
ether e4:5f:01:4c:5c:00 txqueuelen 1000 (Ethernet)
RX packets 105 bytes 20375 (19.8 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 178 bytes 22385 (21.8 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
wlan0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.11.16 netmask 255.255.255.0 broadcast 192.168.11.255
inet6 fe80::750f:5ec2:8158:fb80 prefixlen 64 scopeid 0x20<link>
ether e4:5f:01:4c:5c:01 txqueuelen 1000 (Ethernet)
RX packets 488 bytes 59706 (58.3 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 206 bytes 30178 (29.4 KiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
But on the first RPi, even if I have the good IP on eth0 (192.168.4.115), when I try a ping, I have connect: network is unreachable
So I don't know what is missing to achieve the sharing of the connection. And I don't know what I can check? Feel free to ask for any useful data, I don't know what can be useful.
The first RPi doesn't use the NM because I don't need it, the normal way of the RPi is enough.
I'm getting this error when attempting to setup a new server on pgAdmin4:
Unable to connect to server:
could not connect to server: Connection refused (0x0000274D/10061)
Is the server running on host "192.168.210.146" and accepting
TCP/IP connections on port 5432?
I have postgres 12.7 running on CentOS 8 inside a virtual box 6.1 VM which is running on my Windows 10 21H1 laptop. I can connect to the OS using putty and the CentOS web client just fine.
Here is some network info via the CentOS web client terminal:
# nmap localhost
Starting Nmap 7.70 ( https://nmap.org ) at 2021-07-14 16:59 PDT
Nmap scan report for localhost (127.0.0.1)
Host is up (0.000014s latency).
Other addresses for localhost (not scanned): ::1
Not shown: 996 closed ports
PORT STATE SERVICE
22/tcp open ssh
111/tcp open rpcbind
5432/tcp open postgresql
9090/tcp open zeus-admin
Nmap done: 1 IP address (1 host up) scanned in 1.68 seconds
netstat -tlpn
Active Internet connections (only servers)
Proto Recv-Q Send-Q Local Address Foreign Address State PID/Program name
tcp 0 0 0.0.0.0:111 0.0.0.0:* LISTEN 1/systemd
tcp 0 0 0.0.0.0:22 0.0.0.0:* LISTEN 954/sshd
tcp 0 0 127.0.0.1:5432 0.0.0.0:* LISTEN 972/postmaster
tcp 0 0 127.0.0.1:37753 0.0.0.0:* LISTEN 1620/cockpit-bridge
# firewall-cmd --list-all
public (active)
target: default
icmp-block-inversion: no
interfaces: enp0s3
sources:
services: cockpit dhcpv6-client postgresql ssh
ports: 5432/tcp
protocols:
masquerade: no
forward-ports:
source-ports:
icmp-blocks:
rich rules:
#
# ifconfig
enp0s3: flags=4163<UP,BROADCAST,RUNNING,MULTICAST> mtu 1500
inet 192.168.210.146 netmask 255.255.254.0 broadcast 192.168.211.255
inet6 fe80::a00:27ff:fecb:8d2d prefixlen 64 scopeid 0x20<link>
ether 08:00:27:cb:8d:2d txqueuelen 1000 (Ethernet)
RX packets 4704 bytes 512333 (500.3 KiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 3757 bytes 2510585 (2.3 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
lo: flags=73<UP,LOOPBACK,RUNNING> mtu 65536
inet 127.0.0.1 netmask 255.0.0.0
inet6 ::1 prefixlen 128 scopeid 0x10<host>
loop txqueuelen 1000 (Local Loopback)
RX packets 7252 bytes 2161674 (2.0 MiB)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 7252 bytes 2161674 (2.0 MiB)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
In the PgAdmin setup server screen I'm using the ip address listed above of 192.168.210.146, user postgres and its password, port 5432 and the database is set to postgres.
I get this same error trying to establish odbc and jdbc connections from my laptop but I'm not sure what in the postgres environment needs to be fixed.I did add 1 entry the pg_hba.conf file as shown below, but that didn't help:
# IPv4 local connections:
host all all 127.0.0.1/32 ident
host all all 192.168.210.146/32 trust #added;not helping
Is there another file or setting that needs to be fixed?
Thanks.
The solution was to first un-comment the listen_address entry in postgresql.conf and then set it to the necessary ip number. Everything connects just fine now. Thanks
We have an openvpn server (I beleive on our router), and mobile clients that connect to the internet from far away locations, but also occasionally from inside our office. These systems are headless so configuring them differently before connecting to the in-office network is a nonstarter - we would like to SSH into them via their avahi hostnames regardless of where they physically are.
Right we can ping and SSH when they are connected to the internet outside of our network. When they are connected from inside our LAN, sometimes hostname.local resolves to 192.168.10.3 (and ping and SSH don't work) and sometimes to 192.168.1.211 (and ping and ssh do work).
When monitoring wireshark on the mobile client, ping requests to the 192.168.10.3 address do appear but are not answered.
How can we configure our clients so they can be reached when connecting from inside of our network?
output of ifconfig on client (connected to VPN via our office LAN):
eth0 Link encap:Ethernet HWaddr 00:04:4b:a7:fa:e5
inet addr:192.168.1.223 Bcast:192.168.1.255 Mask:255.255.255.0
inet6 addr: fe80::7a45:f5b1:1b87:c6f0/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:8964 errors:0 dropped:0 overruns:0 frame:0
TX packets:771 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:1847719 (1.8 MB) TX bytes:160760 (160.7 KB)
Interrupt:42
tap0 Link encap:Ethernet HWaddr ce:d4:a6:18:48:21
inet addr:192.168.10.3 Bcast:192.168.10.255 Mask:255.255.255.0
inet6 addr: fe80::ccd4:a6ff:fe18:4821/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:1381 errors:0 dropped:0 overruns:0 frame:0
TX packets:58 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:214474 (214.4 KB) TX bytes:7149 (7.1 KB)
output of route on client (connected to VPN via our office LAN):
Kernel IP routing table
Destination Gateway Genmask Flags Metric Ref Use Iface
default 192.168.1.1 0.0.0.0 UG 0 0 0 eth0
default 192.168.10.1 0.0.0.0 UG 50 0 0 tap0
default 192.168.1.1 0.0.0.0 UG 100 0 0 eth0
link-local * 255.255.0.0 U 1000 0 0 eth1
192.168.1.0 * 255.255.255.0 U 100 0 0 eth0
192.168.2.0 * 255.255.255.0 U 0 0 0 eth1
192.168.10.0 * 255.255.255.0 U 50 0 0 tap0
Back-to-back pings from another machine on the same LAN to our mobile client. For whatever reason avahi .local names unpredictably resolve to the VPN IP or the other. Anyway, the ping to the VPN IP (second one) just hangs:
[15:51:25]~$ ping liber0.local
PING liber0.local (192.168.1.223) 56(84) bytes of data.
64 bytes from 192.168.1.223: icmp_seq=1 ttl=64 time=4.00 ms
64 bytes from 192.168.1.223: icmp_seq=2 ttl=64 time=6.09 ms
64 bytes from 192.168.1.223: icmp_seq=3 ttl=64 time=38.8 ms
^C
--- liber0.local ping statistics ---
3 packets transmitted, 3 received, 0% packet loss, time 2003ms
rtt min/avg/max/mdev = 4.003/16.302/38.805/15.935 ms
[15:51:29]~$ ping liber0.local
PING liber0.local (192.168.10.3) 56(84) bytes of data.
^C
--- liber0.local ping statistics ---
27 packets transmitted, 0 received, 100% packet loss, time 26629ms
OpenVPN configuration file:
client
dev tap
proto udp
remote <redacted>
float
resolv-retry infinite
nobind
persist-key
persist-tun
verb 3
ca <redacted>.pem
cert <redacted>.pem
key <redacted>.key
cipher AES-256-CBC
auth SHA256
The key hint was that the ICMP packets made it to the VPN connected client, but were not answered. It turned out that the default rp_filter (reverse path filter) is the strictly checking and dropping packets. adding net.ipv4.conf.default.rp_filter = 2 to /etc/sysctl.conf sets rp_filter to loose reverse path checking, and everything works.
I'm trying to use the Broadcom BCM2835 OTG functionality to use the RPi as a Ethernet gadget in order to establish a network connection with a host (I found this is used with RPi Zero).
The OTG is supported in RPi B1 as you can see in the Broadcom BCM2835 specification.
I tried to recompiled the kernel with the module:
Device Drivers > USB support > OTG support
CONFIG_USB_OTG:
The most notable feature of USB OTG is support for a
"Dual-Role" device, which can act as either a device
or a host. The initial role is decided by the type of
plug inserted and can be changed later when two dual
role devices talk to each other.
Select this only if your board has Mini-AB/Micro-AB
connector.
Symbol: USB_OTG [=y]
Type : boolean
Prompt: OTG support
Location:
-> Device Drivers
-> USB support (USB_SUPPORT [=y])
-> Support for Host-side USB (USB [=y])
Defined at drivers/usb/core/Kconfig:44
Depends on: USB_SUPPORT [=y] && USB [=y] && PM [=y]
I added the usb0 interface configuration to /etc/network/interfaces.
allow-hotplug usb0
mapping hotplug
script grep
map usb0
iface usb0 inet static
address 192.168.2.1
netmask 255.255.255.0
broadcast 192.168.2.255
I added line dtoverlay=dwc2 to /boot/config.tx file.
I added dwc2 and g_ether to /etc/modules.
Nothing worked. The output of ifconfig usb0 is:
usb0: flags=4099<UP,BROADCAST,MULTICAST> mtu 1500
inet 192.168.2.1 netmask 255.255.255.0 broadcast 192.168.2.255
ether ba:b9:a5:2a:b2:04 txqueuelen 1000 (Ethernet)
RX packets 0 bytes 0 (0.0 B)
RX errors 0 dropped 0 overruns 0 frame 0
TX packets 0 bytes 0 (0.0 B)
TX errors 0 dropped 0 overruns 0 carrier 0 collisions 0
The host doesn't recognize any USB device when plug.
It's possible to use USB A as a slave? Any idea to solve it?
#!/usr/bin/perl
use Net::Ping;
$p = Net::Ping->new();
my $main_ip="$ARGV[0]";
if ($p->ping($main_ip,1)){
$result=true;
print "$main_ip is alive \n";
}else{
print "$main_ip is down \n";
}
I am using above perl script to ping check the server. It worked fine all the cases except for IP 192.168.0.168.
$ perl test.pl 192.168.0.168
192.168.0.168 is down
]$ ping 192.168.0.168
PING 192.168.0.168 (192.168.0.168) 56(84) bytes of data.
64 bytes from 192.168.0.168: icmp_seq=1 ttl=64 time=0.304 ms
64 bytes from 192.168.0.168: icmp_seq=2 ttl=64 time=0.355 ms
64 bytes from 192.168.0.168: icmp_seq=3 ttl=64 time=2.94 ms
64 bytes from 192.168.0.168: icmp_seq=4 ttl=64 time=0.388 ms
--- 192.168.0.168 ping statistics ---
4 packets transmitted, 4 received, 0% packet loss, time 3292ms
rtt min/avg/max/mdev = 0.304/0.997/2.944/1.124 ms
]$ ping 192.168.0.18
PING 192.168.0.18 (192.168.0.18) 56(84) bytes of data.
From 192.168.0.181 icmp_seq=2 Destination Host Unreachable
From 192.168.0.181 icmp_seq=3 Destination Host Unreachable
From 192.168.0.181 icmp_seq=4 Destination Host Unreachable
--- 192.168.0.18 ping statistics ---
4 packets transmitted, 0 received, +3 errors, 100% packet loss, time 3292ms
pipe 3
]$ perl test.pl 192.168.0.18
192.168.0.18 is down
I had no clue even I have increase ping timeout but the results same
The only problem i can think of is, that the ping command uses the ICMP protocol as default, while Net::Ping uses TCP. You can switch Net::Ping to ICMP by creating your object like this:
my $p = Net::Ping->new( 'icmp' );
Take note, that making ICMP pings requires root privilege on Unix.
In order to send icmp packets you must have rights to create raw sockets, i.e. have root rights.
I suppose you running ping.pl as ordinary user, but you need to be root
ls -al `which ping`
-rws--x--x 1 root root 39640 Dec 17 2011 /bin/ping
^
|
suid bit
ping program has a suid bit, which allows to run ping program with root rights.
By default Net::Ping tries to connect to echo port (7/tcp), if it gets ECONNREFUSED - this means that host is up but refuses connection (nothing is listening on that port). if connect breaks on timeout, this means that host is down.
But! I can block all connection to 7/tcp by firewall:
iptables -I INPUT -p tcp --dport 7 -j DROP
and... voila, i get down instead of alive
So, you should check firewall on your failure pinged host