Failed to ping eth0 from a LAN connection when I enabled the WiFi hot spot in Rpi 3

Question

I have set up a WiFi hotspot in a Rpi3 board using this article https://www.raspberrypi.org/documentation/configuration/wireless/access-point.md. I can ping the eth0 IP before I start hostapd and dnsmasq services. When I start this. I can access the RPi only through the WiFi hotspot. Unable to access through the LAN connection(ping failed to the eth0 IP address). I don't want to share internet so I didn't configure the bridge connection

My Network Settings

auto lo
iface lo inet loopback

#wired
auto eth0
iface eth0 inet static
address 192.168.9.14
netmask 255.255.255.0
gateway 0.0.0.0
#end wired

#wireless
auto wlan0
allow-hotplug wlan0 
iface wlan0 inet static
address 192.168.9.104
netmask 255.255.255.0
broadcast 192.168.9.255
#end wireless

I cant ping 192.168.9.14 when the hotspot Up. I want to communicate to 192.168.9.14 through a LAN if I connected a LAN cable. I need to communicate to 192.168.9.104 if I am connected to the Rpi Wifi hotspot.

WiFi hotspot is working correctly but unable to communicate through LAN connection. LAN connection worked correctly before starting hostapd and dnsmasq

ip link show Result

pi@raspberrypi:~ $ ip link show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN mode DEFAULT group default 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000
    link/ether b8:27:eb:11:19:9c brd ff:ff:ff:ff:ff:ff
3: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP mode DEFAULT group default qlen 1000
    link/ether b8:27:eb:44:4c:c9 brd ff:ff:ff:ff:ff:ff

pi@raspberrypi:~ $ ip addr show
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN group default 
    link/loopback 00:00:00:00:00:00 brd 00:00:00:00:00:00
    inet 127.0.0.1/8 scope host lo
       valid_lft forever preferred_lft forever
    inet6 ::1/128 scope host 
       valid_lft forever preferred_lft forever
2: eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether b8:27:eb:11:19:9c brd ff:ff:ff:ff:ff:ff
    inet 192.168.9.14/24 brd 192.168.9.255 scope global eth0
       valid_lft forever preferred_lft forever
    inet 192.168.9.132/24 brd 192.168.9.255 scope global secondary eth0
       valid_lft forever preferred_lft forever
    inet6 fe80::ba27:ebff:fe11:199c/64 scope link 
       valid_lft forever preferred_lft forever
3: wlan0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc pfifo_fast state UP group default qlen 1000
    link/ether b8:27:eb:44:4c:c9 brd ff:ff:ff:ff:ff:ff
    inet 192.168.9.104/24 brd 192.168.9.255 scope global wlan0
       valid_lft forever preferred_lft forever
    inet6 fe80::ba27:ebff:fe44:4cc9/64 scope link 
       valid_lft forever preferred_lft forever

pi@raspberrypi:~ $ ip route show
default dev eth0 
default via 192.168.9.10 dev eth0  metric 202 
192.168.9.0/24 dev wlan0  proto kernel  scope link  src 192.168.9.104 
192.168.9.0/24 dev eth0  proto kernel  scope link  src 192.168.9.132  metric 202 
pi@raspberrypi:~ $ ^C

Answer 1

The problem is that you have set up both interfaces within the same network segment (192.168.9.0/24). So, once both interfaces are up, when traffic is going out, the routing code will chose among any of the two interfaces where it could go out (when going in, actually, you can't choose which interface it will come in because it's sent to either one interface or the other from the other box so the rpi has no power there.... you can check this by using a sniffer). So the problem is that when you want to reach the IP assigned to eth0 from another host, the traffic is getting to the rpi fine (check with a sniffer, for real, you will see that traffic is reaching the rpi through eth0) but then when responding, the routing decision is choosing the other interface to respond... and then to the originating box you get some traffic that is coming back from the rpi but it has a different source IP from the IP that the originating traffic was sent to.. and then the box will drop this traffic because it's not coming from the expected IP. Long story short: Set up two different network segments, one for each interface so that they don't overlap or set up a bridge (the instructions are on the that rpi manual page you linked).