EAP615-Wall unable to reach internet

I was just trying out OpenWrt on an EAP615-Wall using the snapshot firmware (revision r19421-3aa96efa24) and I've run into an odd issue. I have an already existing network so I was planning to configure it as just an AP and not a router, so I disabled the firewall, dnsmasq, odhcpd, and left the default switch configuration with all the interfaces bridged. However, no matter what I do I can't seem to get the device itself to be able to connect to the internet. I've tried both a static ip (setting the dns and gateway settings appropriately) as well as with dhcp with my existing setup and neither seems to work. The part that's incredibly baffling is that while wget will not connect to anything beyond my private network, I can resolve external dns names and even ping things outside of the network. It's just things like wget or opkg that seem to not work. E.g.:

root@OpenWrt:~# nslookup google.com
Server:         127.0.0.1
Address:        127.0.0.1:53

Non-authoritative answer:
Name:   google.com
Address: 142.250.65.206

Non-authoritative answer:
Name:   google.com
Address: 2607:f8b0:4006:824::200e

root@OpenWrt:~# ping google.com
PING google.com (142.250.65.206): 56 data bytes
64 bytes from 142.250.65.206: seq=0 ttl=119 time=17.661 ms
^C
--- google.com ping statistics ---
1 packets transmitted, 1 packets received, 0% packet loss
round-trip min/avg/max = 17.661/17.661/17.661 ms
root@OpenWrt:~# wget -4 -O - https://google.com/
Downloading 'https://google.com/'
Failed to send request: Operation not permitted

Sounds like a routing issue?

I'd have thought it might be something like that, but the routes look fine as far as I can tell:

root@OpenWrt:~# ip addr
1: lo: <LOOPBACK,UP,LOWER_UP> mtu 65536 qdisc noqueue state UNKNOWN qlen 1000
    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 1504 qdisc fq_codel state UP qlen 1000
    link/ether 14:eb:b6:7c:1a:c6 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::16eb:b6ff:fe7c:1ac6/64 scope link
       valid_lft forever preferred_lft forever
3: lan0@eth0: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue master br-lan state UP qlen 1000
    link/ether 14:eb:b6:7c:1a:c6 brd ff:ff:ff:ff:ff:ff
4: lan3@eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue master br-lan state LOWERLAYERDOWN qlen 1000
    link/ether 14:eb:b6:7c:1a:c6 brd ff:ff:ff:ff:ff:ff
5: lan2@eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue master br-lan state LOWERLAYERDOWN qlen 1000
    link/ether 14:eb:b6:7c:1a:c6 brd ff:ff:ff:ff:ff:ff
6: lan1@eth0: <NO-CARRIER,BROADCAST,MULTICAST,UP> mtu 1500 qdisc noqueue master br-lan state LOWERLAYERDOWN qlen 1000
    link/ether 14:eb:b6:7c:1a:c6 brd ff:ff:ff:ff:ff:ff
22: wlan0: <BROADCAST,MULTICAST> mtu 1500 qdisc noqueue state DOWN qlen 1000
    link/ether 14:eb:b6:7c:1a:c6 brd ff:ff:ff:ff:ff:ff
30: br-lan: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP qlen 1000
    link/ether 14:eb:b6:7c:1a:c6 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::16eb:b6ff:fe7c:1ac6/64 scope link
       valid_lft forever preferred_lft forever
31: br-lan.2@br-lan: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP qlen 1000
    link/ether 14:eb:b6:7c:1a:c6 brd ff:ff:ff:ff:ff:ff
    inet 192.168.1.200/24 brd 192.168.1.255 scope global br-lan.2
       valid_lft forever preferred_lft forever
32: br-lan.1040@br-lan: <BROADCAST,MULTICAST,UP,LOWER_UP> mtu 1500 qdisc noqueue state UP qlen 1000
    link/ether 14:eb:b6:7c:1a:c6 brd ff:ff:ff:ff:ff:ff
    inet6 fe80::16eb:b6ff:fe7c:1ac6/64 scope link
       valid_lft forever preferred_lft forever
