|
could somebody assist me with resolving the following issues?
I am trying to extract BD (bluetooth device) address form "hcitool scan" command.
I am having two issues.
1. When I use the attached code in terminal it returns expected BD addresses, The requested output is "color coded" so I have highlighted the actual output.
It is working exactly what the grep options are specified.
I am stomped as far as how to option grep to retrieve the LAST part of the address.
I did try to option for SPECIFICALLY retrieve only five of the hex with colon ( combinations , for testing purposes , but it didn't work.
I am assuming that would be one way to get the whole address -retrieve five combinations of hex / colon and then retrieve the last two hex digits.
Here is my attempt do retrieve the five hex / colon combinations
hcitool scan | grep '[[:xdigit:]]\{2\}:]\{5\}'
I do not need references to man, I am asking for code help.
This following code partially works retrieving five hex / colon combinations
pi@pi:~ $ hcitool scan | grep '[[:xdigit:]]\{2\}:'
00:50:B6:80:4D:5D jim-desktop
Addendum
SOLVED
Retrieved full address by "reversing" the grep - processing FIRST hex number then processing colon /hex combination five times.
pi@pi:~ $ hcitool scan | grep -i '[[:xdigit:]]\{2\}\(:[[:xdigit:]]\{2\}\)\{5\}'
00:50:B6:80:4D:5Djim-desktop
2. This issue is very puzzling. The code which works as expected in terminal bombs when used in C++. Now the hcitool has "build in" delay when "scan" is implemented. That is NORMAL Bluetooth "inquiry response" behavior. When used as "hcitool scan" it takes few seconds to detect the bluetooth device(s). The response shows up in stdout and in my case it is written to tmp file.
All normal.
The problem is "grep" - when output form scan is piped thru there is no output whatsoever.
It makes no difference if hcitool is implemented as "sudo" on not.
Only some unspecified hcitool commands actually need to be run as "sudo" , scan is not one of them.
I understand there are other "extracting" commands, however, I would prefer to resolve both of these issues using grep.
As always , help with code is very much appreciated.
system("sudo hcitool scan | grep '[[:xdigit:]]\{2\}:'2>&1 | tee /tmp/address.txt ");
modified 19-May-19 1:18am.
|
|
|
|
|
|
I have pretty much given up on using bluez hci functions.
Instead I am looking at bluetoothctl and hcitools.
At this point I can visually identify both local and "nearby" bluetooth devices using "system" calls in my C++ code.
I am not sure how to use these scripts for actual transfer of data.
For now I like to retrieve the received text for further processing - using redirection . See bellow example when using terminal. My C++ code provides similar output to console.
I understand that some command require "sudo" (user) but do not understand why the redirection is failing.
Perhaps I need to provide detailed path to the "test" file ?
Appreciate any help.
<pre>pi@pi:/ $ sudo hcitool scan --info --class
Scanning ...
BD Address: 00:50:B6:80:4D:5D [mode 1, clkoffset 0x4dae]
Device class: Computer, Desktop workstation (0x000104)
Manufacturer: Broadcom Corporation (15)
LMP version: 2.0 (0x3) [subver 0x430e]
LMP features: 0xff 0xff 0x8d 0xfe 0x9b 0xf9 0x00 0x80
<3-slot packets> <5-slot packets> <encryption> <slot offset>
<timing accuracy> <role switch> <hold mode> <sniff mode>
<park state> <RSSI> <channel quality> <SCO link> <HV2 packets>
<HV3 packets> <u-law log> <A-law log> <CVSD> <power control>
<transparent SCO> <broadcast encrypt> <EDR ACL 2 Mbps>
<EDR ACL 3 Mbps> <enhanced iscan> <interlaced iscan>
<interlaced pscan> <inquiry with RSSI> <extended SCO>
<EV4 packets> <EV5 packets> <AFH cap. slave>
<AFH class. slave> <3-slot EDR ACL> <5-slot EDR ACL>
<AFH cap. master> <AFH class. master> <EDR eSCO 2 Mbps>
<EDR eSCO 3 Mbps> <3-slot EDR eSCO> <extended features>
pi@pi:/ $ sudo hcitool scan --info --class 2>test.txt
-bash: test.txt: Permission denied
|
|
|
|
|
The sudo command switches you into root access, so your default directory will be root's $HOME. But you most likely don't have permission to access that, so use something that you do have access to. Studying Linux documentation will probably give you some ideas.
|
|
|
|
|
Awhile back, on a bet, I set up a server/site setup with no php and no javascript. Php and javascript being 2 of the worst programming languages (yes, I know - everyone uses them).
So I've had this curiousity sitting around for a few months. As suspected, it gets practically zero traffic, not counting all the automated attacks on the php and javascript that isn't there.
Wonder if anyone has any ideas on how such I site could be used for something?
Now, I could pay the big G (and the big 'others'), but I don't want to do that. Which to me seems to limit it to very few options, like maybe Python? An interactive form using python, a database made with Python??? Like I said, any ideas?
|
|
|
|
|
I am trying to learn how to build a package (bluez) from source.
My main objective is to build a bluez library for ARM architecture so I can cross-compile my application on X86 architecture and run it (--host) on ARM.
For such purpose I option autotool generated “configure” script.
There is nothing special about “configure” options for cross-compiling– all “normal” options.
I have been making reasonable progress, but periodically running into “problems”.
Since “configure” is a product of autotools it has a nasty feature failing when debug code is inserted into wrong place.
BUT – one of the standard debugging “configure” options is to ADD environment variable(s) PKG_CONFIG_DEBUG_SPEW=set.
When it works it aids in debugging.
My “current problem” is – for unknown reason PKG_CONFIG_DEBUG_SPEW quit working on my X86 system.
So I installed fresh bluez on my ARM – Raspberry Pi 3B machine , and run plain “configure” with PKG_CONFIG_DEBUG_SPEW=set.
The “configure” script completed, so did “make” and “make install”.
All normal, no errors or issues.
I repeated the same – fresh install etc. on my X86 and got NO PKG_CONFIG_DEBUG_SPEW output.
I did check the config.log and it has the PKG_CONFIG_DEBUG_SPEW option “invoked”.
I suspect the “pkg-config” MAY be the problem, I do hope it is NOT my Ubuntu OS running on X86.
I did try to purge and reinstall “pkg-config” but run into too many dependencies.
I am attaching the actual output from "configure" where pkg-config is actually run
and PKG_CONFIG_DEBUG_SPEW is active
checking for pkg-config... /usr/bin/pkg-config
checking pkg-config is at least version 0.9.0... PKG_CONFIG_DEBUG_SPEW variable enabling debug spew
Adding directory '/usr/local/lib/arm-linux-gnueabihf/pkgconfig' from PKG_CONFIG_PATH
Adding directory '/usr/local/lib/pkgconfig' from PKG_CONFIG_PATH
Adding directory '/usr/local/share/pkgconfig' from PKG_CONFIG_PATH
Adding directory '/usr/lib/arm-linux-gnueabihf/pkgconfig' from PKG_CONFIG_PATH
Adding directory '/usr/lib/pkgconfig' from PKG_CONFIG_PATH
Adding directory '/usr/share/pkgconfig' from PKG_CONFIG_PATH
Global variable definition 'pc_sysrootdir' = '/'
Global variable definition 'pc_top_builddir' = '$(top_builddir)'
no output option set, defaulting to --exists
Error printing disabled by default due to use of output options --exists, --atleast/exact/max-version, --list-all or no output option at all. Value of --print-errors: 1
Error printing enabled
yes
checking for C/C++ restrict keyword... __restrict
Any (reasonable) suggestion how to recover and get PKG_CONFIG_DEBUG_SPEW functioning on X86 would be greatly appreciated.
Cheers
SOLUTION
Reinstall "pkg-config" package.
modified 5-May-19 14:00pm.
|
|
|
|
|
Vaclav_ wrote: get PKG_CONFIG_DEBUG_SPEW functioning on X86
The hardware platform is irrelevant: Linux is Linux.
|
|
|
|
|
I really need some very basic help with Linux.
I am trying to "configure" package and it needs to have access to dependency package "mount".
The "pkg-config" in charge cannot find "mount.pc".
It just does not exists on my OS.
Mrs. Google keeps telling me HOW mount works and is silent about missing "mount.pc".
I do not need to know how mount works, I need to find out why I have no "mount.pc" and most of all - how to fix it.
Any help leading to solution would be appreciated.
Cheers
PS Same posted on "Linux" forum without a result.
|
|
|
|
|
|
Thanks for reply.
I did look at that and its references.
It essentially suggest to build mount.pc.
I did copy what is in references, but I cannot even verify it --exists,
I need to work on that.
Still do not get why mount.pc is missing in first place.
|
|
|
|
|
I am unable to transfer UDP packets with payload length (736) 46 bytes.
The wireshark traces shows BAD UDP payload length( 736) greater than IP payload length (728).
But UDP payload length 736 is less than MTU (1500) so why I am getting this error.
As per my understanding only if the packet length > MTU then it should result in transmission error.
My client program should be sending UDP datagrams for IPv4 protocol.UDP server program is unable to receive UDP messages from the socket. Shouldn't the packet simply be fragmented if the UDP length exceeds the IP Payload Length? IP Payload length max should be MTU value isn't it ?
How to debug this issue further with respect to UDP client and Server?
|
|
|
|
|
Send packets of various lengths and see which ones work and which don't. Then there's pattern from which you can formulate a theory which may lead to a solution. Or not.
"(I) am amazed to see myself here rather than there ... now rather than then".
― Blaise Pascal
|
|
|
|
|
sarali wrote: How to debug this issue further with respect to UDP client and Server?
I used bing/google to search for your Wireshark error code. Amazingly the top 10 results are mostly garbage and incorrect information. Even the response on the wireshark forum was wrong regarding this error message. Welcome to the misinformation age.
Here is an accurate response:
In your case the error message is telling you that the IP header (total packet length - IP header length) is 728. The error message is also telling you that the UDP payload length is 736 which is 8 bytes greater than the IP tot_len value.
It's probably not a coincidence that you are off by 8 bytes... that happens to be the exact length of the UDP header.
Look through your code for the packet length calculation. I am willing to bet you missed adding the UDP header length.
Even if you forced sending this packet over the wire via raw socket... it will be dropped by the receiving side because it's considered corrupt when the packet lengths are mismatched.
TL;DR
You promised to send 728 but sent 736 instead.
Best Wishes,
-David Delaune
|
|
|
|
|
Hi,
I tied to print the packet length calculation in my program before sending it out.
I think the UDP payload length and IP length length calculation looks fine.
APP: INFO: ip header checksum:f9b9 udp checksum size_udp:736 sizeof(struct udp_hdr):8,size_ApplMsg:728udphdr->dgram_len:57346 m->data_len:770 size_ip:756 l2_data_shift:14
Further I am able to transfer UDP packets of size 20bytes,40 bytes using the same program.No issues observed.So right now I do not suspect the program. But I donot understand why the wireshark says "Bad UDP payload length". Not sure how the packet length can go wrong.Whether UDP packet is hardware offloaded ? We may be dropping the packet at the Kernel level due to this bad UDP length. So I tried to increase the UDP buffer size in kernel but of no use.
The netstat -su output shows 0 send/receive buffer errors.
[root@ATCAC06_100 /]# netstat -su
IcmpMsg:
InType0: 233961
InType3: 213187
InType8: 14
OutType0: 14
OutType3: 213187
OutType8: 17
OutType69: 233944
Udp:
592800 packets received
1439 packets to unknown port received.
0 packet receive errors
501661 packets sent
0 receive buffer errors
0 send buffer errors
UdpLite:
IpExt:
In my program I am trying to read the return value of "recvFrom" call is -1 and in that case I tried to print the strerror(errno).
But I could get prints only for the successful case ( return value > 0) and not for unsuccessful case.So mostly the packet is getting dropped at the Kernel level but how do I confirm this.Any debugging steps please share. I am using DPDK 18.08 version( on RHEL 7.6 platform) for packet forwarding.Please suggest how to resolve this issue.
modified 19-Apr-19 14:47pm.
|
|
|
|
|
Listen,
You are posting this same question all over the internet. I've even seen you over on the Intel forums.
My prior analysis is completely correct. Here is the screenshot you posted over on the Intel forums.
https://software.intel.com/sites/default/files/managed/80/b4/bad_udp_length.png
- Your packet length calculation is incorrect.
- Also... your UDP checksum is missing.
The UDP checksum might be OK if you have enabled checksum offloading on your network card. But the packet length calculation is absolutely your problem.
Best Wishes,
-David Delaune
|
|
|
|
|
Thanks David.The issue got resolved it was indeed the packet len which was not getting set correctly.
|
|
|
|
|
sarali wrote: it was indeed the packet len which was not getting set correctly.
I'm happy to have helped.
Best Wishes,
-David Delaune
|
|
|
|
|
I had to write an application long time ago whose job was to check if PID is Active or not.
The Scenario was:
Crontab will execute a process every minute
Process takes longer than a minute
So, new process will check if PID file exists or not
If PID exists new process will abort.
But before aborting new process will ensure that current process is not running longer than 30 minutes. Because, it is observed if the particular process is running more than 20 minutes, it's because some exception that the process couldn't handle. In this case, we simply kill the process for greater good.
Then a scenario crossed my mind.
What if somehow current process failed remove the pid file(whatever the reason) and the PID I am trying to kill is not my my process.
What is the possibility of reaching this scenario.
FYI, I don't handle that service more than 2 years, it's still running. But I want to know if there is any issue.
I do not fear of failure. I fear of giving up out of frustration.
|
|
|
|
|
Mohibur Rashid wrote: What is the possibility of reaching this scenario.
I guess if the process segfaults it could potentially leave behind the pid file. Why can't you just cat /proc/YOURPID/exe from your crontab script and check that the path is equal to what you are expecting?
Try it and let me know.
Best Wishes,
-David Delaune
|
|
|
|
|
I have solved the issue readlink command on exe file under pid.
but repeating PID by OS is my concern.
I do not fear of failure. I fear of giving up out of frustration.
|
|
|
|
|
Mohibur Rashid wrote: but repeating PID by OS is my concern.
Well I am not a Linux expert but I can read documentation just as good as the next guy. The documentation states /proc/sys/kernel/pid_max defaults to 32786. It also states that the Linux kernel will not reuse a PID until complete wrap-around has occurred.
So if your server is spawning over 32786 processes every 30 minutes... Yes, PID reuse would be an issue for you. Otherwise you are OK.
Best Wishes,
-David Delaune
|
|
|
|
|
As you note, the process could abort without removing the pid file. The man page for ps suggests finding the process name by ps -q <pid> -o comm=. You can then compare the two names, and kill when needed.
Another option would be to use fuser and see if the returned pid, if any, matches that of the pid file.
If you have source code to both the worker process and the controller app, then you could place a lock on the pid file in the worker, and check the lock status in the controller. If no lock has been placed on the pid file, then the worker has died without removing the pid file.
|
|
|
|
|
The issue was solved long time ago, at least 2 years ago and thank you!
I do not fear of failure. I fear of giving up out of frustration.
|
|
|
|
|
I am using this link to help me to install a package.
R: Install Add-on Packages[^]
From the documentation I gather I need to have a zipped / tar file.
I downloaded this file "bluez_5.43-2+deb9u1_armhf.deb" and it is not tar file, hence this call fails
im@jim-desktop:~$ R CMD INSTALL bluez_5.43-2+deb9u1_armhf.deb
Warning: invalid package ‘bluez_5.43-2+deb9u1_armhf.deb’
Error: ERROR: no packages specified
Is there another command to install / add package ?
Help will be greatly appreciated.
|
|
|
|
|
I don't know whether to laugh, cry or just shoot myself. Perhaps the best I can do is to quote Wolfgang Pauli: Quote: "That is not only not right; it is not even wrong",
Look, do us all a favor and go out and buy a book on Ubuntu and actually read it.
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
