org.bluez.error.inprogress error with bluetooth - linux

I have an issue where the Bluetooth got disconnected after 1-2s of connection, the master side will show the following error:
org.bluez.error.inprogress
tracing to the log I saw it will enter the following func:
un 11 16:23:46 rap bluetoothd[21474]: src/device.c:search_cb() 00:0E:8E:8B:CA:9D: No service update
Jun 11 16:23:46 rap bluetoothd[21474]: src/device.c:device_svc_resolved() /org/bluez/hci0/dev_00_0E_8E_8B_CA_9D err 0
Jun 11 16:23:46 rap bluetoothd[21474]: src/device.c:connect_profiles() /org/bluez/hci0/dev_00_0E_8E_8B_CA_9D (all), client :1.394
...
Jun 11 16:23:49 rap kernel: [12110.003903] bluetooth:l2cap_sock_release:1197: sock 0000000078f38a7c, sk 00000000f306c001
Jun 11 16:23:49 rap kernel: [12110.003907] bluetooth:l2cap_sock_shutdown:1113: sock 0000000078f38a7c, sk 00000000f306c001
Jun 11 16:23:49 rap kernel: [12110.003910] bluetooth:l2cap_sock_shutdown:1123: Handling sock shutdown
Jun 11 16:23:49 rap kernel: [12110.003913] bluetooth:l2cap_chan_hold:489: chan 0000000093211dd1 orig refcnt 3
Jun 11 16:23:49 rap kernel: [12110.003916] bluetooth:l2cap_sock_shutdown:1132: chan 0000000093211dd1 state BT_CONNECTED
Jun 11 16:23:49 rap kernel: [12110.003921] bluetooth:l2cap_chan_close:732: chan 0000000093211dd1 state BT_CONNECTED
Jun 11 16:23:49 rap kernel: [12110.003924] bluetooth:l2cap_chan_hold:489: chan 0000000093211dd1 orig refcnt 4
Jun 11 16:23:49 rap kernel: [12110.003930] bluetooth:l2cap_build_cmd:2931: conn 000000003e9a2ca4, code 0x06, ident 0x05, len 4
Jun 11 16:23:49 rap kernel: [12110.003936] bluetooth:l2cap_send_cmd:865: code 0x06
and tracing to the code in blueZ:
static DBusMessage *connect_profiles(struct btd_device *dev, uint8_t bdaddr_type,
DBusMessage *msg, const char *uuid)
{
struct bearer_state *state = get_state(dev, bdaddr_type);
int err;
DBG("%s %s, client %s", dev->path, uuid ? uuid : "(all)",
dbus_message_get_sender(msg));
if (dev->pending || dev->connect || dev->browse)
return btd_error_in_progress(msg); <------------------ HERE
...
}
My question can I somehow know which condition (pending/connect/browse) is causing this error without adding editing the code as I dont have permission to do that ? and how come the blueZ will try to connect to the profile if any of this condition is in progress?

Try restarting the bluetooth service. Had an error that said the same and managed to solve it by restarting the bluetooth service.
sudo service restart bluetooth
Try running the above command and see if it helps.

Related

How to see python script errors being run from rsyslog action