root@OpenWrt:~# ip route
default via 192.168.1.1 dev br-lan.2
192.168.1.0/24 dev br-lan.2 scope link  src 192.168.1.200
root@OpenWrt:~# ip route get 142.250.65.206
142.250.65.206 via 192.168.1.1 dev br-lan.2  src 192.168.1.200

This is after experimenting with setting up the wifi network and having that use a vlan, but I saw pretty much the same routes and behavior before as well)

Also I just discovered that while I can wget another host on 192.168.1.x, I have the same issue trying to wget 192.168.1.1 - even though I can from other hosts on the network. I was trying to see if there was any filtering going on with my existing setup that might for some reason be catching the new device here, but I can't find anything in the existing setup that would do that.

I have an EAP615-Wall too, but do not have this problem. Running OpenWrt SNAPSHOT r19354-39ec9edacb.

Are there two 192.168.1.1's on the network?

In network interfaces, is the DHCP server disabled for your main bridge? Shouldn't be a problem, so I'm just guessing at this point.

I installed the snapshot onto mine via the webgui, installed Luci, connected to the LAN side, disabled the WAN/LAN firewall rules, added the WAN eth port to the bridge, disabled DHCP server for the bridge, moved the "wan" port from static address to DHCP, and configured the wifi radios.

EDIT: at this point, there are no more WAN settings left on my config, be it eth ports, bridges, firewall rules/zones, etc.

There shouldn't be two 192.168.1.1s, the EAP615-wall is currently 192.168.1.200, and my existing router is 192.168.1.1. Interestingly I've discovered that the EAP615-wall can't wget/curl 192.168.1.1 either so I'm starting with debugging that first. Looking at some tcpdump logs from the EAP615-wall while trying:

root@OpenWrt:~# curl -v --insecure https://192.168.1.1
* Failed to connect to 192.168.1.1 port 443 after 131826 ms: Operation timed out
curl: (28) Failed to connect to 192.168.1.1 port 443 after 131826 ms: Operation timed out

Results in these logs:

root@OpenWrt:~# tcpdump -v -i br-lan.2 -nn '(proto \tcp) and ((src 192.168.1.1 and src port 443) or (host 192.168.1.1 and dst port 443))'
tcpdump: listening on br-lan.2, link-type EN10MB (Ethernet), capture size 262144 bytes
14:57:31.939478 IP (tos 0x0, ttl 64, id 50545, offset 0, flags [DF], proto TCP (6), length 60)
    192.168.1.200.48114 > 192.168.1.1.443: Flags [S], cksum 0x8448 (incorrect -> 0x159b), seq 3456882582, win 64240, options [mss 1460,sackOK,TS val 813637518 ecr 0,nop,wscale 4], length 0
14:57:31.940264 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 60)
    192.168.1.1.443 > 192.168.1.200.48114: Flags [S.], cksum 0x379d (correct), seq 2986799829, ack 3456882583, win 14480, options [mss 1460,sackOK,TS val 365684131 ecr 813637518,nop,wscale 6], length 0
14:57:32.930333 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 60)
    192.168.1.1.443 > 192.168.1.200.48114: Flags [S.], cksum 0x3739 (correct), seq 2986799829, ack 3456882583, win 14480, options [mss 1460,sackOK,TS val 365684231 ecr 813637518,nop,wscale 6], length 0
14:57:32.965245 IP (tos 0x0, ttl 64, id 50546, offset 0, flags [DF], proto TCP (6), length 60)
    192.168.1.200.48114 > 192.168.1.1.443: Flags [S], cksum 0x8448 (incorrect -> 0x1199), seq 3456882582, win 64240, options [mss 1460,sackOK,TS val 813638544 ecr 0,nop,wscale 4], length 0
14:57:32.965817 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 60)
    192.168.1.1.443 > 192.168.1.200.48114: Flags [S.], cksum 0x3736 (correct), seq 2986799829, ack 3456882583, win 14480, options [mss 1460,sackOK,TS val 365684234 ecr 813637518,nop,wscale 6], length 0
14:57:35.045257 IP (tos 0x0, ttl 64, id 50547, offset 0, flags [DF], proto TCP (6), length 60)
    192.168.1.200.48114 > 192.168.1.1.443: Flags [S], cksum 0x8448 (incorrect -> 0x0979), seq 3456882582, win 64240, options [mss 1460,sackOK,TS val 813640624 ecr 0,nop,wscale 4], length 0
