PriSonerS61
-
Posts
141 -
Joined
-
Last visited
-
Days Won
1
Content Type
Profiles
Forums
Gallery
Downloads
Blogs
Events
Posts posted by PriSonerS61
-
-
24 minutes ago, eralde said:
@Pars, hi!
Could you tell us a bit more about the issue:
1. what browser do you use?
2. if you open the developers tools panel in your browser (it is typically opened by pressing F12 on your keyboard) are there any errors on the Console tab there?Hello @eralde. When the user reported this issue in our telegram group, I looked at the Chrome developer console to see what kind of error it was, but there is no error there.
KeeneticOS : 5.2 ALPHA 2
*I only tested it on mobile*
Opera : 89.5.4705.84.314
Kiwi browser : 137.0.7337.0
That's all that comes out on the console if it works.
-
1
-
-
Hello. There is a small problem I am having. It has appeared recently, I have come across it several times on several different devices. Namely: when the device is away from home, when it is not at home at that moment, it does not fall off the device list. It's been a few hours on average and it's still on the list.
When I wake up the wifi of a different device, it falls off the network within a few minutes.
The device that is having problems now was dropped from the network in the morning in a few minutes without any problem. So the problem occurs for a random device at a random time.
The device moved away from home 2 hours ago, but it is still listed as such in the device list.
The "show ip arp" output does not show any beri of the problematic device.
I will attach the device information and selftest file in the next secret message.
-
1
-
-
I support this. I also want to prevent devices with random mac address from connecting to my network. Maybe put a checkbox in the segment settings like "prevent devices with random mac address from connecting". It works like Wireless ACL and when enabled, devices with a random mac address cannot connect to that network/segment.
I did some research on the internet and this is how you can tell if the match address is random or not. I don't know how true it is...
"If the 2nd character in a mac address is 2, 6, A or E, that mac address is randomly generated."
-
When navigating to the relevant page, the following error appears in the developer console. @eralde
-
2
-
-
1) When updating from 4.2 alpha 7 to the first alpha 8 the PPPoE password was deleted, we had to add it again.
2) After the update, the "mobility domain id" and "mobility domain key" fields were deleted, I filled them again, but the "mobility domain id" field is not saved. UI problem, the data is in the config.3) The "wifi mesh system" page is not loaded in the new interface
-
1
-
1
-
-
Reported to keenetic with ticket number #628989
-
2
-
-
22 minutes ago, eralde said:
To disable traffic prioritization you should uncheck the second checkbox on the picture below
(it does the same thing as the toggle in the current UI)
Personally, I don't think specifying a kbps limit is a very popular feature, but if it gets a lot of votes, we'll probably implement it.
Perhaps an easier way to achieve the same result would be to modify the inputs to allow you to enter a non-integer value (in Mbps) there.
I don't quite understand your first message. Aren't the "Smart Queue Management" and "Application classification and prioritization" features independent of each other?
I just wanted an on/off feature for the Smart Queue Management feature because it limits the speed according to the value entered. Maybe the user may want to remove or disable it later.
-------
Yes I agree with that, if we are not forced to enter integers in mbps, it will indirectly work the same as kbps.
-
Hello. I think IntelliQoS is missing a few controls. @eralde
These are :
1) Enable / disable
2) MBPS / KBPS selectionFeature 1 is needed because : SQM cannot be disabled, there is no control for this in the new interface. When you want to disable it, you cannot enter the value 0 or leave it empty.
The 2nd feature is needed for the following reason: Sometimes users may want to fine tune the speed in KBPS. I think it would be good to give this choice to the user.
-
4
-
-
Hello @eralde. There is a small spelling mistake in the Turkish language. It says "ipv4" where it should say "ipv6". Actually, that is the ipv6 section. There is no problem in English language, there is this problem in Turkish language.
Tr : https://ibb.co/F0fscdy
En : https://ibb.co/yQ16cNr-
1
-
-
1 minute ago, dimon27254 said:
Incorrect app names appeared in 4.1 Alpha 15:
Yes exactly, I noticed it in Alpha 15 but I forgot to report it.
I thought you didn't report it because it wasn't fixed in Alpha 16, but as usual you did.
-
Hello @eralde @Anna Zhelankina. There is an error in application names in the new interface.
Also there is something called "private-cloud" in the new interface. What is this because there is no such thing in the old interface.
Spoiler
Spoiler
-
1
-
-
Hello. The title is a bit off. The reason is the 26px space on the left side. It will be fixed if the CSS rule is removed. @eralde @Anna Zhelankina
Before
SpoilerAfter
Spoiler-
3
-
-
9 minutes ago, eralde said:
Looks like we've found the source of the issue. It will be fixed in one of the future builds.
Good news. I'm wondering, is the source of the problem related to the interface or something else ?
Does it have anything to do with the old problem and fix I posted above?
-
-
This is another proof that in the data coming to the page via RCI, i.e. in "show mws member", it looks correct, but in the interface it looks wrong.
Spoiler
-
12 minutes ago, eralde said:
I apologize, but I misled you. We use data from the show mws member (on the controller) command output do display the Wi-Fi standard in the UI.
Still the show mws member command output is present in the self-test file, so I've checked it out.
It looks like the controller UI shows the correct standard, there is no 802.11ac for the 2.4 GHz band.
https://help.keenetic.com/hc/en-us/articles/213968949-What-you-need-to-know-about-Wi-Fi-5-IEEE-802-11ac-
We should fix the standard displayed in the extender UI.In the "show mws member" output, "mode": "11ac". It also appears as "AC" in Selftest. If the data is taken from the "show mws member" output, how can it be wrong on the interface when the "show mws member" output has the correct data ?
My device is already connected with 5ghz, not 2.4ghz. 5ghz 2x2 80mhz
In this case, the data in the "show mws member" output matches the "mode" data on the interface of the extender device, but the data on the controller device does not match.
Contrary to what you say, the data on the interface of the controller device should be corrected, not the data on the interface of the extender device.
show mws member (controller)
Spoiler"backhaul": {
"uplink": "WifiMaster1/WifiStation0",
"root": "8000.50:ff:**:**:**:**",
"bridge": "8000.50:ff:**:**:**:**",
"cost": 50,
"ap": "WifiMaster0/Backhaul0",
"authenticated": true,
"txrate": 702,
"uptime": 4264,
"ht": 80,
"mode": "11ac",
"gi": 800,
"rssi": -52,
"mcs": 8,
"txss": 2,
"ebf": true,
"dl-mu": true,
"pmf": true,
"security": "wpa2-psk"
},
controllerSpoiler
extender
Spoiler
-
Maybe the problem is related to the problem and fix in the link below. Maybe it could be a clue...
-
18 minutes ago, eralde said:
Please provide the output of the show ip hotspot command on the controller (only the extender device data block is needed), as well as the output of the show mws associations command (is it executed on the extender itself?) and the self-test files from both devices.
Hello. Thank you for your concern. The command "show mws associations" was executed on the "controller" device. Anyway, no response will be returned when this command is written to the extender device.
In the next hidden message I will tag you and attach the self-test file from both devices.
show ip hotspotSpoiler{
"mac": "50:ff:20:**:**:**",
"via": "50:ff:20:**:**:**",
"ip": "192.168.1.2",
"hostname": "Sprinter",
"name": "Sprinter (KN-3710)",
"system-mode": "extender",
"interface": {
"id": "Bridge0",
"name": "Home",
"description": "Home network"
},
"dhcp": {
"static": true
},
"registered": true,
"access": "permit",
"schedule": "",
"priority": 6,
"active": true,
"rxbytes": 1808496,
"txbytes": 3255177,
"uptime": 152374,
"first-seen": 152374,
"last-seen": 18,
"http-port": 80,
"description": "Keenetic Sprinter (NDMS 4.01.A.10.0-0): KN-3710",
"firmware": "4.01.A.10.0-0",
"traffic-shape": {
"rx": 0,
"tx": 0,
"mode": "mac",
"schedule": ""
},
"mac-access": {
"Bridge0": "deny",
"Bridge1": "deny"
}
}, -
Hello @eralde. As I mentioned in the title, the "routing" page does not load. The following error appears in the chrome developer console.
(Tested with chrome and microsoft edge)
-
2
-
1
-
-
Hello. It has been 2 releases since this issue but no fix (4.1 alpha 10)
This feature worked very well in the first version (4.1 alpha 7) but then it broke. I guess nobody saw the problem, so no fix was made... @Le ecureuil @admin
-
Hi @eralde On the "Wi-fi system" page, the "standard" data appears incorrect.
On this page it is 802.11N, while on the extender interface and in the "show mws associations" output it is 802.11AC
There should be 802.11AC everywhere.
show mws associations
{
"station": [
{
"mac": "*******",
"ap": "WifiMaster0/Backhaul0",
"authenticated": true,
"txrate": 702,
"rxrate": 867,
"uptime": 16144,
"txbytes": 170933203,
"rxbytes": 1501900948,
"ht": 80,
"mode": "11ac",
"gi": 800,
"rssi": -53,
"mcs": 8,
"txss": 2,
"ebf": true,
"dl-mu": true,
"pmf": true,
"security": "wpa2-psk"
}
],
"prompt": "(config)"
}
-
1
-
-
1 minute ago, Padavan said:
PriSonerS61
Thanks for your feedback, only MT7615D-based devices was affected, bug already fixed, update is coming soon.
You're welcome, feedback is our duty as users of the developer version
-
1
-
-
53 minutes ago, shurings said:
Привет. Обнаружил то же самое после обновления. Отключение питания на роутере ситуации не изменило.
Помогло переключение ширины канала на 20 МГц и обратно, на 80 МГц.
Hello. Thank you for the information. Yes, I tried what you said and it indeed solved the problem "temporarily". However, afterwards I "reboot and the problem recurs".
I have tried this several times and attached the necessary self-test files to my ticket #619661
-
Hello. After updating the main device to 4.1 alpha 9, all devices connected via 5ghz and including network devices all started connecting at 20mhz instead of 80mhz
Video, self-test and all the rest of the details are available in ticket #619661
[mesh device]
[Clients]
Router advice
in Community Support & Knowledge Exchange
Posted
Hi. If I understand you correctly, you want something like this. You can do this via CLI on your current Keenetic model.
In this case the pc.local address will go to 192.168.1.5.
ip host pc.local 192.168.1.5
system configuration save