Successfully initialized wpa_supplicant but does’t work - yocto

I'm going mad with a stupid issue I can't solve.
During the testing of my Yocto project I always used connmactl in order to connect my board to the internet.
Now I am going to release the product but before releasing I am working on an “internet connection manager”
I guess I can’t use connmanctl anymore since it consist in an interactive command (isn’t it?) so I’m going to use directly wpa_supplicant.
In my script I edit wpa_supplicant.conf as follow:
root#localhost:~# cat /etc/wpa_supplicant/wpa_supplicant.conf
ctrl_interface=/var/run/wpa_supplicant
ctrl_interface_group=0
update_config=1
bgscan=""
network={
ssid="Obi_Lan_Kenobi"
psk="TheForceIsStrongWithThisOne"
}
After that I try to start wpa_supplicant with this command:
wpa_supplicant -B -i mlan0 -c /etc/wpa_supplicant/wpa_supplicant.conf wext
as result of this command I get:
Successfully initialized wpa_supplicant
But if I try to ping google.com (or any other website) i seet that the network doesn’t work, In particular I get this message: ping: sendto: Network is unreachable
Everything is working under connmanctl, but not under wpa_supplicant.
The strange thing is that running iw command everything seems to be configurated in the right way:
root#localhost:~# iw dev mlan0 link
Connected to 56:0c:ff:37:1a:69 (on mlan0)
SSID: Obi_Lan_Kenobi
freq: 2412
RX: 32154 bytes (310 packets)
TX: 19436 bytes (128 packets)
signal: -38 dBm
rx bitrate: 1.0 MBit/s
tx bitrate: 72.2 MBit/s MCS 7 short GI
bss flags: short-preamble short-slot-time
dtim period: 2
beacon int: 100
I honestly can’t understand why.
Does anybody have a suggestion about that?

Related

Connect Retroflag GPi (Raspberry Pi Zero W) to WPA2 Enterprise

I just got my retroflag gpi case working and set up. I have one small problem though. I can't connect my Pi to my WPA2-Enterprise network. I've tried a bunch of settings in wpa_supplicant.conf but can't get it to work.
Pi Model or other hardware: Raspberry Pi Zero W & Retroflag GPi Case
Power Supply used: Retroflag GPi's inbuilt.
RetroPie Version Used: 4.6.1
Built From: https://github.com/RetroPie/RetroPie-Setup/releases/download/4.6/retropie-buster-4.6-rpi1_zero.img.gz
USB Devices connected: Retroflag GPi
Controller used: Retroflag GPi
Error messages received:
Can't see any error messages. Don't know where they appear. It just says IP-address Unkown in show ip.
Guide used: Several on Google. This one among others: https://gist.github.com/elec3647/1e223c02ef2a9a3f836db7984011b53b.
This one for documentation: https://w1.fi/cgit/hostap/plain/wpa_supplicant/wpa_supplicant.conf
File: /etc/wpa_supplicant/wpa_supplicant.conf
Attachment of config files: (wpa_supplicant.conf)
ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=netdev
update_config=1
country=SE
ap_scan=1
network={
ssid="Wifi-Name"
scan_ssid=1
identity="myusername"
password="mypassword"
key_mgmt=WPA-EAP
eap=TTLS
phase1="peapver=0 peaplabel=1"
phase2="autheap=MSCHAPV2"
}
I actually solved it just now.
For anyone wondering I managed to connect to the network on another machine (Ubuntu) and used Network Manager. I then checked the log (according to this link) with the command:
journalctl -u NetworkManager
This gave me this config for wpa_supplicant.conf:
country=SE
ctrl_interface=DIR=/var/run/wpa_supplicant GROUP=netdev
update_config=1
ap_scan=1
network={
ssid="Wifi-Name"
scan_ssid=1
bgscan="simple:30:-65:300"
key_mgmt=WPA-EAP WPA-EAP-SHA256
password="password"
eap=PEAP
fragment_size=1266
phase2="auth=MSCHAPV2"
identity="username"
proactive_key_caching=1
}
This might not work for everyone else since the configs are always different for every network. So be sure to do the same steps as I did if you can't get it to work.
So glad I finally got this, haha.

When writing message length is more than 1024B(mtu), it failed in softroce mode