14:57:35.045837 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 60)
    192.168.1.1.443 > 192.168.1.200.48114: Flags [S.], cksum 0x3666 (correct), seq 2986799829, ack 3456882583, win 14480, options [mss 1460,sackOK,TS val 365684442 ecr 813637518,nop,wscale 6], length 0
14:57:37.530328 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 60)
    192.168.1.1.443 > 192.168.1.200.48114: Flags [S.], cksum 0x356d (correct), seq 2986799829, ack 3456882583, win 14480, options [mss 1460,sackOK,TS val 365684691 ecr 813637518,nop,wscale 6], length 0

I'm not super familiar with this stuff, but I see the SYN, SYN-ACK, but then no ACK... and I'm not sure what's going on with that.

My current network config:

config interface 'loopback'
        option device 'lo'
        option proto 'static'
        option ipaddr '127.0.0.1'
        option netmask '255.0.0.0'

config globals 'globals'
        option packet_steering '1'

config device
        option name 'br-lan'
        option type 'bridge'
        list ports 'lan0'
        list ports 'lan1'
        list ports 'lan2'
        list ports 'lan3'
        option vlan_filtering '1'


config bridge-vlan
        option device 'br-lan'
        option vlan '2'
        list ports 'lan0:u'

config interface 'lan'
        option device 'br-lan.2'
        option proto 'dhcp'
        option netmask '255.255.255.0'
        option ipv6 '0'

config bridge-vlan
        option device 'br-lan'
        option vlan '1040'
        list ports 'lan0:t'

config interface 'guest'
        option device 'br-lan.1040'
        option proto 'none'

But I had the same issue before I added the VLAN stuff, when I think the config was more like

config interface 'loopback'
        option device 'lo'
        option proto 'static'
        option ipaddr '127.0.0.1'
        option netmask '255.0.0.0'

config globals 'globals'
        option packet_steering '1'

config device
        option name 'br-lan'
        option type 'bridge'
        list ports 'lan0'
        list ports 'lan1'
        list ports 'lan2'
        list ports 'lan3'

config interface 'lan'
        option device 'br-lan'
        option proto 'dhcp'
        option netmask '255.255.255.0'
        option ipv6 '0'

For comparison, if I try to curl/wget another host on the local network that does work though:

