What's new
  • SNBForums Code of Conduct

    SNBForums is a community for everyone, no matter what their level of experience.

    Please be tolerant and patient of others, especially newcomers. We are all here to share and learn!

    The rules are simple: Be patient, be nice, be helpful or be gone!

Beta Asuswrt-Merlin 3006.102.5 Beta is now available

I created my first IoT network using Guest Network Pro. Something in the log popped up and I don't know how to solve it. I had a DHCP reservation for a range that connects to wifi. Moving the range to the IoT network caused an IP conflict with the old subnet. Do I simply change the desired IP of the range to the new subnet? Seems pretty obvious now that I type this, and I will try it but I was wondering if anyone has run across this. Here's the log snippet:

Code:
Jul 12 09:48:08 dnsmasq-dhcp[479731]: not giving name Samsung-Range to the DHCP lease of 192.168.52.171 because the name exists in /etc/hosts with address 10.1.1.202
 
I created my first IoT network using Guest Network Pro. Something in the log popped up and I don't know how to solve it. I had a DHCP reservation for a range that connects to wifi. Moving the range to the IoT network caused an IP conflict with the old subnet. Do I simply change the desired IP of the range to the new subnet? Seems pretty obvious now that I type this, and I will try it but I was wondering if anyone has run across this. Here's the log snippet:

Code:
Jul 12 09:48:08 dnsmasq-dhcp[479731]: not giving name Samsung-Range to the DHCP lease of 192.168.52.171 because the name exists in /etc/hosts with address 10.1.1.202
No, remove it completely, and then add it under Guest Network Pro advanced settings for that particular IoT network.
 
No, remove it completely, and then add it under Guest Network Pro advanced settings for that particular IoT network.
Thanks, I had looked but somehow missed that!
 
I created my first IoT network using Guest Network Pro. Something in the log popped up and I don't know how to solve it. I had a DHCP reservation for a range that connects to wifi. Moving the range to the IoT network caused an IP conflict with the old subnet. Do I simply change the desired IP of the range to the new subnet? Seems pretty obvious now that I type this, and I will try it but I was wondering if anyone has run across this. Here's the log snippet:

Code:
Jul 12 09:48:08 dnsmasq-dhcp[479731]: not giving name Samsung-Range to the DHCP lease of 192.168.52.171 because the name exists in /etc/hosts with address 10.1.1.202
When the guest network pro option use same subnet as main network is disabled, lan DHCP manual ip reservation do not work on the guest network pro clients. Remove those manual reservations and either use the suggestion made by the prior poster or use a scripting file explained at the following link to create manual reservations for guest network pro clients.
 
Last edited:
I am testing beta on be88u and I found 2 bugs.
1. After change of vpn server from the list, the page shows previous page status. The same when I start server, after starting, it shows it like disabled. Only CTRL+F5 helps. It simply does not refresh the screen after any change.
2. There is not ping reply from server through VPN (tested on OpenVPN) until I enable ping from WAN. This is not quite requested setup. I would expected to have enabled internal ip address and prevent to ping only external one.

Can somebody confirm it?
 
I have a few LoRa IoT devices from YoLink (mostly water leak alarms). They all talk LoRa to a hub that then forwards to my network.
I must say, I am impressed with the range of these devices. From what I understand though - the link speed (on the LoRa side) is very slow. Good for simple IoT devices like smoke alarms, leak sensors etc.
I live in a multi-level home- the issue is climate control, hot and cold spots. And turning fans/heaters on/off to balance things out. So I’m <this close> to rolling up my sleeves and building ESP32-based temp sensors (and then interfacing my home HVAC, replacing the dumb central thermostat with a distributed model and home assistant controller logic) for the trouble spots, but rather than having them jam up my wifi intranet with all their chatter/messaging, LoRa came to mind.
And yes, 433MHz has a range of 8-10km/5mi iirc. But it’s not for large complex communication, as you said, due to speed constraints. I’m of the understanding that pipelines might use it between nodes/stations with MQTT for status messaging, which is basically what I’m looking to achieve in my home on a much smaller scale. Then a bigger brain with faster control can issue commands over wifi. Complex, but efficient in all sorts of ways, I think.
 
