madwifi-devel Mailing List for MADWIFI
Status: Beta
Brought to you by:
otaku
You can subscribe to this list here.
2003 |
Jan
|
Feb
|
Mar
|
Apr
|
May
|
Jun
(3) |
Jul
(36) |
Aug
(22) |
Sep
(90) |
Oct
(86) |
Nov
(55) |
Dec
(87) |
---|---|---|---|---|---|---|---|---|---|---|---|---|
2004 |
Jan
(97) |
Feb
(53) |
Mar
(88) |
Apr
(87) |
May
(84) |
Jun
(84) |
Jul
(38) |
Aug
(74) |
Sep
(67) |
Oct
(60) |
Nov
(96) |
Dec
(67) |
2005 |
Jan
(112) |
Feb
(131) |
Mar
(132) |
Apr
(84) |
May
(72) |
Jun
(87) |
Jul
(91) |
Aug
(94) |
Sep
(84) |
Oct
(171) |
Nov
(180) |
Dec
(114) |
2006 |
Jan
(181) |
Feb
(200) |
Mar
(207) |
Apr
(151) |
May
(185) |
Jun
(113) |
Jul
(124) |
Aug
(97) |
Sep
(120) |
Oct
(150) |
Nov
(116) |
Dec
(134) |
2007 |
Jan
(148) |
Feb
(159) |
Mar
(245) |
Apr
(155) |
May
(217) |
Jun
(181) |
Jul
(196) |
Aug
(164) |
Sep
(82) |
Oct
(114) |
Nov
(217) |
Dec
(217) |
2008 |
Jan
(146) |
Feb
(98) |
Mar
(168) |
Apr
(201) |
May
(80) |
Jun
(100) |
Jul
(189) |
Aug
(30) |
Sep
(163) |
Oct
(56) |
Nov
(70) |
Dec
(71) |
2009 |
Jan
(85) |
Feb
(38) |
Mar
(45) |
Apr
(50) |
May
(95) |
Jun
(77) |
Jul
(74) |
Aug
(36) |
Sep
(37) |
Oct
(12) |
Nov
(71) |
Dec
(10) |
2010 |
Jan
(54) |
Feb
(73) |
Mar
(69) |
Apr
(74) |
May
(31) |
Jun
(100) |
Jul
(26) |
Aug
(36) |
Sep
(36) |
Oct
(34) |
Nov
(21) |
Dec
(6) |
2011 |
Jan
(2) |
Feb
(7) |
Mar
(3) |
Apr
(3) |
May
(7) |
Jun
(2) |
Jul
(7) |
Aug
(5) |
Sep
(8) |
Oct
(7) |
Nov
(4) |
Dec
|
2012 |
Jan
(2) |
Feb
|
Mar
|
Apr
(3) |
May
|
Jun
(1) |
Jul
(3) |
Aug
|
Sep
(1) |
Oct
(3) |
Nov
(1) |
Dec
(2) |
2013 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
(1) |
Jun
|
Jul
|
Aug
(2) |
Sep
|
Oct
|
Nov
(10) |
Dec
|
2014 |
Jan
|
Feb
(2) |
Mar
|
Apr
(1) |
May
|
Jun
(1) |
Jul
|
Aug
(1) |
Sep
(2) |
Oct
|
Nov
(4) |
Dec
(3) |
2015 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
2017 |
Jan
(1) |
Feb
|
Mar
|
Apr
|
May
|
Jun
|
Jul
|
Aug
|
Sep
|
Oct
|
Nov
|
Dec
|
From: Michael R. <mre...@ma...> - 2017-01-08 11:34:53
|
Hi all. As you may be aware of, the MadWifi project has ceased, and the focus in terms of linux-drivers for Atheros chipsets for good reasons has turned towards ath5k, ath9k and friends. As a result, both the madwifi-devel and madwifi-users mailing list haven't seen any relevant traffic for many months now - not even much spam has been received, go figure. For this reason I will now close both mailing lists. Thanks to everyone who has participated in the many discussions that took place here over the years. I wish you all the best for the future and hope to see you at another place somewhere in the net. Bye, Mike |
From: Michael R. <mre...@ma...> - 2015-01-11 16:19:30
|
Hi all. > In order to complete the move, the next step is to switch the repository > on madwifi-project.org to read-only mode. If needs be, it would be > possible to commit to it at sf.net. That had happened shortly after I wrote that last mail. Today I turned off the subversion repository at madwifi-project.org, and put up a redirect to its new home over at sf.net. You will notice it when trying to check out from http://madwifi-project.org/svn: the svn client should let you know that the repository has moved permanently to a new location and that you need to relocate your local working copy. See [1] for instructions. > Then I'll redirect all visitors accessing Trac's repository browser to the > corresponding facility at sf.net; the requested information will be > delivered, but from sf.net rather than from our Trac. For example, [2] > will be redirected to [3]. I took care of this topic today, too. I've tried my best to also establish redirections for "deep links" that one might have bookmarked or found in search engine results. I am aware of only one feature that could not be covered that way: when browsing changesets, Trac allows to select one of the modified files and show only the changes applied to this single file. The sf.net changeset browser offers a similar functionality, but the URLs to these views contain a parameter with a commit ID that cannot be determined with the means of mod_rewrite rules. However, I think this feature is not used often, so this small breakage should not hurt. Bye, Mike [1] http://svnbook.red-bean.com/en/1.7/svn.ref.svn.c.relocate.html |
From: Pommnitz J. <Pom...@ia...> - 2014-12-16 14:30:51
|
Pavel, thanks fort he heads up! I’m not sure I will do anything before the holidays about this, but your input is greatly appreciated. Kind regards Joerg Von: Pavel Roskin [mailto:pr...@gn...] Gesendet: Freitag, 12. Dezember 2014 22:55 An: Pommnitz Jörg Cc: mad...@li... Betreff: Re: [Madwifi-devel] Madwifi and ETSI EN 300 328 V1.8.1 Hello Jörg, Yes, there is similar code in MadWifi. Just look for AR5212_CCA_MAX_GOOD_VALUE and AR5416_CCA_MAX_GOOD_VALUE. There is a little problem with the code - MadWifi uses the same value for 2GHz and 5GHz, whereas the changes in ath9k use separate limits for different bands. I don't want to change any MadWifi logic that cannot be trivially tested. We don't have any active userbase. If we do it wrong, nobody would tell us. I would rather verify that the change applies to all chipsets supported by ath5k and ath9k. If you want changes in MadWifi, please make sure they are in ath5k and ath9k for the corresponding chipsets. ath5k uses the same value for both bands, AR5K_TUNE_CCA_MAX_GOOD_VALUE equal to -95. It would need to be changed to support per-band limits. ath9k always uses per-band limits. But the limits are wildly different across chipsets, ranging from -116 to -60. Pavel ________________________________ IABG mbH Sitz der Gesellschaft: Ottobrunn, Registergericht: Amtsgericht München, HRB 5499 Geschäftsführung: Prof. Dr.-Ing. Rudolf F. Schwarz Vorsitzender des Aufsichtsrats: RA Engelbert Kupka MdL a.D. |
From: Pavel R. <pr...@gn...> - 2014-12-12 21:55:07
|
Hello Jörg, Yes, there is similar code in MadWifi. Just look for AR5212_CCA_MAX_GOOD_VALUE and AR5416_CCA_MAX_GOOD_VALUE. There is a little problem with the code - MadWifi uses the same value for 2GHz and 5GHz, whereas the changes in ath9k use separate limits for different bands. I don't want to change any MadWifi logic that cannot be trivially tested. We don't have any active userbase. If we do it wrong, nobody would tell us. I would rather verify that the change applies to all chipsets supported by ath5k and ath9k. If you want changes in MadWifi, please make sure they are in ath5k and ath9k for the corresponding chipsets. ath5k uses the same value for both bands, AR5K_TUNE_CCA_MAX_GOOD_VALUE equal to -95. It would need to be changed to support per-band limits. ath9k always uses per-band limits. But the limits are wildly different across chipsets, ranging from -116 to -60. Pavel |
From: Pommnitz J. <Pom...@ia...> - 2014-12-10 11:34:00
|
Hello all, do you know whether it is possible to make Madwifi supported hardware ETSI EN 300 328 V1.8.1 compliant? If so, what would be required? I found the following ath9k patches http://www.spinics.net/lists/linux-wireless/msg115798.html http://www.spinics.net/lists/linux-wireless/msg118665.html These changes supposedly update ath9k to comply with the new ETSI norm. Can these patches be adapted to Madwifi? Regards Jörg ________________________________ IABG mbH Sitz der Gesellschaft: Ottobrunn, Registergericht: Amtsgericht München, HRB 5499 Geschäftsführung: Prof. Dr.-Ing. Rudolf F. Schwarz Vorsitzender des Aufsichtsrats: RA Engelbert Kupka MdL a.D. |
From: <moh...@gm...> - 2014-11-13 02:41:05
|
Hi, moh...@gm... is now following you. View moh...@gm...'s profile http://invites.info-emailer.com/download.jsp?welcome=1&email=mad...@li...&viral=true&u=34026197&inviterid=33916295&token=b5ce82bceaee320f4b440b398ffabd53&ts=1415245915792&userid=34026197&inviter=mohanrbr&emailmasterid=efb38a99-355a-4eb4-a68e-827c918cf6af&from=moh...@gm...&src=bcbemailtxt Follow the link below to remove yourself from all such emails http://invites.info-emailer.com/uns_inviter.jsp?email=mad...@li...&iid=efb38a99-355a-4eb4-a68e-827c918cf6af&from=moh...@gm... |
From: <moh...@gm...> - 2014-11-05 22:39:26
|
Hi, moh...@gm... wants to follow you. ****** Is moh...@gm... you friend? ****** If Yes please follow the link below: http://invites.infoaxe.net/signup_e.html?fullname=&email=mad...@li...&invitername=mohanrbr&inviterid=33916295&userid=0&token=0&emailmasterid=24cfb6b3-10e2-4407-a2b5-9c9713e0f403&from=moh...@gm...&src=txt_yes If No please follow the link below: http://invites.infoaxe.net/signup_e.html?fullname=&email=mad...@li...&invitername=mohanrbr&inviterid=33916295&userid=0&token=0&emailmasterid=24cfb6b3-10e2-4407-a2b5-9c9713e0f403&from=moh...@gm...&src=txt_no Follow the link below to remove yourself from all such emails http://invites.infoaxe.net/uns_inviter.jsp?email=mad...@li...&iid=24cfb6b3-10e2-4407-a2b5-9c9713e0f403&from=moh...@gm... |
From: Pommnitz J. <Pom...@ia...> - 2014-09-09 08:12:32
|
Pavel, thanks for your suggestions. Something holding a lock is my suspicion as well. As part of my investigation I'm running a script that dumps the system state. Part of this dump is lsof. Quite reliably I get a "soft lockup" bug like this: Aug 30 07:36:51 localhost kernel: BUG: soft lockup - CPU#0 stuck for 11s! [lsof:30009] Aug 30 07:36:51 localhost kernel: Aug 30 07:36:51 localhost kernel: Pid: 30009, comm: lsof Aug 30 07:36:51 localhost kernel: EIP: 0060:[pit_read+96/123] CPU: 0 Aug 30 07:36:51 localhost kernel: EIP is at pit_read+0x60/0x7b Aug 30 07:36:51 localhost kernel: EFLAGS: 00000282 Tainted: P (2.6.23.12-himonn-4329 #1) Aug 30 07:36:51 localhost kernel: EAX: 00000001 EBX: 00000001 ECX: 00c16421 EDX: 00000282 Aug 30 07:36:51 localhost kernel: ESI: f718eb40 EDI: f718eb40 EBP: 0185123e DS: 007b ES: 007b FS: 0000 Aug 30 07:36:51 localhost kernel: CR0: 8005003b CR2: 080afee0 CR3: 37c7d000 CR4: 000006d0 Aug 30 07:36:51 localhost kernel: DR0: 00000000 DR1: 00000000 DR2: 00000000 DR3: 00000000 Aug 30 07:36:51 localhost kernel: DR6: ffff0ff0 DR7: 00000400 Aug 30 07:36:51 localhost kernel: [getnstimeofday+43/172] getnstimeofday+0x2b/0xac Aug 30 07:36:51 localhost kernel: [ktime_get_real+13/33] ktime_get_real+0xd/0x21 Aug 30 07:36:51 localhost kernel: [dev_hard_start_xmit+52/618] dev_hard_start_xmit+0x34/0x26a Aug 30 07:36:51 localhost kernel: [__qdisc_run+77/284] __qdisc_run+0x4d/0x11c Aug 30 07:36:51 localhost kernel: [net_tx_action+156/168] net_tx_action+0x9c/0xa8 Aug 30 07:36:51 localhost kernel: [__do_softirq+53/117] __do_softirq+0x35/0x75 Aug 30 07:36:51 localhost kernel: [do_softirq+34/38] do_softirq+0x22/0x26 Aug 30 07:36:51 localhost kernel: [local_bh_enable+107/121] local_bh_enable+0x6b/0x79 Aug 30 07:36:51 localhost kernel: [established_get_first+124/136] established_get_first+0x7c/0x88 Aug 30 07:36:51 localhost kernel: [established_get_first+111/136] established_get_first+0x6f/0x88 Aug 30 07:36:51 localhost kernel: [tcp_get_idx+119/152] tcp_get_idx+0x77/0x98 Aug 30 07:36:51 localhost kernel: [seq_read+208/625] seq_read+0xd0/0x271 Aug 30 07:36:51 localhost kernel: [seq_read+0/625] seq_read+0x0/0x271 Aug 30 07:36:51 localhost kernel: [proc_reg_read+53/70] proc_reg_read+0x35/0x46 Aug 30 07:36:51 localhost kernel: [proc_reg_read+0/70] proc_reg_read+0x0/0x46 Aug 30 07:36:51 localhost kernel: [vfs_read+166/296] vfs_read+0xa6/0x128 Aug 30 07:36:51 localhost kernel: [sys_read+65/103] sys_read+0x41/0x67 Aug 30 07:36:51 localhost kernel: [sysenter_past_esp+95/133] sysenter_past_esp+0x5f/0x85 Aug 30 07:36:51 localhost kernel: ======================= Which to me looks like as if lsof tries to read or stat a proc file for an open socket and then gets stuck on a lock held by something else. I have another question that you might be able to answer (I very much hope so): The problem eventually rights itself, so I assumed that a hardware reset kicks the WLAN card into a working state again. To verify this, I switched on reset debugging and indeed got traces, but not for ath_reset, which I expected, but for a channel change: Sep 5 17:37:16 localhost kernel: change_channel: called by scan_next Sep 5 17:37:16 localhost kernel: ath_set_channel: called by change_channel Sep 5 17:37:16 localhost kernel: ath_chan_set: 44 (5220 MHz) -> 52 (5260 MHz) Because change_channel is called by scan_next I assumed initially that this is unrelated to my problem and part of the normal operations. However, I discovered that this only happens at the network nodes that are affected by the problem (the affected nodes are identified by their position in the network topology, not the actual hardware, e.g. I changed nodes around and nodes that work perfectly well on one spot behave erroneously on another). I'm now somewhat at a loss, because I can't interpret this observation. My question: Do you know which error condition would trigger scan_next? Thanks in advance and kind regards Jörg > -----Ursprüngliche Nachricht----- > Von: Pavel Roskin [mailto:pr...@gn...] > Gesendet: Donnerstag, 4. September 2014 17:49 > An: Pommnitz Jörg > Cc: mad...@li... > Betreff: Re: Seeing strange queueing problems (??) with Madwifi on old > 2.6.23 kernel > > Hi Jörg, > > It has been a while since I looked at the MadWifi code for goals other > than porting it to the new kernels, but let me just give you some ideas. > > Quoting Pommnitz Jörg <Pom...@ia...>: > > > Hello all, > > for reasons I won't discuss here, we are stuck with Madwifi on an > > old 2.6.23 kernel. > > That should be OK. MadWifi targeted kernels as old as 2.4.22 until > recently, so I could not really use the features offered by the newer > kernels. I removed support for older kernels because I could not test > it, but even now, kernels as old as 2.6.13 are supported. > > > I see a very strange problem where an adhoc network node (running > > madwifi, of course) suddenly seems to stop sending anything at all > > (including IBSS beacons) and after minutes (!!) seems to push out > > all the missing packets in a short burst. > > First of all, check if other hardware would do it in the Ad-Hoc mode > and if the hardware you are using would have that problem in other > modes (station and AP). > > > To illustrate this, have a look at the attached packet capture. This > > is from a MANET that runs OLSRv1. The misbehaving node has the > > address 10.11.0.2. The first packet is number 746 (113 seconds in > > the trace). A lot of packets that were sent seconds apart arrive > > almost at the same time. Other neighbouring nodes do not show this > > behaviour. > > > > Any idea what might cause this? > > A lock (mutex perhaps) in the kernel code that blocks all > transmissions. Or a lock in MadWifi itself. Print timestamps in the > beginning and the end of ieee80211_hardstart() and ath_hardstart(). > That would give you an idea. > > It's also possible that the particular card detects interference > incorrectly and blocks all transmissions. That would be a hardware > problem. > > -- > Regards, > Pavel Roskin ________________________________ IABG mbH Sitz der Gesellschaft: Ottobrunn, Registergericht: Amtsgericht München, HRB 5499 Geschäftsführung: Prof. Dr.-Ing. Rudolf F. Schwarz Vorsitz, Dipl.-Ing. Matthias Spott Vorsitzender des Aufsichtsrats: RA Engelbert Kupka MdL a.D. |
From: Pavel R. <pr...@gn...> - 2014-09-04 16:23:39
|
Hi Jörg, It has been a while since I looked at the MadWifi code for goals other than porting it to the new kernels, but let me just give you some ideas. Quoting Pommnitz Jörg <Pom...@ia...>: > Hello all, > for reasons I won't discuss here, we are stuck with Madwifi on an > old 2.6.23 kernel. That should be OK. MadWifi targeted kernels as old as 2.4.22 until recently, so I could not really use the features offered by the newer kernels. I removed support for older kernels because I could not test it, but even now, kernels as old as 2.6.13 are supported. > I see a very strange problem where an adhoc network node (running > madwifi, of course) suddenly seems to stop sending anything at all > (including IBSS beacons) and after minutes (!!) seems to push out > all the missing packets in a short burst. First of all, check if other hardware would do it in the Ad-Hoc mode and if the hardware you are using would have that problem in other modes (station and AP). > To illustrate this, have a look at the attached packet capture. This > is from a MANET that runs OLSRv1. The misbehaving node has the > address 10.11.0.2. The first packet is number 746 (113 seconds in > the trace). A lot of packets that were sent seconds apart arrive > almost at the same time. Other neighbouring nodes do not show this > behaviour. > > Any idea what might cause this? A lock (mutex perhaps) in the kernel code that blocks all transmissions. Or a lock in MadWifi itself. Print timestamps in the beginning and the end of ieee80211_hardstart() and ath_hardstart(). That would give you an idea. It's also possible that the particular card detects interference incorrectly and blocks all transmissions. That would be a hardware problem. -- Regards, Pavel Roskin |
From: Pommnitz J. <Pom...@ia...> - 2014-08-29 13:59:46
|
Hello all, for reasons I won't discuss here, we are stuck with Madwifi on an old 2.6.23 kernel. I see a very strange problem where an adhoc network node (running madwifi, of course) suddenly seems to stop sending anything at all (including IBSS beacons) and after minutes (!!) seems to push out all the missing packets in a short burst. To illustrate this, have a look at the attached packet capture. This is from a MANET that runs OLSRv1. The misbehaving node has the address 10.11.0.2. The first packet is number 746 (113 seconds in the trace). A lot of packets that were sent seconds apart arrive almost at the same time. Other neighbouring nodes do not show this behaviour. Any idea what might cause this? Thanks in advance Joerg ________________________________ IABG mbH Sitz der Gesellschaft: Ottobrunn, Registergericht: Amtsgericht München, HRB 5499 Geschäftsführung: Prof. Dr.-Ing. Rudolf F. Schwarz Vorsitz, Dr. Anita Linseisen, Dipl.-Ing. Matthias Spott Vorsitzender des Aufsichtsrats: RA Engelbert Kupka MdL a.D. |
From: N.Leiten <nic...@gm...> - 2014-06-27 09:29:15
|
Hi, It's all simple. Just read driver. Especially HAL part. There's ability in Atheros-chipsets to set timestamps on every received frame. You can look at this derction. I don't remember for sure, but in 802.11-stack there's no much resources for this. 2014-04-11 15:40 GMT+03:00 Nobaene Sehloho <nse...@gm...>: > hi, my name is Elizabeth. > > I am a Masters student doing a project on indoor position. > > I wish to use the RTT signal to find the signal arrival time. I read an > article that mentioned modifying the madwifi drivers code. I am not sure > how to start about solving this problem > > your help will be much appreciated. > > Regards, > Elizabeth > > > -- > > *Nobaene Elizabeth Sehloho * > *"Life is all about knowing where your priorities lie*" > > > > ------------------------------------------------------------------------------ > Put Bad Developers to Shame > Dominate Development with Jenkins Continuous Integration > Continuously Automate Build, Test & Deployment > Start a new project now. Try Jenkins in the cloud. > http://p.sf.net/sfu/13600_Cloudbees > _______________________________________________ > Madwifi-devel mailing list > Mad...@li... > https://lists.sourceforge.net/lists/listinfo/madwifi-devel > > |
From: Nobaene S. <nse...@gm...> - 2014-04-11 12:40:36
|
hi, my name is Elizabeth. I am a Masters student doing a project on indoor position. I wish to use the RTT signal to find the signal arrival time. I read an article that mentioned modifying the madwifi drivers code. I am not sure how to start about solving this problem your help will be much appreciated. Regards, Elizabeth -- *Nobaene Elizabeth Sehloho* *"Life is all about knowing where your priorities lie*" |
From: Pavel R. <pr...@gn...> - 2014-02-05 04:10:33
|
Hello Michael, Quoting Michael Renzmann <mre...@ma...>: > As noted in the "reference edition" thread some weeks ago, I have pushed a > complete copy of the MadWifi subversion repository (including the full > history) to sf.net - see [1]. > > In order to complete the move, the next step is to switch the repository > on madwifi-project.org to read-only mode. If needs be, it would be > possible to commit to it at sf.net. I don't think it's needed. If anything bad happens to me or to the reference edition, it can always be forked. > Then I'll redirect all visitors accessing Trac's repository browser to the > corresponding facility at sf.net; the requested information will be > delivered, but from sf.net rather than from our Trac. For example, [2] > will be redirected to [3]. > > While at it, snapshot generation will be stopped - it didn't work properly > anyway. If anyone cares, I maybe write a short note explaining how to > download a snapshot of the branch/revision one needs right out of the > sf.net repository browser. Fine with me. Thank you for closing the project in a civilized manner! -- Regards, Pavel Roskin |
From: Michael R. <mre...@ma...> - 2014-02-04 19:53:46
|
Hi all. As noted in the "reference edition" thread some weeks ago, I have pushed a complete copy of the MadWifi subversion repository (including the full history) to sf.net - see [1]. In order to complete the move, the next step is to switch the repository on madwifi-project.org to read-only mode. If needs be, it would be possible to commit to it at sf.net. Then I'll redirect all visitors accessing Trac's repository browser to the corresponding facility at sf.net; the requested information will be delivered, but from sf.net rather than from our Trac. For example, [2] will be redirected to [3]. While at it, snapshot generation will be stopped - it didn't work properly anyway. If anyone cares, I maybe write a short note explaining how to download a snapshot of the branch/revision one needs right out of the sf.net repository browser. Bye, Mike [1] http://sourceforge.net/p/madwifi/svn/ [2] http://madwifi-project.org/changeset/4181 [3] http://sourceforge.net/p/madwifi/svn/4181/ |
From: Beat M. <mb...@sw...> - 2013-11-15 11:14:44
|
Hello First of all I know that madwifi is death (sadly to say that!!) I've just downloaded the source from git and tried to compile with kernel 2.6.23. This will not work anymore beause client will connect/disconect always... I'm really stucked because ath5k does not support well my cards I have (10dbm lower than madwifi and throughput 1/2 of madwifi) so I cannot go to ath5k with my 30 repeaters I have :-( Madwifi worked fine the last 5 years :-) Now I have more and more problems with ath_mgtstart: discard, no xmit buf which I almost never had. It seems to me that interferences produce this error. The fact is that the embedded board has 256MB but it hangs up because of low memory or to put network traffic over this repeater in this state... This seems to be independent of the used cards because i have this issue with Winstron CM9, SR5 and Compex WCLM54AGP23 So I try to fix this issue to go on with madwifi... I have now downloaded the source of the version with worked so long for me and want to solve this problem. Is there any help any infos which could be the problem? I have searched a lot of this issue but not found any solution. Thanks for any help!! Beat |
From: Pavel R. <pr...@gn...> - 2013-11-15 00:33:17
|
Hi Michael, On Thu, 14 Nov 2013 08:06:04 +0100 Michael Renzmann <mre...@ma...> wrote: > Hi Pavel (and all), > > the webserver including the svn repos is back online. Sorry for the > delay, but I don't check the various mailing lists on a regular > basis. Threfore it's better to send me a personal mail if there's any > issue with the server. > > I recently moved a copy of the comlete repos, including the full > history, to sf.net. My intention is to keep the repos - and in a next > step also the website - there, so that I may be able to shut our > server down at some point. Thank you for your effort! > Is your github fork meant to be a permanent institution? If so, I'd > vote to point people there by default, and keep the svn repos for > history only. Please let me know what you think. I'm fine with that. I feel more freedom about applying patches to the sources that are not the official MadWifi project. I would not make such big changes as the removal of support for Linux 2.6.12 and older in the MadWifi subversion repository, as I would feel obliged to ask in the lists, and I don't think I would hear anything interesting back. But if the MadWifi site just points to my repository and says that I'm maintaining MadWifi in a separate repository, that would be a good solution. I would have the moral obligation to keep it working, but I would be free from the need to consult with the (barely existing) community. The reason for dropping support for Linux 2.6.12 and older is that I found a dubious PDE macro that conflicted with the changes needed to support procfs changes in Linux 3.10. I tried to compile Linux 2.4.22 and found that I need so many things just to configure it and prepare for building modules - old compiler, old make, and even bash was giving me trouble so I had to use ksh. And then I would not be able to run that kernel on my hardware. To understand the changes made to the kernel, I would need to download historic Linux repositories converted from bitkeeper. I wrote scripts to test MadWifi with a large set of kernels (https://github.com/proski/kernel-farm), but it would need to be adapted for the 2.4 build system. That was way too much effort. Linux 2.6.13 was a natural cutoff point as it introduced WPA and WPA2 in wireless extensions 18. As we know, WEP is not considered secure these days. Yes, MadWifi could support WPA on older kernels, but it was ugly. I don't expect to apply any big changes, but I will apply bugfixes and cleanups (in reasonable amounts). -- Regards, Pavel Roskin |
From: Pavel R. <pr...@gn...> - 2013-11-14 23:53:09
|
On Thu, 14 Nov 2013 11:36:29 +0000 Nick Kossifidis <mic...@gm...> wrote: > 2013/11/14 Nick Kossifidis <mic...@gm...>: > > > > I think since you want to go that way, it would be nice to switch > > the binary HAL with the one from FreeBSD or Atheros's LegacyHAL, it > > should be easy to do so (API should still be the same) and it'll be > > much easier to compare ath5k/ath9k to madwifi+freebsdHAL/AtherosHAL > > since we'll also have source code access to the HAL. The reference edition is for those who want to run MadWifi on the bleeding edge kernels rather than dual boot. > Just noticed you've already done the switch, is it Atheros's HAL or > FreeBSD's ? It's MadWifi trunk. It was already present on github: https://github.com/puzzlet/madwifi I cloned it and applied the only patch that was present in the latest snapshot but not in that repository (removal of __devinitdata). -- Regards, Pavel Roskin |
From: Nick K. <mic...@gm...> - 2013-11-14 11:36:35
|
2013/11/14 Nick Kossifidis <mic...@gm...>: > > I think since you want to go that way, it would be nice to switch the > binary HAL with the one from FreeBSD or Atheros's LegacyHAL, it should > be easy to do so (API should still be the same) and it'll be much > easier to compare ath5k/ath9k to madwifi+freebsdHAL/AtherosHAL since > we'll also have source code access to the HAL. Just noticed you've already done the switch, is it Atheros's HAL or FreeBSD's ? -- GPG ID: 0xEE878588 As you read this post global entropy rises. Have Fun ;-) Nick |
From: Nick K. <mic...@gm...> - 2013-11-14 11:28:34
|
2013/11/13 Pavel Roskin <pr...@gn...>: > Hello! > > This might be of interest for developers working on ath5k and ath9k > drivers. It may be useful to have working MadWifi code for reference > to see how MadWifi accesses hardware registers, what packets it would > send, how it would communicate with other devices, how fast the > connections would be. > > I fully realize that the MadWifi code is ugly and I don't want anyone > to use it for any new serious project (I know that existing embedded > systems still use MadWifi). Still, it's very unhelpful for developers > that the MadWifi site is down and the MadWifi code doesn't compile for > the latest kernels. > > So I forked MadWifi on GitHub: > https://github.com/proski/madwifi > > Here's the summary of the changes I've made so far: > > Compilation fixed for Linux 3.10-3.12 and the current linux-next. > ath_info removed, it's should probably be maintained separately. > Removed integration with the official Subversion repository (it's down). > Removed support for Linux 2.6.12 and older, I have no time to compile > test it, let alone test the actual functionality. > Fixed compile errors in rare cases (e.g. SKB debugging and no VLAN). > Fixed some warnings, more fixes coming. > > The purpose of the changes is not to make MadWifi work better. The > purpose is to make it compile cleanly and serve as a working reference > for ath5k and ath9k development. > > -- > Regards, > Pavel Roskin I've already cloned ath-info to another repository since I don't have access to the madwifi's svn anymore and I wanted to add some functionality: https://github.com/mickflemm/ath-info I've also cloned madwifi-old-openhal there for reference (since -together with madwifi-trace, dadwifi etc- got deleted from the svn and it's not easy for someone to find them on old revisions-): https://github.com/mickflemm/madwifi-old-openhal I think since you want to go that way, it would be nice to switch the binary HAL with the one from FreeBSD or Atheros's LegacyHAL, it should be easy to do so (API should still be the same) and it'll be much easier to compare ath5k/ath9k to madwifi+freebsdHAL/AtherosHAL since we'll also have source code access to the HAL. However IMHO it should be much easier to compare FreeBSD to Linux than maintaining madwifi for this purpose, not only we have the latest net80211 code there, the HAL is also open source, maintained/updated, contains 11n support etc. I know that a lot of people are using MadWiFi on embedded systems -especially for ar5k chips- mostly due to turbo support (which we also have on ath5k, we just don't have a way to set it from userspace). I'd really like to see them contribute to ath5k to fit their needs than keep on using madwifi, even if their changes don't go upstream it'll still be much easier to maintain a patch that adds a feature on ath5k than keep on using madwifi. -- GPG ID: 0xEE878588 As you read this post global entropy rises. Have Fun ;-) Nick |
From: Michael R. <mre...@ma...> - 2013-11-14 07:36:51
|
Hi Pavel (and all), the webserver including the svn repos is back online. Sorry for the delay, but I don't check the various mailing lists on a regular basis. Threfore it's better to send me a personal mail if there's any issue with the server. I recently moved a copy of the comlete repos, including the full history, to sf.net. My intention is to keep the repos - and in a next step also the website - there, so that I may be able to shut our server down at some point. Is your github fork meant to be a permanent institution? If so, I'd vote to point people there by default, and keep the svn repos for history only. Please let me know what you think. Bye, Mike Pavel Roskin <pr...@gn...> wrote: >Hello! > >This might be of interest for developers working on ath5k and ath9k >drivers. It may be useful to have working MadWifi code for reference >to see how MadWifi accesses hardware registers, what packets it would >send, how it would communicate with other devices, how fast the >connections would be. > >I fully realize that the MadWifi code is ugly and I don't want anyone >to use it for any new serious project (I know that existing embedded >systems still use MadWifi). Still, it's very unhelpful for developers >that the MadWifi site is down and the MadWifi code doesn't compile for >the latest kernels. > >So I forked MadWifi on GitHub: >https://github.com/proski/madwifi > >Here's the summary of the changes I've made so far: > >Compilation fixed for Linux 3.10-3.12 and the current linux-next. >ath_info removed, it's should probably be maintained separately. >Removed integration with the official Subversion repository (it's >down). >Removed support for Linux 2.6.12 and older, I have no time to compile >test it, let alone test the actual functionality. >Fixed compile errors in rare cases (e.g. SKB debugging and no VLAN). >Fixed some warnings, more fixes coming. > >The purpose of the changes is not to make MadWifi work better. The >purpose is to make it compile cleanly and serve as a working reference >for ath5k and ath9k development. > >-- >Regards, >Pavel Roskin > >------------------------------------------------------------------------------ >DreamFactory - Open Source REST & JSON Services for HTML5 & Native Apps >OAuth, Users, Roles, SQL, NoSQL, BLOB Storage and External API Access >Free app hosting. Or install the open source package on any LAMP >server. >Sign up and see examples for AngularJS, jQuery, Sencha Touch and >Native! >http://pubads.g.doubleclick.net/gampad/clk?id=63469471&iu=/4140/ostg.clktrk >_______________________________________________ >Madwifi-devel mailing list >Mad...@li... >https://lists.sourceforge.net/lists/listinfo/madwifi-devel |
From: p0g0 <p0...@ma...> - 2013-11-13 13:45:12
|
Hi Beat, Mike fixed the madwifi-project.org HTTP bug (probably): the site's version of Apache doesn't handle vhosts with both HTTP & HTTPS services perfectly, but a bit of reconfiguring seems to have got it back on track. wh > Hi Beat, > >This is a bug. The site is still up on the https connection. The bug >first showed up last week and an Apache restart fixed it. I'll poke >Mike about it, but should you need to in the future, ping him on >#madwifi. > >wh >On 11/12/2013 05:56 AM, Beat Meier wrote: > Hello > > > What's going on with the madwifi project homepage > http://madwifi-project.org/? > I'ts shutdown or temp. not reachable? > > Greetings > > Beat > > ------------------------------------------------------------------------------ > November Webinars for C, C++, Fortran Developers > Accelerate application performance with scalable programming models. Explore > techniques for threading, error checking, porting, and tuning. Get the most > from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk > _______________________________________________ > Madwifi-devel mailing list > Mad...@li... > https://lists.sourceforge.net/lists/listinfo/madwifi-devel > |
From: Pavel R. <pr...@gn...> - 2013-11-13 00:52:02
|
Hello! This might be of interest for developers working on ath5k and ath9k drivers. It may be useful to have working MadWifi code for reference to see how MadWifi accesses hardware registers, what packets it would send, how it would communicate with other devices, how fast the connections would be. I fully realize that the MadWifi code is ugly and I don't want anyone to use it for any new serious project (I know that existing embedded systems still use MadWifi). Still, it's very unhelpful for developers that the MadWifi site is down and the MadWifi code doesn't compile for the latest kernels. So I forked MadWifi on GitHub: https://github.com/proski/madwifi Here's the summary of the changes I've made so far: Compilation fixed for Linux 3.10-3.12 and the current linux-next. ath_info removed, it's should probably be maintained separately. Removed integration with the official Subversion repository (it's down). Removed support for Linux 2.6.12 and older, I have no time to compile test it, let alone test the actual functionality. Fixed compile errors in rare cases (e.g. SKB debugging and no VLAN). Fixed some warnings, more fixes coming. The purpose of the changes is not to make MadWifi work better. The purpose is to make it compile cleanly and serve as a working reference for ath5k and ath9k development. -- Regards, Pavel Roskin |
From: p0g0 <p0...@ma...> - 2013-11-12 20:40:04
|
Hi Beat, This is a bug. The site is still up on the https connection. The bug first showed up last week and an Apache restart fixed it. I'll poke Mike about it, but should you need to in the future, ping him on #madwifi. wh On 11/12/2013 05:56 AM, Beat Meier wrote: > Hello > > > What's going on with the madwifi project homepage > http://madwifi-project.org/? > I'ts shutdown or temp. not reachable? > > Greetings > > Beat > > ------------------------------------------------------------------------------ > November Webinars for C, C++, Fortran Developers > Accelerate application performance with scalable programming models. Explore > techniques for threading, error checking, porting, and tuning. Get the most > from the latest Intel processors and coprocessors. See abstracts and register > http://pubads.g.doubleclick.net/gampad/clk?id=60136231&iu=/4140/ostg.clktrk > _______________________________________________ > Madwifi-devel mailing list > Mad...@li... > https://lists.sourceforge.net/lists/listinfo/madwifi-devel > |
From: Beat M. <mb...@sw...> - 2013-11-12 11:16:16
|
Hello What's going on with the madwifi project homepage http://madwifi-project.org/? I'ts shutdown or temp. not reachable? Greetings Beat |
From: Pavel R. <pr...@gn...> - 2013-08-07 16:13:54
|
On Fri, 2 Aug 2013 09:38:06 +0000 (UTC) Leo <leo...@gm...> wrote: > Dear Friends, > > I have got an error when using Madwifi to create several VAPs. > > I create two VAPs imitating the user guide's code > > wlanconfig ath create wlandev wifi0 wlanmode ap > > After creating two VAPs, it comes to the error > > wlanconfig: ioctl: Input/output error > > I have read about some docs said that in one physical device there > should only be one station mode VAP. But In my scenario, I just want > to create more than 2 VAPs in AP mode. Try removing the station VAP. You may want to use the autocreate parameter to avoid creating it. Also look at the maxvaps parameter. Try setting it to 8. > I was using an old version kernel 2.6.24-26-generic as the project is > based on an old version linux. And the madwifi version is svn r4126 > branch madiwifi- hal-0.10.5.6 > > Any suggestions or solutions? If possible, use the trunk. It was somewhat better maintained in the past, although MadWifi is not really maintained now. -- Regards, Pavel Roskin |