root@OpenWrt:~# curl -v --insecure https://192.168.1.143:8443
> GET / HTTP/1.1
> Host: 192.168.1.143:8443
> User-Agent: curl/7.82.0
> Accept: */*
>
< HTTP/1.1 302
< Location: /manage
< Content-Length: 0
< Date: Tue, 12 Apr 2022 15:11:16 GMT
<

And the tcpdump logs there make sense (truncated here):

tcpdump: listening on br-lan.2, link-type EN10MB (Ethernet), capture size 262144 bytes
15:11:15.645815 IP (tos 0x0, ttl 64, id 19510, offset 0, flags [DF], proto TCP (6), length 60)
    192.168.1.200.46470 > 192.168.1.143.8443: Flags [S], cksum 0x84d6 (incorrect -> 0xaafe), seq 2828664637, win 64240, options [mss 1460,sackOK,TS val 3793140987 ecr 0,nop,wscale 4], length 0
15:11:15.646372 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 60)
    192.168.1.143.8443 > 192.168.1.200.46470: Flags [S.], cksum 0x7ba8 (correct), seq 2282668246, ack 2828664638, win 28960, options [mss 1460,sackOK,TS val 3876096292 ecr 3793140987,nop,wscale 7], length 0
15:11:15.646578 IP (tos 0x0, ttl 64, id 19511, offset 0, flags [DF], proto TCP (6), length 52)
    192.168.1.200.46470 > 192.168.1.143.8443: Flags [.], cksum 0x84ce (incorrect -> 0x0be5), ack 1, win 4015, options [nop,nop,TS val 3793140988 ecr 3876096292], length 0
15:11:15.742881 IP (tos 0x0, ttl 64, id 19512, offset 0, flags [DF], proto TCP (6), length 348)
    192.168.1.200.46470 > 192.168.1.143.8443: Flags [P.], cksum 0x85f6 (incorrect -> 0xeb4b), seq 1:297, ack 1, win 4015, options [nop,nop,TS val 3793141084 ecr 3876096292], length 296
15:11:15.743464 IP (tos 0x0, ttl 64, id 56808, offset 0, flags [DF], proto TCP (6), length 52)
    192.168.1.143.8443 > 192.168.1.200.46470: Flags [.], cksum 0x18c0 (correct), ack 297, win 235, options [nop,nop,TS val 3876096389 ecr 3793141084], length 0
15:11:15.763198 IP (tos 0x0, ttl 64, id 56809, offset 0, flags [DF], proto TCP (6), length 1427)
    192.168.1.143.8443 > 192.168.1.200.46470: Flags [P.], cksum 0x5e21 (correct), seq 1:1376, ack 297, win 235, options [nop,nop,TS val 3876096409 ecr 3793141084], length 1375
15:11:15.763285 IP (tos 0x0, ttl 64, id 19513, offset 0, flags [DF], proto TCP (6), length 52)
    192.168.1.200.46470 > 192.168.1.143.8443: Flags [.], cksum 0x84ce (incorrect -> 0x047d), ack 1376, win 4006, options [nop,nop,TS val 3793141105 ecr 3876096409], length 0

You can probably guess my ability to help is a bit limited.

network config looks the same as mine
edit: somehow made a mess of the indents.

firewall is
config defaults
option input 'ACCEPT'
option output 'ACCEPT'
option forward 'REJECT'
option synflood_protect '1'

dhcp - should be defacto disabled, since none of my interfaces uses it.

config dnsmasq
	option domainneeded '1'
	option boguspriv '1'
	option filterwin2k '0'
	option localise_queries '1'
	option rebind_protection '1'
	option rebind_localhost '1'
	option local '/lan/'
	option domain 'lan'
	option expandhosts '1'
	option nonegcache '0'
	option authoritative '1'
	option readethers '1'
	option leasefile '/tmp/dhcp.leases'
	option resolvfile '/tmp/resolv.conf.d/resolv.conf.auto'
	option nonwildcard '1'
	option localservice '1'
	option ednspacket_max '1232'

config dhcp 'lan'
	option interface 'lan'
	option start '100'
	option limit '150'
	option leasetime '12h'
	option dhcpv4 'server'
	list ra_flags 'managed-config'
	list ra_flags 'other-config'
	option ra 'hybrid'
	option dhcpv6 'hybrid'
	option ignore '1'

config dhcp 'wan'
	option interface 'wan'
	option ignore '1'

config odhcpd 'odhcpd'
	option maindhcp '0'
	option leasefile '/tmp/hosts/odhcpd'
	option leasetrigger '/usr/sbin/odhcpd-update'
	option loglevel '4'

Here is a dumb question: if your router was something other than 192.168.1.1, does it work? I know that may be a fair bit of work to try, though, and may have quite a few negative knock down effects. I guess another one is to see if your router is rejecting the EAP615 for some reason, and it should have dchp logs of some sort, indicating it has either added or rejected the EAP615. Is your router's firewall rejecting all requests from your device to/through 192.168.1.1 for some reason? There should be a log for that, too.

Also adding in my current status. Device uptime is now 6d 16h. Connected 17h 29m was when I switched from Static IP to DHCP, as part of an attempt to diagnose 5GHz/DFS issues.

It really does look like there could be two 192.168.1.1. Investigate the rest of the network. Get rid of the VLAN 1040 stuff until the LAN is fully working. When you do go back to VLANs, it is highly recommended not to try to mix tagged and untagged on the same port.

Remove the netmask line when using dhcp. That is not a valid setting. Netmask will be controlled by the DHCP server.

In /etc/config/dhcp, make sure the LAN has no DHCP server. For a dumb AP you can leave dnsmasq running, but disable the server on LAN. Note that a network restart does not restart/reload dnsmasq, that has to be done separately.

Ah, I got it working after removing most of the firewall config. I had thought I had disabled the firewall, but probably misunderstood or something.

1 Like

This topic was automatically closed 10 days after the last reply. New replies are no longer allowed.