When I am writing message length is more than 1024B(mtu), it failed in softroce mode, pls help check why.
Using the standard tool ib_write_lat to test:
when ib_write_lat -s 1024 -n 5
When ib_write_lat -s 1025 -n 5, it fails.
My softroce version in in Red Hat Enterprise Linux Server release 7.4 (Maipo)
Is it a bug in softroce?
No it isn't a bug. I had similar problems.
What did you configure at your interface configuration?
I expect that you have a MTU of 1500 Bytes configured (or leaved the default value), this will result in RoCE using 1024. If you configure your interface MTU to 4200 you can use the ib_write_lat command with up to 4096 bytes.
InfiniBand protocol Maximum Transmission Unit (MTU) defines several fix size MTU: 256, 512, 1024, 2048 or 4096 bytes.
RoCE based application that uses RDMA that runs over Ethernet should take into account that the RoCE MTU is smaller than the Ethernet MTU. (normally 1500 is the default).
https://community.mellanox.com/docs/DOC-1447

Cannot send command IR with HotPI

I bought a HotPi a while ago, and decided to use it. So I followed the procedure to configure the IR and after a few hours I was able to IR signals on my Raspberry 1.
But my purpose here is to send IR signals, which I tried, without any luck.
So this is the command I try to do (just for test):
irsend SEND_START devinput KEY_POWER ; sleep 3
And this is what lircd tells me:
lircd-0.9.4c[907]: Notice: accepted new client on /var/run/lirc/lircd
lircd-0.9.4c[907]: Info: Cannot configure the rc device for /dev/lirc0
lircd-0.9.4c[907]: Error: invalid send buffer
lircd-0.9.4c[907]: Error: this remote configuration cannot be used to transmit
lircd-0.9.4c[907]: Error: error processing command: SEND_START devinput KEY_POWER
lircd-0.9.4c[907]: Error: transmission failed
lircd-0.9.4c[907]: Info: removed client
Edit:
It seems I'm not using the good drivers. According to the HotPi documentation, I'm suppose to use lirc-rpi, which I'm suppos to install with
sudo modprobe lirc-rpi
Which, at least, doesn't return an error. But trying to configure the interface tells me that the driver doesn't exist:
pi#raspberrypi:~ $ mode2 --driver lirc-rpi --device /dev/lirc0
Driver `lirc-rpi' not found. (Missing -U/--plugins option?)
Available drivers:
accent
alsa_usb
asusdh
atilibusb
atwf83
audio
audio_alsa
awlibusb
bte
bw6130
commandir
creative
creative_infracd
default
devinput
dfclibusb
dsp
dvico
ea65
file
ftdi
ftdi-exp
ftdix
girs
i2cuser
irlink
irtoy
livedrive_midi
livedrive_seq
logitech
macmini
mouseremote
mouseremote_ps2
mp3anywhere
mplay
mplay2
pcmak
pinsys
pixelview
samsung
sb0540
silitek
slinke
sonyir
srm7500libusb
tira
tira_raw
udp
uirt2
uirt2_raw
usb_uirt_raw
usbx
zotac
Here is no info what lirc version you are using. There are vast differences between the legacy 0.9.0 still used in some distros and modern lirc.
That said, the logs seems pretty clear. You are using the devinput driver, right? This driver does not support sending data, reflecting the fact that also the kernel doesn't.
You then need to use another driver - first stop might be the default one. If/when using this other driver, you need another lircd.conf.
Please refer to http://lirc.org/html/configuration-guide.html
EDIT: Ah, lirc-0.9.4c says the log. Sorry, my bad. The reply should still be valid, though.
When you record the remote, use:
irrecord -d /dev/lirc0 -f name.conf
The -f uses raw mode. This then worked for me on the transmit side, before I got same error as you.

Can't use CAIDA Dataset with tcpreplay to simulate network traffic in network

I have a server and I need to simulate real network traffic. I've been asked to do this using a CAIDA Dataset. I have downloaded the public Dataset which can be found here:
CAIDA Public Dataset
I also need to rewrite the source ip address in the .pcap file to be the one of the server. I tried doing it the way it's described at the end of this page: tcprewrite wiki
I run:
tcprewrite --infile=oc48-mfn.dirA.20020814-160000.UTC.anon.pcap --outfile=oc48-mfn.dirA.20020814-160000.UTC.anon_rewrite.pcap --dstipmap=0.0.0.0/0:10.101.30.60 --enet-dmac=00:0c:29:00:b1:bd
And I get:
Warning: oc48-mfn.dirA.20020814-160000.UTC.anon.pcap was captured using a snaplen of 48 bytes. This may mean you have truncated packets.
Fatal Error: From ./plugins/dlt_hdlc/hdlc.c:dlt_hdlc_encode() line 255:
Non-HDLC packet requires --hdlc-address
So after some tries like this I finally run these to get an error free tcprewrite:
tcpprep --auto=bridge --pcap=oc48-mfn.dirA.20020814-160000.UTC.anon.pcap --cachefile=cache1.cache
Which gives:
Warning: oc48-mfn.dirA.20020814-160000.UTC.anon.pcap was captured using a snaplen of 48 bytes. This may mean you have truncated packets.
Warning: oc48-mfn.dirA.20020814-160000.UTC.anon.pcap was captured using a snaplen of 48 bytes. This may mean you have truncated packets.
And then I run:
tcprewrite --infile=oc48-mfn.dirA.20020814-160000.UTC.anon.pcap --outfile=oc48-mfn.dirA.20020814-160000.UTC.anon_rewrite.pcap --dstipmap=0.0.0.0/0:10.101.30.60 --enet-dmac=00:0c:29:00:b1:bd --cachefile=cache1.cache --hdlc-control=0 --hdlc-address=0xBF
And I get:
Warning: oc48-mfn.dirA.20020814-160000.UTC.anon.pcap was captured using a snaplen of 48 bytes. This may mean you have truncated packets.
So it seems like a success, except the warning that shows up in every command.
I open the new .pcap file with tcpdump to check that the destination IP addresses have changed to the one of the server and it has been done.
So then I run tcpreplay:
tcpreplay -i ens160 --loop 5 --unique-ip oc48-mfn.dirA.20020814-160000.UTC.anon.pcap
And I run tcpdump on the server to see the traffic from the .pcap file, but the traffic looks like this:
13:30:50.194780 05:8c:55:6f:40:00 (oui Unknown) > 0f:00:08:00:45:00 (oui
Unknown), ethertype Unknown (0x3406), length 60:
0x0000: ed11 f484 7785 f477 0d79 0050 0487 007c ....w..w.y.P...|
0x0010: e7d5 d203 c32b 5010 27f7 aa51 0000 4854 .....+P.'..Q..HT
0x0020: 5450 0000 0000 0000 0000 0000 0000 TP............
I have tried the smallFlow.pcap from the sample captures of tcpreplay: Sample Captures
and it worked just fine.
So any suggestions on how to properly use the CAIDA .pcap files?
Your stated goal is "I need to simulate real network traffic", but you're using pcaps where "the payload has been removed from all packets" (per the CAIDA web page you linked to).
These two statements are in conflict with each other. All your packets are literally no larger then 48bytes which is merely enough for the TCP/IP header (and then even so, may not be sufficient in all cases). This is what the warning is telling you. You can't put the data back.
You'll need to find a new source of pcaps.

how to record an ir signal from an AC remote using LIRC in raspberry pi?

i had already used the LIRC of the raspberry pi to record and use the IR signals of a samsung TV remote. the recording process was fine. i used this site for reference.But now i am unable to record the IR signals from a bluestar AC in the same method. After 1-3 dots (not always the same number), irrecord exits with the following error message:
irrecord: could not find gap.
irrecord: gap not found, can't continue
then i tried recording the AC remote signals using mode2 and routing it to a text file and manually modified the lircd.conf file to include the raw code as shown in the link
How to use irrecord with 2ms timing instead of the default 5ms?
but then i get the error that
irsend: command failed: SEND_ONCE /etc/lirc/lircd.conf KEY_POWER
irsend: unknown remote : "/etc/lirc/lircd.conf"
Possibly lircd doesn't accept all characters (e.g. slash) for the remote name. Try changing the:
name /etc/lirc/lircd.conf
in the .conf file to a different name (e.g. MY_REMOTE), then invoke the irsend like:
irsend SEND_ONCE MY_REMOTE KEY_POWER
The air conditioning controls send more bits than the television ones for example. You have to configure the lirc.conf header as:
begin remote
name IRAIR1
bits 48 #Configuración para 48 bits
flags SPACE_ENC
eps 30
aeps 100
header 3388 1678
one 430 1257
zero 430 412
ptrail 428
gap 108399
begin raw_codes
name KEY_POWER
3478 1676 500 1218 501 388
472 ..................................
end raw_codes
end remote
I think exactly what 48 bits are sending. This guy explains it: http://absurdlycertain.blogspot.com.es/2013/03/lirc-raspi-remote-control-configuration.html
Do not forget to restart the device, with me it does not work if I do not.
Sorry for my English