Re: patches for if_iwi and wlan for WEP mode
-- Message: 4 Date: Wed, 7 Mar 2012 10:45:11 -0800 From: Adrian Chadd adr...@freebsd.org Subject: Re: patches for if_iwi and wlan for WEP mode To: Mitsuru IWASAKI iwas...@jp.freebsd.org Cc: freebsd-current@freebsd.org, freebsd-wirel...@freebsd.org, bschm...@freebsd.org Message-ID: caj-vmomduf2ydbfjzyaxpimzutdcbbg2scuz5kcw3ze3xtt...@mail.gmail.com Content-Type: text/plain; charset=ISO-8859-1 Hi, I'd rather you didn't commit iwi_update_mcast() unless you absolutely know that the NIC doesn't need to be notified of multicast group membership changes. If so, IFF_ALLMULTI flag should be set. http://lists.freebsd.org/pipermail/svn-src-head/2010-May/016983.html AK ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: patches for if_iwi and wlan for WEP mode
Hi, I'd rather you didn't commit iwi_update_mcast() unless you absolutely know that the NIC doesn't need to be notified of multicast group membership changes. If so, please commit that as a separate fix. OK, I'd do so. I don't need mcast stuff for the time being, instead I'd check other area such as suspend/resume for the next target. Today's one at: http://people.freebsd.org/~iwasaki/iwi/iwi-20120308.diff # 2 lines fix, after all ;) Thanks! ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: patches for if_iwi and wlan for WEP mode
On 8 March 2012 09:32, Mitsuru IWASAKI iwas...@jp.freebsd.org wrote: Hi, I'd rather you didn't commit iwi_update_mcast() unless you absolutely know that the NIC doesn't need to be notified of multicast group membership changes. If so, please commit that as a separate fix. OK, I'd do so. I don't need mcast stuff for the time being, instead I'd check other area such as suspend/resume for the next target. Today's one at: http://people.freebsd.org/~iwasaki/iwi/iwi-20120308.diff # 2 lines fix, after all ;) :-) Thanks for this! Once it's done, let's sort out the multicast stuff. Either we set IFF_ALLMULTI as AK suggested or we figure out and write a proper _update_mcast() function. We can commit that as a separate patch. I found my 2945 NIC btw, so hopefully I can get some test in on saturday. Adrian ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: patches for if_iwi and wlan for WEP mode
On Wednesday, March 07, 2012 2:43:52 pm Adrian Chadd wrote: On 7 March 2012 11:17, Bernhard Schmidt bschm...@freebsd.org wrote: On Tuesday 06 March 2012 21:12:55 Adrian Chadd wrote: .. except that the default if_transmit handling breaks fragments. Sigh. So we're going to have to implement if_transmit for all net80211 drivers soon and fix fragment handling. Not saying that you are wrong, it is unrelated to the issue at hand though and I'm not even sure it can be fixed just by replacing if_transmit(). Anyways, a bug going unnoticed for 3 years or something isn't that high on my priority list. Oh, it's absolutely not a requirement here. It was more a comment that he didn't need to implement if_transmit just yet in order to fix this bug, but it's likely a good idea moving forward. I have recently acquired an iwi(4) NIC so I'll also test this out. Don't let me stop you though. :) However, you could do that by having a net80211_ifattach() type thing that sets if_transmit and invokes the driver-provided if_start. I don't think wireless devices are using multiple transmit queues in such a way that if_transmit would be a benefit, and if_start is a simpler model. -- John Baldwin ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: patches for if_iwi and wlan for WEP mode
On 8 March 2012 07:43, John Baldwin j...@freebsd.org wrote: However, you could do that by having a net80211_ifattach() type thing that sets if_transmit and invokes the driver-provided if_start. I don't think wireless devices are using multiple transmit queues in such a way that if_transmit would be a benefit, and if_start is a simpler model. THe problem is that the default if_transmit uses IFQ_ENQUEUE and the _start() versions out there use IFQ_DEQUEUE without necessarily handling fragments at all. We end up having m-m_nextpkt NULL'ed upon IFQ_ENQUEUE, thus not only making a fragment list entirely broken, the fragments themselves are actually leaked. So we end up running out of mbufs. The solution I can see working at the moment is creating if_transmit for each wireless device and correctly handling any fragments in the head mbuf before calling IFQ_DEQUEUE. Adrian ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: patches for if_iwi and wlan for WEP mode
I'd rather you file a PR first describing what you just did, then commit the fix and close the PR. OK, I've just submitted a PR. I'll follow the procedure you suggested. http://www.freebsd.org/cgi/query-pr.cgi?pr=kern/165819 Thanks ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: patches for if_iwi and wlan for WEP mode
In RELENG_7, data frame is transmitted by iwi_tx_start() like this. ether_output ether_output_frame IFQ_HANDOFF/IFQ_HANDOFF_ADJ if_start iwi_start iwi_tx_start After 8.0-RELEASE, device specific if_transmit() is called via net80211 layer. ether_output ether_output_frame if_transmit IFQ_HANDOFF/IFQ_HANDOFF_ADJ if_start ieee80211_start parent-if_transmit(ie. iwi_transmit()) There was not if_transmit method in iwi(4), so I add it. On if_qflush(), CURRENT kernel complains that `transmit and qflush must both either be set or both be NULL' from if.c. I wrote iwi_qflush(), but actually never tested it... Hmm, it still is the case for = 8 afaik, there is a default if_transmit() which is used for all wireless drivers which seems to work pretty well. That's why I'm wondering, iwi(4) would be the first driver to have it's own if_transmit() function. I'm not aware of any technical reason for adding one, or did I miss something? If not I'd rather not have one added, for sake of consistency. By your this comment, I noticed that my understanding on iwi_start() call stack 8.0 was wrong a bit, correct one is like this; ether_output ether_output_frame if_transmit IFQ_HANDOFF/IFQ_HANDOFF_ADJ if_start ieee80211_start parent-if_transmit(ie. if_transmit()) IFQ_HANDOFF/IFQ_HANDOFF_ADJ if_start iwi_start iwi_start_locked iwi_tx_start So iwi_transmit and iwi_qflush would not be necessary. Today's version of patches at: http://people.freebsd.org/~iwasaki/iwi/iwi-20120307.diff This would be the final version I hope. Thanks! ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: patches for if_iwi and wlan for WEP mode
Hi, I'd rather you didn't commit iwi_update_mcast() unless you absolutely know that the NIC doesn't need to be notified of multicast group membership changes. If so, please commit that as a separate fix. I'll look at iwi later and give you feedback on that particular change. Thanks for chasing this down! Adrian ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: patches for if_iwi and wlan for WEP mode
On Wednesday 07 March 2012 16:38:44 Mitsuru IWASAKI wrote: So iwi_transmit and iwi_qflush would not be necessary. correct Today's version of patches at: http://people.freebsd.org/~iwasaki/iwi/iwi-20120307.diff This would be the final version I hope. I gave it a quick spin, works for me. You can add Tested/Reviewed by: bschmidt if you like. Thanks! -- Bernhard ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: patches for if_iwi and wlan for WEP mode
On Tuesday 06 March 2012 21:12:55 Adrian Chadd wrote: .. except that the default if_transmit handling breaks fragments. Sigh. So we're going to have to implement if_transmit for all net80211 drivers soon and fix fragment handling. Not saying that you are wrong, it is unrelated to the issue at hand though and I'm not even sure it can be fixed just by replacing if_transmit(). Anyways, a bug going unnoticed for 3 years or something isn't that high on my priority list. -- Bernhard ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: patches for if_iwi and wlan for WEP mode
On 7 March 2012 11:17, Bernhard Schmidt bschm...@freebsd.org wrote: On Tuesday 06 March 2012 21:12:55 Adrian Chadd wrote: .. except that the default if_transmit handling breaks fragments. Sigh. So we're going to have to implement if_transmit for all net80211 drivers soon and fix fragment handling. Not saying that you are wrong, it is unrelated to the issue at hand though and I'm not even sure it can be fixed just by replacing if_transmit(). Anyways, a bug going unnoticed for 3 years or something isn't that high on my priority list. Oh, it's absolutely not a requirement here. It was more a comment that he didn't need to implement if_transmit just yet in order to fix this bug, but it's likely a good idea moving forward. I have recently acquired an iwi(4) NIC so I'll also test this out. Don't let me stop you though. :) Adrian ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: patches for if_iwi and wlan for WEP mode
On Wednesday 07 March 2012 19:45:11 Adrian Chadd wrote: Hi, I'd rather you didn't commit iwi_update_mcast() unless you absolutely know that the NIC doesn't need to be notified of multicast group membership changes. If so, please commit that as a separate fix. Oh well, iwi(4) receives multicast frames just fine, they are discarded somewhere else though last time I've checked, another offtopic issue ;) I'll look at iwi later and give you feedback on that particular change. I did look into this once for ipw it was I guess, the firmware doesn't support filtering based on addresses so everything one could achieve here is enable/disable filtering of all multicast frames. Check iwi_configuration.enable_multicast_filtering, which is a bool actually not an uint8_t. -- Bernhard ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: patches for if_iwi and wlan for WEP mode
It's on topic because he included that in his patch. :) Adrian Sent from my Palm Pre on ATamp;T On Mar 7, 2012 12:18 PM, Bernhard Schmidt lt;bschm...@freebsd.orggt; wrote: On Wednesday 07 March 2012 19:45:11 Adrian Chadd wrote: gt; Hi, gt; gt; I'd rather you didn't commit iwi_update_mcast() unless you absolutely gt; know that the NIC doesn't need to be notified of multicast group gt; membership changes. If so, please commit that as a separate fix. Oh well, iwi(4) receives multicast frames just fine, they are discarded somewhere else though last time I've checked, another offtopic issue ;) gt; I'll look at iwi later and give you feedback on that particular change. I did look into this once for ipw it was I guess, the firmware doesn't support filtering based on addresses so everything one could achieve here is enable/disable filtering of all multicast frames. Check iwi_configuration.enable_multicast_filtering, which is a bool actually not an uint8_t. -- Bernhard ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: patches for if_iwi and wlan for WEP mode
Thanks Bernhard and Adrian, I think the problem seems to be solved.
My patches set IEEE80211_NODE_ASSOCID bit only if ni-ni_associd
is set. Any suggestions on this part are welcome.
Are you sure the net80211 part is correct? It looks to me as if you
are just masking the real issue. The IEEE80211_NODE_ASSOCID flag is
ment to be used to verify that an associd has actually been set, not
doing so will break other things I guess. iwi(4) is a bit tricky in
that regard, as it sets the associd itself, check iwi_checkforqos().
I'd verify that function is actually called and if so if the parameters
are correct. I fumbled around there once, might have wrong WEP..
As you suggested, iwi_checkforqos() has problems, wrong asresp
frame parsing.
@@ -1357,8 +1365,8 @@
frm += 2;
wme = NULL;
- while (frm efrm) {
- IEEE80211_VERIFY_LENGTH(efrm - frm, frm[1], return);
+ while (efrm - frm 1) {
+ IEEE80211_VERIFY_LENGTH(efrm - frm, frm[1] + 2, return);
switch (*frm) {
case IEEE80211_ELEMID_VENDOR:
if (iswmeoui(frm))
Bacause of the condition `while (frm efrm)',
IEEE80211_VERIFY_LENGTH() was checking item length beyond the
ieee80211_frame region, and returned from iwi_checkforqos() without
setting flags, capinfo and associd!
I made above changes referring to net80211 code such as
ieee80211_sta.c.
Today's version of patches at:
http://people.freebsd.org/~iwasaki/iwi/iwi-20120306.diff
This one don't have changes on net80211 part at all.
What's the reason behing adding if_qflush()/if_transmit()?
In RELENG_7, data frame is transmitted by iwi_tx_start() like this.
ether_output
ether_output_frame
IFQ_HANDOFF/IFQ_HANDOFF_ADJ
if_start
iwi_start
iwi_tx_start
After 8.0-RELEASE, device specific if_transmit() is called via net80211 layer.
ether_output
ether_output_frame
if_transmit
IFQ_HANDOFF/IFQ_HANDOFF_ADJ
if_start
ieee80211_start
parent-if_transmit(ie. iwi_transmit())
There was not if_transmit method in iwi(4), so I add it.
On if_qflush(), CURRENT kernel complains that `transmit and qflush
must both either be set or both be NULL' from if.c.
I wrote iwi_qflush(), but actually never tested it...
From: Adrian Chadd adr...@freebsd.org
Would you please open a PR with this particular issue and then attach
the patch to it?
I prefer committing changes on iwi(4) by myself, because grimreaper@
keep giving pressure to me `Your src commit bit is still idle.' for
long time :)
I just want to stop it.
I'd rather you not commit the net80211 change until I've verified that
WEP works or doesn't work with ath(4).
Never mind, I think I don't need to touch on net80211.
Thanks!
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: patches for if_iwi and wlan for WEP mode
Hi, I'd rather you file a PR first describing what you just did, then commit the fix and close the PR. Since you've found a problem, it sounds like a great reason to open a Problem Report. :) You can then link the commit against the PR so they reference each other. I've been doing it for my ath/net80211 bugfixes, no matter how quickly I find/fix the bug. Adrian ___ freebsd-current@freebsd.org mailing list http://lists.freebsd.org/mailman/listinfo/freebsd-current To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: patches for if_iwi and wlan for WEP mode
On Tuesday 06 March 2012 18:30:46 Mitsuru IWASAKI wrote:
Thanks Bernhard and Adrian, I think the problem seems to be solved.
My patches set IEEE80211_NODE_ASSOCID bit only if ni-ni_associd
is set. Any suggestions on this part are welcome.
Are you sure the net80211 part is correct? It looks to me as if you
are just masking the real issue. The IEEE80211_NODE_ASSOCID flag is
ment to be used to verify that an associd has actually been set, not
doing so will break other things I guess. iwi(4) is a bit tricky in
that regard, as it sets the associd itself, check iwi_checkforqos().
I'd verify that function is actually called and if so if the parameters
are correct. I fumbled around there once, might have wrong WEP..
As you suggested, iwi_checkforqos() has problems, wrong asresp
frame parsing.
@@ -1357,8 +1365,8 @@
frm += 2;
wme = NULL;
- while (frm efrm) {
- IEEE80211_VERIFY_LENGTH(efrm - frm, frm[1], return);
+ while (efrm - frm 1) {
+ IEEE80211_VERIFY_LENGTH(efrm - frm, frm[1] + 2, return);
switch (*frm) {
case IEEE80211_ELEMID_VENDOR:
if (iswmeoui(frm))
Bacause of the condition `while (frm efrm)',
IEEE80211_VERIFY_LENGTH() was checking item length beyond the
ieee80211_frame region, and returned from iwi_checkforqos() without
setting flags, capinfo and associd!
I made above changes referring to net80211 code such as
ieee80211_sta.c.
Today's version of patches at:
http://people.freebsd.org/~iwasaki/iwi/iwi-20120306.diff
This one don't have changes on net80211 part at all.
Looks good to me, please get that into the tree.
What's the reason behing adding if_qflush()/if_transmit()?
In RELENG_7, data frame is transmitted by iwi_tx_start() like this.
ether_output
ether_output_frame
IFQ_HANDOFF/IFQ_HANDOFF_ADJ
if_start
iwi_start
iwi_tx_start
After 8.0-RELEASE, device specific if_transmit() is called via net80211 layer.
ether_output
ether_output_frame
if_transmit
IFQ_HANDOFF/IFQ_HANDOFF_ADJ
if_start
ieee80211_start
parent-if_transmit(ie. iwi_transmit())
There was not if_transmit method in iwi(4), so I add it.
On if_qflush(), CURRENT kernel complains that `transmit and qflush
must both either be set or both be NULL' from if.c.
I wrote iwi_qflush(), but actually never tested it...
Hmm, it still is the case for = 8 afaik, there is a default
if_transmit() which is used for all wireless drivers which seems to
work pretty well. That's why I'm wondering, iwi(4) would be the first
driver to have it's own if_transmit() function. I'm not aware of any
technical reason for adding one, or did I miss something? If not I'd
rather not have one added, for sake of consistency.
From: Adrian Chadd adr...@freebsd.org
Would you please open a PR with this particular issue and then attach
the patch to it?
I prefer committing changes on iwi(4) by myself, because grimreaper@
keep giving pressure to me `Your src commit bit is still idle.' for
long time :)
I just want to stop it.
;)
--
Bernhard
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: patches for if_iwi and wlan for WEP mode
.. except that the default if_transmit handling breaks fragments. Sigh.
So we're going to have to implement if_transmit for all net80211
drivers soon and fix fragment handling.
Adrian
On 6 March 2012 11:05, Bernhard Schmidt bschm...@freebsd.org wrote:
On Tuesday 06 March 2012 18:30:46 Mitsuru IWASAKI wrote:
Thanks Bernhard and Adrian, I think the problem seems to be solved.
My patches set IEEE80211_NODE_ASSOCID bit only if ni-ni_associd
is set. Any suggestions on this part are welcome.
Are you sure the net80211 part is correct? It looks to me as if you
are just masking the real issue. The IEEE80211_NODE_ASSOCID flag is
ment to be used to verify that an associd has actually been set, not
doing so will break other things I guess. iwi(4) is a bit tricky in
that regard, as it sets the associd itself, check iwi_checkforqos().
I'd verify that function is actually called and if so if the parameters
are correct. I fumbled around there once, might have wrong WEP..
As you suggested, iwi_checkforqos() has problems, wrong asresp
frame parsing.
@@ -1357,8 +1365,8 @@
frm += 2;
wme = NULL;
- while (frm efrm) {
- IEEE80211_VERIFY_LENGTH(efrm - frm, frm[1], return);
+ while (efrm - frm 1) {
+ IEEE80211_VERIFY_LENGTH(efrm - frm, frm[1] + 2, return);
switch (*frm) {
case IEEE80211_ELEMID_VENDOR:
if (iswmeoui(frm))
Bacause of the condition `while (frm efrm)',
IEEE80211_VERIFY_LENGTH() was checking item length beyond the
ieee80211_frame region, and returned from iwi_checkforqos() without
setting flags, capinfo and associd!
I made above changes referring to net80211 code such as
ieee80211_sta.c.
Today's version of patches at:
http://people.freebsd.org/~iwasaki/iwi/iwi-20120306.diff
This one don't have changes on net80211 part at all.
Looks good to me, please get that into the tree.
What's the reason behing adding if_qflush()/if_transmit()?
In RELENG_7, data frame is transmitted by iwi_tx_start() like this.
ether_output
ether_output_frame
IFQ_HANDOFF/IFQ_HANDOFF_ADJ
if_start
iwi_start
iwi_tx_start
After 8.0-RELEASE, device specific if_transmit() is called via net80211
layer.
ether_output
ether_output_frame
if_transmit
IFQ_HANDOFF/IFQ_HANDOFF_ADJ
if_start
ieee80211_start
parent-if_transmit(ie. iwi_transmit())
There was not if_transmit method in iwi(4), so I add it.
On if_qflush(), CURRENT kernel complains that `transmit and qflush
must both either be set or both be NULL' from if.c.
I wrote iwi_qflush(), but actually never tested it...
Hmm, it still is the case for = 8 afaik, there is a default
if_transmit() which is used for all wireless drivers which seems to
work pretty well. That's why I'm wondering, iwi(4) would be the first
driver to have it's own if_transmit() function. I'm not aware of any
technical reason for adding one, or did I miss something? If not I'd
rather not have one added, for sake of consistency.
From: Adrian Chadd adr...@freebsd.org
Would you please open a PR with this particular issue and then attach
the patch to it?
I prefer committing changes on iwi(4) by myself, because grimreaper@
keep giving pressure to me `Your src commit bit is still idle.' for
long time :)
I just want to stop it.
;)
--
Bernhard
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
patches for if_iwi and wlan for WEP mode
Hi,
I've fixed iwi(4) so that Intel(R) PRO/Wireless 2915ABG work
in WEP mode, which seems to be broken since 8.0-RELEASE.
The patches against HEAD at:
http://people.freebsd.org/~iwasaki/iwi/iwi-20120305.diff
I'm not sure that changes on ieee80211 layer are right fixes,
but all of mbufs were discarded in ieee80211_start() in WEP mode.
void
ieee80211_start(struct ifnet *ifp)
{
[snip]
if (ni-ni_associd == 0
(ni-ni_flags IEEE80211_NODE_ASSOCID)) {
IEEE80211_DISCARD_MAC(vap, IEEE80211_MSG_OUTPUT,
eh-ether_dhost, NULL,
sta not associated (type 0x%04x),
htons(eh-ether_type));
vap-iv_stats.is_tx_notassoc++;
ifp-if_oerrors++;
m_freem(m);
ieee80211_free_node(ni);
continue;
}
My patches set IEEE80211_NODE_ASSOCID bit only if ni-ni_associd
is set. Any suggestions on this part are welcome.
I'm going to commit the changes coming weekend.
Thanks!
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: patches for if_iwi and wlan for WEP mode
Hi!
(cc'ing freebsd-wireless, where we try to talk about this kind of stuff...)
On 5 March 2012 09:42, Mitsuru IWASAKI iwas...@jp.freebsd.org wrote:
Hi,
I've fixed iwi(4) so that Intel(R) PRO/Wireless 2915ABG work
in WEP mode, which seems to be broken since 8.0-RELEASE.
Thanks for looking into this!
I've not looked into ath(4) and WEP (ever, to be honest) - I really
should. I wonder if it's similarly broken. But if it isn't, ath(4)
doesn't yet use if_transmit/if_flush. That's on my TODO list (in order
to fix fragment handling, rather than WEP.)
Would you please open a PR with this particular issue and then attach
the patch to it?
I'd rather you not commit the net80211 change until I've verified that
WEP works or doesn't work with ath(4).
Thanks!
Adrian
The patches against HEAD at:
http://people.freebsd.org/~iwasaki/iwi/iwi-20120305.diff
I'm not sure that changes on ieee80211 layer are right fixes,
but all of mbufs were discarded in ieee80211_start() in WEP mode.
void
ieee80211_start(struct ifnet *ifp)
{
[snip]
if (ni-ni_associd == 0
(ni-ni_flags IEEE80211_NODE_ASSOCID)) {
IEEE80211_DISCARD_MAC(vap,
IEEE80211_MSG_OUTPUT,
eh-ether_dhost, NULL,
sta not associated (type 0x%04x),
htons(eh-ether_type));
vap-iv_stats.is_tx_notassoc++;
ifp-if_oerrors++;
m_freem(m);
ieee80211_free_node(ni);
continue;
}
My patches set IEEE80211_NODE_ASSOCID bit only if ni-ni_associd
is set. Any suggestions on this part are welcome.
I'm going to commit the changes coming weekend.
Thanks!
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
Re: patches for if_iwi and wlan for WEP mode
On Monday 05 March 2012 18:42:12 Mitsuru IWASAKI wrote:
Hi,
I've fixed iwi(4) so that Intel(R) PRO/Wireless 2915ABG work
in WEP mode, which seems to be broken since 8.0-RELEASE.
The patches against HEAD at:
http://people.freebsd.org/~iwasaki/iwi/iwi-20120305.diff
I'm not sure that changes on ieee80211 layer are right fixes,
but all of mbufs were discarded in ieee80211_start() in WEP mode.
void
ieee80211_start(struct ifnet *ifp)
{
[snip]
if (ni-ni_associd == 0
(ni-ni_flags IEEE80211_NODE_ASSOCID)) {
IEEE80211_DISCARD_MAC(vap,
IEEE80211_MSG_OUTPUT,
eh-ether_dhost, NULL,
sta not associated (type 0x%04x),
htons(eh-ether_type));
vap-iv_stats.is_tx_notassoc++;
ifp-if_oerrors++;
m_freem(m);
ieee80211_free_node(ni);
continue;
}
My patches set IEEE80211_NODE_ASSOCID bit only if ni-ni_associd
is set. Any suggestions on this part are welcome.
Are you sure the net80211 part is correct? It looks to me as if you
are just masking the real issue. The IEEE80211_NODE_ASSOCID flag is
ment to be used to verify that an associd has actually been set, not
doing so will break other things I guess. iwi(4) is a bit tricky in
that regard, as it sets the associd itself, check iwi_checkforqos().
I'd verify that function is actually called and if so if the parameters
are correct. I fumbled around there once, might have wrong WEP..
I'm going to commit the changes coming weekend.
What's the reason behing adding if_qflush()/if_transmit()?
--
Bernhard
___
freebsd-current@freebsd.org mailing list
http://lists.freebsd.org/mailman/listinfo/freebsd-current
To unsubscribe, send any mail to freebsd-current-unsubscr...@freebsd.org
