Making a wifi hotspot maintaining internet connection on the RPi

Question

I followed this tutorial about making a wifi hotspot with a RPi 3 successfully. I can connect to the hotspot and have internet access on my devices, but I don't have internet access on my raspberry pi anymore via ethernet!

I can still ssh on it and ping to 8.8.8.8, but not to domain names like www.google.com

How can I set up a wireless hotspot while maintaining internet connection on the pi through ethernet? Is this even possible?

EDIT: here is the output of the commands I was asked to reproduce in the comments.

pi@raspberrypi:~ $ route -n
Kernel IP routing table
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface
0.0.0.0         192.168.1.1     0.0.0.0         UG    202    0        0 eth0
169.254.0.0     0.0.0.0         255.255.0.0     U     303    0        0 wlan0
192.168.1.0     0.0.0.0         255.255.255.0   U     202    0        0 eth0
192.168.42.0    0.0.0.0         255.255.255.0   U     0      0        0 wlan0

pi@raspberrypi:~ $ cat /etc/resolv.conf

# Generated by resolvconf

pi@raspberrypi:~ $ sudo iptables -L

Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination         
ACCEPT     all  --  anywhere             anywhere             state RELATED,ESTABLISHED
ACCEPT     all  --  anywhere             anywhere            

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         

pi@raspberrypi:~ $ sudo iptables -t nat -L

Chain PREROUTING (policy ACCEPT)
target     prot opt source               destination         

Chain INPUT (policy ACCEPT)
target     prot opt source               destination         

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination         

Chain POSTROUTING (policy ACCEPT)
target     prot opt source               destination         
MASQUERADE  all  --  anywhere             anywhere            

EDIT2: Output of /etc/network/interfaces and /etc/dhcpcd.conf

I have configured a static ip on the wlan0 in the interfaces file as per the tutorial, and a static ip on eth0 in the dhcpcd.conf (because it didn't worked on the interfaces file for ethernet).

pi@raspberrypi:~ $ cat /etc/network/interfaces

# interfaces(5) file used by ifup(8) and ifdown(8)

# Please note that this file is written to be used with dhcpcd
# For static IP, consult /etc/dhcpcd.conf and 'man dhcpcd.conf'

# Include files from /etc/network/interfaces.d:
source-directory /etc/network/interfaces.d

auto lo
iface lo inet loopback

iface eth0 inet dhcp

allow-hotplug wlan0
iface wlan0 inet static
    address 192.168.42.1
    netmask 255.255.255.0
#    wpa-conf /etc/wpa_supplicant/wpa_supplicant.conf

#allow-hotplug wlan1
#iface wlan1 inet manual
#    wpa-conf /etc/wpa_supplicant/wpa_supplicant.conf

pi@raspberrypi:~ $ cat /etc/dhcpcd.conf

# A sample configuration for dhcpcd.
# See dhcpcd.conf(5) for details.

# Allow users of this group to interact with dhcpcd via the control socket.
#controlgroup wheel

# Inform the DHCP server of our hostname for DDNS.
hostname

# Use the hardware address of the interface for the Client ID.
clientid
# or
# Use the same DUID + IAID as set in DHCPv6 for DHCPv4 ClientID as per RFC4361.
#duid

# Persist interface configuration when dhcpcd exits.
persistent

# Rapid commit support.
# Safe to enable by default because it requires the equivalent option set
# on the server to actually work.
option rapid_commit

# A list of options to request from the DHCP server.
option domain_name_servers, domain_name, domain_search, host_name
option classless_static_routes
# Most distributions have NTP support.
option ntp_servers
# Respect the network MTU.
# Some interface drivers reset when changing the MTU so disabled by default.
#option interface_mtu

# A ServerID is required by RFC2131.
require dhcp_server_identifier

# Generate Stable Private IPv6 Addresses instead of hardware based ones
slaac private

# A hook script is provided to lookup the hostname if not set by the DHCP
# server, but it should not be run by default.
nohook lookup-hostname

interface eth0

static ip_address=192.168.1.144/24
static routers=192.168.1.1
static domain_name_server=8.8.8.8

EDIT3: It appears that the problem is that the file /etc/resolv.conf clears itself some seconds after editing it, but I don't know what is overwriting or regenerating it...

Answer 1

Your /etc/resolv.conf is empty, which is consistent with you being able to ping by IP address, but not by DNS name. How are you getting your IP address on your RPi? If via DHCP, your DHCP server should be configured to provide DNS information. If you've manually configured a fixed IP address, you need to list a DNS server (e.g. nameserver 8.8.8.8) to your /etc/resolv.conf file, or via GUI. Let us know how you've configured your RPi's network and we can provide more specific help.

Answer 2

The problem was, as said by bobstro, that the /etc/resolv.conf file was empty, but the file is regenerated automatically every few seconds.

The solution was to add the line dns-nameservers 8.8.8.8 below the eth0 interface definition (iface eth0 inet dhcp) to the /etc/network/interfaces file and reboot the pi. After the reboot, the nameserver gets copied to /etc/resolv.conf and I am able to ping to websites successfully.

Answer 3

There are so many things wrong with your setup.

Firstly there is no point in configuring /etc/dhcpcd.conf because you have disabled dhcpcd by calling dhcp (as you would see from the boot log).

Secondly there is no point in editing /etc/resolv.conf, because it changed by resolvconf which is called so many processes (including dhcpd). There ARE ways of setting it (which you can research), but this is generally a bad idea.

Answer 4

Do you happen have avahi-daemon running? I once had a similar problem as you on my RPI running as a nginx server that /etc/resolv.conf will mystically became empty after a couple of days but still be able to access via ssh and ping with IP address. I delete avahi-daemon and the problem go away since then. I still don't know what exactly caused it, but I think it is caused by conflicts from another DNS resolve service.