On Jul 12, 2019, at 2:39 PM, David White wrote:> > Thanks Roger for all your help here. I hope the 2 attachments come through. The .sh is my doctored version of the script and the .report is its output. I welcome any suggestions or ideas about what might be causing my problems with monitoring to the Belkin UPS. CheersHi David, Nothing looks out of order in your configuration files. (They are fairly similar to a configuration I am currently running on Ubuntu 18.04.) You mentioned in the other thread that Ubuntu is running in a chroot in Android. There is a chance that the Android kernel configuration is messing with things here, and you may need to use strace to watch some of the system calls. In the mean time, what if you stop the nut-client service, and run upsmon in debugging mode? sudo /sbin/upsmon -DD Also, what do you get from "netstat -tn | grep -w 3493"?
Hi Charles and thanks for your help. 1. I just re-started the Ubuntu/Android system. This runs a root script including "service nut-server start" followed by the same for nut-client. I can check the status on both and they show as running. I can see expected results running "upsc belkinusb". 2. When I check the results from "netstat -t -n" I am NOT finding anything on 3493. Hmmm. I then tried "netstat -l" since there should be a server socket listening on 3494, right? There is nothing of 3493. But I do see an entry with local address = localhost:nut. When I "cat /etc/services" I find nut listed on 3493. 3. So I run "netstat -l | grep nut" and I see the socket and I see an entry for what looks like a stream listener tied to /var/run/nut/blazer_usb-belkinusb. 4. I did not know of the -DD option on upsmon and likely would not have thought of this anyhow. In the output I almost immediately see a connection failure to belkinusb at localhost for the socket saying permission denied. That doesn't look right. But not exactly what that means or how to fix it. This seems to be progress of a sort, at least for my understanding of all this. Any further comments/tips? Cheers On 7/14/2019 8:18 PM, Charles Lepple wrote:> On Jul 12, 2019, at 2:39 PM, David White wrote: >> >> Thanks Roger for all your help here. I hope the 2 attachments come through. The .sh is my doctored version of the script and the .report is its output. I welcome any suggestions or ideas about what might be causing my problems with monitoring to the Belkin UPS. Cheers > > Hi David, > > Nothing looks out of order in your configuration files. (They are fairly similar to a configuration I am currently running on Ubuntu 18.04.) > > You mentioned in the other thread that Ubuntu is running in a chroot in Android. There is a chance that the Android kernel configuration is messing with things here, and you may need to use strace to watch some of the system calls. > > In the mean time, what if you stop the nut-client service, and run upsmon in debugging mode? > > sudo /sbin/upsmon -DD > > Also, what do you get from "netstat -tn | grep -w 3493"? >
On Jul 15, 2019, at 11:15 AM, David White wrote:> > 2. When I check the results from "netstat -t -n" I am NOT finding anything on 3493. Hmmm. I then tried "netstat -l" since there should be a server socket listening on 3494, right? There is nothing of 3493. But I do see an entry with local address = localhost:nut. When I "cat /etc/services" I find nut listed on 3493. >Mistake on my end; I was thinking "netstat -tln" or "netstat -atn". Without the "-n", it looks up "3493" in /etc/services, as you mentioned.> 3. So I run "netstat -l | grep nut" and I see the socket and I see an entry for what looks like a stream listener tied to /var/run/nut/blazer_usb-belkinusb. >This should be there, but it's the Unix-domain socket (not TCP) between the driver and upsd, so not relevant at the moment.> 4. I did not know of the -DD option on upsmon and likely would not have thought of this anyhow. In the output I almost immediately see a connection failure to belkinusb at localhost for the socket saying permission denied. That doesn't look right. But not exactly what that means or how to fix it.I am still confused as to why upsc works, but maybe this is related? "Android adds a "paranoid network" option to the Linux kernel, which restricts access to some networking features depending on the group of the calling process. This option should not be set in any other OS not using Android security model - because it requires 4 groups with specific UIDs (3001-3005) to exist, and all relevant users to be added to them - which in our case would be all users anyways, as that's the "traditional" behavior." https://github.com/AsteroidOS/meta-bass-hybris/commit/b819096ed5a5ef12828c63b1f2f0b8e962fd1e81 More info: * https://wiki.postmarketos.org/wiki/Kernel_configuration#CONFIG_ANDROID_PARANOID_NETWORK * https://elinux.org/Android_Security#Paranoid_network-ing If you can get to the kernel config for the Android side of things, you can check for that CONFIG_... option. If it is enabled, then maybe there is something different about the user ID that upsmon is running under versus upsc.