I live in a multi-level home- the issue is climate control, hot and cold spots. And turning fans/heaters on/off to balance things out. So I’m <this close> to rolling up my sleeves and building ESP32-based temp sensors (and then interfacing my home HVAC, replacing the dumb central thermostat with a distributed model and home assistant controller logic) for the trouble spots, but rather than having them jam up my wifi intranet with all their chatter/messaging, LoRa came to mind.
And yes, 433MHz has a range of 8-10km/5mi iirc. But it’s not for large complex communication, as you said, due to speed constraints. I’m of the understanding that pipelines might use it between nodes/stations with MQTT for status messaging, which is basically what I’m looking to achieve in my home on a much smaller scale. Then a bigger brain with faster control can issue commands over wifi. Complex, but efficient in all sorts of ways, I think.
What has this got to do with beta testing this firmware?
Please keep discussions on this specific release. Off-topic posts will be either ignored or deleted, depending on my mood at the time.
 
I am testing beta on be88u and I found 2 bugs.
1. After change of vpn server from the list, the page shows previous page status. The same when I start server, after starting, it shows it like disabled. Only CTRL+F5 helps. It simply does not refresh the screen after any change.
2. There is not ping reply from server through VPN (tested on OpenVPN) until I enable ping from WAN. This is not quite requested setup. I would expected to have enabled internal ip address and prevent to ping only external one.

Can somebody confirm it?
I tried a factory reset as last option, the second bug disappeared, but first one is still there and it is very annoying.
 
I can't click 'Apply' here and change any settings.
 

Attachments

  • Untitled.png
    Untitled.png
    232.4 KB · Views: 193
@Zakalwe
Could you please post again in a readable version?
 
I can't click 'Apply' here and change any settings.
Already identified here:
 
Do you have any hits on these rules? Maybe your browser is trying DoT and getting rejected.
Code:
iptables -nvL DNSFILTER_DOT
ip6tables -nvL DNSFILTER_DOT
Did the results mean anything for you?
Should something else return?
If I disable DNS Director completely, the command does not list anything. BUT pretty much always returns super high ping on https://www.dnscheck.tools/
 
Last edited:
A bit out of topic, but for this release has Asus and TrendMicro fixed or provided an ETA for the non-working QoS on Wifi 7 models?
 
What has this got to do with beta testing this firmware?
Nothing, gents...except perhaps solving some Guest Networking/IoT issues by getting them off wifi and using other wireless comms where appropriate. Laser focus is one thing, but looking at issues a little more holistically can come in handy too, wouldn't you agree. But point taken and noted for the future.
 
I tried a factory reset as last option, the second bug disappeared, but first one is still there and it is very annoying.
Yeah, I report the page not refreshing thing in the last release. Seems like that's when it started. Most people said it was an Edge/Microsoft problem or thing. So don't know, but it is annoying.
 
related to ai mesh. is there any way to fix it without removing the mesh node and readding it or anything like that?

You can temporarily disable the conflicting setting. Retrieve the current value, then set it to 0:

Code:
nvram get dwb_mode
nvram set dwb_mode=0

Load the Wireless page, do your wireless changes, apply, then reapply the original value:

Code:
nvram set dwb_mode=PREVIOUS_VALUE
nvram commit

Asus is still looking into the issue, I'm waiting for a fix from them since I'd rather they develop a proper fix than having me implement just a partial workaround.
 
Whatever redacted MAC from line #2 tried to use DoT first and was blocked. If that’s the device you were testing from it might explain the delays.
Great. Then a empty return means it's OK.
Anyways, probably not firmware related... But weirdly slow, only because I enable DoT.
Perhaps I remember it wrong from the previous router.

Running tests directly on the router pretty much confirms the same high variations in response time with DoT. DoH is equally as fast as without DoT/DoH.

The testing goes on 😉
Not sure what else I can do to confirm a misbehaving DNS.
 

Support SNBForums w/ Amazon

If you'd like to support SNBForums, just use this link and buy anything on Amazon. Thanks!

Sign Up For SNBForums Daily Digest

Get an update of what's new every day delivered to your mailbox. Sign up here!

Staff online

Back
Top