Weird behaviour on Profiles/Devices

Thread Rating:
  • 0 Vote(s) - 0 Average
  • 1
  • 2
  • 3
  • 4
  • 5
#1
Hi,

The last week I installed the software on my Raspberry Pi3 and have been doing some testing.

I am running into the following problem:

I have a device to which I have assigned a certain profile:

[Image: Image1.png]

In connections, the device appears connected and with the correct profile assigned.

[Image: Image2.png]

But when consulting the statistics, the records generated by this device appear in a different profile ... in fact, if I go to view the associated connection, the profiles do not match.

I think the rules of the wrong profile are being applied...

[Image: Image3.png]

[Image: Image4.png]

I have tried restarting the connections, and even restarting the service ... but it remains the same ..

Am I doing something wrong?
Any ideas?

Thanks in advance...

EDIT:

I'm checking log files and on devices.log I can see that the device has assigned the profile ID 4


Code:
2020-12-11 19:48:45 - Enabling access for device Movil_Xiaomi_MiA3_Richi with profile ID 4, IP 192.168.0.128 and MAC 60:AB:67:86:45:E6

But on bind_queries.log, it seems that the rules applied for the device are those of profile ID 2...


Code:
11-Dec-2020 19:38:53.263 client @0x2502b58 192.168.0.128#7195 (fr.app.chat.global.xiaomi.net): view view_profile_2: query: fr.app.chat.global.xiaomi.net IN A + (192.1$
11-Dec-2020 19:38:53.362 client @0x2502b58 192.168.0.128#18999 (fr.app.chat.global.xiaomi.net): view view_profile_2: query: fr.app.chat.global.xiaomi.net IN A + (192.$
11-Dec-2020 19:38:53.395 client @0x2502b58 192.168.0.128#18081 (fr.app.chat.global.xiaomi.net): view view_profile_2: query: fr.app.chat.global.xiaomi.net IN A + (192.$
Reply
#1
Hi,

The last week I installed the software on my Raspberry Pi3 and have been doing some testing.

I am running into the following problem:

I have a device to which I have assigned a certain profile:

[Image: Image1.png]

In connections, the device appears connected and with the correct profile assigned.

[Image: Image2.png]

But when consulting the statistics, the records generated by this device appear in a different profile ... in fact, if I go to view the associated connection, the profiles do not match.

I think the rules of the wrong profile are being applied...

[Image: Image3.png]

[Image: Image4.png]

I have tried restarting the connections, and even restarting the service ... but it remains the same ..

Am I doing something wrong?
Any ideas?

Thanks in advance...

EDIT:

I'm checking log files and on devices.log I can see that the device has assigned the profile ID 4


Code:
2020-12-11 19:48:45 - Enabling access for device Movil_Xiaomi_MiA3_Richi with profile ID 4, IP 192.168.0.128 and MAC 60:AB:67:86:45:E6

But on bind_queries.log, it seems that the rules applied for the device are those of profile ID 2...


Code:
11-Dec-2020 19:38:53.263 client @0x2502b58 192.168.0.128#7195 (fr.app.chat.global.xiaomi.net): view view_profile_2: query: fr.app.chat.global.xiaomi.net IN A + (192.1$
11-Dec-2020 19:38:53.362 client @0x2502b58 192.168.0.128#18999 (fr.app.chat.global.xiaomi.net): view view_profile_2: query: fr.app.chat.global.xiaomi.net IN A + (192.$
11-Dec-2020 19:38:53.395 client @0x2502b58 192.168.0.128#18081 (fr.app.chat.global.xiaomi.net): view view_profile_2: query: fr.app.chat.global.xiaomi.net IN A + (192.$
Reply
#2
Regarding log files it looks that Movil_Xiaomi_MiA3_Richi where connected with profile ID 4 at 19:48:45 while bind_queries.log shows queries before this time (19:38:53) with profile ID 2.

If Richi profile ID is 4, I think Movil_Xiaomi_MiA3_Richi device is connected with the right profile. You should have logs after 19:48:45 in bind_queries.log that contains "view_profile_4".
Reply
#2
Regarding log files it looks that Movil_Xiaomi_MiA3_Richi where connected with profile ID 4 at 19:48:45 while bind_queries.log shows queries before this time (19:38:53) with profile ID 2.

If Richi profile ID is 4, I think Movil_Xiaomi_MiA3_Richi device is connected with the right profile. You should have logs after 19:48:45 in bind_queries.log that contains "view_profile_4".
Reply
#3
(12-14-2020, 11:53 AM)paul Wrote: Regarding log files it looks that Movil_Xiaomi_MiA3_Richi where connected with profile ID 4 at 19:48:45 while bind_queries.log shows queries before this time (19:38:53) with profile ID 2.

If Richi profile ID is 4, I think Movil_Xiaomi_MiA3_Richi device is connected with the right profilHie. You should have logs after 19:48:45 in bind_queries.log that contains "view_profile_4".

Hi,

Thanks for your response.


