Dumb AP: issue with IPv4 connectivity on wireless

Hello!

Device: D-Link DIR-869 rev A.1
OpenWRT version: 19.07 and tried on 23.05 RC1
Purpose: dumb AP
Issue: IPv4 not working to reach outside world on wireless

I have an IPv4 issue with my D-Link DIR-869 A1 dumb AP. This router has two radios for wireless, one for 5.0GHz and the other for 2.4GHz WiFi.

I followed the dumb AP guide (see https://openwrt.org/docs/guide-user/network/wifi/dumbap), from a fresh install on my device (I tried with OpenWRT 19.07, latest stable for the device, and 23.05-rc.1, because support was added back for the device).

On my first comment you will find my /etc/config/network and my /etc/config/wireless.

You will see that I configured both device's radios with the same network (SSID and protection).

Everything works fine on the ethernet switch. My wireless issues are present on multiple tested devices (one laptop on Arch Linux and two Android smartphones with different OS versions) for IPv4 only.

Here is my issue which happens on both OpenWRT 19.07 and 23.05 RC1:

  • if I enable only the 2.4 WiFi, I don't have any IPv4 connectivity (despite the fact I have an IPv4 address on my client device), IPv6 is working fine
  • if I enable only the 5.0 WiFi, I have the same issue on the client device, IPv6 still working fine
  • if I enable both, I don't have IPv4 connection when my client device is still connected to the 2.4 WiFi but when it upgrades to 5.0, IPv4 works fine
  • if I enable both and let the client device upgrade to 5.0, I can then disable the 2.4 WiFi and have working IPv4 on the client device (but if I disable and re-enable the WiFi on this device, when the AP is still on 5.0 only, then it won't have IPv4 connectivity again)
  • if I enable both and let the client device upgrade to 5.0, then disable the 5.0 WiFi and let the client downgrade to 2.4 WiFi, IPv4 does connectivity not work

The connected device always have an IPv4 assigned (the dumb AP has a static address and the DHCP is disabled, my main router handle it). For device connected with ethernet (including the same laptop I tried with WiFi), everything works perfectly.

What I tried (in both radios) which did not change anything:

  • un-hide the network
  • setting the country code of my country (FR, you can see I left this setting)
  • changing frequency channel and width
  • disable WWM mode (I re-enabled it as it did not change anything and I read that it's better to keep it enabled for WiFi fairness, correct me if I'm wrong)

I have no idea of what is going on. I tried a lot of different configurations but the issue remains (on wireless only).

Anyone has an idea on how to fix this? Did I made a bad configuration?

Thanks in advance for any help!

Here is my /etc/config/network:

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 ula_prefix 'fd9f:df36:7ddf::/48'

config device
	option name 'br-lan'
	option type 'bridge'
	list ports 'eth0.1'
	list ports 'eth0.2'

config device
	option name 'eth0.1'
	option macaddr '10:be:f5:d8:43:ec'

config device
	option name 'eth0.2'
	option macaddr '10:be:f5:d8:43:ef'

config interface 'lan'
	option device 'br-lan'
	option proto 'static'
	option ipaddr '192.168.0.2'
	option netmask '255.255.0.0'
	option gateway '192.168.0.0'
	list dns '192.168.0.0'

And my /etc/config/wireless:

config wifi-device 'radio0'
	option type 'mac80211'
	option path 'pci0000:00/0000:00:00.0'
	option channel '40'
	option band '5g'
	option htmode 'VHT40'
	option cell_density '0'
	option country 'FR'

config wifi-iface 'default_radio0'
	option device 'radio0'
	option network 'lan'
	option mode 'ap'
	option ssid 'WiFi'
	option encryption 'psk2'
	option hidden '1'
	option key '[REDACTED]'

config wifi-device 'radio1'
	option type 'mac80211'
	option path 'platform/ahb/18100000.wmac'
	option channel '7'
	option band '2g'
	option htmode 'HT20'
	option country 'FR'
	option cell_density '0'

config wifi-iface 'default_radio1'
	option device 'radio1'
	option network 'lan'
	option mode 'ap'
	option ssid 'WiFi'
	option encryption 'psk2'
	option hidden '1'
	option key '[REDACTED]'

Hi

eth0.x is semantic from swconfig (pre DSA)
but as i see, there is no swconfig part (switch / vlans)

so, maybe you are update 19.xx to 23.05 and tried to keep config, or restore config, or tried to mimic old config

whatever ...
best thing is that you simply do a factory default and post your factory network/wireless config. This way it will be clear is your device using DSA or not

How did you determine this lan network addressing scheme?

Why are you using a /16 here? Is your network actually configured with a /16? The most common is /24.

Meanwhile your gateway and dns are invalid. Those are pointing to a subnet ID and not a valid host address. Maybe you meant 192.168.0.1?

Thanks for you answer @NPeca75!

Yes, in fact there was a switch/vlan config originally. When I followed the dumb AP guide, this config stayed because I did it with LuCi web interface. But when I tried with 23.05, I decided to just do it with SSH so I erased the original files to use those given in the guide. So the switch/vlan configuration is not here anymore.

The issue is the same on 19.07 with and without switch/vlan (I tried to disable vlan and enable it back, no change). So I thought disabling it when trying on 23.05 would not be a problem (in fact, it makes the WAN port working as a LAN port so I use it to connect the AP to the gateway).

When I installed 23.05, I unchecked "keep configuration" and started the configuration from scratch. I did not import a configuration backup because I thought the issue may come from my manual configuration.

As I had the same issue with switch/vlan enabled and disabled on 19.03, should I really try to reconfigure it on 23.05 where I still have the issue?

Thanks for your answer @RuralRoots!

My gateway is on 192.168.0.0 (this is a NanoPi R6S with FriendlyWRT and the default configuration sets its IP to 192.168.0.0, I did not touch it).

My internet connection works fine on ethernet (plugged directly on the gateway or plugged on the dumb AP switch) so I thought the configuration was OK. But I understand this is not an usual configuration.

Thanks for your response @psherman (42 Wallaby Way Sydney?)!

Because my gateway (NanoPi R6s on FriendlyWRT) was configured like this by default and I did not touch it. It works like this on ethernet so I thought it was not problematic, just unusual.

I can confirm my gateway is on 192.168.0.0 (and it runs the DNS server), I can ping other devices on the network, SSH into the gateway (and use the LuCi web interface of the gateway on 192.68.0.0) and I can surf on the web like a charm (by plugging directly on the gateway or on the dumb AP switch, which is connected to the gateway).

Should I try to change the gateway IP to 192.168.0.1 and the subnet to 192.168.0.1/24? I'm not sure it would work better, as my connection works really fine on internet and only wireless has a problem but I can give it a try if you think it would fix my WiFi issues.

Yes. But you need to make the corresponding changes on your main router.

And as @NPeca75 pointed out, there is no swconfig statement in the config, so it is necessary to fix that too.

Edit: the fastest way to fix your problem is to start with a reset to defaults on this device and post the configs - we can guide you through the process. But your main router is not properly configured either, so that needs to be fixed.

So, I just tried to change my main router IP to 192.168.0.1 and the prefix to 192.168.0.1/24.
In the dumb AP, I changed the gateways and DNS IP to 192.168.0.1.

It seems to work for now (on ethernet and wireless, 2.4 and 5.0, including IPv4 connectivity), I'm curious to understand why it was not working well only on wireless but really fine on ethernet. I will monitor during the next days but it seems it resolved the issue!

Thanks FriendlyElec to make a bad configuration by default on the gateway… :neutral_face:

@psherman it seems my dumb AP works fine without switch configuration and it managed to let me use the WAN port for my gateway <---> AP link, should I try to fix this anyway or "if it's not broken, don't fix it"?

By default, the WAN and the switch were on separated vlans, I guess disabling/removing the vlan configuration puts every ports on the same vlan, which is what I want. Is it really better to reset and reconfigure the dumb AP, and just configure the vlan to all put on the same?

I’m not sure why WiFi failed while Ethernet worked, but the addresses were invalid and some operating systems will oddly work with an invalid address while others will realize it is invalid and not even try. If you were using different devices to test WiFi vs wired connectivity, that might explain why.

That's where all the magic is: I tried with my laptop on ethernet and on WiFi (without connecting both at the same time to be sure) and it was working well on ethernet but very bad on WiFi.

I guess we'll never know (I hope so because it would mean the problem won't appear again and I won't ask again).

As you are a moderator, should I make the post as resolved or should I wait to monitor for some days before validating the fix?

I don't think anyone has noted this yet, but 192.168.0.0 is invalid as a host IP on a /24 network.

This is because .0 is the network's address in this case. Additionally - .255 is invalid too, as its the broadcast address.

Trying giving your gateway/DNS is assigned a valid IP.

:+1:

I think you caught it - cool!

Yes, you should mark it as resolved. You can always add to the thread within 10 days of whenever it is 'solved', or open a new one if necessary at a later date. But I think it's likely fixed now.

I did...

It's actually an invalid address on all subnet sizes from /16 and smaller.

2 Likes

Done, thanks for your help!

Only the first 0 and last 255 (the ones inside the subnet are valid). But as you allude, its common not to use them anyways.

1 Like

In the case of 192.168.0.0 -- that is invalid for all network sizes /16 or smaller. 192.168.1.0 would have been okay for a /16 (or really any network larger than a /24), but the specific address that was in the OP's post (and apparently default on their FriendlyWRT router) is was invalid regardless of the subnet size.

1 Like

I caught that as well.

3 Likes

Sorry, I should have given you credit for that, too :slight_smile:

3 Likes

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