I am working on some application using Qt 5.7.0 GCC 64bit on Linux workstation 4.4.0-36-generic #55-Ubuntu SMP Thu Aug 11 18:01:55 UTC 2016 x86_64 x86_64 x86_64 GNU/Linux which among other things shows available WiFi networks from selection, the core code is here:
void UeWiFiDiscoveryTask::run()
{
QList<QNetworkConfiguration> networksList=this->ueNetworkConfigurationManager()->allConfigurations();
QList<UeWiFiNetworkRecord*> wifiList=QList<UeWiFiNetworkRecord*>();
foreach(QNetworkConfiguration network,
networksList)
{
if(network.isValid()&&network.bearerType()==QNetworkConfiguration::BearerWLAN&&network.state()==QNetworkConfiguration::Discovered)
{
qDebug() << Q_FUNC_INFO
<< network.state();
wifiList.append(new UeWiFiNetworkRecord(new QImage(":/images/testWifi.jpg"),
network.name()));
emit this->ueSignalWiFiFound(*wifiList.last());
} // if
} // foreach
emit this->ueSignalWiFiDiscoveryFinished(wifiList);
} // run
The code runs on separated thread and it works perfectly. However, I am reading Qt Bearer Management docs and I cannot find the way, how to distinguish between Free WiFi and encrypted/protected WiFi. How do I add such functionality?
P.S.: I am aware this is how-to question and I am ready to gain some negative points, however, I've been reading the docs for several days and I am lost!
Assuming this is a system with NetworkManager then QNetworkConfiguration::identifier() will return the D-Bus ObjectPath of the NetworkManager configuration item.
I.e. you could use QtDBus to call the org.freedesktop.NetworkManager.Settings.Connection.GetSettings() method on that object which I think should include the information you are looking for
Related
I am writing a grpc based server and client. Server is running on linux and client is running on windows.
I am trying to handle the scenario when the server is not started but the client is up.
auto state = m_channel->GetState(true);
while (state != GRPC_CHANNEL_READY || state != GRPC_CHANNEL_SHUTDOWN)
{
std::chrono::time_point deadline = std::chrono::system_clock::now() + std::chrono::seconds(30);
if (m_channel->WaitForStateChange(state, deadline))
{
std::cout << "new state is: " << static_cast<int>(state) << "\n";
state = m_channel->GetState(true);
}
}
When I run, this it fails with this error:
**
I0929 22:24:05.748000000 14812 subchannel.cc:905] subchannel 0123CF78 {address=ipv4:192.168.175.130:40051, args={grpc.client_channel_factory=0x121dd68, grpc.default_authority=192.168.175.130:40051, grpc.internal.channel_credentials=0x121dce8, grpc.internal.security_connector=0x1235f28, grpc.internal.subchannel_pool=0x1225db0, grpc.max_receive_message_length=-1, grpc.primary_user_agent=grpc-c++/1.49.0-dev, grpc.resource_quota=0x1225990, grpc.server_uri=dns:///192.168.175.130:40051}}: connect failed (UNAVAILABLE:WSA Error {syscall:"ConnectEx", os_error:"No connection could be made because the target machine actively refused it.\r\n", grpc_status:14, wsa_error:10061, created_time:"2022-09-29T20:24:05.748604482+00:00"}), backing off for -1057 ms
**
Where as when I run the client on linux, I see it properly waiting till the server is up and running.
Is there a specific firewall setting that is needed for windows ?
Interesting thing to notice is the back off time is in -ve, where as on linux, it is a +ve value and increases as per the backoff strategy.
The issue is fixed, when I started using grpc conan-package to build the server and client instead of locally built grpc from source. I believe some mistakes were made while building grpc locally from source.
I did not get time to look in details for the root cause it.
I need to use Peak System PCAN USB dongle in my Qt6 application.
At first I checked it works from command line.
In my Ubuntu 20.04 I have the kernel drivers installed:
$ grep PEAK_ /boot/config-`uname -r`
CONFIG_CAN_PEAK_PCIEFD=m
CONFIG_CAN_PEAK_PCI=m
CONFIG_CAN_PEAK_PCIEC=y
CONFIG_CAN_PEAK_PCMCIA=m
CONFIG_CAN_PEAK_USB=m
and loaded:
$ lsmod | grep ^peak
peak_usb 49152 0
I also tried to exchange data with can-tools and it worked out of the box.
Here the relevant output of the ip command:
$ ip addr
6: can0: <NOARP,ECHO> mtu 16 qdisc pfifo_fast state DOWN group default qlen 10
link/can
The problem arises when I try to connect from the Qt application:
std::unique_ptr<QCanBusDevice> _device;
QString errorString;
_device.reset(QCanBus::instance()->createDevice("peakcan", "can0", &errorString));
I get:
qt.canbus.plugins.peakcan: Cannot load library pcanbasic: (pcanbasic: cannot open shared object file: No such file or directory)
So I downloaded the PCAN Basic package.
In the readme there are the requirements:
System Requirements
-------------------
- PCAN Linux Driver: 8.0.17 and above
(Driver for Linux can be download at www.peak-system.com/linux)
So I compiled and installed the drivers. Now the peakcan plugin is found:
qt.canbus.plugins.peakcan: Using PCAN-API version: 4.5.2.15
but now:
no device is discovered by Qt
ip addr shows no can devices
lsmod | grep ^peak shows no drivers loaded
Question #1: am I missing anything in order to get it works?
By the way, in the Linux driver page they also state:
The CAN interfaces are then accessed via the common SocketCAN framework as network devices
Hence I tried to find any available device using socketcan:
QString errorString;
const QList<QCanBusDeviceInfo> devices = QCanBus::instance()->availableDevices(QStringLiteral("socketcan"), &errorString);
if (!errorString.isEmpty()) qDebug() << errorString;
foreach (QCanBusDeviceInfo info, devices)
{
qDebug() << info.name();
}
but it finds no devices.
If I try to connect to it:
std::unique_ptr<QCanBusDevice> _device;
QString errorString;
_device.reset(QCanBus::instance()->createDevice("socketcan", "can0", &errorString));
I get:
RTNETLINK answers: Operation not permitted
I guess because I'm running the application with user privileges.
I get the same error if I try to bring the interface up without sudo:
$ ip link set can0 up
RTNETLINK answers: Operation not permitted
Question #2: Is there any group I need to join to in order to let Qt6 to bring up the network device without root privileges?
I'm using .NET Core on an embedded Linux platform with good success so far. I just ran into a problem with trying to open a tty device in raw (noncanonical mode) though. If I was using regular C or C++ I would call cfmakeraw() after opening the device, but how do I do that from a .NET Core app?
The device I need to work with is a CDC ACM function driver for the USB client connector, i.e. it's a virtual COM port. It appears in my system as /dev/ttyGS0. I can open the device and then read from it and write to it using this code:
FileStream vcom = new FileStream("/dev/ttyGS0", FileMode.Open);
Because the tty device opens in canonical mode by default I don't receive any characters until the user sends the carriage return character at the end of the line of text. I need to receive each character as it is sent, rather than waiting untill the carriage return is sent, i.e. I need to use raw mode for the tty device.
The code below does not work because .NET Core does not realize that this device is a virtual serial port, so it throws an exception when I try to open it this way. When I open the real UART devices using SerialPort then they do behave in raw mode as expected.
SerialPort serialPort = new SerialPort("/dev/ttyGS0);
Since you have a terminal device, you could try to alter its termios configuration prior to actually using it.
Try issuing the shell command stty -F /dev/ttyGS0 raw before you run your program.
The raw setting will make the following termios changes (according to the stty man page) for noncanonical mode:
-ignbrk -brkint -ignpar -parmrk -inpck -istrip -inlcr -igncr -icrnl -ixon -ixany -ixoff -imaxbel
-opost
-icanon -isig -xcase -iuclc
min 1 time 0
Note that no c_cflag attributes (e.g. baudrate, parity, character size) nor echo attributes (as you already know) are changed by the raw setting.
For comparison the libc cfmakeraw() routine that you mention makes the following termios settings:
t->c_iflag &= ~(IGNBRK|BRKINT|PARMRK|ISTRIP|INLCR|IGNCR|ICRNL|IXON);
t->c_oflag &= ~OPOST;
t->c_lflag &= ~(ECHO|ECHONL|ICANON|ISIG|IEXTEN);
t->c_cflag &= ~(CSIZE|PARENB);
t->c_cflag |= CS8;
t->c_cc[VMIN] = 1; /* read returns when one char is available. */
t->c_cc[VTIME] = 0;
You can use stty -F /dev/ttyGS0 sane to restore the terminal to a default termios configuration.
I'm running a debian stable ThinkPad X1 (1294-3QG) with exactly three packages from squeeze-backports needed for the GraphicsModi:
initramfs-tools 0.99~bpo60+1
linux-base 3.4~bpo60+1
linux-image-3.2.0-0.bpo.2-amd64 3.2.9-1~bpo60
While running that kernel, starting for example paraview results in those errors:
Unrecognized deviceID 126
X Error: BadAlloc (insufficient resources for operation) 11
Extension: 154 (Uknown extension)
Minor opcode: 3 (Unknown request)
Resource id: 0x3200273
X Error: GLXBadContext 169
Extension: 154 (Uknown extension)
Minor opcode: 5 (Unknown request)
Resource id: 0x32002b0
paraview: ../../src/xcb_io.c:183: process_responses: Zusicherung »!(req && current_request && !(((long) (req->sequence) - (long) (current_request)) <= 0))« nicht erfüllt.
Somewhere on the net, I found the hint to offer the memory settings in the xorg.conf, but that did not solve my problem.
Starting within the current stable kernel works fine.
Running glxgearsresults similar:
Unrecognized deviceID 126
X Error of failed request: BadAlloc (insufficient resources for operation)
Major opcode of failed request: 154 (GLX)
Minor opcode of failed request: 3 (X_GLXCreateContext)
Serial number of failed request: 27
Current serial number in output stream: 29
I further tried, to solve the problem by updating xserver-xorg-video-intel (and all dependencies libdrm-intel1 libxfont1, xserver-common, xserver-xorg, xserver-xorg-core, xserver-xorg-input-evdev, xserver-xorg-video-fbdev and xserver-xorg-video-vesa) to backports, but that was not prosperous.
Additional, I found the entry
[drm] MTRR allocation failed. Graphics performance may suffer.
in the output of dmesg.
I had the same issue on self-made server station with Intel i7 2700k (which has Intel HD 3000) running Debian Stable 6.0.4 (squeeze) x64. Basically I knew that this platform has loads of problems with unix systems (as always intel GPU does), but it purpose is server, so on-board graphic is fair enough for that. Anyways I wanted someday to run just a move (on TV connected via HDMI*/VGA), so I installed gnome-core with gdm3 to run manually.
With kernel 2.6.32-5-amd64 everything was excellent, besides few things, which forced me to upgrade kernel:
SSD support (added & improved from linux-image-2.6.33)
HDMI - no devices was recognized, couldn't add & change resolution (cvt xrandr).
So I added squeeze-backports to sources.list and upgraded only kernel (same what you did).
After that HDMI connection works great, but I noticed slow refresh rate - tearing during loading gdm3 login screen and after. I checked dmesg and kernel messages for some infos
cat dmesg | grep failed && cat dmesg | grep drm && cat /var/log/messages | grep failed && cat /var/log/messages | grep drm - found same. Than I run glxgears and found same error.
I was digging net for few days after some solutions and ideas.
Found many useless things about allocating RAM (enable_mtrr_cleanup) etc.
Basically for my hardly ever cinematic needs it wasn't tragedy, but I like when everything is perfect, so I still was working around to fix it.
And at last! Got it solved! Problem was not with the RAM or new kernel itself.
I have to mention here, that I compiled Debian kernel myself - 3.2 based on settings from previous install.
I removed also all unneeded libs for my architecture (i.e. libdrm for nvidia radeon and others - even VESA!!!)
I added just for a moment wheezy (testing) repositories, upgraded and installed new packages with dependences as root (only this ones):
echo deb http://ftp.pl.debian.org/debian/ testing main contrib non-free >> /etc/apt/sources.list
apt-get update
apt-get install --reinstall -t testing libdrm2 libdrm-intel1 xserver-xorg-video-intel xserver-xorg-core libgl1-mesa-glx libgl1-mesa-dri mesa-utils
dpkg-reconfigure xserver-xorg
That fixed all problems with rendering and allocation on Intel GPU :)
Think it should works for you and everyone with Intel GPU-s. Don't forget to remove wheeze (testing) from sources.list when you are done.
Regards, T_Send.
I solved it now on my own by updating some mesa concerning packages. I'm running debian stable with those following packages from backports:
initramfs-tools, libdrm-intel1, libgl1-mesa-dev, libgl1-mesa-dri,
libgl1-mesa-glx, linux-base, linux-headers-3.2.0-0.bpo.1-all-amd64,
linux-headers-3.2.0-0.bpo.1-amd64, linux-headers-3.2.0-0.bpo.1-common,
linux-headers-3.2.0-0.bpo.1-common-rt,
linux-headers-3.2.0-0.bpo.1-rt-amd64,
linux-headers-3.2.0-0.bpo.2-all-amd64,
linux-headers-3.2.0-0.bpo.2-amd64, linux-headers-3.2.0-0.bpo.2-common,
linux-headers-3.2.0-0.bpo.2-common-rt,
linux-headers-3.2.0-0.bpo.2-rt-amd64, linux-image-3.2.0-0.bpo.2-amd64,
linux-kbuild-3.2, mesa-common-dev
Hoping this info will help other, too.
Basically, I want to put my computer in the middle of a serial line and record the conversation going across it. I'm trying to reverse engineer this conversation and eventually emulate one end of the conversation.
Rough Diagram of what I'm trying to do:
Normally, I have this:
__________ __________
| | | |
|Device 1|<======>|Device 2|
|________| |________|
I want to do this:
__________ __________ __________
| | | | | |
|Device 1|<===>|Computer|<===>|Device 2|
|________| |________| |________|
With the computer in the middle basically bridging the connection between the two devices and logging the data that goes across.
Answers using any programming language are probably useful. Preferably I would be able to do this on either Windows or Linux (or both if someone has a general solution to this problem).
Well, a programmatic way to do it would be to just open the relevant devices, and start forwarding data between them, simultaneously saving to a file.
Most any language can do it. There are nice libraries for things like java and python.
Several implementations exist on the web, I found a python one called Telnet Serial Bridge (TSB) by googling, which would allow you to bridge connections together over ethernet, and log using telnet tools like putty.
Though in the past, I've used the java rxtx serial comm library from rxtx.qbang.org to do it myself, though I suspect there's an updated version now, or maybe something built into the JVM proper.
Adapted from an example on that site:
import gnu.io.CommPort;
import gnu.io.CommPortIdentifier;
import gnu.io.SerialPort;
import java.io.FileDescriptor;
import java.io.IOException;
import java.io.InputStream;
import java.io.OutputStream;
public class TwoWaySerialComm
{
void bridge( String portName1, String portName2 ) throws Exception
{
CommPortIdentifier portIdentifier1 = CommPortIdentifier.getPortIdentifier(portName1);
CommPortIdentifier portIdentifier2 = CommPortIdentifier.getPortIdentifier(portName2);
if ( portIdentifier1.isCurrentlyOwned() || portIdentifier2.isCurrentlyOwned())
{
System.out.println("Error: Port is currently in use");
}
else
{
CommPort commPort1 = portIdentifier1.open(this.getClass().getName(),2000);
CommPort commPort2 = portIdentifier2.open(this.getClass().getName(),2000);
if ( commPort instanceof SerialPort && commPort2 instanceof SerialPort )
{
SerialPort serialPort1 = (SerialPort) commPort1;
serialPort1.setSerialPortParams(57600,SerialPort.DATABITS_8,SerialPort.STOPBITS_1,SerialPort.PARITY_NONE);
InputStream in1 = serialPort1.getInputStream();
OutputStream out1 = serialPort1.getOutputStream();
SerialPort serialPort2 = (SerialPort) commPort2;
serialPort2.setSerialPortParams(57600,SerialPort.DATABITS_8,SerialPort.STOPBITS_1,SerialPort.PARITY_NONE);
InputStream in2 = serialPort2.getInputStream();
OutputStream out2 = serialPort2.getOutputStream();
(new Thread(new SerialReader(in1, out2))).start();
(new Thread(new SerialReader(in2, out1))).start();
}
else
{
System.out.println("Error: Only serial ports are handled by this example.");
}
}
}
/** */
public static class SerialReaderWriter implements Runnable
{
InputStream in;
OutputStream out;
public SerialReader ( InputStream in, OutputStream out )
{
this.in = in;
this.out = out;
}
public void run ()
{
byte[] buffer = new byte[1024];
int len = -1;
try
{
while ( ( len = this.in.read(buffer)) > -1 )
{
out.write(buffer,0, len);
System.out.print(new String(buffer,0,len));
}
}
catch ( IOException e )
{
e.printStackTrace();
}
}
}
public static void main ( String[] args )
{
try
{
(new TwoWaySerialComm()).bridge("COM1", "COM3");
}
catch ( Exception e )
{
// TODO Auto-generated catch block
e.printStackTrace();
}
}
}
This is a small python script to bridge between two physical ports` #!/usr/bin/python
import time, sys, serial
import collections
import re
from serial import SerialException
from termcolor import colored
SERIALPORT1 = "/dev/rfcomm0" # the default com/serial port the receiver is connected to
BAUDRATE1 = 115200 # default baud rate we talk to Moteino
SERIALPORT2 = "/dev/ttyUSB0" # the default com/serial port the receiver is connected to
BAUDRATE2 = 9600 # default baud rate we talk to Moteino
# MAIN()
if __name__ == "__main__":
try:
# open up the FTDI serial port to get data transmitted to Moteino
ser1 = serial.Serial(SERIALPORT1, BAUDRATE1, timeout=1) #timeout=0 means nonblocking
ser1.flushInput();
print "\nCOM Port [", SERIALPORT1, "] found \n"
except (IOError, SerialException) as e:
print "\nCOM Port [", SERIALPORT1, "] not found, exiting...\n"
exit(1)
try:
# open up the FTDI serial port to get data transmitted to Moteino
ser2 = serial.Serial(SERIALPORT2, BAUDRATE2, timeout=1) #timeout=0 means nonblocking
ser2.flushInput();
print "\nCOM Port [", SERIALPORT2, "] found \n"
except (IOError, SerialException) as e:
print "\nCOM Port [", SERIALPORT2, "] not found, exiting...\n"
exit(1)
try:
while 1:
ser1_waiting = ser1.inWaiting()
if ser1_waiting > 0:
#rx1 = ser1.read(ser1_waiting)
rx1 = ser1.readline()
ser2.write(rx1)
print colored(rx1, 'red')
ser2_waiting = ser2.inWaiting()
if ser2_waiting > 0:
#rx2 = ser2.read(ser2_waiting)
rx2 = ser2.readline()
ser1.write(rx2)
print rx2
except IOError:
print "Some IO Error found, exiting..." `
I can offer a solution for Windows using 2 software utilities:
TCP COM Bridge - can connect 2 COM port over internal TCP connection.
Advanced Serial Port Monitor - can monitor and record the conversation between devices.
Both utilities are here:
http://www.aggsoft.com/
Well, I'm a novice and since you didn't say anything about the platform you’re on, I'll tell you what I did, but I'll warn you in advance, this depends on software you may or may not have and this may not actually be an answer at all, so caveat lector.
My hardware is a MacBook Pro 2.4 GHZ running 10.7.5 with 4GB ram.
What I was trying to do was read the serial comm chatter from an application that was running in Wine (since the application was windows based, but I didn’t want to use windows (icky poo). Heck , I didn’t want to use mac either, but I wasn’t making the headway I wanted to in virtual linux either, add to that Ubuntu is a little weird in the direction they’ve taken with some of the nitty gritty command-line “schtuff”.
Required software to start.
Parallels Desktop Build 7.0.15107 (Might be able to do this in Virtual Box, I haven't tried)
MultiCom (Freeware By Martin Louis for Mac)
http://members.iinet.net.au/~mgl/MartysPlace/MultiCom.html
Ubuntu 8.0.4 Hardy Heron
There maybe other ways, I must have chased down about a dozen ways to do what I wanted to do and I'm not happy yet with the output so this maybe a huge waste of time.
This solution doesn't use
strace
ttysnoop
gpspipe
socat
pyserial
And to be honest, ttysnoop seemed to be exactly what I wanted, socat seemed like a distant 2nd but a little too much for a novice imo.
The problems I ran into with other clients (possibly due to my inability to figure out how to change features about com connections) had to do with blocking. What you want, when you monitor a serial port, is a non-blocking connection. So you just listen to the port chatter and don’t interfere.
If you make a connection to it with clients like...
jpnevulator
minicom
cutecom
screen, etc.
...it seems that they take over the com port and the serial port is suddenly not available for you to monitor. There must be a way to configure them so this isn’t the case but I couldn’t figure it out. Add to that the complication that if you try to monitor from the mac side what the ports in your virtual machine are doing, it’s a little stickier still or trying to use any way you can to get past this “bump” of how to send the same data to 2 serial ports. So if you're smarter than me, I invite you to please make me less dumb.
On the Mac Side…
Launch MultiCom
Set – Port A
a) Configure as a Serial
b) Serial Device /dev/cu.KeySerial (in my case, you’ll need to discover what port you need heuristically using Terminal and typing ls /dev/tty.*
c) Click “Ok” and select the enable check box.
Set – Port B
a) Socket File Server
b) Socket File : /Users/shadowwraith/Desktop/socket.txt
On Virtual Machine Side (Parallels Ubuntu 8.0.4)
a) With the VM shutdown configure add 2 serial ports that reference the same socket file as CLIENTS (not servers) by specifying the full path.
b) Enable both by selecting the check box (Note: remember as far as the VM is concerned there is no USB connection to the serial device. You’re making that connection via the MultiCom software (or someother means if you know of one, what MultiCom is doing is acting as a conduit for the single port connection to the USB serial connector then duplicating all I/O to the socket file server which all the clients can connect to which can be multiple VMs or multiple serial ports in the same VM.)
c) Boot VM and set one serial port for your program and the other serial port for your sniffing. And POOF..there you go.
See below for more technical minutia about what to do...
Linux
How to display a serial port?
dmesg | grep tty
This is what you would type in to get the sniffer to read the input assuming the serial port you chose to actively use a serial connection was on the other socketed port, ttyS0 at com 1 for instance (ttyS1 is at com 3 in this but you can figure this out by using dmesg | grep tty).
Seeing the information…
jpnevulator --ascii --timing-print --tty "/dev/ttyS1" –read
Unrelated information that you shouldn’t use, but lead-up to me understanding why it was the wrong way to do this…
How to map a com port in linux (when you’re not worried about sniffing a port or using configure to add the serial ports)?
ln -s /dev/ttyUSB0 com3
To undo this type
unlink com3
Where ttyUSB0 is the port found from dmesg | grp tty and com3 is the desired port for Wine. This is done in the ~/.wine/dosdevices directory.
For example take a cable from rx/tx of devices to the computer com port rx pin and run a terminal or serial port logger. Just that.