Also should I be using this NOR version or the Generic AR300M16 ?
The NOR version is the only one that doesn't give an error at the firmware check after upload.
Then you need the generic version.
The "nor" flash is under the nand section and is a dual flash, bootstrapping from nor and running from nand.
If you try to flash the "nor" image from luci it will quietly fail as it merrilly writes to empty space where the nand chip would have been....
Flashed with the Generic AM300M16 firmware.
Still not getting an IP on WAN.
I don't have a gigabit unmanaged switch handy but below is when I connect to my EdgeRouter X which is gigabit.
AR300M16 negotiates 100Mb so this could be the issue that my ISP NTD and Starlink doesn't want to accept a 100Mb connection and drops it.
Wed Apr 17 09:38:24 2024 daemon.notice netifd: Network device 'eth1' link is up
Wed Apr 17 09:38:24 2024 daemon.notice netifd: Interface 'wan' has link connectivity
Wed Apr 17 09:38:24 2024 daemon.notice netifd: Interface 'wan' is setting up now
Wed Apr 17 09:38:24 2024 kern.info kernel: [34609.224794] eth1: link up (100Mbps/Full duplex)
Wed Apr 17 09:38:24 2024 daemon.notice netifd: wan (7006): udhcpc: started, v1.36.1
Wed Apr 17 09:38:25 2024 daemon.notice netifd: wan (7006): udhcpc: broadcasting discover
Wed Apr 17 09:38:26 2024 daemon.notice netifd: wan (7006): udhcpc: broadcasting select for 192.168.15.98, server 192.168.15.1
Wed Apr 17 09:38:26 2024 daemon.notice netifd: wan (7006): udhcpc: lease of 192.168.15.98 obtained from 192.168.15.1, lease time 86400
Wed Apr 17 09:38:26 2024 daemon.notice netifd: Interface 'wan' is now up
Wed Apr 17 09:38:26 2024 daemon.info dnsmasq[1]: reading /tmp/resolv.conf.d/resolv.conf.auto
Wed Apr 17 09:38:26 2024 daemon.info dnsmasq[1]: using nameserver 1.1.1.1#53
Wed Apr 17 09:38:26 2024 daemon.info dnsmasq[1]: using nameserver 8.8.8.8#53
Wed Apr 17 09:38:26 2024 daemon.info dnsmasq[1]: using only locally-known addresses for test
Wed Apr 17 09:38:26 2024 daemon.info dnsmasq[1]: using only locally-known addresses for onion
Wed Apr 17 09:38:26 2024 daemon.info dnsmasq[1]: using only locally-known addresses for localhost
Wed Apr 17 09:38:26 2024 daemon.info dnsmasq[1]: using only locally-known addresses for local
Wed Apr 17 09:38:26 2024 daemon.info dnsmasq[1]: using only locally-known addresses for invalid
Wed Apr 17 09:38:26 2024 daemon.info dnsmasq[1]: using only locally-known addresses for bind
Wed Apr 17 09:38:26 2024 daemon.info dnsmasq[1]: using only locally-known addresses for lan
Wed Apr 17 09:38:26 2024 user.notice firewall: Reloading firewall due to ifup of wan (eth1)
Wed Apr 17 09:38:27 2024 daemon.warn odhcpd[1535]: No default route present, overriding ra_lifetime!
It could be that, or it could be that Starlink is doing strange things with DHCP per the reddit thread I provided earlier. But now we can conclude that it is not an OpenWrt issue.
An intermediate gigabit switch will be a good test, though.
I have another AR300M16 that I've been having the same problem with but now it is failing to get an IP from local networks. I also tried a cellular modem with no success.
It was working.
Default settings.
Fri Mar 22 22:20:55 2024 daemon.notice netifd: Network device 'eth1' link is down
Fri Mar 22 22:20:55 2024 daemon.notice netifd: Interface 'wan' has link connectivity loss
Fri Mar 22 22:20:55 2024 daemon.notice netifd: Interface 'wan6' has link connectivity loss
Fri Mar 22 22:20:55 2024 kern.info kernel: [ 148.185172] eth1: link down
Fri Mar 22 22:20:55 2024 daemon.notice netifd: wan (2021): udhcpc: received SIGTERM
Fri Mar 22 22:20:55 2024 daemon.notice netifd: wan (2021): udhcpc: entering released state
Fri Mar 22 22:20:55 2024 daemon.notice netifd: Interface 'wan6' is now down
Fri Mar 22 22:20:56 2024 daemon.notice netifd: wan (2021): Command failed: ubus call network.interface notify_proto { "action": 0, "link-up": false, "keep": false, "interface": "wan" } (Permission denied)
Fri Mar 22 22:20:56 2024 daemon.notice netifd: Interface 'wan' is now down
Fri Mar 22 22:20:57 2024 daemon.warn odhcpd[1360]: No default route present, overriding ra_lifetime!
Fri Mar 22 22:20:57 2024 kern.info kernel: [ 150.273898] eth1: link up (100Mbps/Full duplex)
Fri Mar 22 22:20:57 2024 daemon.notice netifd: Network device 'eth1' link is up
Fri Mar 22 22:20:57 2024 daemon.notice netifd: Interface 'wan' has link connectivity
Fri Mar 22 22:20:57 2024 daemon.notice netifd: Interface 'wan' is setting up now
Fri Mar 22 22:20:57 2024 daemon.notice netifd: Interface 'wan6' has link connectivity
Fri Mar 22 22:20:57 2024 daemon.notice netifd: Interface 'wan6' is setting up now
Fri Mar 22 22:20:58 2024 daemon.notice netifd: wan (2417): udhcpc: started, v1.36.1
Fri Mar 22 22:20:58 2024 daemon.notice netifd: wan (2417): udhcpc: broadcasting discover
Fri Mar 22 22:21:01 2024 daemon.notice netifd: wan (2417): udhcpc: broadcasting discover
Fri Mar 22 22:21:04 2024 daemon.notice netifd: wan (2417): udhcpc: broadcasting discover
Fri Mar 22 22:21:13 2024 daemon.warn odhcpd[1360]: No default route present, overriding ra_lifetime!
Fri Mar 22 22:21:29 2024 daemon.warn odhcpd[1360]: No default route present, overriding ra_lifetime!
Let's look at the config on the problematic AR300M16:
Please connect to your OpenWrt device using ssh and copy the output of the following commands and post it here using the "Preformatted text </> " button:
Remember to redact passwords, MAC addresses and any public IP addresses you may have:
config defaults
option syn_flood 1
option input REJECT
option output ACCEPT
option forward REJECT
# Uncomment this line to disable ipv6 rules
# option disable_ipv6 1
config zone
option name lan
list network 'lan'
option input ACCEPT
option output ACCEPT
option forward ACCEPT
config zone
option name wan
list network 'wan'
list network 'wan6'
option input REJECT
option output ACCEPT
option forward REJECT
option masq 1
option mtu_fix 1
config forwarding
option src lan
option dest wan
# We need to accept udp packets on port 68,
# see https://dev.openwrt.org/ticket/4108
config rule
option name Allow-DHCP-Renew
option src wan
option proto udp
option dest_port 68
option target ACCEPT
option family ipv4
# Allow IPv4 ping
config rule
option name Allow-Ping
option src wan
option proto icmp
option icmp_type echo-request
option family ipv4
option target ACCEPT
config rule
option name Allow-IGMP
option src wan
option proto igmp
option family ipv4
option target ACCEPT
# Allow DHCPv6 replies
# see https://github.com/openwrt/openwrt/issues/5066
config rule
option name Allow-DHCPv6
option src wan
option proto udp
option dest_port 546
option family ipv6
option target ACCEPT
config rule
option name Allow-MLD
option src wan
option proto icmp
option src_ip fe80::/10
list icmp_type '130/0'
list icmp_type '131/0'
list icmp_type '132/0'
list icmp_type '143/0'
option family ipv6
option target ACCEPT
# Allow essential incoming IPv6 ICMP traffic
config rule
option name Allow-ICMPv6-Input
option src wan
option proto icmp
list icmp_type echo-request
list icmp_type echo-reply
list icmp_type destination-unreachable
list icmp_type packet-too-big
list icmp_type time-exceeded
list icmp_type bad-header
list icmp_type unknown-header-type
list icmp_type router-solicitation
list icmp_type neighbour-solicitation
list icmp_type router-advertisement
list icmp_type neighbour-advertisement
option limit 1000/sec
option family ipv6
option target ACCEPT
# Allow essential forwarded IPv6 ICMP traffic
config rule
option name Allow-ICMPv6-Forward
option src wan
option dest *
option proto icmp
list icmp_type echo-request
list icmp_type echo-reply
list icmp_type destination-unreachable
list icmp_type packet-too-big
list icmp_type time-exceeded
list icmp_type bad-header
list icmp_type unknown-header-type
option limit 1000/sec
option family ipv6
option target ACCEPT
config rule
option name Allow-IPSec-ESP
option src wan
option dest lan
option proto esp
option target ACCEPT
config rule
option name Allow-ISAKMP
option src wan
option dest lan
option dest_port 500
option proto udp
option target ACCEPT
### EXAMPLE CONFIG SECTIONS
# do not allow a specific ip to access wan
#config rule
# option src lan
# option src_ip 192.168.45.2
# option dest wan
# option proto tcp
# option target REJECT
# block a specific mac on wan
#config rule
# option dest wan
# option src_mac MAC#
# option target REJECT
# block incoming ICMP traffic on a zone
#config rule
# option src lan
# option proto ICMP
# option target DROP
# port redirect port coming in on wan to lan
#config redirect
# option src wan
# option src_dport 80
# option dest lan
# option dest_ip 192.168.16.235
# option dest_port 80
# option proto tcp
# port redirect of remapped ssh port (22001) on wan
#config redirect
# option src wan
# option src_dport 22001
# option dest lan
# option dest_port 22
# option proto tcp
### FULL CONFIG SECTIONS
#config rule
# option src lan
# option src_ip 192.168.45.2
# option src_mac MAC#
# option src_port 80
# option dest wan
# option dest_ip 194.25.2.129
# option dest_port 120
# option proto tcp
# option target REJECT
#config redirect
# option src lan
# option src_ip 192.168.45.2
# option src_mac MAC#
# option src_port 1024
# option src_dport 80
# option dest_ip 194.25.2.129
# option dest_port 120
# option proto tcp
root@OpenWrt:~#
looks like the default config, so no issues that I see.
I cannot explain why you're having these issues, but I'm quite certain that it is not a universal thing....
In fact, I'll run a test in a moment. I have an ER-X with EdgeOS handy. I'll connect it to a device with a 100Mbps ethernet port (TP-Link TL-WR902AC) and a device with a gigabit port (Linksys E3000)... both of those devices running 23.05.3.
Fri Mar 22 22:12:44 2024 daemon.notice netifd: wan (1822): udhcpc: started, v1.36.1
Fri Mar 22 22:12:45 2024 daemon.notice netifd: wan (1822): udhcpc: broadcasting discover
Fri Mar 22 22:12:48 2024 daemon.notice netifd: wan (1822): udhcpc: broadcasting discover
Fri Mar 22 22:12:51 2024 daemon.notice netifd: wan (1822): udhcpc: broadcasting discover
Fri Mar 22 22:13:32 2024 daemon.notice netifd: wan (1822): udhcpc: broadcasting select for 192.168.1.42, server 192.168.1.1
Fri Mar 22 22:13:32 2024 daemon.notice netifd: wan (1822): udhcpc: lease of 192.168.1.42 obtained from 192.168.1.1, lease time 86400
And from the WR902AC
Mon Mar 25 11:57:42 2024 daemon.notice netifd: wan (4151): udhcpc: started, v1.36.1
Mon Mar 25 11:57:42 2024 daemon.notice netifd: wan (4151): udhcpc: broadcasting discover
Mon Mar 25 11:57:43 2024 daemon.notice netifd: wan (4151): udhcpc: broadcasting select for 192.168.1.43, server 192.168.1.1
Mon Mar 25 11:57:43 2024 daemon.notice netifd: wan (4151): udhcpc: lease of 192.168.1.43 obtained from 192.168.1.1, lease time 86400
Both connect with no issues with an ER-X as the DHCP server (v2.0.9-hotfix.7).
I also know that these connect without issue to my Unifi Dream Machine Pro (DHCP server) via 2 Unifi switches.
The AR300m lite has only one ethernet port, whereas the AR300M has 2 ethernet ports. So the problem with the lite does not impact the regular, at least based on the device info page.
I have used many ar300m-xx in the past and never had a problem - except just one time.
That was very similar (reading my notes from 5 years ago). It turned out to be a slightly damaged rj45 connector on one end of the wan patch cable.
It worked with some ethernet ports, failed on others, but always showed the port coming up on plugging in.