Thanks for that!!
But i have to say, its not good UX. I would recommend re doing the whole UI - as it is, its just a mess, over complicated and buggy for no reason.

Thanks for that!!
But i have to say, its not good UX. I would recommend re doing the whole UI - as it is, its just a mess, over complicated and buggy for no reason.

What you show in the GIF appears to be by design. Given that the device youāre attempting delete likely still has an active DHCP lease as well as being online and active, you are technically deleting it, but because of all of the aforementioned details, it will just reappear because itās still active, still has a lease, etc.
Edit: The purpose of being able to delete this device despite all of this is if you had any overrides for that particular client, such as giving it a Name, VLAN overrides, DL/UL limitation overrides, etc. Letās say you gave that device a VLAN override and itās active. When you delete the device, the override (and any other overrides) will get removed, but since the device still has a lease, etc. it will automatically repopulate.
Even if no device is connected? I dont even have a Asrock NIC. Connected to the router is a SFP+ Mellanox and another router for the WIFI
I would imagine the OUI of that devices MAC address is registered to Asrock, which is why that is showing up under make.
In the GIF, the device is not greyed out, so the device is connected and active on the network. If thatās not the case, itās a completely separate issue that weād need to investigate.
However, even if it were to be greyed out indicating the device was connected but is not currently connected, it may still have a DHCP lease.
Iāve never seen a device grayed out on my router before and i can assure you its not connected
I was able to remove it by doing the reset and by changing the site it was on. Thank you for that
Interesting to say the least. If you see anything like that again, please post and feel free to tag me directly. Iād like to get access to debug it if possible.
Will do!
Just out of curiosity, did you test the fiber passthrough spf+ with the route10? Iām thinking about getting AT&T fiber and wondering if placing the was-110 sfp+ into the 10G wan port on the route10 will work?
It did for me when I did it.. Iāve been trying alta on and off and still waiting for a feature or two to be added before I fully shift over. I got a lot of their hardware built up to make the switch now.
I am using this type of module without issues so far, but this does not constitute official support or a guarantee of compatibility. Iām on Bell Canada up north of the border. I do know we have at least a few users, but also great to see a confirmation, thanks @Jerky_san!
I used the guide from this site and run the community 8311 firmware on it. Hereās one more specific to AT&T hardware: Masquerade as the AT&T Inc. BGW320-500/505 with the WAS-110 or HLX-SFPX - PON dot WIKI
Please note that PON modules of any type are not officially supported or validated for use in our devices. While some modules that use standard SerDes data rates and perform their own PON protocol handling may appear to operate, compatibility cannot be guaranteed. Successful operation may depend on module provisioning and configuration, and users assume all risk when using unsupported modules. This clarification is intended to avoid confusion regarding support status, and not to suggest that problems are expected.
Iām a WAS-110 user too on Route10, also on Bell and all is well.
Swinging this topic around again.. On my Asus GT-AXE16000 running asus-merlin I was able to run a script at startup that would allow me access to the WAS-110 via the WAN port. The wiki shows how to configure this same stuff on ubiquiti
I was wondering if an Alta employee could chime in and say if they see anything wrong with trying something similar with the commands alta would accept instead? Any issues I should look out for? Mine is the default 192.168.11.1 ip for the stick. On ubiquiti it was just adding an ip to the interface and then doing a source NAT rule.
I tried a straight static rule but that doesnāt seem to route properly because it is still missing the creation of the subnet on the interface I guess.
Update run the ubiquiti commands āeth4 wan2 eth3 wan1
ip addr add dev eth4 local 192.168.11.2/24
iptables -t nat -A POSTROUTING -o eth4 -d 192.168.11.1 -j SNAT --to 192.168.11.2
Then static route
Name: WAS-110
Type: Interface
Network: 192.168.11.1/24
Interface: eth4(or eth3 if you are using wan3 instead)
save
Should connect after that
Update again:
Well.. it worked for like 1 -2 minutes and now it stopped.. Iām not sure why. If I delete and recreate the static rule it will let me connect for another 1-2 minutes then stops again. So it has to be something to do with alta being different.
Another Update:
I found that right after you execute the static route command if you open the ip and login. Then you stick on the main page where it shows the temps it will keep refreshing the page and keeps the connection alive preventing it from being closed. So then you can open a second tab and do whatever you need to do in there. I personally have been monitoring temps because theyāve dropped about 5-8C from running in my old switch to the alta.
I assign a separate logical interface to the same physical Ethernet port on the router (eth4), which places it in the same subnet as the ONT management interface so itās reachable via ARP and just works. My WAN on this port uses PPPoE, but you can still add an alias with a static IP in this subnet and also have the router receive an IP via DHCP from the ISP upstream on that same port. Here are the relevant parts extracted from my current post-cfg.sh if you wish to try it, as this will make it persistent.
#!/bin/ash
# /cfg/post-cfg.sh - Route10 ā WAS-110 ONT management
# ONT mgmt on eth4 -> 192.168.11.2/24 (ONT at 192.168.11.1)
PATH=/sbin:/usr/sbin:/bin:/usr/bin
set -u
log() { logger -p user.notice -t post-cfg "$*"; }
warn() { logger -p user.warning -t post-cfg "$*"; }
# --- ONT (FTTH) Management Interface on eth4 ---
uci -q delete network.ont_mgmt
uci set network.ont_mgmt='interface'
uci set network.ont_mgmt.ifname='eth4'
uci set network.ont_mgmt.proto='static'
uci set network.ont_mgmt.ipaddr='192.168.11.2'
uci set network.ont_mgmt.netmask='255.255.255.0'
uci set network.ont_mgmt.defaultroute='0'
uci set network.ont_mgmt.peerdns='0'
uci set network.ont_mgmt.auto='1'
# --- Firewall zone + LAN forwarding to ONT (so you can reach 192.168.11.1 from LAN) ---
if ! uci -q get firewall.ont.name >/dev/null 2>&1; then
uci set firewall.ont='zone'
fi
uci set firewall.ont.name='ont'
uci set firewall.ont.network='ont_mgmt'
uci set firewall.ont.input='ACCEPT'
uci set firewall.ont.output='ACCEPT'
uci set firewall.ont.forward='REJECT'
if ! uci -q get firewall.forward_lan_ont.src >/dev/null 2>&1; then
uci set firewall.forward_lan_ont='forwarding'
fi
uci set firewall.forward_lan_ont.src='lan'
uci set firewall.forward_lan_ont.dest='ont'
# --- Commit + apply ---
uci commit network || warn "uci commit network failed (continuing)"
uci commit firewall || warn "uci commit firewall failed (continuing)"
if ifup ont_mgmt >/dev/null 2>&1; then
log "ifup ont_mgmt OK (192.168.11.2/24 on eth4)"
else
warn "ifup ont_mgmt failed (exit $?)"
fi
if /etc/init.d/firewall reload >/dev/null 2>&1; then
log "firewall reloaded"
else
warn "firewall reload failed (exit $?)"
fi
ping -c1 -W1 192.168.11.1 >/dev/null 2>&1 \
&& log "ONT reachable (192.168.11.1)" \
|| warn "ONT not reachable (192.168.11.1)"
exit 0
Iām waiting for a window to reboot and try this. I really appreciate you posting a whole script for it as it definitely makes things much easier.
I rebooted with this script in /cfg/post-cfg.sh file and it does not appear to have worked or perhaps even ran? Iām not exactly sure how I can tell but i do not see a new interface or anything. Am I supposed to set something to run this script before I reboot?
Update:
Rearranged a bit and it started working
Iām very sorry that I neglected to share instructions along with it, I had meant to. Usually other than placing it (assuming correctness, like exact path and ensuring LF line endings), the main thing is making it executable (chmod +x /cfg/post-cfg.sh).
Iām glad you were able to get it working.
No itās totally fine.. Honestly Iāve played with my route10 a lot over time but Iām making a concerted effort this time to actually switch. It worked yesterday for a bit but when I woke up this morning it had stopped working again and I had to reboot the router again(reboots extremely fast so that is pleasing). Is there something I might be missing that will make it stop working overtime? I didnāt do anything after I saw it working again last night and just went to sleep.
Also is there a specific encoding I should be using like UTF-8? I see you said to make sure the LF line endings and I had been using both winscp and vi to edit but Iāll be honest and say I donāt remember a way to see the format like that in vi or scp.
Lastly, I just appreciate you helping me at all tbh.. You didnāt have to so any help you give is always appreciated.