The WDS client mode seems to work with ATH10k, and I have the same problem without it.
My problem is not in the AP-VLAN feature. I didn't use the encryption in my test. The frames with vlan tag are not sent by ath10k wireless card, in Sta mode, AP mode, Sta + wds mode.
My PC1 sends a frame to PC2 with or without VLAN tag.
If the tag is present the frame is not sent.
If the tag is not present the frame is sent.
In my test, the frame with VLAN tag should be sent through ATH10K.
I enable the debug in ATH10k driver. The frame with the vlan tag is sent to the wireless radio card.
I check the frame dump from ath10k_htt_tx function but I didn't see any error in frame format.
I paste the dump below (the frame it is an arp frame in the vlan 6).
ath10k_pci 0000:01:00.0: htt tx flags0 37 flags1 3072 len 70 id 0 frags_paddr 06a54000, msdu_paddr 0c158c66 vdev 0 tid 16 freq 0
ath10k_pci 0000:01:00.0: htt tx msdu: 00000000: 88 03 00 00 04 f0 21 0e 38 e1 04 f0 21 18 03 a0
ath10k_pci 0000:01:00.0: htt tx msdu: 00000010: ff ff ff ff ff ff a 00 09 90 00 4a 97 aa aa
ath10k_pci 0000:01:00.0: htt tx msdu: 00000020: 03 00 00 00 81 00 00 06 08 06 00 01 08 00 06 04
ath10k_pci 0000:01:00.0: htt tx msdu: 00000030: 00 01 00 09 90 00 4a 97 c0 a8 06 fd 00 00 00 00
ath10k_pci 0000:01:00.0: htt tx msdu: 00000040: 00 00 c0 a8 06 01
Moreover, for each frame sent the Tx status from the cards will increment the failed_count counter, but I didn't know what went wrong.
Any idea ?
Regards.
Cedric.
> -----Message d'origine-----
> De : Michal Kazior [mailto:[email protected]]
> Envoyé : vendredi 5 juin 2015 07:42
> À : Cedric VONCKEN
> Cc : linux-wireless
> Objet : Re: ATH10K and VLAN
>
> On 3 June 2015 at 16:46, Cedric VONCKEN <[email protected]> wrote:
> > I'm testing to send a VLAN frame through ATH10K device.
> > I'm using compat wireless 2015-03-09 from openWRT. The ATH10K
> > firmware used is 10.2.4.45
> >
> > My test platform is:
> > Pc1 : IP 10.101.4.3 (without VLAN)
> > VLAN 1 : IP 192.168.5.1
> >
> > Equipment in AP mode. The netdev is bridged with eth0
> >
> > Equipment in client mode with WDS mode enables. The
> client is connected to the AP. The netdev is bridged with eth0.
> > AP and client use ATH10K wireless card.
> >
> > PC2: IP 10.101.4.4 (without VLAN)
> > VLAN 1 : IP 192.168.5.2
> >
> > The PC1 is connected to the equipment in AP mode and
> the PC2 is connected to the equipment in client mode.
> >
> >
> > I can ping from PC1 to PC2 without vlan (ping 10.101.4.4).
> > I cannot ping from PC1 to PC2 with VLAN.
> > With tcpdump I checked the vlan frame is sent to the netdev but
> this frame is not send to the air.
> >
> > Is it possible to send a VLAN frame through ATH10K? If no, is
> it a driver limitation or firmware limitation?
>
> I'm not sure if IFTYPE_WDS works with ath10k but IFTYPE_AP_VLAN works
> fine for me on latest github.com/kvalo/ath master branch. Can you test if
> it works with no encryption, please?
>
>
> Michał
On 5 June 2015 at 12:52, Michal Kazior <[email protected]> wrote:
> On 5 June 2015 at 12:46, voncken <[email protected]> wrote:
>>> De : [email protected] [mailto:linux-wireless-
>>> [email protected]] De la part de Michal Kazior
>>> Envoyé : vendredi 5 juin 2015 11:46
>>> À : voncken
>>> Cc : linux-wireless; [email protected]
>>> Objet : Re: ATH10K and VLAN : Frame with VLAN tag are not sent
>>>
>>> [...]
>>> >> I see no reason why this should fail. The dot1q encapsulation
>>> >> shouldn't influence how firmware behaves.. but maybe I'm wrong.
>>> >>
>>> >> It's still unclear to me what your topology looks like. Perhaps
>>> >> you're having problem with environmental configuration itself? Did
>>> >> you try other Wi-Fi device (e.g. ath9k) instead of ath10k?
>>> > Yes I tested with ath9k wireless card, the same configuration works.
>>> >
>>> > I did an interesting test. With ostinato software I generate an ICMP
>>> frame without vlan tag. I changed the ethertype in the frame.
>>> > I tried with the ethertype 0x800 (IP), 0x801, 0x8892 (PROFINET), 0x8100
>>> (dot1q), 0x0600. All frames are sent except when the ethertype is set to
>>> 0x8100. It seems the firmware do not accept the ethertype 0x8100.
>>>
>>> Interesting. This may suggest firmware actually doesn't handle dot1q VLAN
>>> tagging properly in NWifi Tx encap mode. Can you try changing it to 802.3
>>> encap and re-test, please?
>>>
>>> --- a/drivers/net/wireless/ath/ath10k/mac.c
>>> +++ b/drivers/net/wireless/ath/ath10k/mac.c
>>> @@ -3172,7 +3172,7 @@ ath10k_tx_h_get_txmode(struct ath10k *ar, struct
>>> ieee80211_vif *vif,
>>> if (ieee80211_is_data_present(fc) && sta && sta->tdls)
>>> return ATH10K_HW_TXRX_ETHERNET;
>>>
>>> - return ATH10K_HW_TXRX_NATIVE_WIFI;
>>> + return ATH10K_HW_TXRX_ETHERNET;
>>> }
>>>
>>> Note: Your backports may not have the necessary code.. In which case
>>> it'll be difficult to do this the easy way. If that's the case I suggest
>>> you get latest backports or generate them yourself from the latest
>>> kvalo/ath master.
>> I will try to change my backport. But it is not easy, because I need to use a cross-compiler. From openwrt website I can download a backport 2015-05-08. I will try to integrate it.
>>
>> Do you know how I can generate a tar file for openwrt from kale git hub?
>
> That's non-trivial as far as I understand. You could try generating a
> quilt patch in openwrt to update ath10k. Either some sort of manual
> cherry-picking of the txmode patch for ath10k or create a partial diff
> (e.g. only drivers/net/wireless/ath/ath10k) between openwrt backports
> and kvalo/ath generated backports.
I've managed to reproduce your problem in my setup.
With NWifi Txed frames with dot1Q VLAN tagging aren't even sent OTA
and are reported as not acked by firmware.
When I changed the Tx encap mode to 802.3 (ethernet) I can see frames
OTA but they are corrupted 3addr frames with invalid SA/DA addresses.
I'm guessing this is because firmware expects explicit
WMI_PEER_ADD_WDS_ENTRY_CMDID to be issued when trying too use 802.3 Tx
encap with 4addr frames.
Michał
> De : [email protected] [mailto:linux-wireless-
> [email protected]] De la part de Michal Kazior
> Envoyé : vendredi 5 juin 2015 11:46
> À : voncken
> Cc : linux-wireless; [email protected]
> Objet : Re: ATH10K and VLAN : Frame with VLAN tag are not sent
>
> [...]
> >> I see no reason why this should fail. The dot1q encapsulation
> >> shouldn't influence how firmware behaves.. but maybe I'm wrong.
> >>
> >> It's still unclear to me what your topology looks like. Perhaps
> >> you're having problem with environmental configuration itself? Did
> >> you try other Wi-Fi device (e.g. ath9k) instead of ath10k?
> > Yes I tested with ath9k wireless card, the same configuration works.
> >
> > I did an interesting test. With ostinato software I generate an ICMP
> frame without vlan tag. I changed the ethertype in the frame.
> > I tried with the ethertype 0x800 (IP), 0x801, 0x8892 (PROFINET), 0x8100
> (dot1q), 0x0600. All frames are sent except when the ethertype is set to
> 0x8100. It seems the firmware do not accept the ethertype 0x8100.
>
> Interesting. This may suggest firmware actually doesn't handle dot1q VLAN
> tagging properly in NWifi Tx encap mode. Can you try changing it to 802.3
> encap and re-test, please?
>
> --- a/drivers/net/wireless/ath/ath10k/mac.c
> +++ b/drivers/net/wireless/ath/ath10k/mac.c
> @@ -3172,7 +3172,7 @@ ath10k_tx_h_get_txmode(struct ath10k *ar, struct
> ieee80211_vif *vif,
> if (ieee80211_is_data_present(fc) && sta && sta->tdls)
> return ATH10K_HW_TXRX_ETHERNET;
>
> - return ATH10K_HW_TXRX_NATIVE_WIFI;
> + return ATH10K_HW_TXRX_ETHERNET;
> }
>
> Note: Your backports may not have the necessary code.. In which case
> it'll be difficult to do this the easy way. If that's the case I suggest
> you get latest backports or generate them yourself from the latest
> kvalo/ath master.
I will try to change my backport. But it is not easy, because I need to use a cross-compiler. From openwrt website I can download a backport 2015-05-08. I will try to integrate it.
Do you know how I can generate a tar file for openwrt from kale git hub?
Cedric
>
>
> Michał
> --
> To unsubscribe from this list: send the line "unsubscribe linux-wireless"
> in the body of a message to [email protected] More majordomo info
> at http://vger.kernel.org/majordomo-info.html
On 5 June 2015 at 11:23, voncken <[email protected]> wrote:
[...]
>> I see no reason why this should fail. The dot1q encapsulation shouldn't
>> influence how firmware behaves.. but maybe I'm wrong.
>>
>> It's still unclear to me what your topology looks like. Perhaps you're
>> having problem with environmental configuration itself? Did you try other
>> Wi-Fi device (e.g. ath9k) instead of ath10k?
> Yes I tested with ath9k wireless card, the same configuration works.
>
> I did an interesting test. With ostinato software I generate an ICMP frame without vlan tag. I changed the ethertype in the frame.
> I tried with the ethertype 0x800 (IP), 0x801, 0x8892 (PROFINET), 0x8100 (dot1q), 0x0600. All frames are sent except when the ethertype is set to 0x8100. It seems the firmware do not accept the ethertype 0x8100.
Interesting. This may suggest firmware actually doesn't handle dot1q
VLAN tagging properly in NWifi Tx encap mode. Can you try changing it
to 802.3 encap and re-test, please?
--- a/drivers/net/wireless/ath/ath10k/mac.c
+++ b/drivers/net/wireless/ath/ath10k/mac.c
@@ -3172,7 +3172,7 @@ ath10k_tx_h_get_txmode(struct ath10k *ar, struct
ieee80211_vif *vif,
if (ieee80211_is_data_present(fc) && sta && sta->tdls)
return ATH10K_HW_TXRX_ETHERNET;
- return ATH10K_HW_TXRX_NATIVE_WIFI;
+ return ATH10K_HW_TXRX_ETHERNET;
}
Note: Your backports may not have the necessary code.. In which case
it'll be difficult to do this the easy way. If that's the case I
suggest you get latest backports or generate them yourself from the
latest kvalo/ath master.
Michał
On 5 June 2015 at 12:46, voncken <[email protected]> wrote:
>> De : [email protected] [mailto:linux-wireless-
>> [email protected]] De la part de Michal Kazior
>> Envoyé : vendredi 5 juin 2015 11:46
>> À : voncken
>> Cc : linux-wireless; [email protected]
>> Objet : Re: ATH10K and VLAN : Frame with VLAN tag are not sent
>>
>> [...]
>> >> I see no reason why this should fail. The dot1q encapsulation
>> >> shouldn't influence how firmware behaves.. but maybe I'm wrong.
>> >>
>> >> It's still unclear to me what your topology looks like. Perhaps
>> >> you're having problem with environmental configuration itself? Did
>> >> you try other Wi-Fi device (e.g. ath9k) instead of ath10k?
>> > Yes I tested with ath9k wireless card, the same configuration works.
>> >
>> > I did an interesting test. With ostinato software I generate an ICMP
>> frame without vlan tag. I changed the ethertype in the frame.
>> > I tried with the ethertype 0x800 (IP), 0x801, 0x8892 (PROFINET), 0x8100
>> (dot1q), 0x0600. All frames are sent except when the ethertype is set to
>> 0x8100. It seems the firmware do not accept the ethertype 0x8100.
>>
>> Interesting. This may suggest firmware actually doesn't handle dot1q VLAN
>> tagging properly in NWifi Tx encap mode. Can you try changing it to 802.3
>> encap and re-test, please?
>>
>> --- a/drivers/net/wireless/ath/ath10k/mac.c
>> +++ b/drivers/net/wireless/ath/ath10k/mac.c
>> @@ -3172,7 +3172,7 @@ ath10k_tx_h_get_txmode(struct ath10k *ar, struct
>> ieee80211_vif *vif,
>> if (ieee80211_is_data_present(fc) && sta && sta->tdls)
>> return ATH10K_HW_TXRX_ETHERNET;
>>
>> - return ATH10K_HW_TXRX_NATIVE_WIFI;
>> + return ATH10K_HW_TXRX_ETHERNET;
>> }
>>
>> Note: Your backports may not have the necessary code.. In which case
>> it'll be difficult to do this the easy way. If that's the case I suggest
>> you get latest backports or generate them yourself from the latest
>> kvalo/ath master.
> I will try to change my backport. But it is not easy, because I need to use a cross-compiler. From openwrt website I can download a backport 2015-05-08. I will try to integrate it.
>
> Do you know how I can generate a tar file for openwrt from kale git hub?
That's non-trivial as far as I understand. You could try generating a
quilt patch in openwrt to update ath10k. Either some sort of manual
cherry-picking of the txmode patch for ath10k or create a partial diff
(e.g. only drivers/net/wireless/ath/ath10k) between openwrt backports
and kvalo/ath generated backports.
Michał
> >>> >
> >>> > I did an interesting test. With ostinato software I generate an
> >>> > ICMP
> >>> frame without vlan tag. I changed the ethertype in the frame.
> >>> > I tried with the ethertype 0x800 (IP), 0x801, 0x8892 (PROFINET),
> >>> > 0x8100
> >>> (dot1q), 0x0600. All frames are sent except when the ethertype is
> >>> set to 0x8100. It seems the firmware do not accept the ethertype
> 0x8100.
> >>>
> >>> Interesting. This may suggest firmware actually doesn't handle dot1q
> >>> VLAN tagging properly in NWifi Tx encap mode. Can you try changing
> >>> it to 802.3 encap and re-test, please?
> >>>
> >>> --- a/drivers/net/wireless/ath/ath10k/mac.c
> >>> +++ b/drivers/net/wireless/ath/ath10k/mac.c
> >>> @@ -3172,7 +3172,7 @@ ath10k_tx_h_get_txmode(struct ath10k *ar,
> >>> struct ieee80211_vif *vif,
> >>> if (ieee80211_is_data_present(fc) && sta && sta->tdls)
> >>> return ATH10K_HW_TXRX_ETHERNET;
> >>>
> >>> - return ATH10K_HW_TXRX_NATIVE_WIFI;
> >>> + return ATH10K_HW_TXRX_ETHERNET;
> >>> }
> >>>
> >>> Note: Your backports may not have the necessary code.. In which case
> >>> it'll be difficult to do this the easy way. If that's the case I
> >>> suggest you get latest backports or generate them yourself from the
> >>> latest kvalo/ath master.
> >> I will try to change my backport. But it is not easy, because I need
> to use a cross-compiler. From openwrt website I can download a backport
> 2015-05-08. I will try to integrate it.
> >>
> >> Do you know how I can generate a tar file for openwrt from kale git
> hub?
> >
> > That's non-trivial as far as I understand. You could try generating a
> > quilt patch in openwrt to update ath10k. Either some sort of manual
> > cherry-picking of the txmode patch for ath10k or create a partial diff
> > (e.g. only drivers/net/wireless/ath/ath10k) between openwrt backports
> > and kvalo/ath generated backports.
>
> I've managed to reproduce your problem in my setup.
>
> With NWifi Txed frames with dot1Q VLAN tagging aren't even sent OTA and
> are reported as not acked by firmware.
>
> When I changed the Tx encap mode to 802.3 (ethernet) I can see frames OTA
> but they are corrupted 3addr frames with invalid SA/DA addresses.
> I'm guessing this is because firmware expects explicit
> WMI_PEER_ADD_WDS_ENTRY_CMDID to be issued when trying too use 802.3 Tx
> encap with 4addr frames.
>
Thanks for these informations, but where I need to set the flag WMI_PEER_ADD_WDS_ENTRY_CMDID?
The backport 2015-05-08 should support your modification. I'm trying du compile it.
>
> Michał
On 5 June 2015 at 09:55, voncken <[email protected]> wrote:
> The WDS client mode seems to work with ATH10k, and I have the same problem without it.
> My problem is not in the AP-VLAN feature. I didn't use the encryption in my test. The frames with vlan tag are not sent by ath10k wireless card, in Sta mode, AP mode, Sta + wds mode.
>
> My PC1 sends a frame to PC2 with or without VLAN tag.
> If the tag is present the frame is not sent.
> If the tag is not present the frame is sent.
>
> In my test, the frame with VLAN tag should be sent through ATH10K.
>
> I enable the debug in ATH10k driver. The frame with the vlan tag is sent to the wireless radio card.
> I check the frame dump from ath10k_htt_tx function but I didn't see any error in frame format.
>
> I paste the dump below (the frame it is an arp frame in the vlan 6).
> ath10k_pci 0000:01:00.0: htt tx flags0 37 flags1 3072 len 70 id 0 frags_paddr 06a54000, msdu_paddr 0c158c66 vdev 0 tid 16 freq 0
> ath10k_pci 0000:01:00.0: htt tx msdu: 00000000: 88 03 00 00 04 f0 21 0e 38 e1 04 f0 21 18 03 a0
> ath10k_pci 0000:01:00.0: htt tx msdu: 00000010: ff ff ff ff ff ff a 00 09 90 00 4a 97 aa aa
> ath10k_pci 0000:01:00.0: htt tx msdu: 00000020: 03 00 00 00 81 00 00 06 08 06 00 01 08 00 06 04
> ath10k_pci 0000:01:00.0: htt tx msdu: 00000030: 00 01 00 09 90 00 4a 97 c0 a8 06 fd 00 00 00 00
> ath10k_pci 0000:01:00.0: htt tx msdu: 00000040: 00 00 c0 a8 06 01
Oh. So you actually refer to the dot1q VLAN tagging. I haven't tested
this but I would expect this to work.
> Moreover, for each frame sent the Tx status from the cards will increment the failed_count counter, but I didn't know what went wrong.
Perhaps htt tx msdu was completed with failure status code. You didn't
provide enough logs so I'm just guessing.
> Any idea ?
I see no reason why this should fail. The dot1q encapsulation
shouldn't influence how firmware behaves.. but maybe I'm wrong.
It's still unclear to me what your topology looks like. Perhaps you're
having problem with environmental configuration itself? Did you try
other Wi-Fi device (e.g. ath9k) instead of ath10k?
Michał
On 5 June 2015 at 18:26, voncken <[email protected]> wrote:
>> >>> [...]
>> >>> >> I see no reason why this should fail. The dot1q encapsulation
>> >>> >> shouldn't influence how firmware behaves.. but maybe I'm wrong.
>> >>> >>
>> >>> >> It's still unclear to me what your topology looks like. Perhaps
>> >>> >> you're having problem with environmental configuration itself?
>> >>> >> Did you try other Wi-Fi device (e.g. ath9k) instead of ath10k?
>> >>> > Yes I tested with ath9k wireless card, the same configuration
>> works.
>> >>> >
>> >>> > I did an interesting test. With ostinato software I generate an
>> >>> > ICMP
>> >>> frame without vlan tag. I changed the ethertype in the frame.
>> >>> > I tried with the ethertype 0x800 (IP), 0x801, 0x8892 (PROFINET),
>> >>> > 0x8100
>> >>> (dot1q), 0x0600. All frames are sent except when the ethertype is
>> >>> set to 0x8100. It seems the firmware do not accept the ethertype
>> 0x8100.
>> >>>
>> >>> Interesting. This may suggest firmware actually doesn't handle dot1q
>> >>> VLAN tagging properly in NWifi Tx encap mode. Can you try changing
>> >>> it to 802.3 encap and re-test, please?
>> >>>
>> >>> --- a/drivers/net/wireless/ath/ath10k/mac.c
>> >>> +++ b/drivers/net/wireless/ath/ath10k/mac.c
>> >>> @@ -3172,7 +3172,7 @@ ath10k_tx_h_get_txmode(struct ath10k *ar,
>> >>> struct ieee80211_vif *vif,
>> >>> if (ieee80211_is_data_present(fc) && sta && sta->tdls)
>> >>> return ATH10K_HW_TXRX_ETHERNET;
>> >>>
>> >>> - return ATH10K_HW_TXRX_NATIVE_WIFI;
>> >>> + return ATH10K_HW_TXRX_ETHERNET;
>> >>> }
>> >>>
>> >>> Note: Your backports may not have the necessary code.. In which case
>> >>> it'll be difficult to do this the easy way. If that's the case I
>> >>> suggest you get latest backports or generate them yourself from the
>> >>> latest kvalo/ath master.
>> >> I will try to change my backport. But it is not easy, because I need
>> to use a cross-compiler. From openwrt website I can download a backport
>> 2015-05-08. I will try to integrate it.
>> >>
>> >> Do you know how I can generate a tar file for openwrt from kale git
>> hub?
>> >
>> > That's non-trivial as far as I understand. You could try generating a
>> > quilt patch in openwrt to update ath10k. Either some sort of manual
>> > cherry-picking of the txmode patch for ath10k or create a partial diff
>> > (e.g. only drivers/net/wireless/ath/ath10k) between openwrt backports
>> > and kvalo/ath generated backports.
>>
>> I've managed to reproduce your problem in my setup.
>>
>> With NWifi Txed frames with dot1Q VLAN tagging aren't even sent OTA and
>> are reported as not acked by firmware.
>>
>> When I changed the Tx encap mode to 802.3 (ethernet) I can see frames OTA
>> but they are corrupted 3addr frames with invalid SA/DA addresses.
>> I'm guessing this is because firmware expects explicit
>> WMI_PEER_ADD_WDS_ENTRY_CMDID to be issued when trying too use 802.3 Tx
>> encap with 4addr frames.
>>
> In my compat, I intagrated the function ath10k_tx_h_get_txmode (I don't not if it is sufficient). The frame seems be formwarded (in wireshark I can see an encapsuled Ethernet frame). I will work to find where I need to add the flag WMI_PEER_ADD_WDS_ENTRY_CMDID.
I've been playing with getting 4addr + 802.1q to work. The main
problem is mac80211 doesn't tell if an interface/peer is 4addr so
driver is forced to inspect each Tx frame and infer the addressing
mode. This isn't very efficient and is pretty ugly.
I was only able to get STA+4addr+802.1q to work with some hacks. I
didn't get AP+4addr+802.1q to work yet.
Perhaps a much better solution to your problem will be to use work
done by David, see the RAW/sw crypto patch thread:
http://lists.infradead.org/pipermail/ath10k/2015-June/005393.html
You might not be interested in the sw crypto per se, but the RAW Tx
encap that comes with it is promising and if the patch goes in (or if
you apply it manually) you should be able to get your VLAN tagging to
work (with cryptmode=1 ath10k_core parameter) now at the cost of some
CPU waste and slower performance (no A-MSDU with RAW Tx encap).
Michał
> > The WDS client mode seems to work with ATH10k, and I have the
> same problem without it.
> > My problem is not in the AP-VLAN feature. I didn't use the
> encryption in my test. The frames with vlan tag are not sent by ath10k
> wireless card, in Sta mode, AP mode, Sta + wds mode.
> >
> > My PC1 sends a frame to PC2 with or without VLAN tag.
> > If the tag is present the frame is not sent.
> > If the tag is not present the frame is sent.
> >
> > In my test, the frame with VLAN tag should be sent through
> ATH10K.
> >
> > I enable the debug in ATH10k driver. The frame with the vlan
> tag is sent to the wireless radio card.
> > I check the frame dump from ath10k_htt_tx function but I didn't
> see any error in frame format.
> >
> > I paste the dump below (the frame it is an arp frame in the
> vlan 6).
> > ath10k_pci 0000:01:00.0: htt tx flags0 37 flags1 3072 len 70 id 0
> > frags_paddr 06a54000, msdu_paddr 0c158c66 vdev 0 tid 16 freq 0
> > ath10k_pci 0000:01:00.0: htt tx msdu: 00000000: 88 03 00 00 04 f0 21
> > 0e 38 e1 04 f0 21 18 03 a0 ath10k_pci 0000:01:00.0: htt tx msdu:
> > 00000010: ff ff ff ff ff ff a 00 09 90 00 4a 97 aa aa ath10k_pci
> > 0000:01:00.0: htt tx msdu: 00000020: 03 00 00 00 81 00 00 06 08 06 00
> > 01 08 00 06 04 ath10k_pci 0000:01:00.0: htt tx msdu: 00000030: 00 01
> > 00 09 90 00 4a 97 c0 a8 06 fd 00 00 00 00 ath10k_pci 0000:01:00.0: htt
> > tx msdu: 00000040: 00 00 c0 a8 06 01
>
> Oh. So you actually refer to the dot1q VLAN tagging. I haven't tested
> this but I would expect this to work.
I'm agree with you it should work, but not :-(
>
>
> > Moreover, for each frame sent the Tx status from the cards will
> increment the failed_count counter, but I didn't know what went wrong.
>
> Perhaps htt tx msdu was completed with failure status code. You didn't
> provide enough logs so I'm just guessing.
I didn't have more log on this point, I'm trying the ath10k debug, the ath10 ftrace. If you know how I can have more log on the failure, I will send these logs.
>
>
> > Any idea ?
>
> I see no reason why this should fail. The dot1q encapsulation shouldn't
> influence how firmware behaves.. but maybe I'm wrong.
>
> It's still unclear to me what your topology looks like. Perhaps you're
> having problem with environmental configuration itself? Did you try other
> Wi-Fi device (e.g. ath9k) instead of ath10k?
Yes I tested with ath9k wireless card, the same configuration works.
I did an interesting test. With ostinato software I generate an ICMP frame without vlan tag. I changed the ethertype in the frame.
I tried with the ethertype 0x800 (IP), 0x801, 0x8892 (PROFINET), 0x8100 (dot1q), 0x0600. All frames are sent except when the ethertype is set to 0x8100. It seems the firmware do not accept the ethertype 0x8100.
>
>
> Michał
> >>> [...]
> >>> >> I see no reason why this should fail. The dot1q encapsulation
> >>> >> shouldn't influence how firmware behaves.. but maybe I'm wrong.
> >>> >>
> >>> >> It's still unclear to me what your topology looks like. Perhaps
> >>> >> you're having problem with environmental configuration itself?
> >>> >> Did you try other Wi-Fi device (e.g. ath9k) instead of ath10k?
> >>> > Yes I tested with ath9k wireless card, the same configuration
> works.
> >>> >
> >>> > I did an interesting test. With ostinato software I generate an
> >>> > ICMP
> >>> frame without vlan tag. I changed the ethertype in the frame.
> >>> > I tried with the ethertype 0x800 (IP), 0x801, 0x8892 (PROFINET),
> >>> > 0x8100
> >>> (dot1q), 0x0600. All frames are sent except when the ethertype is
> >>> set to 0x8100. It seems the firmware do not accept the ethertype
> 0x8100.
> >>>
> >>> Interesting. This may suggest firmware actually doesn't handle dot1q
> >>> VLAN tagging properly in NWifi Tx encap mode. Can you try changing
> >>> it to 802.3 encap and re-test, please?
> >>>
> >>> --- a/drivers/net/wireless/ath/ath10k/mac.c
> >>> +++ b/drivers/net/wireless/ath/ath10k/mac.c
> >>> @@ -3172,7 +3172,7 @@ ath10k_tx_h_get_txmode(struct ath10k *ar,
> >>> struct ieee80211_vif *vif,
> >>> if (ieee80211_is_data_present(fc) && sta && sta->tdls)
> >>> return ATH10K_HW_TXRX_ETHERNET;
> >>>
> >>> - return ATH10K_HW_TXRX_NATIVE_WIFI;
> >>> + return ATH10K_HW_TXRX_ETHERNET;
> >>> }
> >>>
> >>> Note: Your backports may not have the necessary code.. In which case
> >>> it'll be difficult to do this the easy way. If that's the case I
> >>> suggest you get latest backports or generate them yourself from the
> >>> latest kvalo/ath master.
> >> I will try to change my backport. But it is not easy, because I need
> to use a cross-compiler. From openwrt website I can download a backport
> 2015-05-08. I will try to integrate it.
> >>
> >> Do you know how I can generate a tar file for openwrt from kale git
> hub?
> >
> > That's non-trivial as far as I understand. You could try generating a
> > quilt patch in openwrt to update ath10k. Either some sort of manual
> > cherry-picking of the txmode patch for ath10k or create a partial diff
> > (e.g. only drivers/net/wireless/ath/ath10k) between openwrt backports
> > and kvalo/ath generated backports.
>
> I've managed to reproduce your problem in my setup.
>
> With NWifi Txed frames with dot1Q VLAN tagging aren't even sent OTA and
> are reported as not acked by firmware.
>
> When I changed the Tx encap mode to 802.3 (ethernet) I can see frames OTA
> but they are corrupted 3addr frames with invalid SA/DA addresses.
> I'm guessing this is because firmware expects explicit
> WMI_PEER_ADD_WDS_ENTRY_CMDID to be issued when trying too use 802.3 Tx
> encap with 4addr frames.
>
In my compat, I intagrated the function ath10k_tx_h_get_txmode (I don't not if it is sufficient). The frame seems be formwarded (in wireshark I can see an encapsuled Ethernet frame). I will work to find where I need to add the flag WMI_PEER_ADD_WDS_ENTRY_CMDID.
Cedric.