hagaygo / OpenWrtManager

Mobile app for interacting with your OpenWrt device.
GNU General Public License v3.0
145 stars 10 forks source link

WiFi Status -> Error parsing reply from device #20

Closed xyza closed 2 years ago

xyza commented 2 years ago

Hello, I got OpenWRT 21.02.1 (latest version) installed, upgraded from 19.07. OpenWRTManager installed and everything was working fine before and after the upgrade. A few days ago I had to factory reset the router (additionally changed the router SSID to something having UTF8 char in the name), then I started receiving these "Error parsing reply from device" in the WIFI Status module. What I tried so far is reinstalling and reconfigure application from scratch, also hit "Update Devices" multiple times, nothing helped. Attached below the UI with the error.

IMG_20211114_092249

hagaygo commented 2 years ago

Hi,

Thanks for detailed information.

You mentioned you set a SSID with UTF8 char , if you think/suspect this is the problem, it is to easy to test/verify it. Change the SSID to something really simple (like 12345678) and then try refreshing the app, if it works we'll know there is an issue with the SSID name from some reason.

Other option is to capture LuCI responses using developer tools on the browser since your device respond with unexpected JSON response.

I'll need your JSON data so i can debug and find out why the app can not handle it.

Enter your device LuCI Overview page and open Developer Tools of your browser.

Then Choose Network TAB and filter by XHR requests only.

You should be able to see 2-3 new requests each 5 seconds :

image

Click on each new request and select "response" on the right pane.

You should be able to see The JSON response on the right pane.

Something like this :

image

Please send me the JSON data (The raw text itself , no screenshots) for each new request and preferably for mistake proofing several copies of them (for recurring requests).

Please check the JSON content and remove "private" data if you find any (like "secret" ip address or other sensitive data) but keep the json intact and valid.

On next versions i might add a tool to extract problematic JSON data from the app itself.

hagaygo commented 2 years ago

Hi

I tried to reproduce the error using the JSON data you sent me and i did not manage to reproduce the error.

Attached is a test version apk (inside a zip), which i added on the drawer (menu, sliding menu) a new option called "Copy Last Response To Clipboard", install it , it will replace the google play version just fine.

After refreshing the data , this version will store the last raw JSON response in memory and by pressing this button it will copy it to clipboard and then you can use an email or other app to store it to file (it can be quite big) and post it here. If all goes by plan i should be able to easily reproduce the error you have and i will add this feature in the official release with more tests and less "quick & dirty".

openwrt_manager-testcopyclipboard.zip

xyza commented 2 years ago

Hi, Followed your instructions, for some reason I got two types of responses, attached both. response.txt response2.txt

xyza commented 2 years ago

Hi, I got onto something. I have attached below my current WiFi configuration, the issue seems to occur when I have a disabled interface (2.4GHz in this case). If I enable it, the application works as expected, WiFi status shows connected clients. Can you do something with this info? Btw, in my previous post, responses are both from the current configuration.

hagaygo commented 2 years ago

Thanks for the files , From first glance i can not say i see the problem , I will have to add some more sophisticated logs top the app se we can more easily trace issues like this.

As for disabled interface , no issue here with same test.

xyza commented 2 years ago

What I can say for certain is that i can reproduce the issue every time I disable the interface, and the other way around, it should mean something.

hagaygo commented 2 years ago

Attached is another test version , the copy to clipboard button is now on any "error parsing reponse" overview on and not on drawer and should contain more debug data (exception data and stacktrace) i hope it would be enough so we can trace the exact problem.

openwrt_manager-test-copy-to-clipboard.zip

xyza commented 2 years ago

Attached is another test version , the copy to clipboard button is now on any "error parsing reponse" overview on not on drawer and should contain more debug data (exception data and stacktrace) i hope it would be enough so we can trace the exact problem.

openwrt_manager-test-copy-to-clipboard.zip

Hi, this version does not have the Copy to clipboard option in the menu

hagaygo commented 2 years ago

The button should be visible under "error parsing reply from device", if not make sure you indeed installed the new version.

xyza commented 2 years ago