This is my action in rsyslog.conf:
module(load="omprog")
if( $msg contains "UPDOWN") then {
action(type="omprog" binary="/etc/rsyslog.d/netmiko.py" template="RSYSLOG_TraditionalFileFormat")
}
This is the python script I am working on:
pattern = re.compile('GigabitEthernet0\/\d{1,2}')
def process_line(line):
state = ''
if 'to up' in line:
state = f'UP\n'
elif 'to down' in line:
state = f'DOWN\n'
file = open("/home/blinky/python.log","a")
result = re.findall(pattern, line)
if len(result) > 0:
file.write(f'{result} - {state}')
file.close()
try:
msg = sys.stdin.readline()
file = open("/home/blinky/python.log","a")
file.write(line)
file.close()
process_line(msg)
except Exception as e:
file = open("/etc/rsyslog.d/python_error.log","a")
file.write(e)
file.close()
So the issue I have is trying to debug the python script, I can not see any of the errors it produces, as you can see I am trying to output the exception to a file but I get nothing there either. I have looked in the log file and this is the response I get from doing a shut no shut on the switch port:
Nov 20 21:50:39 10.0.0.254 1281: Nov 20 21:50:38.013: %LINK-5-CHANGED: Interface GigabitEthernet0/14, changed state to administratively down
Nov 20 21:50:39 10.0.0.254 1282: Nov 20 21:50:39.013: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet0/14, changed state to down
Nov 20 21:50:39 repperio rsyslogd: omprog: program '/etc/rsyslog.d/netmiko.py' (pid 2006160) terminated; will be restarted [v8.2112.0 try https://www.rsyslog.com/e/2119 ]
Nov 20 21:50:39 repperio rsyslogd: action 'action-1-omprog' suspended (module 'omprog'), retry 0. There should be messages before this one giving the reason for suspension. [v8.2112.0 try https://www.rsyslog.com/e/2007 ]
Nov 20 21:50:40 repperio rsyslogd: action 'action-1-omprog' resumed (module 'omprog') [v8.2112.0 try https://www.rsyslog.com/e/2359 ]
Nov 20 21:50:43 10.0.0.254 1283: Nov 20 21:50:42.756: %LINK-3-UPDOWN: Interface GigabitEthernet0/14, changed state to up
Nov 20 21:50:43 10.0.0.254 1284: Nov 20 21:50:43.756: %LINEPROTO-5-UPDOWN: Line protocol on Interface GigabitEthernet0/14, changed state to up
Nov 20 21:50:43 repperio rsyslogd: child process (pid 2006317) exited with status 1 [v8.2112.0]
Nov 20 21:50:43 repperio rsyslogd: omprog: program '/etc/rsyslog.d/netmiko.py' (pid 2006317) terminated; will be restarted [v8.2112.0 try https://www.rsyslog.com/e/2119 ]
Nov 20 21:50:43 repperio rsyslogd: action 'action-1-omprog' suspended (module 'omprog'), retry 0. There should be messages before this one giving the reason for suspension. [v8.2112.0 try https://www.rsyslog.com/e/2007 ]
Nov 20 21:50:44 repperio rsyslogd: action 'action-1-omprog' resumed (module 'omprog') [v8.2112.0 try https://www.rsyslog.com/e/2359 ]
The script monitors the Cisco switch for interfaces going up and down and triggers the python script, this in turn will alter the configuration of the switch port using Netmiko. Without the ability to debug the python script I am scuppered, any ideas?

Is it possible that any Userspace application can call our driver routines without opening the /dev interface node

Suppose I have implemented file_operations such as read, write, open, release, flush etc. and I wrote userspace application which calls these routines. In character driver, Userspace application communicate through /dev interface node.
for example - (/dev/diagnostics_1000_1-4:2.1) and I am bit surprise another application call our driver routines and we don't have control on those application.
Do they really call flush system call which directly/indirectly mapped to our function pointer ".flush"?
Snippet below -
[Wed Aug 16 23:07:02 2022] UserspaceOpen:448 PID = 291098, Pname = MyApp
[Wed Aug 16 23:07:02 2022] Diagnostics_1000: UserspaceOpen:461 - Interface is 3
....
[Tue Aug 16 23:07:38 2022] UserspaceRead:1182 PID = 25460, Pname = MyApp
[Tue Aug 16 23:07:38 2022] UserspaceFlush:622 PID = 25470, Pname = lsb_release
[Tue Aug 16 23:07:38 2022] UserspaceFlush:631 Wrong process:: PID = 25470, Pname = lsb_release, and pDev->pName = MyApp
[Tue Aug 16 23:07:38 2022] UserspaceFlush:622 PID = 25469, Pname = sh
[Tue Aug 16 23:07:38 2022] UserspaceFlush:631 Wrong process:: PID = 25469, Pname = sh, and pDev->pName = MyApp
[Tue Aug 16 23:07:38 2022] UserspaceWrite:1394 PID = 25463, Pname = MyApp
[Tue Aug 16 23:07:38 2022] UserspaceWrite_bulk_callback:1241 PID = 25428, Pname = VizCompositorTh
[Tue Aug 16 23:07:39 2022] UserspaceRead:1182 PID = 25460, Pname = MyApp
You can see that MyApp opens the interface "diagnostics_1000_1-4:2.1" but UserspaceFlush driver routines also called by lsb_release and sh process in the middle of operation and breaking the code flow. Though lsb_release and sh process haven't open the interface but somehow they triggered Flush operation.
We fixed the code by comparing the process name and continues if it matches otherwise return error code.
UserspaceFlush:631 Wrong process:: PID = 25469, Pname = sh, and pDev->pName = MyApp
Is there any design flaw? I want to understand what I am missing conceptually and how we can make it secure.
How to make sure that flush routine get called by the same process always i.e MyApp and file descriptor get closed by same application i.e MyApp because files actually opened by MyApp only.

OpenCV how to select which camera to connect to?

I am writing an OpenCV 3.4 app on Ubuntu 16.04.
However, I am running into a problem where no matter what deviceId I set on my VideoCapture() function, I always get the built in webcam stream. However I need to get the stream from my usb camera. Btw my usb camera is a Logitech c920, and my computer is a ThinkPad P51 (not sure if that would matter)
Here is my code:
#include <opencv2/highgui.hpp>
#include <opencv2/opencv.hpp>
#include <opencv2/aruco.hpp>
#include <iostream>
int main(int, char**){
cv::Mat inputImage;
std::vector<int> markerIds;
std::vector<std::vector<cv::Point2f> > markerCorners, rejectedCandidates;
cv::aruco::DetectorParameters parameters;
cv::VideoCapture inputVideo(1); // I have tried 0, 1, 2...20 all the same stream
cv::Ptr<cv::aruco::Dictionary> dictionary = cv::aruco::getPredefinedDictionary(cv::aruco::DICT_4X4_50);
while (inputVideo.grab()){
cv::Mat image, imageCopy;
inputVideo.retrieve(image);
image.copyTo(imageCopy);
std::vector<int> ids;
std::vector<std::vector<cv::Point2f> > corners;
cv::aruco::detectMarkers(image, dictionary, corners, ids);
if (ids.size() > 0) cv::aruco::drawDetectedMarkers(imageCopy, corners, ids);
cv::imshow("out", imageCopy);
if(cv::waitKey(30) >= 0) break;
}
}
Thanks!
EDIT:
This is the result I get with ls -lR /dev/v4l:
/dev/v4l:
total 0
drwxr-xr-x 2 root root 80 Feb 23 10:53 by-id
drwxr-xr-x 2 root root 80 Feb 23 10:53 by-path
/dev/v4l/by-id:
total 0
lrwxrwxrwx 1 root root 12 Feb 23 10:53 usb-046d_HD_Pro_Webcam_C920_25CCF0FF-video-index0 -> ../../video1
lrwxrwxrwx 1 root root 12 Feb 23 2019 usb-8SSC20F27019L1GZ83C07ZY_Integrated_Camera-video-index0 -> ../../video0
/dev/v4l/by-path:
total 0
lrwxrwxrwx 1 root root 12 Feb 23 10:53 pci-0000:00:14.0-usb-0:6:1.0-video-index0 -> ../../video1
lrwxrwxrwx 1 root root 12 Feb 23 2019 pci-0000:00:14.0-usb-0:8:1.0-video-index0 -> ../../video0
And this is what I get with lsusb:
Bus 002 Device 001: ID 1d6b:0003 Linux Foundation 3.0 root hub
Bus 001 Device 005: ID 138a:0097 Validity Sensors, Inc.
Bus 001 Device 004: ID 04ca:7066 Lite-On Technology Corp.
Bus 001 Device 008: ID 046d:082d Logitech, Inc. HD Pro Webcam C920
Bus 001 Device 003: ID 046d:c539 Logitech, Inc.
Bus 001 Device 002: ID 04d9:0169 Holtek Semiconductor, Inc.
Bus 001 Device 006: ID 8087:0a2b Intel Corp.
Bus 001 Device 001: ID 1d6b:0002 Linux Foundation 2.0 root hub
Not sure how to match them?

gitlab can't deliver email normally

I have installed the gitlab-omnibus version in my centos.It seems that everything is OK.But when a newer want to sign up, he/she must recieve the comfirm enalbe which send from gitlab.I have config the /etc/gitlab/gitlab.rb according to the gitlab's office document.
And I check my var/log/email,I found the message is as follow:
Apr 22 15:05:39 iZ23syflhhzZ postfix/cleanup[5899]: 9789EC3907: message-id=<201504220705.t3M75dkU005893#iZ23syflhhzZ>
Apr 22 15:05:39 iZ23syflhhzZ sendmail[5893]: t3M75dkU005893: to=postmaster, delay=00:00:00, xdelay=00:00:00, mailer=relay, pri=32576, relay=[127.0.0.1] [127.0.0.1], dsn=2.0.0, stat=Sent (Ok: queued as 9789EC3907)
Apr 22 15:05:39 iZ23syflhhzZ postfix/qmgr[5724]: 9789EC3907: from=<>, size=4301, nrcpt=1 (queue active)
Apr 22 15:05:39 iZ23syflhhzZ postfix/smtpd[5896]: disconnect from localhost[127.0.0.1]
Apr 22 15:05:39 iZ23syflhhzZ postfix/cleanup[5899]: A6D63C38FD: message-id=<201504220705.t3M75dkU005893#iZ23syflhhzZ>
Apr 22 15:05:39 iZ23syflhhzZ postfix/qmgr[5724]: A6D63C38FD: from=<>, size=4456, nrcpt=1 (queue active)
Apr 22 15:05:39 iZ23syflhhzZ postfix/local[5900]: 9789EC3907: to=<postmaster#iZ23syflhhzZ.localdomain>, orig_to=<postmaster#iZ23syflhhzZ>, relay=local, delay=0.1, delays=0.05/0.04/0/0.01, dsn=2.0.0, status=sent (forwarded as A6D63C38FD)
Apr 22 15:05:39 iZ23syflhhzZ postfix/qmgr[5724]: 9789EC3907: removed
Apr 22 15:05:40 iZ23syflhhzZ postfix/smtp[5902]: A6D63C38FD: to=<hiufan#qq.com>, orig_to=<postmaster#iZ23syflhhzZ>, relay=mx3.qq.com[113.108.16.62]:25, delay=0.73, delays=0.01/0.03/0.12/0.57, dsn=5.0.0, status=bounced (host mx3.qq.com[113.108.16.62] said: 550 Mail content denied. http://service.mail.qq.com/cgi-bin/help?subtype=1&&id=20022&&no=1000726 (in reply to end of DATA command))
Apr 22 15:05:40 iZ23syflhhzZ postfix/qmgr[5724]: A6D63C38FD: removed
It is very confused that I am not setting the email called hiufan#qq.com,I just setting the 066337#sina.com as the default sender email.
Here is my setting of /etc/gitlab/gitlab.rb:
gitlab_rails['smtp_enable'] = true
gitlab_rails['smtp_address'] = "smtp.sina.com"
gitlab_rails['smtp_port'] = 25
gitlab_rails['smtp_user_name'] = "066337#sina.com"
gitlab_rails['smtp_password'] = "xxxxxx"
gitlab_rails['smtp_domain'] = "sina.com"
gitlab_rails['smtp_authentication'] = "login"
gitlab_rails['smtp_enable_starttls_auto'] = true
gitlab_rails['smtp_tls'] = false
gitlab_rails['gitlab_email_from'] = "066337#sina.com"
user["git_user_email"] = "066337#sina.com"
Could anyone tell me why this happened?Thank you very much.
Look at the second last line of the log file
to=<hiufan#qq.com>, orig_to=<postmaster#iZ23syflhhzZ>, relay=mx3.qq.com[113.108.16.62]:25, delay=0.73, delays=0.01/0.03/0.12/0.57, dsn=5.0.0, status=bounced (host mx3.qq.com[113.108.16.62] said: 550 Mail content denied. (in reply to end of DATA command))
If hiufan#qq.com is the email address of the user registering, that
indicates that the message was sent by the gitlab machine but rejected by the receiving mail server (at qq.com):
status=bounced (host mx3.qq.com[113.108.16.62] said: 550 Mail content denied
Looking at the given link (using google translate)
http://service.mail.qq.com/cgi-bin/help?subtype=1&&id=20022&&no=1000726
it seems that it was rejected as it is identified as spam/bulk email. (I guess that if you do read chinese the error message makes more sense)
If so, I don't think there is much you can do at the gitlab side. You can perhaps try to edit the confirmation message template, but it is and automatically generated email and there is always a risk of a spam filter identifying it as such.
Gitlab confirmation emails can easily be identified as spam. And QQMail is really powerful in identifying and rejecting spam.
My suggestion would be changing the config of Gitlab, to stop needing confirmation email for registration.

Cannot add members to MongoDB Replica Set

I'm trying to configure a MongoDB Replica Set but every time I try to add another member it fails.
I have 3 members I'm trying to configure. Their mongod.conf files all look like this:
# mongo.conf
#where to log
logpath=/log/mongod.log
logappend=true
# fork and run in background
fork = true
smallfiles=true
rest=true
port = 27017
replSet=KidzpaceReplSet
dbpath=/data
With the acception of the ports. They are 27017(Primary), 27018(Secondary) and 27019(Arbiter) respectively.
I have verified that the members can see each other:
[ec2-user#domU-12-31-39-06-C4-74 ~]$ mongo --host 174.129.232.170 --port 27018
MongoDB shell version: 2.4.3
connecting to: 174.129.232.170:27018/test
>
[ec2-user#domU-12-31-39-0A-30-E8 ~]$ mongo --host 174.129.230.20 --port 27017
MongoDB shell version: 2.4.3
connecting to: 174.129.230.20:27017/test
>
When adding the second member to the set it returns OK:
KidzpaceReplSet:PRIMARY> rs.add("174.129.232.170:27018")
{ "ok" : 1 }
However whatever the next command I run is, In this case it's adding my Arbiter, the set fails with this error:
KidzpaceReplSet:PRIMARY> rs.add("174.129.232.177:27019", true)
Tue May 28 20:24:07.139 DBClientCursor::init call() failed
Tue May 28 20:24:07.140 trying reconnect to 127.0.0.1:27017
Tue May 28 20:24:07.141 reconnect 127.0.0.1:27017 ok
reconnected to server after rs command (which is normal)
This is the the log file:
Tue May 28 20:44:06.173 [rsStart] replSet I am domU-12-31-39-06-C4-74:27017
Tue May 28 20:44:06.173 [rsStart] replSet STARTUP2
Tue May 28 20:44:07.175 [rsSync] replSet SECONDARY
Tue May 28 20:44:07.175 [rsMgr] replSet info electSelf 0
Tue May 28 20:44:08.174 [rsMgr] replSet PRIMARY
Tue May 28 20:44:29.813 [conn1] replSet replSetReconfig config object parses ok, 2 members specified
Tue May 28 20:44:29.817 [conn1] replSet replSetReconfig [2]
Tue May 28 20:44:29.817 [conn1] replSet info saving a newer config version to local.system.replset
Tue May 28 20:44:29.834 [conn1] replSet saveConfigLocally done
Tue May 28 20:44:29.834 [conn1] replSet info : additive change to configuration
Tue May 28 20:44:29.834 [conn1] replSet replSetReconfig new config saved locally
Tue May 28 20:44:39.835 [rsHealthPoll] DBClientCursor::init call() failed
Tue May 28 20:44:39.835 [rsHealthPoll] replset info 174.129.232.170:27018 heartbeat failed, retrying
Tue May 28 20:44:40.834 [rsHealthPoll] DBClientCursor::init call() failed
Tue May 28 20:44:40.834 [rsHealthPoll] replSet info 174.129.232.170:27018 is down (or slow to respond):
Tue May 28 20:44:40.835 [rsHealthPoll] replSet member 174.129.232.170:27018 is now in state DOWN
Tue May 28 20:44:40.835 [rsMgr] replSet total number of votes is even - add arbiter or give one member an extra vote
Tue May 28 20:44:40.835 [rsMgr] can't see a majority of the set, relinquishing primary
Tue May 28 20:44:40.835 [rsMgr] replSet relinquishing primary state
Tue May 28 20:44:40.835 [rsMgr] replSet SECONDARY
Tue May 28 20:44:40.835 [rsMgr] replSet closing client sockets after relinquishing primary
Tue May 28 20:44:42.044 [conn1] end connection 127.0.0.1:58727 (0 connections now open)
Tue May 28 20:44:46.150 [rsHealthPoll] replSet member 174.129.232.170:27018 is up
Tue May 28 20:44:46.151 [rsMgr] replSet not electing self, not all members up and we have been up less than 5 minutes
Tue May 28 20:44:52.156 [rsMgr] replSet not electing self, not all members up and we have been up less than 5 minutes
UPDATE
I'm wondering if maybe the problem is when I run rs.initiate(). It gives me this output:
{
"set" : "KidzpaceReplSet",
"date" : ISODate("2013-05-28T20:59:05Z"),
"myState" : 1,
"members" : [
{
"_id" : 0,
"name" : "domU-12-31-39-06-C4-74:27017",
"health" : 1,
"state" : 1,
"stateStr" : "PRIMARY",
"uptime" : 23,
"optime" : {
"t" : 1369774732,
"i" : 1
},
"optimeDate" : ISODate("2013-05-28T20:58:52Z"),
"self" : true
}
],
"ok" : 1
}
Notice the name of the member? "name" : "domU-12-31-39-06-C4-74:27017" Where does this name come from? It's not my IP Address. I'm not sure but maybe this could be the source of the problem.
So it turns out rs.initiate() might give the member that launches it some kind of internal alias for it's IP address. In my case it was: domU-12-31-39-06-C4-74.
The initial connection to the secondary is fine because the primary instigates it. However since the secondary now has this alias to use when it tries to talk back to the primary, it fails.
The solution was a to copy the existing configuration:
cfg = rs.conf()
manually change the name(host) of the primary node:
cfg.members[0].host = 666.666.666.666:27017
And reconfigure the replica set:
rs.reconfig(cfg)

Resources