GNU/Linux

Fedora 25 with GNOME 3: Making a Wi-Fi hotspot 7

 in GNU/Linux  tagged fedora / gnome / hotspot / network manager / nm-connection-editor / wi-fi by

Recently we tried to create a Wi-Fi hotspot on Fedora 25 running GNOME 3.

When we clicked on the Use as Hotspot... button  on the network manager it did not activate the hotspot.
Actually, nothing changed after we clicked on the button.
We tried this several times, some while being disconnected from all networks, others with having the Wi-Fi device disabled etc. None of the tests payed out.

To mitigate the problem, we used nm-connection-editor to create the hotspot configuration and then activate it from the network manager.

After we starter nm-connection-editor, we pressed the Add button to create a new configuration:

From the prompt, we selected the option Wi-Fi and then clicked on the Create... button.

In the newly appeared window, we filled in

  • the Connection name (which is not used by the system, it is only for us to identify which configuration this is),
  • then the SSID (which is the name of the network you will create and connect to),
  • we set Mode to Hotspot

Then we switched to the Wi-Fi Security tab where we filled in the type of protection we want the hotspot to have and the password for it.

We clicked Save and then we closed the Network Connections window as well.

From the network manager, we clicked on Use as Hotspot... button and then the Turn On button on the confirmation popup to finish the activation.

After this, the network manager changed its screen and showed a page which had all the necessary information that are needed to connect to our newly created hotspot.

Note:

In case you cannot connect because the password verification fails even though you are providing the correct password, you can always do the ugly hack of setting up a hotspot with no security to get your job done…

How to find the program interpreter that a Linux application requests 1

 in GNU/Linux  tagged cut / elf / readelf / tr by
Recently we tried to execute an application and we got the following error:
-bash: ./main: No such file or directory
This error occurred because our application was trying to use an interpreter that was not available on that machine.
We used the readelf utility that displays information about ELF files (including the interpreter information) to resolve our issue.
Specifically we used readelf -l ./main which displays the information contained in the file’s segment headers, if it has any.
(You can replace the parameter -l with --program-headers or --segments, they are the same).

From the data that was produced we only needed the following line:

[Requesting program interpreter: /lib/ld-linux-armhf.so.3]
so we used grep to filter out all other lines and then cut and tr to get the data after the : character (second column) and then remove all spaces and the ] character from the result.
The full and final command we used was:
readelf -l ./main | grep 'Requesting' | cut -d':' -f2 | tr -d ' ]';

Device has MAC address X, instead of configured address Y.

 in GNU/Linux  tagged address / eth0 / MAC by

Recently, we tried to take a network interface down on a VM, when we executed the command

ifdown eth0

we got the following error:

ERROR    : [/etc/sysconfig/network-scripts/ifdown-eth] Device  has MAC address 00:00:00:00:00:00
 00:45:4D:04:02:36
 00:45:4D:04:02:40, instead of configured address 00:45:4D:16:0B:29. Ignoring.

We used ifconfig eth0 to check the information on the network interfaces which resulted in the following data:

eth0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
 inet 10.1.20.115  netmask 255.255.255.0  broadcast 10.1.20.255
 inet6 fe80::215:5dff:fe01:236  prefixlen 64  scopeid 0x20<link>
 ether 00:45:4d:04:02:36  txqueuelen 1000  (Ethernet)
 RX packets 10103919  bytes 5474528935 (5.0 GiB)
 RX errors 0  dropped 0  overruns 0  frame 0
 TX packets 6541413  bytes 1190276207 (1.1 GiB)
 TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

We saw that the value ether for eth0 was 00:45:4d:04:02:36, which was one of the addresses the warning mentioned that are valid.

Apparently, we had an error in the following configuration file:

/etc/sysconfig/network-scripts/ifcfg-eth0

The value for HWADDR was set to 00:45:4D:16:0B:29 which was wrong (most likely this file was copied here from another source), after we updated the value to 00:45:4d:04:02:36 we were able to use the device normally.

Start CLion as root on Fedora 1

 in GNU/Linux  tagged clion / linux / root / x-server / xhost by

Solution

Execute the following as a normal user


xhost +si:localuser:root;
sudo ./clion.sh;

Background Story and More Information

Recently we needed to start CLion as root on Fedora to allow the application we were developing to bind the DHCP service of the system.
When we tried to start CLion as root we got the following error:

java.awt.AWTError: Can't connect to X11 window server using ':0' as the value of the DISPLAY variable.

