Temmuz Son Hafta Genel Katilima Acik Seminerler
tech@openbsd.org Bogazici Temmuz Son Hafta Genel Katýlýma Açýk Eðitim Seminerleri 20 Temmuz Taþeron - Alt Ýþveren - Tedarikçi Yönetiminin Hukuksal Boyutu 21-22 Temmuz Stratejik Satýnalma Yönetimi ve Modern Satýnalma Teknikleri 24 Temmuz Risk Sermayeleri, Fon Kaynaklarý ve Finansal Yönetim Süreçleri 24 Temmuz Etkin Zaman Yönetimi ile Kiþisel ve Kurumsal Dinamizm Baþarý 25 Temmuz Organizasyon ve Yönetim Planý Geliþtirme 25-26 Temmuz Þirket Alým Satým ve Evliliklerinde Deðer Tespit Analizi, Sanayi Þirketlerinde Yatýrým Geri Dönüþ Hesabý ve Fizibilite Teknikleri 26 Temmuz Yöneticiler Ýçin Finansman 28-29 Temmuz Maliyet Yönetim Muhasebesi 28-29 Temmuz Uygulamalarla Süreç Yönetimi ve Ýyileþtirme 27 Temmuz Ýnternet ve Sosyal Medyada Þirket Ýtibarý - Kurum Kimliði - Marka Korunmasý * Katilim icin kayit formu doldurulmasi ve banka makbuzu ile tarafimiza gonderilmesi gerekmektedir. * Ogle yemekleri, ara ikramlar, kongre cantalari, ilgili kitap ve tum dokumanlar ucrete dahildir. * Ramazan dolayisiyla ogle yemegine katilamayacak katilimcilar dilerlerse iftar yemegine katilabilirler. w w w b-o-s-p-h-o-r-u-s-c-o-n-f-e-r-e-n-c-e-s--c o m / 0 216 422/95/95 Guncel Zirve ve Sempozyum Programlarý 1 Tahsilat Yonetimi Zirvesi Musteri Arastirmasi, Kredi ve Risk Kriterleri Tahsilat: Isin ta kendisidir... Tahsil Edilmedikce Ne Alacak Alacak, Ne Satis Satis, Ne Musteri Musteridir! Bazen yasayakalmak yanlislardan sakinmayla ilgilidir, bazen de dogrulari yapmakla... Alev Alatli Ne yazik ki, ne zaman hangisi gecerli, hicbir zaman bilemeyecegiz; bu nedenle aslinda ikisi de ayni anda gecerli: Schrodingerin Kedisi meselesi... CORECost Reduction WorkShop Maliyet Dusurme Teknikleri Maliyet ve Degisim 2 3 Turk Ticaret Kanunu ve Is Hayatinda Degisen Uygulamalar Son Duzenlemeye Iliskin Gelismeler, Degisen Ezberler ve Alinmasi Gereken Onlemler w w w b-o-s-p-h-o-r-u-s-c-o-n-f-e-r-e-n-c-e-s--c o m / 0 216 422/95/95 Konferans 1: Tahsilat Yonetimi Zirvesi Musteri Arastirmasi, Kredi ve Risk Kriterleri Konferans 2: Maliyet Dusurme Teknikleri Maliyet ve Degisim Konferans 3: Turk Ticaret Kanunu ve Is Hayatinda Degisen Uygulamalar 26 Temmuz 2012 / 09.30-17.30 Divan Istanbul City Otel / 650 TL + KDV 8 Agustos 2012 / 09.30-17.30 Le Meridien Otel - Istanbul / 750 TL + KDV 26 Temmuz 2012 / 09.30-17.30 Divan Istanbul City Otel / 650 TL + KDV Konusmacilar: - Doc. Dr. Sevket SAYILGAN // Marmara Universitesi - Ahmet ESGIN // 4S Is Gelistirme Kocu - Koray INAN // Global Partner Finans - Semih OLGUN // Yonetim Danismani - Hicran Cigdem YORGANCIOGLU // Danisman - Vahe BAKIRCI // Yeminli Mali Musavir - Aydin GOLE // Satis ve Yonetim Danismani - Av. Ceyda CIMILLI AKAYDIN // Hukuk Danismani Konusmacilar: - Savas YETER // Inoksan Genel Muduru - Ahmet ESGIN // 4S Is Gelistirme Kocu - Kasim CAPRAZ // Bilim Musavirlik, Y K Baskani - Ozlem Pinar AYABAKAN // Erkurt Holding I.K. Md. - Hakan GUNER // Yonetim Danismani, Konusmacilar: - Dr. Veysi SEVIG - Dr. Bumin DOGRUSOZ Kapsam: Isletmelerin alacaklarinin toplam varliklar icindeki payi ve tahsilat yonetiminin onemi surekli artmaktadir. Daralan piyasa sartlarinda alacaklara yapilan yatirimlarin onemli tutarlara ulasmasi, hatta cok sayida firmada alacak tutarlarinin stoklara yapilan yatirimi asmasinin yani sira bircok iskolunda genellikle son yillarda alacaklarin satislara oraninin yukselme egilimi gostermesi de dikkatleri daha basarili bir alacak tahsilati yonetimi uzerine cekmistir. Tahsilat yonetimi cok sayida mikro/makro bilesenin kontrolunu gerektirmektedir. Programimizda, - Tahsilat zincirinin; yonetimsel, davranissal, finansal ve hukuksal etkilesimli bilesenleri; - Alacak devir hizini yukselterek isletmelere uygun basarili tahsilat yonetiminin gerceklestirilmesinin eylem plani, - Musteri kaybi yasanmaksizin sorun cozum onerileri ve isleyise entegre verimli risk yonetim modelleri ele alinacaktir. Kapsam: Hayatta kalmanin ve surdurulebilir gelismeyi saglayarak rekabet gucunu arttirmanin bir yolu: Cost Reduction. Bir at yarisinda birinci gelen at ile ikincisi arasinda sadece bir burun farki, 150 km.lik bir bisiklet yarisinda da birinci ile ikinci arasinda bir tekerlek farki olabilir. Cost Reduction yani Maliyetlerin Dusurulmesi size bu burun veya tekerlek farkini saglayabilir. Bu suretle rakiplerinizden bir adim onde olabilirsiniz. Cost Reduction projeleri Amerika Birlesik Devletlerinde, Ingilterede ve diger gelismis ulkelerde yuzyila yakin bir sureden beri devamli uygulanmaktadir. Sonradan bu sahaya giren uzak dogu ise bu isi cok daha basarili bir sekle donusturmus ve dunya pazarlarini bir kasirga gibi kasip kavurmustur. Programimiz uretimden dagitima, insan gucunden musteri iliskileri yonetimine tum isletme fonksiyonlarinda maliyet dusurme ve yuksek verim alma kriterlerini ileri modellerle irdelemek ve emsal saglamak amacli tasarlanmistir.
small net80211 node cache fix
Node cache eviction is too agressive, possibly kicking off associated
stations for no good reason. I missed that associated stations are in
state IEEE80211_S_RUN rather than IEEE80211_S_ASSOC (which means trying
to associate).
Also compile the debug message shown when a node is evicted from the
cache to make such problems easier to spot (won't affect install media
as it is protected by IEEE80211_STA_ONLY).
Index: ieee80211_node.c
===
RCS file: /cvs/src/sys/net80211/ieee80211_node.c,v
retrieving revision 1.70
diff -u -p -r1.70 ieee80211_node.c
--- ieee80211_node.c16 Jul 2012 14:51:46 - 1.70
+++ ieee80211_node.c18 Jul 2012 10:24:59 -
@@ -1176,12 +1176,12 @@ ieee80211_clean_nodes(struct ieee80211co
ic-ic_state == IEEE80211_S_RUN) {
if (cache_timeout) {
if (ni-ni_state != IEEE80211_STA_COLLECT
- (ni-ni_state == IEEE80211_STA_ASSOC ||
+ (ni-ni_state = IEEE80211_STA_ASSOC ||
ni-ni_inact IEEE80211_INACT_MAX))
continue;
} else {
if (ic-ic_opmode == IEEE80211_M_HOSTAP
- ((ni-ni_state == IEEE80211_STA_ASSOC
+ ((ni-ni_state = IEEE80211_STA_ASSOC
ni-ni_inact IEEE80211_INACT_MAX) ||
(ni-ni_state == IEEE80211_STA_AUTH
ni-ni_inact == 0)))
@@ -1194,9 +1194,10 @@ ieee80211_clean_nodes(struct ieee80211co
continue;
}
}
+ if (ifp-if_flags IFF_DEBUG)
+ printf(%s: station %s purged from node cache\n,
+ ifp-if_xname, ether_sprintf(ni-ni_macaddr));
#endif
- DPRINTF((station %s purged from LRU cache\n,
- ether_sprintf(ni-ni_macaddr)));
/*
* If we're hostap and the node is authenticated, send
* a deauthentication frame. The node will be freed when
Re: Any idea of donate a Raspberry Pi to a developer?
On Tue, Jul 17, 2012 at 07:55:28PM +0200, Johan Ryberg wrote: You simply just throw another persons political opinion on me. I have read that thread as well but that's not the point. Do you honestly believe that one answer speaks for all other very skilled developers? It's a fact that the Pi is a case of severely underdocumented blobby hardware. It's chances in OpenBSD land are close to zero. -Otto
Re: small net80211 node cache fix
On 2012/07/18 12:51, Stefan Sperling wrote:
Node cache eviction is too agressive, possibly kicking off associated
stations for no good reason. I missed that associated stations are in
state IEEE80211_S_RUN rather than IEEE80211_S_ASSOC (which means trying
to associate).
there's ieee80211_node_state with the IEEE80211_STA_* enum ..
enum ieee80211_node_state {
IEEE80211_STA_CACHE,/* cached node */
IEEE80211_STA_BSS, /* ic-ic_bss, the network we joined */
IEEE80211_STA_AUTH, /* successfully authenticated */
IEEE80211_STA_ASSOC,/* successfully associated */
IEEE80211_STA_COLLECT /* This node remains in the cache while
* the driver sends a de-auth message;
* afterward it should be freed to make room
* for a new node.
*/
};
and also ieee80211_state with IEEE80211_S_*,
enum ieee80211_state {
IEEE80211_S_INIT= 0,/* default state */
IEEE80211_S_SCAN= 1,/* scanning */
IEEE80211_S_AUTH= 2,/* try to authenticate */
IEEE80211_S_ASSOC = 3,/* try to assoc */
IEEE80211_S_RUN = 4 /* associated */
};
so I'm not sure about this, it looks like the diff changes things so that
nodes in STA_COLLECT are no longer kicked off?
Also compile the debug message shown when a node is evicted from the
cache to make such problems easier to spot (won't affect install media
as it is protected by IEEE80211_STA_ONLY).
OK for this bit.
Index: ieee80211_node.c
===
RCS file: /cvs/src/sys/net80211/ieee80211_node.c,v
retrieving revision 1.70
diff -u -p -r1.70 ieee80211_node.c
--- ieee80211_node.c 16 Jul 2012 14:51:46 - 1.70
+++ ieee80211_node.c 18 Jul 2012 10:24:59 -
@@ -1176,12 +1176,12 @@ ieee80211_clean_nodes(struct ieee80211co
ic-ic_state == IEEE80211_S_RUN) {
if (cache_timeout) {
if (ni-ni_state != IEEE80211_STA_COLLECT
- (ni-ni_state == IEEE80211_STA_ASSOC ||
+ (ni-ni_state = IEEE80211_STA_ASSOC ||
ni-ni_inact IEEE80211_INACT_MAX))
continue;
} else {
if (ic-ic_opmode == IEEE80211_M_HOSTAP
- ((ni-ni_state == IEEE80211_STA_ASSOC
+ ((ni-ni_state = IEEE80211_STA_ASSOC
ni-ni_inact IEEE80211_INACT_MAX) ||
(ni-ni_state == IEEE80211_STA_AUTH
ni-ni_inact == 0)))
@@ -1194,9 +1194,10 @@ ieee80211_clean_nodes(struct ieee80211co
continue;
}
}
+ if (ifp-if_flags IFF_DEBUG)
+ printf(%s: station %s purged from node cache\n,
+ ifp-if_xname, ether_sprintf(ni-ni_macaddr));
#endif
- DPRINTF((station %s purged from LRU cache\n,
- ether_sprintf(ni-ni_macaddr)));
/*
* If we're hostap and the node is authenticated, send
* a deauthentication frame. The node will be freed when
Listo para tu viaje de Fiestas Patrias? .publicidad
andrea.jpg miranda.jpg [demime 1.01d removed an attachment of type image/jpeg which had a name of 9f183befcab3ac8b2011967ba1a4d0a9] [demime 1.01d removed an attachment of type image/jpeg which had a name of 43ed3e5be87b0997c059fa628c4a618b]
Re: Any idea of donate a Raspberry Pi to a developer?
On Wed, Jul 18, 2012 at 01:28:13PM +0200, Otto Moerbeek wrote: On Tue, Jul 17, 2012 at 07:55:28PM +0200, Johan Ryberg wrote: You simply just throw another persons political opinion on me. I have read that thread as well but that's not the point. Do you honestly believe that one answer speaks for all other very skilled developers? It's a fact that the Pi is a case of severely underdocumented blobby hardware. It's chances in OpenBSD land are close to zero. -Otto According to hubertf's blog, this boots on NetBSD http://www.feyrer.de/NetBSD/bx/blosxom.cgi/nb_20120714_0236.html jirib
Re: Any idea of donate a Raspberry Pi to a developer?
On Tue, Jul 17, 2012 at 06:08:24PM +0200, Johan Ryberg wrote: Hi. I wounder if it's any idea to donate a Raspberry Pi to a developer to make it work on OpenBSD? As understood it is the hardware spec to closed give it a chance but I rather ask then not. If there's somebody with the skills time and interest to do this, I think they will probably be resourceful enough to get hold of the £25 board without too much trouble. As was said on port-arm@netbsd (who have rpi booting multiuser, but with very limited device support) if you were in a position to convince hardware manufacturers to give access to components' manuals, your help would be very valuable indeed. :) Really the panda and beagle devices are more interesting targets developer-wise (more docs, faster cpu, and supporting significantly more RAM; 512 is a lot more comfortable than 224 if you want to run standard applications on it) and for any kind of general improvement in ARM support (compiler, toolchain etc) which affects all arm devices, they would be the ones to get working well first as it's much easier to do this work on a machine which builds more quickly (also there's definitely a need for something nicer than the Thecus for package building).
Re: SNMPv3 Support
On Wed, Jul 18, 2012 at 4:16 PM, Gerhard Roth wrote: same here, wouldn't it be possible to match the ipsec.conf grammar and ignore the SNMPv3 naming a bit? auth hmac-sha1 authkey fooobar enc aes enckey dkjdkj - instead of - hmac sha authpass foobar cipher aes privpass dkjdkj or maybe authpass and encpass, but what does priv mean. So instead of user name [authpass pass hmac [MD5|SHA]] \ [privpass pass cipher [DES|AES]] let's use user name [hmac-[md5|sha1] authkey key] \ [enc [des|aes] enckey key] Is that ipsec.conf like enough? why weren't all the other _priv instances renamed to _encr? is there any value in keeping SNMP_MSGFLAG_PRIV and such around? uu_privkey looks a bif of an alien alongside uu_authkey.
Re: SNMPv3 Support
On Wed, 18 Jul 2012 16:51:27 +0200, Mike Belopuhov m...@crypt.org.ru wrote: On Wed, Jul 18, 2012 at 4:16 PM, Gerhard Roth wrote: same here, wouldn't it be possible to match the ipsec.conf grammar and ignore the SNMPv3 naming a bit? auth hmac-sha1 authkey fooobar enc aes enckey dkjdkj - instead of - hmac sha authpass foobar cipher aes privpass dkjdkj or maybe authpass and encpass, but what does priv mean. So instead of user name [authpass pass hmac [MD5|SHA]] \ [privpass pass cipher [DES|AES]] let's use user name [hmac-[md5|sha1] authkey key] \ [enc [des|aes] enckey key] Is that ipsec.conf like enough? why weren't all the other _priv instances renamed to _encr? is there any value in keeping SNMP_MSGFLAG_PRIV and such around? uu_privkey looks a bif of an alien alongside uu_authkey. I agree with Reyk that the configuration of snmpd should be possible to anyone who has not read all the SNMPv3 RFCs. OTOH, shouldn't the code somehow reflect which part of the RFCs it implements? Otherwise its hard to understand whats happening. And unfortunately the RFCs use the word priv or privacy consistenly instead of encryption. Gerhard
Re: SNMPv3 Support
yes, I agree. It makes sense to keep the RFC terminology in the implementation but to use the common language in the configuration grammar. developers need to understand the code related to the RFCs, users shouldn't have to learn new terminology for crypto thats is configured in n other places in OpenBSD. @mikeb isn't it the same in iked? all the fancy IKEv2-RFC terminology in the code and a configuration that sounds more natural to OpenBSD, eg. TS/Traffic Selectors vs. from ... to flows? On Wed, Jul 18, 2012 at 5:01 PM, Gerhard Roth gerhard_r...@genua.de wrote: I agree with Reyk that the configuration of snmpd should be possible to anyone who has not read all the SNMPv3 RFCs. OTOH, shouldn't the code somehow reflect which part of the RFCs it implements? Otherwise its hard to understand whats happening. And unfortunately the RFCs use the word priv or privacy consistenly instead of encryption. Gerhard
Informativo IDC
[IMAGE] Se você não estiver visualizando a imagem acesse este link . header-julho2 CONHEÇA AS ÁREAS DE ATUAÇÃO DO IDC: Pós-Graduação em Direito Cursos de Extensão Seminários Filosofia Preparatórios para Concursos PÓS-GRADUAÇÃO EM DIREITO Especialização em DIREITO CIVIL E PROCESSUAL CIVIL 14ª ed. â Aulas nas 3ª, 4ª e 5ª feiras (eventuais 4ªs sem atividades) â InÃcio 14/08/2012 â Turno: noite Saiba mais Especialização em DIREITO PENAL E PROCESSUAL PENAL 13ª ed. â Aulas nas 3ª, 4ª e 5ª feiras (eventuais 4ªs sem atividades) â Início 14/08/2012 - Turno: noite Saiba mais Especialização em DIREITO DO TRABALHO E PROCESSUAL DO TRABALHO 13ª ed. â Aulas nas 3ª, 4ª e 5ª feiras (eventuais 4ªs sem atividades) â Início 14/08/2012 - Turno: noite Saiba mais Especialização em DIREITO PÚBLICO 12ª ed. â Aulas nas 2ª, 3ª e 5ª feiras (eventuais 5ªs sem atividades) â Início 13/08/2012 - Turno: noite Saiba mais MBA em DIREITO DA EMPRESA - Ênfase em Direito Tributário 8ª ed. â Aulas 6ª feiras à noite e sábados manhã e tarde (finais de semana alternados) â InÃcio 10/08/2012 Saiba mais Especialização em DIREITO CIVIL - Ênfase em Família e Sucessões 9ª ed. â Aulas 6ª feiras à noite e sábados manhã e tarde (finais de semana alternados) - Início 10/08/2012 Saiba mais Especialização em DIREITO PROCESSUAL CIVIL 11ª ed. â Aulas 6ª feiras à noite e sábados pela manhã â InÃcio 10/08/2012 Saiba mais Especialização em DIREITO DO TRABALHO, PROCESSO DO TRABALHO E PREVIDENCIÁRIO 4ª ed. - Aulas nas 3ª, 4ª e 5ª feiras (eventuais 4ªs sem atividades) â Início 14/08/2012 - Turno: manhã Saiba mais Especialização em DIREITO IMOBILIÁRIO, CONTRATOS E RESPONSABILIDADE CIVIL 4ª ed. â Aulas sextas-feiras à noite e sábados manhã â InÃcio 10/08/2012 Saiba mais Especialização em DIREITO PREVIDENCIÁRIO 10ª ed. â Aulas nas 2ª, 4ª e 5ª feiras (eventuais 4ªs sem atividades) â Início 13/08/2012 - Turno: noite Saiba mais Especialização em GESTÃO PÚBLICA 2ª ed. - Aulas nas 3ª, 4ª e 5ª feiras (eventuais 4ªs sem atividades) â Início 14/08/2012 Saiba mais Especialização em OPERAÇÕES ESPECIAIS POLICIAIS Início 24/08/2012 Saiba mais Especialização em DIREITO DO TRABALHO, PROCESSO DO TRABALHO E PREVIDENCIÁRIO - EM SANTA MARIA (G10) 1ª ed. - Aulas: -6ªs feiras das 14h às 17h35min e das 19h15min às 22h45min -Sábados das 08h30min às 12h05min - Início 24/08/2012 Saiba mais Especialização em DIREITO CIVIL E PROCESSO CIVIL - EM SANTA MARIA (G10) 1ª ed. - Aulas: -6ªs feiras das 14h às 17h35min e das 19h15min às 22h45min -Sábados das 08h30min às 12h05min - Início 24/08/2012 Saiba mais MBA em DIREITO DA EMPRESA - Ênfase em Direito Tributário - EM SANTA MARIA (G10) 1ª ed. - Aulas: -6ªs feiras das 14h às 17h35min e das 19h15min às 22h45min -Sábados das 08h30min às 12h05min - Início 24/08/2012 Saiba mais Especialização em DIREITO CIVIL E PROCESSO CIVIL - EM NOVO HAMBURGO (FACULDADE IENH) 1ª ed. - Aulas: 2ª, 4ª e 5ª feiras à noite - (eventuais quintas sem atividades) - Início 20/08/2012 Saiba mais CURSOS DE EXTENSÃO Clique aqui para saber mais. CAPACITAÇÃO EM LICITAÇÕES E CONTRATOS: início 14/09/2012 DIREITO ADMINISTRATIVO | PRESENCIAL OU EAD: início 22/08/2012 PRÁTICA TRABALHISTA: início 20/08/2012 DIREITO DO TRABALHO: início 23/08/2012 DIREITO E PRÁTICA CIVIL | PRESENCIAL OU EAD: início 23/08/2012 DIREITO PREVIDENCIÁRIO | PRESENCIAL E EAD: início 25/08/2012 DIREITO PROCESSUAL AMBIENTAL | PRESENCIAL OU EAD: início 23/08/2012 PLANEJAMENTO E GESTÃO DE ESCRITÓRIOS JURÍDICOS: início 05/10/2012 PORTUGUÊS REGULAR | PRESENCIAL OU EAD: início 21/08/2012 CÁLCULOS DOS BENEFÍCIOS PREVIDENCIÁRIOS DO RGPS: início 14/09/2012 CURSO PRÁTICO E AVANÇADO DE DESAPOSENTAÇÃO: inscrições abertas PRÁTICA PREVIDENCIÁRIA: início 20/08/2012 REGIMES PRÓPRIOS DE PREVIDÊNCIA SOCIAL E PRIVADA | PRESENCIAL OU EAD: início 21/08/2012 SEMINÁRIOS CÁLCULO DE LIQUIDAÇÃO DE SENTENÇA TRABALHISTA - 14 a 22/09/2012 ANÁLISE SINTÁTICA - 14/09/2012 ORATÓRIA, EXPRESSIVIDADE E DESINIBIÇÃO - 24 e 25/08/2012 ORATÓRIA E TÉCNICA VOCAL DIRECIONADO À ÁREA JURÍDICA - 14 e 25/09/2012 SAÚDE E TÉCNICA VOCAL PARA PROFESSORES- 05 a 06/10/2012 CRIMES ELETRÔNICOS NO BRASIL E NO MUNDO - LEGISLAÇÃO E INVESTIGAÇÃO- 29/09/2012 PRÁTICA DE AÇÃO DE DIREITO DE FAMÍLIA - 06/10/2012 TEMAS ATUAIS NO DIREITO PREVIDENCIÁRIO - 03 e 04/10/2012 A TERCEIRIZAÇÃO DO TRABALHO E A RESPONSABILIDADE DO EMPREGADOR- 24/11/2012 PRÁTICA DE EXECUÇÃO TRABALHISTA - 14 e 15/09/2012 CAPACITAÇÃO EM PREGÃO ELETRÔNICO- 14/09/2012 PRÁTICA DE INVENTÁRIO E PARTILHA JUDICIAL - 29/09/2012 RECURSOS NOS TRIBUNAIS SUPERIORES - 22/09/2012 DIREITO SUCESSÓRIO PARA FUNCIONÁRIO DE CARTÓRIOS E TABELIONATOS - 04 e 11/08/2012 LOCAÇÕES, TEORIA E PRÁTICA - 06/10/2012 SÚMULA E OJ'S DO TST - 04/08/2012 a 06/10/2012 FORMAÇÃO DE HONORÁRIOS E MARKETING JURÍDICO- 20 e 27/10/2012 PREVENÇÃO E DEFESA DE RECLAMAÇÕES
ral rt2661 tx interrupt race fix
ral(4) cards using the rt2661 driver code (RT2561, RT2561S, RT2661 variants) suffer a race in TX interrupt handling which can cause TX processing to get stuck. This problem was previously discussed here: http://marc.info/?l=openbsd-miscm=125895269930106w=2 The patch proposed there was rejected by Damien for reasons unknown to me: http://marc.info/?l=openbsd-techm=126451543507085w=2 Sepherosa Ziehau from dragonfly fixed this problem in a different way: http://gitweb.dragonflybsd.org/dragonfly.git/commit/9dd87f8a6f730e54dfa4f21f3d9fae6a615b1908 My approach for a fix is based on Sephe's approach. With 2661, TX interrupt processing is split between two interrupt handlers. One that runs when the chip has offloaded the frame to the ASIC (rt2661_tx_dma_intr) and one that runs when the ASIC reports back about transmission success or failure (rt2661_tx_intr). Currently, we free the mbuf for the transmitted frame during the first interrupt (rt2661_tx_dma_intr), but do not release the STA node reference yet and do not make space in the TX queue. When the second interrupt handler (rt2661_tx_intr) runs, we obtain the STA node corresponding to the transmitted frame, and update the STA node's associated AMRR node, which contains counters used by the rate adaptation code (Adaptive Multi Rate Retry algorithm). Then space is made in the TX queue. This approach assumes that rt2661_tx_intr and rt2661_tx_dma_intr will always be triggered in the right amount and order. This assumption doesn't seem to be safe. I've seen the driver end up in a situation where some entries in the TX queue are not removed at all. To fix this, we can keep track of which AMRR node needs to be updated when the second interrupt handler gets to run. By not tying the AMRR node to the STA node directly, we can release the STA node reference in the first interrupt handler and make room in the TX queue there. The hardware provides an 8-bit field for driver-specific data in the TX descriptor, which can be written before TX and read back when TX completes. This field is currently used to store the ID of the queue a frame was transmitted from, and read back in rt2661_tx_intr to obtain, via the queue, the STA node corresponding to the transmitted frame. Instead of storing a queue ID, we can store an identifier for the AMRR node that needs to be updated when the TX has completed (in case the STA node has already been freed when the second interrupt occurs, we free the corresponding AMRR node instead of updating it). With the patch below I've haven't seen my ral AP lock up in 2 days, whereas before I could trigger the problem simply by taking the laptop to my kitchen, where signal to the AP is poor. Can anyone confirm that this patch provides similar benefits elsewhere? If your ral(4) device reports itself as Ralink RT2561, Ralink RT2561S, or Ralink RT2661, please test and report back. Thanks! Index: rt2661.c === RCS file: /cvs/src/sys/dev/ic/rt2661.c,v retrieving revision 1.67 diff -u -p -r1.67 rt2661.c --- rt2661.c17 Jul 2012 14:43:12 - 1.67 +++ rt2661.c18 Jul 2012 13:38:39 - @@ -34,6 +34,7 @@ #include sys/timeout.h #include sys/conf.h #include sys/device.h +#include sys/queue.h #include machine/bus.h #include machine/endian.h @@ -57,6 +58,7 @@ #include net80211/ieee80211_var.h #include net80211/ieee80211_amrr.h #include net80211/ieee80211_radiotap.h +#include net80211/ieee80211_node.h #include dev/ic/rt2661var.h #include dev/ic/rt2661reg.h @@ -88,6 +90,8 @@ void rt2661_reset_rx_ring(struct rt2661 void rt2661_free_rx_ring(struct rt2661_softc *, struct rt2661_rx_ring *); struct ieee80211_node *rt2661_node_alloc(struct ieee80211com *); +void rt2661_node_free(struct ieee80211com *, + struct ieee80211_node *); intrt2661_media_change(struct ifnet *); void rt2661_next_scan(void *); void rt2661_iter_func(void *, struct ieee80211_node *); @@ -115,7 +119,7 @@ uint16_trt2661_txtime(int, int, uint32_ uint8_trt2661_plcp_signal(int); void rt2661_setup_tx_desc(struct rt2661_softc *, struct rt2661_tx_desc *, uint32_t, uint16_t, int, int, - const bus_dma_segment_t *, int, int); + const bus_dma_segment_t *, int, int, u_int8_t); intrt2661_tx_mgt(struct rt2661_softc *, struct mbuf *, struct ieee80211_node *); intrt2661_tx_data(struct rt2661_softc *, struct mbuf *, @@ -156,6 +160,13 @@ intrt2661_prepare_beacon(struct rt2661 #endif void rt2661_enable_tsf_sync(struct rt2661_softc *); intrt2661_get_rssi(struct rt2661_softc *, uint8_t); +struct rt2661_amrr_node *rt2661_amrr_node_alloc(struct ieee80211com *, + struct rt2661_node *); +void
Re: SNMPv3 Support
Hi, On Wed, Jul 18, 2012 at 4:16 PM, Gerhard Roth gerhard_r...@genua.de wrote: thanks for your thorough inspection of my code. I really appreciate this. Please find my answers inline below. Hope I didn't miss one. Your latest diff looks good! I will test and have another look at the diff and implementation details tomorrow or on Friday. But... you should work with Markus to get SNMP over OpenSSH working ;-) (eg. RFC 5592). In fact we thought about this. But then, are there any SNMP management stations in the field that support this transport module? I have no idea. Well, the question is if there are any stations with TSM support yet. AFAIK, TSM was defined with either SSH or DTLS by Cisco. So maybe Cisco is using it in some of their products? Maybe net-snmp. Defining users in snmpd.conf(5) is fine, just as I did it for iked with iked.conf(5). But it reminds me that we should have a common possibility to connect all these daemons (iked, snmpd, npppd, ...) to an authentication backend like radius or LDAP. It would be nice to have a little radius/ldap client library (or just static .c-files) that can be used by all of them. Maybe port OpenPAM to OpenBSD? ;) My experience is that you can scare people with the word PAM ;-) Even if it's Open, but maybe I'm wrong, I haven't looked at it for a long time. I see that these are standard SNMPv3 terms but isn't there a way to find a better grammar for snmpd.conf(5)? Fine with me. I'm not a fan of CameCase either. Just though that using the terms from the RFC would make this easier to understand and match. How about: noAuthNoPriv- none authNoPriv - auth authPriv- encr Is there a better alternative for encr? Maybe just enc (I know it would complicate the grammar because it's a reserved keyword) or something more abstract like high or all? SNMPv3 is relatively hard to configure - at least in other SNMP implementations - we should make it easier! No problem. I added a little bit more explanation now. Just tell me what you think of it. Yes, your manpage bits are better now. Thanks. Maybe you'll get more comments from jmc@, he always helped me a lot with improving the manpages. Reyk
Re: SNMPv3 Support
On 2012/07/18 21:42, Reyk Floeter wrote: In fact we thought about this. But then, are there any SNMP management stations in the field that support this transport module? I have no idea. Well, the question is if there are any stations with TSM support yet. AFAIK, TSM was defined with either SSH or DTLS by Cisco. So maybe Cisco is using it in some of their products? Maybe net-snmp. net-snmp has code to support DTLS and SSH (using libssh2 for the SSH part). I haven't tried it and it's not enabled in the port at present, but I could take a look at doing this (probably as an flavour to avoid extra deps in the usual case) if it would be useful. Defining users in snmpd.conf(5) is fine, just as I did it for iked with iked.conf(5). But it reminds me that we should have a common possibility to connect all these daemons (iked, snmpd, npppd, ...) to an authentication backend like radius or LDAP. It would be nice to have a little radius/ldap client library (or just static .c-files) that can be used by all of them. smtpd would fit in that ... ;)
