I'm currently working on a PCIe-based Intel network card driver for my OS development project. While the driver seems to be working well, as soon as I enable INTA (IRQ 16, using the I/O APIC) I keep getting a flood of interrupts which completely blocks my kernel. These are not caused by the network card (Interrupt Cause Register is all zeroes), except in very few cases where the card actually received a packet.
Things I have tried:
Test other IRQ trigger settings - level-triggered on "low" should be correct, since in other cases nothing happens at all (network card interrupts should work).
Disable all other PCIe devices: I tried writing 0x0400 into each device's PCIe cfg space command register (set the interrupt disable flag, clear all other flags); I only excluded the network card, the video card and bridge devices. Although that operation succeeds, I am not entirely sure that this really disables the given devices, since those interrupts still occur.
Is writing 0x0400 to the command register the proper way to completely disable a PCIe device?
Related
When the device is in confirmed mode, it waits for a downlink confirmation (ACK) from the network after each uplink. If the confirmation is not received by the device, it will repeat (up to a maximum of 8 times and increasing the SF of the UL if it was lowered before) the uplink until it receives a confirmation. It may take about 30 seconds to send the 8 repetitions.
If the device does not see a confirmation and needs to send another uplink (e.g. alarm or new periodic measurement), it will send the new uplink and forget the previous one. To operate in confirmed mode, the device must be declared in confirmed mode (or ACK) on the network platform. You can activate it via the IoT configurator in the network parameters
Be aware that this operation consumes much more battery power than a traditional operation, even more, if the network quality is poor.
If the transmitter loses a lot of frames, it would be better to reposition the transmitter (if possible) or the GW (if possible) to improve the transmission rather than activating the ACK which will drain the battery faster than "expected" depending on the network condition.
Is this answer correct or not?
I am using Multipeer Connectivity Framework in my APP and its working absolutely fine but when APP is invoking any API or downloading any file from server then its delaying the response. Sometimes its failed and sometimes I am getting Time out error.
I have also checked "Network" status on xCode debug navigator and found that speed is going up and down instantly and never going beyond 6kb/s and sometimes its showing as 0 kb/s but when I disable Multipeer Connectivity then it works fine and speed going at 70kb/s too.
I have also noticed that if bluetooth is ON then its happening not with the Wifi.
Any suggestion would be really appreciable.
This is happening because when advertising, Multipeer always advertises on the wifi (there's no way to say bluetooth only). The way it advertises is by switching the wifi access mode into adhoc multiple times per second to find other peers, then switching back to AP mode (ie. resuming its connection to your wifi router). Doing this is highly disruptive to large transfers.
You have two options to fix this:
1) as soon as you can, after getting connected, call stopAdvertising(). This will stop the wifi mode from being constantly changed, and your throughput will resume at its normal rate. Warning: you cannot micro-manage this, because it takes up to 30 seconds after calling stopAdvertising() until it takes effect
2) switch from Multipeer to an alternative framework that allows you to specify bluetooth-only, and only use bluetooth. I wrote one called BluePeer which I use in my apps. It is unicast (not multicast) and supports roles like Client/Server (as well as role-less like Multipeer)
I have been beating my head on the wall with this project. I have an app built to an iPhone 5 that needs to communicate with my mac via bluetooth low-energy, and I want to do it through linux using the bluez protocol. I have my mac dual booted with ubuntu 12.04 and my iPhone app is connectible (acting as a peripheral), which I verified with lightblue. So, my question is, basically, is this possible? Will bluez support this type of connection, or will it only work if I use a dongle?
I have tried many different permutations of bluez. My linux kernel is 3.11.0. I think I am currently running bluez 4.98. I can get the hcitool to sense my app, then I use gatttool -b -I -t random which gives me the [ ][MAC.......][LE]>
then I type connect, I get
[CON][MAC.......][LE]> for about 15 seconds and then the CON goes away. That was the best I could do. Actually, at this point I'm not even getting that anymore. I'm getting any one of 3 errors. Either connection refused (111), could not create connection, or device busy (16).
Anyway, any help is appreciated!
Thanks.
To quickly answer your question, yes BlueZ DOES support pairing with iOS devices. That being said, the way Bluetooth Low Energy works is that you only need pairing if you want to perform an action on a characteristic (i.e. reading, writing, or enabling indications/notifications), and that characteristic requires pairing for that action to be performed. In other words, I think that the errors you are seeing are unrelated to pairing (since they occur before you do anything to the characteristics). I recommend that you try resetting the hci device with the command:
hciconfig hciX reset
Where hciX is the local hci device you are using.
If that doesn't work, try using #hcidump or #btmon to read the raw hci data and possibly get a clearer picture of what exactly might be happening.
If you want to make sure that you have a local hci device (and therefore meaning you wouldn't need a dongle), run the following command
hcitool dev
This should display the local hci devices. If the response is empty, that means that your Linux system is not using Apple's Bluetooth hardware, and that you probably need a dongle.
Also, watch out for other common errors, i.e. are you sure that your peripheral device is connectable, does it have proper implementation of services and characteristics, does the peripheral device have a random address (hence the -t random option?), are you sure you can see it from your linux machine (e.g. with the #hcitool lescan command), and if you are using the gatttool command correctly. There are a couple of good bluez questions on this site that might be beneficial to look at:
Using Bluetooth Low Energy from The Command Line
Bluetooth Low Energy Listening for Notifications/Indications
Raspberry Pi iBeacon Connection Timing Out
Attribute Requires Authentication Before Read/Write
Finally, when it comes to pairing, you have to increase the security level by passing "--sec-level=medium" or "--sec-level=high", e.g.
gatttool --sec-level=high -t random -b <MAC Address> --primary
or
gatttool -l high -t random -b <MAC Address> --primary
This should initiate the pairing process, and then result in a pop-window to appear asking you to accept the pairing request
I hope that this helps,
My understanding is that current WiFi driver uses rate control algorithm to choose a data rate within a small set of predetermined values to send packets over the WiFi medium. Different algorithms exist for this purpose. But how does this process work when WiFi driver decides that the connection is lost and shutdown the connection all together? Which part of the code should I read in open source WiFi driver such as MadWiFi and the likes?
The WiFi driver for your hardware which runs in Linux communicates with the WiFi chip which also runs a pretty complex firmware. The interface between the driver and the firmware is hardware specific. In some hardware the detection of connection loss events is done completely by the firmware and the driver only gets a "disconnected" event while in others the driver is also involved.
Regardless of who does what disconnection usually occurs due to either
Receiving a DEAUTH frame from the AP
Detecting too many missing beacons. Beacons are WiFi frames sent periodically by the AO (for most APs every ~100ms) . If you get too far from the AP or the AP was just powered off you stop seeing the beacons in the air and usually you'll signal disconnection or try to roam to a different AP.
Too many failures on Tx of packets (i.e. not receiving ACK frames for too much traffic)
This usually indicates that you've gone too far from the AP. It could be that you can "hear" the AP but it can't hear you already. In this case it also makes sense to signal a disconnection.
For example you can look in TI wifi driver in the Linux kernel drivers/net/wireless/ti/wlcore/events.c and the function wlcore_event_beacon_loss()
In Cfg80211 architecture, assume we are station mode.
driver call kernel API cfg80211_send_disassoc() if we received a deassoc/deauth frame.this function will notify corresponding application (ex wpa_supplicant) a disconnect event.
on another hand, when we decide to disconnect with AP, applicantion (ex wpa_supplicant) can call linux kernel API cfg80211_disconnected(), it will trigger corresponding driver ioctl function to finish disconnection task.
I have observed from a wireless packet capture in my home network that anytime my iPhone device switches from asleep to active, and it is not attached to a power source, it sends a DHCP Request. I have validated this behavior with two different iPhones (with different iOS versions). I have also tested an Android device and this does not happen.
Hence this makes me wonder why does an iPhone need to send a DHCP Request, once switched from asleep to active, if the DHCP lease has not expired? In addition, why doesn't this happen in an Android device?
I am pretty sure this is not an issue related to a bug, such as the one reported in
http://www.net.princeton.edu/apple-ios/ios41-allows-lease-to-expire-keeps-using-IP-address.html
If the device thinks it has an unexpired lease, and the device's network interface has just brought up physical LINK, then that the client should start in the DHCP INIT-REBOOT state (or even INIT state).
Alternatively, if the device thinks it has an unexpired lease, and has kept LINK up continuously since going to sleep, then the client could start in the BOUND state when awaking.
Basically the main reason that the devices react differently is the way they handle the sleep mode (most iOS will disable the wireless interface, whereas in Android it is configurable in the menu).