Specifically, the whole error log was as follows:

[george@bytefreaks bin]$ sudo ./clion.sh 
[sudo] password for george: 
No protocol specified

Start Failed: Failed to initialize graphics environment

java.awt.AWTError: Can't connect to X11 window server using ':0' as the value of the DISPLAY variable.
    at sun.awt.X11GraphicsEnvironment.initDisplay(Native Method)
    at sun.awt.X11GraphicsEnvironment.access$200(X11GraphicsEnvironment.java:65)
    at sun.awt.X11GraphicsEnvironment$1.run(X11GraphicsEnvironment.java:115)
    at java.security.AccessController.doPrivileged(Native Method)
    at sun.awt.X11GraphicsEnvironment.<clinit>(X11GraphicsEnvironment.java:74)
    at java.lang.Class.forName0(Native Method)
    at java.lang.Class.forName(Class.java:264)
    at java.awt.GraphicsEnvironment.createGE(GraphicsEnvironment.java:103)
    at java.awt.GraphicsEnvironment.getLocalGraphicsEnvironment(GraphicsEnvironment.java:82)
    at sun.awt.X11.XToolkit.<clinit>(XToolkit.java:126)
    at java.lang.Class.forName0(Native Method)
    at java.lang.Class.forName(Class.java:264)
    at java.awt.Toolkit$2.run(Toolkit.java:860)
    at java.awt.Toolkit$2.run(Toolkit.java:855)
    at java.security.AccessController.doPrivileged(Native Method)
    at java.awt.Toolkit.getDefaultToolkit(Toolkit.java:854)
    at java.awt.Toolkit.getEventQueue(Toolkit.java:1734)
    at java.awt.EventQueue.isDispatchThread(EventQueue.java:1043)
    at javax.swing.SwingUtilities.isEventDispatchThread(SwingUtilities.java:1361)
    at javax.swing.text.StyleContext.reclaim(StyleContext.java:454)
    at javax.swing.text.StyleContext.addAttribute(StyleContext.java:311)
    at javax.swing.text.html.StyleSheet.addAttribute(StyleSheet.java:578)
    at javax.swing.text.StyleContext$NamedStyle.addAttribute(StyleContext.java:1501)
    at javax.swing.text.StyleContext$NamedStyle.setName(StyleContext.java:1312)
    at javax.swing.text.StyleContext$NamedStyle.<init>(StyleContext.java:1259)
    at javax.swing.text.StyleContext.addStyle(StyleContext.java:107)
    at javax.swing.text.StyleContext.<init>(StyleContext.java:87)
    at javax.swing.text.html.StyleSheet.<init>(StyleSheet.java:166)
    at javax.swing.text.html.HTMLEditorKit.getStyleSheet(HTMLEditorKit.java:391)
    at com.intellij.util.ui.UIUtil.<clinit>(UIUtil.java:102)
    at com.intellij.ide.plugins.PluginManager.start(PluginManager.java:73)
    at sun.reflect.NativeMethodAccessorImpl.invoke0(Native Method)
    at sun.reflect.NativeMethodAccessorImpl.invoke(NativeMethodAccessorImpl.java:62)
    at sun.reflect.DelegatingMethodAccessorImpl.invoke(DelegatingMethodAccessorImpl.java:43)
    at java.lang.reflect.Method.invoke(Method.java:498)
    at com.intellij.ide.Bootstrap.main(Bootstrap.java:39)
    at com.intellij.idea.Main.main(Main.java:81)

This error occurred because the default configuration of the X server permissions did not allow the root to connect to it.
To verify this, we used xhost X server access control program to check the permissions.
Executing xhost with no command line arguments gave us a message indicating whether or not access control was currently enabled, followed by the list of those users allowed to connect.
For example in our case the output was as follows:


[george@bytefreaks bin]$ xhost
access control enabled, only authorized clients can connect
SI:localuser:george

To add root to the list of users that was allowed to start an X application we executed the following command:


[george@bytefreaks bin]$ xhost +si:localuser:root
localuser:root being added to access control list

Executing xhost again, we got the updated list which included the root


[george@bytefreaks bin]$ xhost
access control enabled, only authorized clients can connect
SI:localuser:root
SI:localuser:george

After this, we were able to start CLion using sudo with no problems.


[george@bytefreaks bin]$ sudo ./clion.sh

Note: This patch is not permanent, we actually execute it once at every restart of the machine.