Cannot unsubscribe
Hello all. Our institution DNS as changed due to legal requirments, but old is kept active with redirection to new one. So, when I send a e-mail, it is sent with new DNS. Also I'm receiving e-mails that are sent to older (probably as with this one from mailling list) due to redirection. Basically I'm receiving messages from mailing list and when I do unsubscribe, I receive e-mail like " [...] is not a member of list 'linux-wireless'". I've also contacted linux-wireless-approval@... about this issue as told on that response, but no reply so far. So, how can I unsubscribe? Thanks. BR, Mário Lopes This message was sent using IMP, the Internet Messaging Program. -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Specific tx rates with ath10k
Hi. You can change to fixed bitrate for all types of traffic for 802.11g/a modes, even on ath10k: for 2.4 GHz @ 54 Mbit/s - iw dev wiface set bitrates legacy-2.4 54 for 5 GHz @ 54 Mbit/s - iw dev wiface set bitrates legacy-5 54 Setting fixed speed for HT and VHT modes currently only takes effect on unicast traffic, I would like that this could be applied to other types of traffic in a future ath9k/ath10k driver. Quoting Ben Greear : Ath10k firmware gives ability to set specific fixed rate-control rates for beacons/mgt, multicast, broadcast, and regular traffic. The ath10k driver only sets regular traffic currently. I had previously hacked my firmware to just set all rate types when ath10k driver requested to set the rate. But, that is not what my customer needs. So, I am now planning to add some debugfs entries to allow users to set beacon/mgt, multicast and broadcast rates individually (I don't have time or interest right now to try patching things top to bottom to try to get this feature into mac80211 stack or 'iw'). My question is, for when user just runs a command like this: ./local/sbin/iw dev vap1 set bitrates legacy-2.4 6 ht-mcs-2.4 What is the desired behaviour? Set all rates (beacons/mgt, bcast, multicast, regular) to the same fixed speed, or just a certain subset of these traffic types? I can make my firmware do whatever combination is required, and then users can over-ride the values by using debugfs. As a note, ath10k firmware will NOT send beacons at HT speeds, so if you fix an HT rate, then firmware will ignore that for the beacons/mgt ratecontrol type. Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html This message was sent using IMP, the Internet Messaging Program. -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Specific tx rates with ath10k
Not on that specific setup. I'm using OpenWRT (ath9k & ath10k) and Ubuntu 14 (ath9k only). There are some equipment that send broadcast traffic as unicast in order to reduce airtime. I don't know which, just remembered about that on some published papers. I would be very usefull to transmit broadcast traffic as real broadcast traffic at HT/VHT speeds in order to reduce air time, which speed is based on last sent unicast frame speed or build a pessimist rate adaptation algoritm with a sort of link with rate adaptation algoritm used for unicast traffic. Quoting Ben Greear : On 03/13/2015 02:37 AM, Mário Lopes wrote: Hi. You can change to fixed bitrate for all types of traffic for 802.11g/a modes, even on ath10k: for 2.4 GHz @ 54 Mbit/s - iw dev wiface set bitrates legacy-2.4 54 for 5 GHz @ 54 Mbit/s - iw dev wiface set bitrates legacy-5 54 Have you actually tried this with an ath10k AP and seen that beacons and broadcast go out at 54Mbps? If so, please let me know what firmware version you are using. Setting fixed speed for HT and VHT modes currently only takes effect on unicast traffic, I would like that this could be applied to other types of traffic in a future ath9k/ath10k driver. I know beacons won't go out at HT speeds, at least not with the logic that I tried in the firmware...but I have not checked to see if my patch allows setting broadcast to HT speeds Thanks, Ben Quoting Ben Greear : Ath10k firmware gives ability to set specific fixed rate-control rates for beacons/mgt, multicast, broadcast, and regular traffic. The ath10k driver only sets regular traffic currently. I had previously hacked my firmware to just set all rate types when ath10k driver requested to set the rate. But, that is not what my customer needs. So, I am now planning to add some debugfs entries to allow users to set beacon/mgt, multicast and broadcast rates individually (I don't have time or interest right now to try patching things top to bottom to try to get this feature into mac80211 stack or 'iw'). My question is, for when user just runs a command like this: ./local/sbin/iw dev vap1 set bitrates legacy-2.4 6 ht-mcs-2.4 What is the desired behaviour? Set all rates (beacons/mgt, bcast, multicast, regular) to the same fixed speed, or just a certain subset of these traffic types? I can make my firmware do whatever combination is required, and then users can over-ride the values by using debugfs. As a note, ath10k firmware will NOT send beacons at HT speeds, so if you fix an HT rate, then firmware will ignore that for the beacons/mgt ratecontrol type. Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html This message was sent using IMP, the Internet Messaging Program. -- Ben Greear Candela Technologies Inc http://www.candelatech.com This message was sent using IMP, the Internet Messaging Program. -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Change random waiting time between frames
Hello all. Is there a way, by changing ath9k or mac80211 code for example, in order to change random waiting time to fixed, which exists between consecutive frames sent from same AP/STA/mesh point to another? AFAIK it's called "random backoff timer". It's desired to work both on unicast and broadcast frames. Thanks for the help. BR, Mário Lopes. This message was sent using IMP, the Internet Messaging Program. -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Issue with frame injection on monitor interface (ath9k)
Hi everyone. When using frame injection over monitor interface, with handmade packet with Radiotap header + QoS + Data, at sender I capture the packet with tcpdump and it is equal to the one I sent. Although, at receiver station, the packet is diferent, FCS was recalculated or forced to active and calculated, MCS is not the one I supplied, sequence number (QoS field) is not the same, amongst other things. Also, QoS Ack policy was "No Ack" at sender (QoS Control = 0x0020), a Ack frame was transmitted to sender and the received packet arrived with QoS Control = 0x. Tested with Microtik R52n-M (AR9220) on following operating systems: - AP-STA using Ubuntu Ubuntu 14.04.1 LTS; - AdHoc using OpenWRT r43000, with kmod-ath9k version 3.10.49+2014-11-04-1 and kmod-mac80211 version 3.10.49+2014-11-04-1. Regarding to OpenWRT, this malfunction was reported here: https://dev.openwrt.org/ticket/18913 Thanks. This message was sent using IMP, the Internet Messaging Program. -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Issue with frame injection on monitor interface (ath9k)
Before trying Radiotap header approach, I did disable Ack's with iw but the transmition rate remained at basic rate (6 Mbit/s) despite forcing higher MCS with iw, so it was useless. Could be this a bug in the driver, unicast traffic sent with NoAck flag treated as a broadcast, despite higher bitrate forcing? Returning to Radiotap, what's the point of injecting a frame with radiotap header if it isn't going to be used? I didn't try all the possible combinations, but the ones I tryied, they where changed before arriving at receiver. Thanks. BR, Mário Lopes. Quoting wim torfs : On 02/19/2015 03:53 PM, Mário Lopes wrote: Hi everyone. When using frame injection over monitor interface, with handmade packet with Radiotap header + QoS + Data, at sender I capture the packet with tcpdump and it is equal to the one I sent. Although, at receiver station, the packet is diferent, FCS was recalculated or forced to active and calculated, MCS is not the one I supplied, sequence number (QoS field) is not the same, amongst other things. Also, QoS Ack policy was "No Ack" at sender (QoS Control = 0x0020), a Ack frame was transmitted to sender and the received packet arrived with QoS Control = 0x. Mario, If I'm not mistaken, the mac80211 parses your injected packet, retrieves relevant information, such as flags from the radiotap header, removes the radiotap header from your packet and then proceeds with sending the packet as any normal packet towards the radio interface. This, however, means that either the mac80211 rate control algorithm is calls or the ath9k rate control algorithm, depending on your kernel configuration. The ath9k driver uses this rate control information to compose the tx descriptor, after which the packet is handed over to the hardware. I believe it is also the hardware (transmitter side or receiver side, that I don't know), which fills in the actual rate used for the transmission in your packet, since the hardware is capable of retransmitting your packet with a lower rate when transmissions fail too much at the highest rate from the rate selection algorithm. You mentioned that you monitor interface captures the packet as you have sent it. If I remember correctly, the mac80211 forwards this packet towards the monitor interface when the tx status of ath9k has been received, so basically, you receive transmission status information, along with your originally sent packet. Sequence numbers should have been adjusted in this packet I think, however, the transmission rate will be the same as you have specified. If you would like to send at a specific rate, you would need to use the relevant iw commands to fix the transmission rate (or hack ath9k to transmit at a fixed rate). Best regards, Wim. This message was sent using IMP, the Internet Messaging Program. -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Issue with frame injection on monitor interface (ath9k)
Hi. When doing "iw dev wlan0 set noack_map 0x0009", frames are sent with "Ack Policy" set to "No Ack" (at QoS header), receiver don't ack those frames and I guess that "minstrel_ht" falls to lowest bitrate possible or it is disabled when iw command is executed. At this point, manually setting a bitrate with "iw dev wlan0 set bitrates ht-mcs-5 8" doesn't throw a error and also doesn't change bitrate to the desired one, so, it doesn't work. I partially agree with you, setting for example MCS 15 after noack_map, due to lack of acks and block acks, bitrate could be higher than expected because when transmitter is transmitting, with or without frame aggregation, it doesn't have to pass to receiver mode (hardware level), wait and process each ack/back in order to transmit the next frame or next A-MPDU/A-MSDU. Also, it is expected that modulation type change to 64-QAM with 2 streams and in practice that doesn't happen, it continues at BPSK with 1 spatial stream, probably at 802.11a because iwinfo reports 6.0 Mbit/s PHY rate. Finally, thanks for your suggestion about flags on code. BR, Mário Lopes. Quoting wim torfs : On 02/20/2015 11:11 AM, Mário Lopes wrote: Quoting wim torfs : On 02/19/2015 03:53 PM, Mário Lopes wrote: Hi everyone. When using frame injection over monitor interface, with handmade packet with Radiotap header + QoS + Data, at sender I capture the packet with tcpdump and it is equal to the one I sent. Although, at receiver station, the packet is diferent, FCS was recalculated or forced to active and calculated, MCS is not the one I supplied, sequence number (QoS field) is not the same, amongst other things. Also, QoS Ack policy was "No Ack" at sender (QoS Control = 0x0020), a Ack frame was transmitted to sender and the received packet arrived with QoS Control = 0x. Mario, If I'm not mistaken, the mac80211 parses your injected packet, retrieves relevant information, such as flags from the radiotap header, removes the radiotap header from your packet and then proceeds with sending the packet as any normal packet towards the radio interface. This, however, means that either the mac80211 rate control algorithm is calls or the ath9k rate control algorithm, depending on your kernel configuration. The ath9k driver uses this rate control information to compose the tx descriptor, after which the packet is handed over to the hardware. I believe it is also the hardware (transmitter side or receiver side, that I don't know), which fills in the actual rate used for the transmission in your packet, since the hardware is capable of retransmitting your packet with a lower rate when transmissions fail too much at the highest rate from the rate selection algorithm. You mentioned that you monitor interface captures the packet as you have sent it. If I remember correctly, the mac80211 forwards this packet towards the monitor interface when the tx status of ath9k has been received, so basically, you receive transmission status information, along with your originally sent packet. Sequence numbers should have been adjusted in this packet I think, however, the transmission rate will be the same as you have specified. If you would like to send at a specific rate, you would need to use the relevant iw commands to fix the transmission rate (or hack ath9k to transmit at a fixed rate). Before trying Radiotap header approach, I did disable Ack's with iw but the transmition rate remained at basic rate (6 Mbit/s) despite forcing higher MCS with iw, so it was useless. Could be this a bug in the driver, unicast traffic sent with NoAck flag treated as a broadcast, despite higher bitrate forcing? Returning to Radiotap, what's the point of injecting a frame with radiotap header if it isn't going to be used? I didn't try all the possible combinations, but the ones I tryied, they where changed before arriving at receiver. Thanks. BR, Mário Lopes. Mario, I don't see the relation between the disabling of acks and the rate selection. I don't have a working setup currently, so I can not test it, but fixing the rate with iw should work. See whether you did everything correctly. I don't have experience with the NoAck flag, so I cannot comment on that, however, when reflecting the standard and previous work, I don't see any reason why the driver would stick to basic rates. Possibly MPDU aggregation is disabled if the NoAck means also no block acks, but this does not prevent you to use MCS rates. Look, this is me just thinking out loud, so I might be wrong here. As regards radiotap, it does have its use. For instance, if you look into net/mac80211/tx.c and search for ieee80211_parse_tx_radiotap, you will notice that it ensures whether or not the IEEE80211_TX_INTFL_DONT_ENCRYPT and IEEE80
iw set fixed bitrate doesn't commit at 802.11n mode
Hello all. I'm working on 5 GHz band, Microtik R52n-M card and when forcing bitrate, it doesn't work for .11n mode executing the following comands: - iw dev wlan0 set noack_map 0x0009 - iw dev wlan0 set bitrates ht-mcs-5 10 No error is thrown but PHY bitrate remains at 6.0 Mbit/s. After that, I execute comand - iw dev wlan0 set bitrates legacy-5 54 and bitrate goes up to 54 Mbit/s (iperf UDP goes from 5.5 Mbit/s to 31.5Mbit/s) Doing "iw dev wlan0 set bitrates mcs-5 10" bitrate falls back to 6 Mbit/s. Tested on Ubuntu version 14.04.02 LTS x64, AP-STA mode. Thanks. This message was sent using IMP, the Internet Messaging Program. -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Why can we not set the mcast rate for AP/STA interfaces?
Ok. I was asking because some routers allow changing basicrate speed but only on 802.11a/b/g, in AP mode, not on mesh/Ad-Hoc modes. Some non-mandatory feactures can be on code of one module but not implemented in the whole process. Thanks. Quoting Ben Greear : On 03/11/2015 02:56 AM, Mário Lopes wrote: On which 802.11 amendment (a/b/g/n/ac) and driver allows you setting mcast rate for mesh and IBSS interfaces? Far as I know, some vendors send multicast traffic as unicast in order to reduce airtime. I was just looking at the kernel code, I think it was linux/net/wireless/* where the device type is made. I didn't look farther to figure out what it would take to make this work with stations or APs. Thanks, Ben Quoting Ben Greear : From looking at 3.17 code, it appears we are only supposed to set the mcast rate for mesh and IBSS interfaces? What if I want to tell an AP or station to send broadcast/multicast at a higher than default rate? Should this just be controlled by the normal 'iw setbitrates' logic? Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html This message was sent using IMP, the Internet Messaging Program. -- Ben Greear Candela Technologies Inc http://www.candelatech.com This message was sent using IMP, the Internet Messaging Program. -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
Re: Why can we not set the mcast rate for AP/STA interfaces?
On which 802.11 amendment (a/b/g/n/ac) and driver allows you setting mcast rate for mesh and IBSS interfaces? Far as I know, some vendors send multicast traffic as unicast in order to reduce airtime. Quoting Ben Greear : From looking at 3.17 code, it appears we are only supposed to set the mcast rate for mesh and IBSS interfaces? What if I want to tell an AP or station to send broadcast/multicast at a higher than default rate? Should this just be controlled by the normal 'iw setbitrates' logic? Thanks, Ben -- Ben Greear Candela Technologies Inc http://www.candelatech.com -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html This message was sent using IMP, the Internet Messaging Program. -- To unsubscribe from this list: send the line "unsubscribe linux-wireless" in the body of a message to majord...@vger.kernel.org More majordomo info at http://vger.kernel.org/majordomo-info.html