Indeed, it seems that the connection is established with the correct profile, but I don't know why in the log files it seems that the rules of another profile actually apply ...

In the logs after 19:48:45 it can be seen that  the rules of the profile ID = 2 are still applying for the ip 192.168.0.128


Code:
11-Dec-2020 20:13:51.127 client @0x2b71c00 192.168.0.128#50064 (vortex.data.microsoft.com): view view_profile_2: query: vortex.data.microsoft.com IN A + (192.168.0.20)
11-Dec-2020 20:13:54.825 client @0x2b71c00 192.168.0.128#50765 (aefd.nelreports.net): view view_profile_2: query: aefd.nelreports.net IN A + (192.168.0.20)
11-Dec-2020 20:14:02.624 client @0x2664b28 192.168.0.128#52266 (music.amazon.com): view view_profile_2: query: music.amazon.com IN A + (192.168.0.20)
11-Dec-2020 20:14:04.294 client @0x260a9a0 192.168.0.128#56949 (vortex.data.microsoft.com): view view_profile_2: query: vortex.data.microsoft.com IN A + (192.168.0.20)

In fact, after some further research, I see that there are some files called acl_profile_{IdProfile} that contain the IPs of the devices that supposedly are assigned to that profile.



I understand that the process that applies the rules must look in these files for the IP of the connection to establish the rules that it must apply ... And curiously, the file acl_profile_2.conf contains the IP of all connected devices, not just those of the devices assigned to the profile.



All the queries in the log file are being done on view_profile_2 and not on the profile that has been assigned to the device.


I have tried to modify these files manually, but it seems that the application modifies them and includes again the IPs that I have deleted ...
Reply
#3
(12-14-2020, 11:53 AM)paul Wrote: Regarding log files it looks that Movil_Xiaomi_MiA3_Richi where connected with profile ID 4 at 19:48:45 while bind_queries.log shows queries before this time (19:38:53) with profile ID 2.

If Richi profile ID is 4, I think Movil_Xiaomi_MiA3_Richi device is connected with the right profilHie. You should have logs after 19:48:45 in bind_queries.log that contains "view_profile_4".

Hi,

Thanks for your response.


Indeed, it seems that the connection is established with the correct profile, but I don't know why in the log files it seems that the rules of another profile actually apply ...

In the logs after 19:48:45 it can be seen that  the rules of the profile ID = 2 are still applying for the ip 192.168.0.128


Code:
11-Dec-2020 20:13:51.127 client @0x2b71c00 192.168.0.128#50064 (vortex.data.microsoft.com): view view_profile_2: query: vortex.data.microsoft.com IN A + (192.168.0.20)
11-Dec-2020 20:13:54.825 client @0x2b71c00 192.168.0.128#50765 (aefd.nelreports.net): view view_profile_2: query: aefd.nelreports.net IN A + (192.168.0.20)
11-Dec-2020 20:14:02.624 client @0x2664b28 192.168.0.128#52266 (music.amazon.com): view view_profile_2: query: music.amazon.com IN A + (192.168.0.20)
11-Dec-2020 20:14:04.294 client @0x260a9a0 192.168.0.128#56949 (vortex.data.microsoft.com): view view_profile_2: query: vortex.data.microsoft.com IN A + (192.168.0.20)

In fact, after some further research, I see that there are some files called acl_profile_{IdProfile} that contain the IPs of the devices that supposedly are assigned to that profile.



I understand that the process that applies the rules must look in these files for the IP of the connection to establish the rules that it must apply ... And curiously, the file acl_profile_2.conf contains the IP of all connected devices, not just those of the devices assigned to the profile.



All the queries in the log file are being done on view_profile_2 and not on the profile that has been assigned to the device.


I have tried to modify these files manually, but it seems that the application modifies them and includes again the IPs that I have deleted ...
Reply
#4
Ok, I tihink I've found the problem... maybe, there is a bug in the file ConfigShell.php .., in the bind function.

Specifically at the point where the acl_profile files are regenerated (line 599).

The value of $params['ips'] is not being reset in each profile iteration, so the IPs of each profile are accumulating for each subsequent acl_profile that is regenerated.

I have made the relevant modification and now the behavior is correct.
Reply
#4
Ok, I tihink I've found the problem... maybe, there is a bug in the file ConfigShell.php .., in the bind function.

Specifically at the point where the acl_profile files are regenerated (line 599).

The value of $params['ips'] is not being reset in each profile iteration, so the IPs of each profile are accumulating for each subsequent acl_profile that is regenerated.

I have made the relevant modification and now the behavior is correct.
Reply
#5
It is indeed a bug. We reported it on GitHub: https://github.com/keexybox/keexyapp/issues/11

Thank you very much for your debug.

For those who have the issue. You can fix it on your KeexyBox by following the instructions below :
  • Connect over SSH to your raspberryPI
  • As root run :

