Re: RAL(4) together with RT28XX chipset - recurring problem
On Thu, Nov 10, 2011 at 09:43:46PM +, Stuart Henderson wrote: | sys/net80211/ieee80211_node.c r1.63 (in 5.0 but not 4.9) probably helps. Thanks for the pointer. -- Ryan Corder || () ASCII ribbon campaign ryanc at greengrey.org || /\ against HTML email http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0xBEE37813 [demime 1.01d removed an attachment of type application/pgp-signature]
Re: RAL(4) together with RT28XX chipset - recurring problem
On Mon, Nov 15, 2010 at 10:41:21AM +0100, Ing. Alexander Kr??ek wrote: | On Fri, 2010-11-12 at 21:38 +, Stuart Henderson wrote: | On 2010-11-12, David Coppa dco...@gmail.com wrote: | On Fri, Nov 12, 2010 at 4:52 PM, stolendata.net | stolen.data@gmail.com wrote: | I've been using the RAL(4) driver and a wifi card with the RT2561 | chipset (Linksys WMP54g) for a few years as my wifi access point, and | have had no problems at all. Recently I switched to an 802.11n card | with RT2860 chipset (Edimax EW-7728in) in hopes of getting some higher | transfer speeds to my server storage, only to find out that OpenBSD's | 802.11 stack doesn't have any 11n functionality at all and thusly runs | as 11g only. Since I switched to using the RT2860 chipset, first on | obsd 4.3 and currently on 4.8, I've started to experience a recurring | problem: every now and then, after disconnecting a machine from the | access point, RAL(4) will refuse further connections from that machine | (I'm not sure if it depends on the IP of the client or its MAC address | etc.), resulting in only getting a connection timed out when trying | to associate with the AP, until I down/up the RAL(4) interface or | simply restart it using /etc/netstart. [snip] | Yes, it's a known problem with table of associated clients not being | refreshed properly in our 802.11 stack. | For what I know, some dev should be working on fixing it... First off, sorry for resurrecting such and old post. Other than the following entries in the changelog, I've not heard anything on this issue: 4.8 - Added suspend/resume support for PCI ral(4) devices. 4.8 - Fixed bug in hostap mode for the Ralink RT2860, RT3090, RT3390, RT3562 chipset driver. 4.9 - Prevent run(4), rum(4), urtw(4) and ral(4) from adding timeouts if the driver is dying and improved detaching. Anyone know if there has been any work, as mentioned above, on this particular problem? thanks. ryanc -- Ryan Corder || () ASCII ribbon campaign ryanc at greengrey.org || /\ against HTML email http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0xBEE37813 [demime 1.01d removed an attachment of type application/pgp-signature]
Re: RAL(4) together with RT28XX chipset - recurring problem
sys/net80211/ieee80211_node.c r1.63 (in 5.0 but not 4.9) probably helps. On 2011-11-10, Ryan Corder ry...@greengrey.org wrote: On Mon, Nov 15, 2010 at 10:41:21AM +0100, Ing. Alexander Kr??ek wrote: | On Fri, 2010-11-12 at 21:38 +, Stuart Henderson wrote: | On 2010-11-12, David Coppa dco...@gmail.com wrote: | On Fri, Nov 12, 2010 at 4:52 PM, stolendata.net | stolen.data@gmail.com wrote: | I've been using the RAL(4) driver and a wifi card with the RT2561 | chipset (Linksys WMP54g) for a few years as my wifi access point, and | have had no problems at all. Recently I switched to an 802.11n card | with RT2860 chipset (Edimax EW-7728in) in hopes of getting some higher | transfer speeds to my server storage, only to find out that OpenBSD's | 802.11 stack doesn't have any 11n functionality at all and thusly runs | as 11g only. Since I switched to using the RT2860 chipset, first on | obsd 4.3 and currently on 4.8, I've started to experience a recurring | problem: every now and then, after disconnecting a machine from the | access point, RAL(4) will refuse further connections from that machine | (I'm not sure if it depends on the IP of the client or its MAC address | etc.), resulting in only getting a connection timed out when trying | to associate with the AP, until I down/up the RAL(4) interface or | simply restart it using /etc/netstart. [snip] | Yes, it's a known problem with table of associated clients not being | refreshed properly in our 802.11 stack. | For what I know, some dev should be working on fixing it... First off, sorry for resurrecting such and old post. Other than the following entries in the changelog, I've not heard anything on this issue: 4.8 - Added suspend/resume support for PCI ral(4) devices. 4.8 - Fixed bug in hostap mode for the Ralink RT2860, RT3090, RT3390, RT3562 chipset driver. 4.9 - Prevent run(4), rum(4), urtw(4) and ral(4) from adding timeouts if the driver is dying and improved detaching. Anyone know if there has been any work, as mentioned above, on this particular problem? thanks. ryanc -- Ryan Corder || () ASCII ribbon campaign ryanc at greengrey.org || /\ against HTML email http://pgp.mit.edu:11371/pks/lookup?op=getsearch=0xBEE37813 [demime 1.01d removed an attachment of type application/pgp-signature]
Re: RAL(4) together with RT28XX chipset - recurring problem
On Fri, 2010-11-12 at 21:38 +, Stuart Henderson wrote: On 2010-11-12, David Coppa dco...@gmail.com wrote: On Fri, Nov 12, 2010 at 4:52 PM, stolendata.net stolen.data@gmail.com wrote: I've been using the RAL(4) driver and a wifi card with the RT2561 chipset (Linksys WMP54g) for a few years as my wifi access point, and have had no problems at all. Recently I switched to an 802.11n card with RT2860 chipset (Edimax EW-7728in) in hopes of getting some higher transfer speeds to my server storage, only to find out that OpenBSD's 802.11 stack doesn't have any 11n functionality at all and thusly runs as 11g only. Since I switched to using the RT2860 chipset, first on obsd 4.3 and currently on 4.8, I've started to experience a recurring problem: every now and then, after disconnecting a machine from the access point, RAL(4) will refuse further connections from that machine (I'm not sure if it depends on the IP of the client or its MAC address etc.), resulting in only getting a connection timed out when trying to associate with the AP, until I down/up the RAL(4) interface or simply restart it using /etc/netstart. Any ideas? Anyone seen this with before with RAL(4) and/or the RT2860 family? I'm currently netstart'ing the interface every 24 hours via cron to solve the problem, but it feels like jumping through hoops, so to speak - this is after all a bug of some sort. Yes, it's a known problem with table of associated clients not being refreshed properly in our 802.11 stack. For what I know, some dev should be working on fixing it... ciao, david hmm. well, the fact that this didn't happen with RT2561 is interesting... Well, it did happen on RT2561 to me (-current, compiled all system every 1-3 weeks) every now and then (in variable interval from one day to several days), till about 1-2 months ago. So, for RT2561 it seems (to me) to be fixed, after all. PC Engines Alix 2D13 (http://www.pcengines.ch/alix2d13.htm) Tonze PC-620C (miniPCI 802.11b/g) ral0 at pci0 dev 12 function 0 Ralink RT2561S rev 0x00: irq 9, address 00:17:b7:30:41:ab ral0: MAC/BBP RT2561C, RF RT2527 ral0: flags=28943UP,BROADCAST,RUNNING,PROMISC,SIMPLEX,MULTICAST,NOINET6 mtu 1500 lladdr 00:17:b7:30:41:ab priority: 4 groups: wlan media: IEEE802.11 autoselect mode 11g hostap status: active ieee80211: nwid *** chan 7 bssid 00:17:b7:30:41:ab wpakey 0x*** wpaprotos wpa1,wpa2 wpaakms psk wpaciphers ccmp wpagroupcipher ccmp 100dBm inet ... Alexander
Re: RAL(4) together with RT28XX chipset - recurring problem
On 2010-11-15, Ing. Alexander Kr??ek mer...@gremlin.cz wrote: On Fri, 2010-11-12 at 21:38 +, Stuart Henderson wrote: On 2010-11-12, David Coppa dco...@gmail.com wrote: On Fri, Nov 12, 2010 at 4:52 PM, stolendata.net stolen.data@gmail.com wrote: I've been using the RAL(4) driver and a wifi card with the RT2561 chipset (Linksys WMP54g) for a few years as my wifi access point, and have had no problems at all. Recently I switched to an 802.11n card with RT2860 chipset (Edimax EW-7728in) in hopes of getting some higher transfer speeds to my server storage, only to find out that OpenBSD's 802.11 stack doesn't have any 11n functionality at all and thusly runs as 11g only. Since I switched to using the RT2860 chipset, first on obsd 4.3 and currently on 4.8, I've started to experience a recurring problem: every now and then, after disconnecting a machine from the access point, RAL(4) will refuse further connections from that machine (I'm not sure if it depends on the IP of the client or its MAC address etc.), resulting in only getting a connection timed out when trying to associate with the AP, until I down/up the RAL(4) interface or simply restart it using /etc/netstart. Any ideas? Anyone seen this with before with RAL(4) and/or the RT2860 family? I'm currently netstart'ing the interface every 24 hours via cron to solve the problem, but it feels like jumping through hoops, so to speak - this is after all a bug of some sort. Yes, it's a known problem with table of associated clients not being refreshed properly in our 802.11 stack. For what I know, some dev should be working on fixing it... ciao, david hmm. well, the fact that this didn't happen with RT2561 is interesting... Well, it did happen on RT2561 to me (-current, compiled all system every 1-3 weeks) every now and then (in variable interval from one day to several days), till about 1-2 months ago. So, for RT2561 it seems (to me) to be fixed, after all. ah, interesting... in that case, stolendata.net whoever you are, try pulling sys/net80211/ieee80211_ioctl.c up to -current and see if that helps at all.
Re: RAL(4) together with RT28XX chipset - recurring problem
On Fri, Nov 12, 2010 at 4:52 PM, stolendata.net stolen.data@gmail.com wrote: I've been using the RAL(4) driver and a wifi card with the RT2561 chipset (Linksys WMP54g) for a few years as my wifi access point, and have had no problems at all. Recently I switched to an 802.11n card with RT2860 chipset (Edimax EW-7728in) in hopes of getting some higher transfer speeds to my server storage, only to find out that OpenBSD's 802.11 stack doesn't have any 11n functionality at all and thusly runs as 11g only. Since I switched to using the RT2860 chipset, first on obsd 4.3 and currently on 4.8, I've started to experience a recurring problem: every now and then, after disconnecting a machine from the access point, RAL(4) will refuse further connections from that machine (I'm not sure if it depends on the IP of the client or its MAC address etc.), resulting in only getting a connection timed out when trying to associate with the AP, until I down/up the RAL(4) interface or simply restart it using /etc/netstart. Any ideas? Anyone seen this with before with RAL(4) and/or the RT2860 family? I'm currently netstart'ing the interface every 24 hours via cron to solve the problem, but it feels like jumping through hoops, so to speak - this is after all a bug of some sort. Yes, it's a known problem with table of associated clients not being refreshed properly in our 802.11 stack. For what I know, some dev should be working on fixing it... ciao, david
Re: RAL(4) together with RT28XX chipset - recurring problem
On 2010-11-12, David Coppa dco...@gmail.com wrote: On Fri, Nov 12, 2010 at 4:52 PM, stolendata.net stolen.data@gmail.com wrote: I've been using the RAL(4) driver and a wifi card with the RT2561 chipset (Linksys WMP54g) for a few years as my wifi access point, and have had no problems at all. Recently I switched to an 802.11n card with RT2860 chipset (Edimax EW-7728in) in hopes of getting some higher transfer speeds to my server storage, only to find out that OpenBSD's 802.11 stack doesn't have any 11n functionality at all and thusly runs as 11g only. Since I switched to using the RT2860 chipset, first on obsd 4.3 and currently on 4.8, I've started to experience a recurring problem: every now and then, after disconnecting a machine from the access point, RAL(4) will refuse further connections from that machine (I'm not sure if it depends on the IP of the client or its MAC address etc.), resulting in only getting a connection timed out when trying to associate with the AP, until I down/up the RAL(4) interface or simply restart it using /etc/netstart. Any ideas? Anyone seen this with before with RAL(4) and/or the RT2860 family? I'm currently netstart'ing the interface every 24 hours via cron to solve the problem, but it feels like jumping through hoops, so to speak - this is after all a bug of some sort. Yes, it's a known problem with table of associated clients not being refreshed properly in our 802.11 stack. For what I know, some dev should be working on fixing it... ciao, david hmm. well, the fact that this didn't happen with RT2561 is interesting...
