|
|
As I said, it didn't work using the command to get java, I had to manually take it from Oracle, and install it that way. And from Oracle, I didn't had to download openjfx separately (which still didn't worked that way), it came with jdk 8_211.
|
|
|
|
|
Addendum
The following link MAY hold the answer.
I need time to study it.
dbus-daemon[^]
I have posted the following in another (Linux) forum and got no response.
I am hoping I do better here.
The enclosed error tells me to change dbus "configuration" file.
There are few problems with such laconic error.
#1 There are no such things as single "configuration " file.
#2 What I assume is main "session.conf"( NOT configuration - just conf ) has been deleted and replaced by others in THREE different folders.
#3 The instruction in ONE of them - "session.conf" tells specifically NOT to modify this file. That is fine , I generally can follow instruction how to supplement this file BUT
#4 Is this "session.conf" the correct file to supplement ?
#5 Where / HOW EXACTLY do I change this "security " - using "session.conf" as template to be able to name my own dbus ?
PS
I understand the "session.conf" is NOT just plain script / text file so I ma reluctant to "change " anything anyway in it. (Just found out it is in HTML format, I have no experience with HTML!)
Here is the compiler error output:
conn = 0xadff00
register our name on the bus, and check for errors
TESTtest.signal.source
err.message = Connection ":1.77" is not allowed to own the service "TESTtest.signal.source" due to security policies in the configuration file
Failed dbus_bus_request_name: : Resource temporarily unavailable
Addendum:
I have found two x.conf "system.conf" and "session.conf". Neither one of them is very intuitive to let me change the "naming" security to correct the error.
I am enclosing a copy of full "session.conf" I am supposedly modify / copy / use to change the "naming" security. I hope somebody can point out to me what needs to be changed and how to duplicate / make the "supplemental file" as instructed.
FYI - the only entry mentioning "name " is in "system.conf"
<!-- <limit name="max_connections_per_user">256</limit> -->
<!-- <limit name="max_pending_service_starts">512</limit> -->
<!-- <limit name="max_names_per_connection">512</limit> -->
<!-- <limit name="max_match_rules_per_connection">512</limit> -->
<!-- <limit name="max_replies_per_connection">128</limit> -->
PS
I have not figured out how to copy the entire "terminal" output , so there may be duplicates.
The file is included to help to identify WHAT needs to be changed.
GNU nano 2.5.3 File: session.conf
<!-- This configuration file controls the per-user-login-session message bus.
Add a session-local.conf and edit that rather than changing this
file directly. -->
<!DOCTYPE busconfig PUBLIC "-//freedesktop//DTD D-Bus Bus Configuration 1.0//EN"
"http://www.freedesktop.org/standards/dbus/1.0/busconfig.dtd">
<busconfig>
<!-- Our well-known bus type, don't change this -->
<type>session</type>
<!-- If we fork, keep the user's original umask to avoid affecting
the behavior of child processes. -->
<keep_umask/>
<listen>unix:tmpdir=/tmp</listen>
<!-- On Unix systems, the most secure authentication mechanism is
EXTERNAL, which uses credential-passing over Unix sockets.
This authentication mechanism is not available on Windows,
is not suitable for use with the tcp: or nonce-tcp: transports,
and will not work on obscure flavours of Unix that do not have
a supported credentials-passing mechanism. On those platforms/transports,
comment out the <auth> element to allow fallback to DBUS_COOKIE_SHA1. -->
<auth>EXTERNAL</auth>
<standard_session_servicedirs />
<policy context="default">
<!-- Allow everything to be sent -->
<allow send_destination="*" eavesdrop="true"/>
<!-- Allow everything to be received -->
<allow eavesdrop="true"/>
<!-- Allow anyone to own anything -->
<allow own="*"/>
</policy>
<!-- Include legacy configuration location -->
<include ignore_missing="yes">/etc/dbus-1/session.conf</include>
<!-- Config files are placed here that among other things,
further restrict the above policy for specific services. -->
<includedir>session.d</includedir>
<includedir>/etc/dbus-1/session.d</includedir>
<!-- This is included last so local configuration can override what's
in this standard file -->
<include ignore_missing="yes">/etc/dbus-1/session-local.conf</include>
<!-- Include legacy configuration location -->
<include ignore_missing="yes">/etc/dbus-1/session.conf</include>
<!-- Config files are placed here that among other things,
further restrict the above policy for specific services. -->
<includedir>session.d</includedir>
<includedir>/etc/dbus-1/session.d</includedir>
<!-- This is included last so local configuration can override what's
in this standard file -->
<include ignore_missing="yes">/etc/dbus-1/session-local.conf</include>
<include if_selinux_enabled="yes" selinux_root_relative="yes">contexts/dbus_contexts</include>
<!-- For the session bus, override the default relatively-low limits
with essentially infinite limits, since the bus is just running
as the user anyway, using up bus resources is not something we need
to worry about. In some cases, we do set the limits lower than
"all available memory" if exceeding the limit is almost certainly a bug,
having the bus enforce a limit is nicer than a huge memory leak. But the
intent is that these limits should never be hit. -->
<!-- the memory limits are 1G instead of say 4G because they can't exceed 32-bit signed int max -->
<limit name="max_incoming_bytes">1000000000</limit>
<limit name="max_incoming_unix_fds">250000000</limit>
<limit name="max_outgoing_bytes">1000000000</limit>
<limit name="max_outgoing_unix_fds">250000000</limit>
<limit name="max_message_size">1000000000</limit>
<!-- We do not override max_message_unix_fds here since the in-kernel
limit is also relatively low -->
<limit name="service_start_timeout">120000</limit>
<limit name="auth_timeout">240000</limit>
<limit name="pending_fd_timeout">150000</limit>
<limit name="max_completed_connections">100000</limit>
<limit name="max_incomplete_connections">10000</limit>
<limit name="max_connections_per_user">100000</limit>
<limit name="service_start_timeout">120000</limit>
<limit name="auth_timeout">240000</limit>
<limit name="pending_fd_timeout">150000</limit>
<limit name="max_completed_connections">100000</limit>
<limit name="max_incomplete_connections">10000</limit>
<limit name="max_connections_per_user">100000</limit>
<limit name="max_pending_service_starts">10000</limit>
<limit name="max_names_per_connection">50000</limit>
<limit name="max_match_rules_per_connection">50000</limit>
<limit name="max_replies_per_connection">50000</limit>
</busconfig>
As always , any help would be greatly appreciated.
Cheers
Addendum:
Here is what is in the "removed " "session.conf" file.
Which helps a little but bring up another "question"
What is "session.d" folder for - which is empty ?
jim@jim-desktop:/usr/DBUS/share/dbus-1$ ls
services session.conf session.d system.conf system.d system-services
jim@jim-desktop:/usr/DBUS/share/dbus-1$ cd session.d
jim@jim-desktop:/usr/DBUS/share/dbus-1/session.d$ ls
I guess I need for have
<busconfig> element containing configuration directives
in my supplemental file.
<!--
This configuration file is no longer required and may be removed.
In older versions of dbus, this file defined the behaviour of the well-known
session bus. That behaviour is now determined by
/usr/DBUS/share/dbus-1/session.conf, which should not be edited.
For local configuration changes, create a file
session-local.conf or files matching session.d/*.conf in the same directory
as this one, with a <busconfig> element containing configuration directives.
These directives can override D-Bus or OS defaults.
For upstream or distribution-wide defaults that can be overridden
by a local sysadmin, create files matching
/usr/DBUS/share/dbus-1/session.d/*.conf instead.
-->
<!DOCTYPE busconfig PUBLIC "-//freedesktop//DTD D-Bus Bus Configuration 1.0//EN"
"http://www.freedesktop.org/standards/dbus/1.0/busconfig.dtd">
<busconfig></busconfig>
modified 2-Jun-19 21:12pm.
|
|
|
|
|
DELETED
modified 27-May-19 8:58am.
|
|
|
|
|
Maybe you would get better help by going to the developers' site: BlueZ » Contact[^]
|
|
|
|
|
Please don't delete messages that have been responded to. They may be of use to other people on the site.
|
|
|
|
|
Looking to figure out how to design a desktop and theme for an operating system based off of Linux. Can anyone point me in the right direction on how to do this? Anyone know of any books? Any tips? Any pointers? Any Forums? etc. The other parts are alot easier such as subject matter and basic architecture. But, for all I can find right now, everything that is out there teaches to design a server operating system Which would be nothing more than a terminal.
|
|
|
|
|
There are lots of books written on Linux. Just try a bit of searching, and Google will help you.
|
|
|
|
|
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
|
|
|
|
General 
News 
Suggestion 
Question 
Bug 
Answer 
Joke 
Praise 
Rant 
Admin 
Submit an article or tip
