when a pcie read request is given,the FPGA will respond with a delay(due to the delay in reading from custom component in FPGA).Due to this i am getting full 'ff' most of the times. Is it posiible to make the read wait. Does this have anything to do with the pcie completion timeout value.
used the command
sudo setpci -s01:00.0 CAP_EXP+0x28.W=0x0000
i set CTO value using this in the driver
pcie_capability_clear_and_set_word(dev, PCI_EXP_DEVCTL2, PCI_EXP_DEVCTL2_COMP_TIMEOUT, 0xd);
output:
$ sudo lspci -vv -s 01:00.0 | grep -A1 DevCtl2
DevCtl2: Completion Timeout: 4s to 13s, TimeoutDis-, LTR-, OBFF Disabled
LnkCtl2: Target Link Speed: 8GT/s, EnterCompliance- SpeedDis-
Related
I have openwrt implementation on a TPLink WR902AC (pocket router)
I have a /etc/network/wireless configuration file with 10 sta configurations for connecting to AP all of which are active (option disabled '0')
This is to ensure that openwrt connects to any one of the APs configured.
Only the first 4 configured are attempted to be connected and the rest are simply ignored.
(if first 4 configured are not available the 5th one is being ignored)
I tried to identify the bottleneck.
Only first 4 wpa_supplicant instances are called as evident from these files in /tmp/run
./tmp/run/wpa_supplicant/wifi3
./tmp/run/wpa_supplicant/wifi1
./tmp/run/wpa_supplicant/wifi2
./tmp/run/wpa_supplicant/wifi0
When I disable the first one, the fifth one gets connected on reconnect with "wifi"
I tried to check the source code. I lost the track after ubus being called from wifi script.
This I believe is similar question to https://forum.openwrt.org/t/limit-on-the-number-of-wifi-ssids/63141
iw list on openwrt show me the limit.
valid interface combinations:
* #{ IBSS } <= 1, #{ managed, AP, mesh point, P2P-client, P2P-GO } <= 4,
total <= 4, #channels <= 1, STA/AP BI must match
I tried to use wpa_supplicant directly instead of depending on scripts.
wpa_supplicant -c /root/wifi0.conf -i wifi0 -s -B
wpa_supplicant -c /root/wifi1.conf -i wifi1 -s -B
wpa_supplicant -c /root/wifi2.conf -i wifi2 -s -B
wpa_supplicant -c /root/wifi3.conf -i wifi3 -s -B
wpa_supplicant -c /root/wifi4.conf -i wifi4 -s -B
wpa_supplicant -c /root/wifi5.conf -i wifi5 -s -B
This failed with "interface wifi4" not available error.
Could someone point me to the source where this hard limit is set?
Is there any way around this?
Thanks in advance.
Update:-
mt7601u based usb WiFi dongle was added to wr902ac and configured (as radio2)
This time only one is connected. If I have AP configured, sta doesn't even get connected.
so number of slots is limited. (ap counts as one slot and each sta is one slot)
The built-in 2.4 GHZ has 4 slots & 5 GHz has 8 slots.
The mt7601u based wifi has only 1 slot.
Probably there exists a usb dongle that has 8 slots. Could someone point me to the theory behind all this?
Given the following sample/simple snmpd.conf (Net-SNMP 5.7.2 on RHEL 7.4)
rwcommunity private 192.168.56.101
trapsess -Ci --clientaddr=192.168.56.128 -v 2c -c private 192.168.56.101:162
when starting a SNMP Daemon
snmpd -f -Lo -D -C -c data/snmpd_test.conf udp:192.168.56.128:161
We obtain ''Start Up'' InformRequest with IP source 192.56.168.1 instead of ...128 (WireShark snapshot below)
It is not surprising as the -D option allows us to output the debug information saying that
trace: netsnmp_config_process_memory_list(): read_config.c, 696:
read_config:mem: processing memory: clientaddr 192.168.56.128
trace: run_config_handler(): read_config.c, 562:
9:read_config:parser: clientaddr handler not registered for this time
Web sources however say:
snmp.conf
...This value is also used by snmpd when generating notifications.
snmpd.conf
trapsess [SNMPCMD_ARGS] HOST
provides a more generic mechanism for defining notification destinations.
SNMPCMD_ARGS should be the command-line options required for an equivalent
snmptrap (or snmpinform) command to send the desired notification
I read also some old threads like this one
However this option is working well with snmptrap
snmptrap -D -Lo -Ci --clientaddr=192.168.56.128 -M+path_to_my_mibs -v 2c -c private 192.168.56.101:162 "" .1.3.6.1.4.1.a.b.c.d.e.f.0 i 0
This option is also working when placed in snmp.conf ( mind there is no 'd' here ) and then it applies to snmpset and snmpget (and maybe other)
So my question is: Is it a documentation error, a bug, a misuse of the Net-SNMP stack ?
After a long struggle I may have an answer and I write a short note as I just found a trick
It seems that clientaddr is not parsed correctly wherever in the snmpd.conf
(I tried not also inside the trapsess line)
But it seems to be a valid option in the command line of snmpd
like it was a valid option in the snmptrap command line. So I assumed it could be the same parsing mechanism for both.
a condition also is that the IP addres must be valid one
which means that
snmpd -f -Lo -D -C -c data/snmpd_test.conf --clientaddr=192.168.56.128 udp:192.168.56.128:161
seems to fully solve my problem.
I will perform more tests and if accurate format this answer a little bit better but it seems a good hint.
I am trying to simulate network latency for all traffic to a certain ip/url. I tried using a proxy through Charles but the traffic is going through HTTP or SOCKS. I found some information online but it does not seem to work for me. Can anyone see what is wrong with my commands?
#enable pf
pfctl -E
#add a temporary extra ruleset (called "anchor") named "deeelay
(cat /etc/pf.conf && echo "dummynet-anchor \"deeelay\"" && echo "anchor
\"deeelay\"") | sudo pfctl -f -
#add a rule to the deeelay set to send any traffic to endpoint through new rule
echo "dummynet out proto tcp from any to myurl.com pipe 1" |
sudo pfctl -a deeelay -f -
#Add a rule to dummynet pipe 1 to delay every packet by 500ms
sudo dnctl pipe 1 config delay 500
I see this warning when I run the commands:
No ALTQ support in kernel
ALTQ related functions disabled
Is that the issue?
The problem was the proto parameter. The application is not using tcp, it is using another protocol. You can either supply all the protocols you want as a list like so:
proto { tcp udp icmp ipv6 tlsp smp }
Or you can just remove the proto parameter altogether and it will do all protocols.
I am using Gumstix overo and from the past many days I am unable to get my Wifi working correctly.
I followed the instructions from Gumstix Overo Wifi and Overo Wifi to set correct parameters in /etc/network/interfaces and /etc/wpa_supplicant.conf.
/etc/network/interfaces file:
# Wireless interfaces
auto wlan0
iface wlan0 inet dhcp
pre-up wpa_supplicant -Dwext -iwlan0 -c/etc/wpa_supplicant.conf -B
down killall -q wpa_supplicant
wpa_supplicant.conf:
ctrl_interface=/var/run/wpa_supplicant
ctrl_interface_group=0
update_config=1
eapol_version=1
ap_scan=1
fast_reauth=1
network={
ssid="xxxxxx"
proto=WPA
key_mgmt=WPA-PSK
pairwise=CCMP TKIP
group=CCMP TKIP
scan_ssid=1
psk="xxxxx"
priority=10
}
After setting up and running ifdown wlan0 && ifup wlan0 i constantly get this message:
[ 1176.528778] cfg80211: Calling CRDA to update world regulatory domain
[ 2155.687255] cfg80211: Calling CRDA to update world regulatory domain
[ 1175.293609] cfg80211: Calling CRDA to update world regulatory domain
My iwconfig:
lo no wireless extensions.
wlan0 IEEE 802.11bg ESSID:off/any
Mode:Managed Frequency:2.412 GHz Access Point: Not-Associated
Retry long limit:7 RTS thr:off Fragment thr:off
Encryption key:off
Power Management:on
My lsmod looks like this:
root#overo:~# lsmod
Module Size Used by
libertas_sdio 16484 0
libertas 99993 1 libertas_sdio
firmware_class 6920 2 libertas_sdio,libertas
ipv6 252525 22
cfg80211 172644 1 libertas
rfkill 17524 3 cfg80211
lib80211 5138 1 libertas
mt9v032 7169 1
omap3_isp 132270 0
v4l2_common 8681 2 omap3_isp,mt9v032
ads7846 10528 0
videodev 98880 3 omap3_isp,mt9v032,v4l2_common
media 12853 3 omap3_isp,mt9v032,videodev
I am using yocto project for gumstix cloned from https://github.com/gumstix/Gumstix-YoctoProject-Repo
It would be great help if I could get any inputs where I am doing wrong.
The reason for wifi drop is the Network manager. By disabling it we can run ifconfig, iwconfig without any interference from the NetworkManager.
or Another workaround is this which is quite successful:
After creating SD card with proper Image on, do not unmount the partitions.
Install a Custom systemd Service
To bring up the wireless interface on boot, you will need to create and install a custom systemd service on the microSD card.
In the rootfs partition, create a new service script:
$sudoedit /media/rootfs/etc/systemd/system/network-wireless#.service
Copy and paste the following into the file:
Description=Wireless network connectivity (%i)
Wants=network.target
Before=network.target
BindsTo=sys-subsystem-net-devices-%i.device
After=sys-subsystem-net-devices-%i.device
[Service]
Type=oneshot
RemainAfterExit=yes
ExecStart=/sbin/ifconfig %i up
ExecStart=/usr/sbin/wpa_supplicant -B -i %i -c /etc/wpa_supplicant.conf
ExecStart=/sbin/dhclient %i
RestartSec=1min
Restart=on-failure
ExecStop=/sbin/ifconfig %i down
[Install]
WantedBy=multi-user.target
Save this file.
Because we are editing these files on a development machine, the normal systemd method of enabling services (systemctl) will not work. To enable our new service:
~ Change into the multi-user.target.wants directory on the root filesystem:
$cd /media/rootfs/etc/systemd/system/multi-user.target.wants/
~ Create a symbolic link to enable the service:
Overo Series COMs
$sudo ln -s ../network-wireless#.service network-wireless#wlan0.service
Finally, edit the wpa_supplicant configuration file:
$sudoedit /media/rootfs/etc/wpa_supplicant.conf
Change it to look like the following:
network={
ssid="Your Network's SSID"
psk="Your WPA2 Passkey"
}
Save the file.
Unmount the partitions on the microSD card.
SSH Into Your System
1) If you don't know the ip $ssh root#overo.local
2) If you know the IP address $ssh root#192.xx.xx.xx.local
I have an XMEGA-A1 Xplained and a JTAG ICE mkII. I just tried to use avrdude on Linux. The first thing I did was to try to set the JTAG fuse off to use PDI (since the Hardware User's Guide said JTAG and PDI can't be used together - section 9.3), but now all I have is 8 rapidly flashing LEDs and no ability to communicate with the device. The LED by the USB connector is solid green/red, though the red flashes when you replug the USB. If I press SW0, the LEDs stop flashing, but they start again as soon as I let go, and pressing any of the 7 other buttons seems to have no effect.
When I try to communicate with the device now, all I get is:
$ avrdude -p x128a1 -c jtag2pdi -P usb -v
avrdude: jtagmkII_setparm(): bad response to set parameter command: RSP_FAILED
avrdude: jtagmkII_close(): bad response to GO command: RSP_ILLEGAL_EMULATOR_MODE
avrdude done. Thank you.
If I use jtag2slow (which worked before), I get:
avrdude: jtagmkII_setparm(): bad response to set parameter command: RSP_FAILED
avrdude: initialization failed, rc=-1
Double check connections and try again, or use -F to override
this check.
avrdude: jtagmkII_close(): bad response to GO command: RSP_ILLEGAL_EMULATOR_MODE
avrdude done. Thank you.
The command I used to set the fuses was taken from what Eclipse generated: -Ufuse4:w:0x1:m
Is there a way to "break into" the device and re-establish communication?
This was caused by a failure of the JTAGICE mkII to communicate over the PDI connection due to a bad connection in the (homemade) squid cable. I made a new one and all is OK. It took a bit of messing around to work out the right connections again, since no-one seems to have put the two connection tables together (i.e. the "Connecting to a PDI target" in AVR Help and "Table 4.1: Programming Headers" in the Xplained user Guide), my squid cable is all grey, and I disconnected it before writing down the connections (don't do this!). So, here it is.
How to connect XMega-A1 Xplained via PDI with JTAGICE mkII
------------------------------------------------------
| JTAGICE mkII | XMEGA-A1 Xplained |
|--------------------------------+-------------------|
| Pin | JTAG Name | Squid Colour | Pin | PDI Name |
|-----------------+--------------+-------------------|
| 2 | GND | White | 2 | GND |
| 4 | VTref | Purple | 4 | VCC |
| 6 | nSRST | Green | 6 | PCI_CLK |
| 9 | TDI | Red | 3 | PDI_DATA |
------------------------------------------------------
Setting fuses
This is mentioned in the documentation, but it's worth repeating here: once you set the JTAGEN fuse to 1 (i.e. disable JTAG) the only way to get back to JTAG is to make a PDI connection and set the fuse back to 0.
Be very careful when setting the fuse if you can't program by PDI, as if you set fuse byte 4 to 0x01, as well as setting JTAGEN, you will also disable external reset (bit 4) and be unable to use ISP programming. If you look above, you will see this is what I did.
Apparently, not all JTAGICE mkII's can do PDI (mine can), so make sure before you blow this fuse!
I had the same problem and it was induces because I was flashing the .elf file instead the .hex.
To solve it I did the next:
Disconnect the xplained usb cable in order to Unpowered the micro.
Reconnect the USB cable and as fast as you can send the command to reprogramm the micro. If someone can help is better.
It worked for me.