The button should be visible under "error parsing reply from device", if not make sure you indeed installed the new version.

Sorry, but this is what I have, no additional option in the main UI or the menu. I'm certain i have installed the last version attached.

hagaygo commented 2 years ago

O.K

Do note that you are now getting different error than you originally posted.

I'll make a new test version asap.

xyza commented 2 years ago

O.K

Do note that you are now getting different error than you originally posted.

I'll make a new test version asap.

Indeed, that error started to show after i enabled and disabled the second interface

hagaygo commented 2 years ago

Here is a test version that should have a button for the error on your last screenshot.

openwrt_manager-test.zip

xyza commented 2 years ago

Here is a test version that should have a button for the error on your last screenshot.

openwrt_manager-test.zip

Indeed, this worked, attached the exception below, and additionally the output of "ubus call luci-rpc getNetworkDevices" exception.txt getNetworkDevices.txt

hagaygo commented 2 years ago

The log shows your device seem to return an empty interface from some reason.

I think the following test version should workaround this , please test and let me know.

openwrt_manager-testing.zip

xyza commented 2 years ago

The log shows your device seem to return an empty interface from some reason.

I think the following test version should workaround this , please test and let me know.

openwrt_manager-testing.zip

I have installed the new version, but i don't see any difference from the one before, the debug button is still there, same as the error message

hagaygo commented 2 years ago

Please attach the output from the clipboard copy , maybe there is another problem.

xyza commented 2 years ago

Please attach the output from the clipboard copy , maybe there is another problem.