Code:
su - keexybox
cd /opt/keexybox/keexyapp/src/Shell/
mv ConfigShell.php ConfigShell.php.bak
wget https://raw.githubusercontent.com/keexybox/keexyapp/master/src/Shell/ConfigShell.php
Reply
#5
It is indeed a bug. We reported it on GitHub: https://github.com/keexybox/keexyapp/issues/11

Thank you very much for your debug.

For those who have the issue. You can fix it on your KeexyBox by following the instructions below :
  • Connect over SSH to your raspberryPI
  • As root run :

Code:
su - keexybox
cd /opt/keexybox/keexyapp/src/Shell/
mv ConfigShell.php ConfigShell.php.bak
wget https://raw.githubusercontent.com/keexybox/keexyapp/master/src/Shell/ConfigShell.php
Reply
#6
(12-15-2020, 04:36 AM)paul Wrote: It is indeed a bug. We reported it on GitHub: https://github.com/keexybox/keexyapp/issues/11

Thank you very much for your debug.

For those who have the issue. You can fix it on your KeexyBox by following the instructions below :
  • Connect over SSH to your raspberryPI
  • As root run :

Code:
su - keexybox
cd /opt/keexybox/keexyapp/src/Controller/
mv ConfigController.php ConfigController.php.bak
wget https://raw.githubusercontent.com/keexybox/keexyapp/master/src/Shell/ConfigShell.php

Hi paul,

is there a mistake in the code you've posted as solution?

Maybe you wanted to say:

Code:
su - keexybox
cd /opt/keexybox/keexyapp/src/Shell/
mv ConfigShell.php ConfigShell.php.bak
wget https://raw.githubusercontent.com/keexybox/keexyapp/master/src/Shell/ConfigShell.php
Reply
#6
(12-15-2020, 04:36 AM)paul Wrote: It is indeed a bug. We reported it on GitHub: https://github.com/keexybox/keexyapp/issues/11

Thank you very much for your debug.

For those who have the issue. You can fix it on your KeexyBox by following the instructions below :
  • Connect over SSH to your raspberryPI
  • As root run :

Code:
su - keexybox
cd /opt/keexybox/keexyapp/src/Controller/
mv ConfigController.php ConfigController.php.bak
wget https://raw.githubusercontent.com/keexybox/keexyapp/master/src/Shell/ConfigShell.php

Hi paul,

is there a mistake in the code you've posted as solution?

Maybe you wanted to say:

Code:
su - keexybox
cd /opt/keexybox/keexyapp/src/Shell/
mv ConfigShell.php ConfigShell.php.bak
wget https://raw.githubusercontent.com/keexybox/keexyapp/master/src/Shell/ConfigShell.php
Reply
#7
(12-15-2020, 09:20 AM)ricardodiaz Wrote:
(12-15-2020, 04:36 AM)paul Wrote: It is indeed a bug. We reported it on GitHub: https://github.com/keexybox/keexyapp/issues/11

Thank you very much for your debug.

For those who have the issue. You can fix it on your KeexyBox by following the instructions below :
  • Connect over SSH to your raspberryPI
  • As root run :

Code:
su - keexybox
cd /opt/keexybox/keexyapp/src/Controller/
mv ConfigController.php ConfigController.php.bak
wget https://raw.githubusercontent.com/keexybox/keexyapp/master/src/Shell/ConfigShell.php

Hi paul,

is there a mistake in the code you've posted as solution?

Maybe you wanted to say:

Code:
su - keexybox
cd /opt/keexybox/keexyapp/src/Shell/
mv ConfigShell.php ConfigShell.php.bak
wget https://raw.githubusercontent.com/keexybox/keexyapp/master/src/Shell/ConfigShell.php

Yes, it is a mistake. I corrected the post.
Reply
#7
(12-15-2020, 09:20 AM)ricardodiaz Wrote:
(12-15-2020, 04:36 AM)paul Wrote: It is indeed a bug. We reported it on GitHub: https://github.com/keexybox/keexyapp/issues/11

Thank you very much for your debug.

For those who have the issue. You can fix it on your KeexyBox by following the instructions below :
  • Connect over SSH to your raspberryPI
  • As root run :

Code:
su - keexybox
cd /opt/keexybox/keexyapp/src/Controller/
mv ConfigController.php ConfigController.php.bak
wget https://raw.githubusercontent.com/keexybox/keexyapp/master/src/Shell/ConfigShell.php

Hi paul,

is there a mistake in the code you've posted as solution?

Maybe you wanted to say:

Code:
su - keexybox
cd /opt/keexybox/keexyapp/src/Shell/
mv ConfigShell.php ConfigShell.php.bak
wget https://raw.githubusercontent.com/keexybox/keexyapp/master/src/Shell/ConfigShell.php

Yes, it is a mistake. I corrected the post.
Reply
#8
KeexyBox 20.10.2 fix this issue (https://github.com/keexybox/keexyapp/rel...ag/20.10.2).
Reply
#8
KeexyBox 20.10.2 fix this issue (https://github.com/keexybox/keexyapp/rel...ag/20.10.2).
Reply


Forum Jump:


Users browsing this thread: 1 Guest(s)