Indeed, another problem :( exception2.txt

hagaygo commented 2 years ago

Don't worry, we are really close.

Hopefully this version would work , or at least wont show the error.

openwrt_manager-testing.zip

xyza commented 2 years ago

Some change, indeed. Just not showing any devices now, it should show at least three.

hagaygo commented 2 years ago

O.K , one step forward and one backward.

I missed something in the clipboard data , added it now.

Please try with this version and attach clipboard data, it should reveal the difference now.

openwrt_manager-testing.zip

xyza commented 2 years ago

Data attached exception3.txt

hagaygo commented 2 years ago

Well , as you can see in exception3.txt attachment id 7 request receive an "empty" response , propaably beacuse there is no parameter for the assoclist command , The response should contain the WIFI clients data.

Please install the attached version and make sure you press "Update devices" on the drawer and then refresh the app. If you still get the error and empty response/requst for id 7 there is a problem with the "Update devices" command and we need to debug it.

openwrt_manager-testing.zip

xyza commented 2 years ago

Well , as you can see in exception3.txt attachment id 7 request receive an "empty" response , propaably beacuse there is no parameter for the assoclist command , The response should contain the WIFI clients data.

Please install the attached version and make sure you press "Update devices" on the drawer and then refresh the app. If you still get the error and empty response/requst for id 7 there is a problem with the "Update devices" command and we need to debug it.

openwrt_manager-testing.zip

Updated the app, shows the same "no connected devices", debug button is missing.

hagaygo commented 2 years ago

Did you press the "Update Devices" option from the drawer/menu ?

xyza commented 2 years ago

Did you press the "Update Devices" option from the drawer/menu ?

Yes, multiple times, and then refreshed a few times

hagaygo commented 2 years ago

O.K, I'll check again tomorrow what else i can change to help us debug this issue , thanks for your corporation so far.

xyza commented 2 years ago

One thing I tried is to enable the second interface (remember for both interfaces enabled did not get any issue). The response is a bit different related with iwinfo assoclist which this time is called twice and with appropriate parameters (device wlan0/wlan1). Parameter device seems to be required. Results are also valid for both interfaces. However when having one only interface, it does not send this parameter at all, and the result is invalid. debug_2interfaces.txt

hagaygo commented 2 years ago

That might be a clue , which one is the disabled interface wlan0 or wlan1 ?

Can you try to disable the "working" interface and keep the other enabled and try to checked request json ?

xyza commented 2 years ago

That might be a clue , which one is the disabled interface wlan0 or wlan1 ?

Can you try to disable the "working" interface and keep the other enabled and try to checked request json ?

wlan1 is the disabled one. I will try disabling the other interface and let you know later in the evening.

xyza commented 2 years ago

That might be a clue , which one is the disabled interface wlan0 or wlan1 ?

Can you try to disable the "working" interface and keep the other enabled and try to checked request json ?

Hi, I came back. I have tried to disable the other interface, the behavior is absolutely the same.

I was looking additionally on how to find which interfaces are available. I have found two ways: Calling "luci-rpc","getWirelessDevices" gets an enumeration of HW devices and associated interface name and whether they are disabled or not like this { "radio0": {"disabled":false, "interfaces": [ { "ifname": "wlan0" } ] }, "radio1": {"disabled":false, "interfaces": [ { "ifname": "wlan1" } ] } } To mention that if disabled: true, the interfaces collection is empty.

The second way is to call "iwinfo","devices" it returns a collection of enabled interfaces { "devices": ["wlan0", "wlan1"] }

Having this enumeration, then we can call further "iwinfo","assoclist",{"device":"wlan0"} and/or "iwinfo","assoclist",{"device":"wlan1"} according to the available interfaces

Let me know if that helps.

hagaygo commented 2 years ago

This is basically what the app does , The "Update Devices" options does a one call to get wireless interfaces info and then using that data when parse the assoclist on every overview refresh.

I guess something is different on your setup, i'll try to make another debug version for you test later on.

xyza commented 2 years ago

This is basically what the app does , The "Update Devices" options does a one call to get wireless interfaces info and then using that data when parse the assoclist on every overview refresh.

I guess something is different on your setup, i'll try to make another debug version for you test later on.

But then I don't get where the empty parameter for assoclist comes from

hagaygo commented 2 years ago

Update devices is either recieves an empty list or store the result badly somehow

hagaygo commented 2 years ago

Just checked , the app uses the getNetworkDevices command and then filters them by on this line :

d.wifiDevices = interfaces.keys.where((i) => interfaces[i]['wireless'] == true).toList();

On my devices it works just fine, can you test/attach your json response for this command ?

image

xyza commented 2 years ago

the json response for that command I posted yesterday, this is the link https://github.com/hagaygo/OpenWRTManager/files/7549017/getNetworkDevices.txt I see only wlan0 is present there, it looks consistent with my configuration

hagaygo commented 2 years ago

Attached is a new test version , i added a new debug button/icon on the drawer , it should copy to the clipboard the last request/response and also the devices stored data (except maybe ip address nothing "secret" there).

Please click stop auto refresh if enable , then click "Update Devices" and use this button to copy the data to the clipboard and store it to file.

Afterwards do a refresh and then do the same with a new file from the data copied to clipboard and attach them both.

Hopefully we'll have enough data now to see where is the problem on your case.

openwrt_manager-testing.zip

hagaygo commented 2 years ago

On the drawer/menu there is a new help icon on the top right

xyza commented 2 years ago

Ok, I hope those are fine, let me know request1.txt request2.txt

hagaygo commented 2 years ago

They are o.k , we can see "update devices" works as expected and wlan0 does get stored by the app it just not being sent on the command from some reason.

I'll keep look into it.

hagaygo commented 2 years ago

I Think i manged to reproduce same error when disabling my wlans a specific way.

Attached is another test version , I think it should work 🤞

openwrt_manager-testing.zip

xyza commented 2 years ago

I Think i manged to reproduce same error when disabling my wlans a specific way.

Attached is another test version , I think it should work 🤞

openwrt_manager-testing.zip

Indeed, it works! 🥳 great job!! let me know if you need testing anything else

hagaygo commented 2 years ago

Great , Thanks for your help in solving this problem.

xyza commented 2 years ago

Great , Thanks for your help in solving this problem.

Thanks for your support and patience! Got a question, do you plan to support also listing Ethernet connected devices in the future?

hagaygo commented 2 years ago

As you know the app is limited to the available API , if LuCI (the web GUI) can show it, the app can support it.

As far i know , LuCI doesn't support it , if you find any API that allows to retrieve this data , feel free to open a new issue with the details.