Bug#343047: madwifi-source: Please include a README.Debian to outline build process
Nate Bargmann wrote: Package: madwifi-source Version: 0.svn20051110-1 Severity: wishlist I decided to try the madwifi-source this evening and am at a bit of a loss on how to proceed. I followed the instructions I've used in the past at http://www.marlow.dk/site.php/tech/madwifi and performed the following: copied /boot/config-2.6.14-2-686 to /usr/src/linux/.config make-kpkg --append-to-version "-2-686" --revision 2.6.14-4 --config oldconfig configure make-kpkg --append-to-version "-2-686" --revision 2.6.14-4 --added-modules madwifi modules_image to build against the installed Debian linux-kernel package. After some output, the build process fails with the following error: # Build modules /usr/bin/make -C /usr/src/modules/madwifi \ CC=gcc LD=ld TOOLPREFIX= \ KERNELPATH=/usr/src/linux KERNELRELEASE=2.6.14-2-686 TARGET=i386-elf ATH_RATE=ath_rate/sample make[3]: Entering directory `/usr/src/modules/madwifi' Checking if all requirements are met... ok. mkdir -p ./symbols for i in ./ath_hal ./net80211 ath_rate/sample ./ath; do \ /usr/bin/make -C $i || exit 1; \ done make[4]: Entering directory `/usr/src/modules/madwifi/ath_hal' cp ./../hal/linux/ah_osdep.c ah_osdep.c uudecode ./../hal/public/i386-elf.hal.o.uu cp ./../hal/public/i386-elf.opt_ah.h opt_ah.h /usr/bin/make -C /usr/src/linux SUBDIRS=/usr/src/modules/madwifi/ath_hal MODVERDIR=/usr/src/modules/madwifi/ath_hal/../symbols modules make[5]: Entering directory `/usr/src/linux-source-2.6.14' WARNING: Symbol version dump /usr/src/linux-source-2.6.14/Module.symvers is missing; modules will have no dependencies and modversions. CC [M] /usr/src/modules/madwifi/ath_hal/ah_osdep.o /bin/sh: scripts/genksyms/genksyms: No such file or directory make[6]: *** [/usr/src/modules/madwifi/ath_hal/ah_osdep.o] Error 1 make[5]: *** [_module_/usr/src/modules/madwifi/ath_hal] Error 2 make[5]: Leaving directory `/usr/src/linux-source-2.6.14' make[4]: *** [all] Error 2 make[4]: Leaving directory `/usr/src/modules/madwifi/ath_hal' make[3]: *** [all] Error 1 make[3]: Leaving directory `/usr/src/modules/madwifi' make[2]: *** [binary-modules] Error 2 make[2]: Leaving directory `/usr/src/modules/madwifi' make[1]: *** [kdist_build] Error 2 make[1]: Leaving directory `/usr/src/modules/madwifi' Module /usr/src/modules/madwifi failed. Hit return to Continue The genksyms file seems is not yet built and I suspect that it won't be built until the kernel is built. Is this necessary? For the packages obtained from marlow.dk building the kernel was not necessary. It would be nice if the source package could provide some guidance about building the Madwifi modules using kernel-package. - Nate >> Hi Nate, Did you look at this effort to document the preferred process of installing madwifi? /usr/share/doc/madwifi-source/README.Debian If that is not sufficient or could be rephrased please let me know about it. Thanks, Kel. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#347860: [Pkg-spca5xx-devel] Bug#347860: spca5xx-source: make-kpkg module_image build fails (with kernel 2.6.14.6)
michel Xhaard wrote: Le Vendredi 13 Janvier 2006 05:35, Brad Sawatzky a écrit : Strange my original spca5xx-20051212 include on top of the spca50x.h file ? #ifdef __KERNEL__ #include #include #include #include #include Are you sure you are using the right source code ? Precisely what I was going to ask. Otavio submitted that same patch to Michel quite a few realeses ago, and spca5xx.h certainly includes linux/version as far as I can see. Please double check you have removed any previous spca5xx source from /usr/src/modules and unpacked the latest spca5xx source tarball. Thanks, Kel.
Bug#333237: Kanotix package for adm8211
Jean-Marc Ranger wrote: Hi Kel, Due to a recently arrived ipw2200, I'm loosing some interest in continuing to package the adm8211 code for Debian. Are you interessed in taking the ownership of the ITP bug in Debian ? Jean-Marc The in-kernel wireless code is too turbulent right now, and adm8211 is specific to each new kernel version now also, so I am not sure it is really suitable for inclusion in the debian archive. Also, I do not own the hardware to test the driver personally. So, no I will not take sole ownership of this ITP. Having said that, there will always be an adm8211-source package available at the previously mentioned location that will try to remain compatible to the latest stable kernel version (from kernel.org), for any interested parties. Thanks, Kel. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#345647: madwifi driver causes kernel oops
Graham wrote: Package: madwifi-source Version: 2005 I've built the module against the Debian "official" kernel 2.6.14-2-686 (version 2.6.14-7). I have a ThinkPad A22p and an Enterasys Networks PCMCIA a/b/g card. I will attach the output of "lspci -vvv". When I click "scan for networks" in kwifimanager, kwifimanager crashes, and dmesg shows this: How about when using the wireless tools from commandline for scanning? Does this also cause instability? Unable to handle kernel paging request at virtual address printing eip: e0aa9fff *pde = Oops: [#1] Modules linked in: r128 drm ipv6 thermal fan button processor ac battery nls_iso8859_1 nls_cp437 vfat fat ath_pci ath_rate_onoe wlan ath_hal joydev snd_cs46xx gameport snd_rawmidi snd_seq_device snd_ac97_codec snd_ac97_bus irtty_sir snd_pcm_oss snd_mixer_oss sir_dev uhci_hcd snd_pcm irda i2c_piix4 ide_cd cdrom psmouse snd_timer crc_ccitt floppy e100 mii yenta_socket rsrc_nonstatic pcmcia_core usbcore serio_raw snd soundcore snd_page_alloc pci_hotplug parport_pc parport intel_agp agpgart pcspkr i2c_core rtc ext3 jbd mbcache ide_disk generic ide_generic piix ide_core evdev mousedev CPU:0 EIP:0060:[]Tainted: P VLI EFLAGS: 00010246 (2.6.14-2-686) EIP is at read_ap_result+0x1bf/0x580 [wlan] eax: ebx: da2b5e9c ecx: edx: de0f8c00 esi: de0f8cf5 edi: d839401c ebp: d839401c esp: da2b5d84 ds: 007b es: 007b ss: 0068 Process kwifimanager (pid: 3795, threadinfo=da2b4000 task=da12a030) Stack: 0292 d5da12b0 da2b5db0 0292 da274998 0001 de144678 d8395000 da6c7e20 d5da1280 d5da1280 c02c4b64 0001 da6c7e20 0296 da6c7e20 d5da1280 d5da12b0 c025d452 Call Trace: [] unix_write_space+0x34/0x70 [] kfree_skbmem+0x42/0xa0 [] unix_stream_recvmsg+0x1ed/0x480 [] ieee80211_iterate_nodes+0x46/0x80 [wlan] [] ieee80211_ioctl_giwscan+0x68/0xc0 [wlan] [] read_ap_result+0x0/0x580 [wlan] [] wireless_process_ioctl+0x668/0x7d0 [] ath_ioctl_giwscan+0x0/0x20 [ath_pci] [] dev_ioctl+0x27d/0x2e0 [] do_ioctl+0x32/0x90 [] vfs_ioctl+0x60/0x1e0 [] sys_ioctl+0x88/0xa0 [] syscall_call+0x7/0xb Code: 8b 43 04 89 42 04 89 ca 8b 84 24 dc 00 00 00 89 50 10 c7 03 00 00 00 00 66 c7 43 02 05 8b 8b 94 24 e0 00 00 00 8b 82 28 01 00 00 <0f> b7 00 66 c7 43 08 01 00 69 c0 a0 86 01 00 89 43 04 8b 8c 24 Any ideas? Thanks -- graham It may be related to the inability of this module to do background scanning, or it could just be a plain old bug in the code. Try using the basic wireless-tools and refrain from using the graphical apps, and see if you can reproduce this instability. This version of the driver is the most stable offering from the madwifi project however it is still tagged as beta code, so it is known to cause instability on some hardware. Thanks, Kel. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#345647: madwifi driver causes kernel oops
Graham wrote: It may be related to the inability of this module to do background scanning, or it could just be a plain old bug in the code. Try using the basic wireless-tools and refrain from using the graphical apps, and see if you can reproduce this instability. Hi Kel, I'm just getting started with wireless networking on Linux, so I don't really know what I'm doing yet. But I'll do my best to help debug this. Once I bring the interface up, I can run "iwlist ath0 scanning" and it completes, and finds my access point. ath0 Scan completed : Cell 01 - Address: 00:06:25:3C:28:B9 ESSID:"My WLAN" Mode:Master Frequency:2.437 GHz (Channel 6) Quality=39/94 Signal level=-56 dBm Noise level=-95 dBm Encryption key:on Bit Rates:1 Mb/s; 2 Mb/s; 5 Mb/s; 6 Mb/s; 9 Mb/s 11 Mb/s; 12 Mb/s; 18 Mb/s; 24 Mb/s; 36 Mb/s 48 Mb/s; 54 Mb/s Extra:bcn_int=100 Extra:wpa_ie=dd160050f2010150f2020150f2020150f202 Well, in my experience these gui apps for configuring wireless on linux really cause more trouble than they are worth. Let me know if you'd like me to try anything else. I'm off to read about how to set up WPA PSK. http://madwifi.org/wiki/UserDocs/802.11i http://madwifi.org/wiki/UserDocs/WPA_PSK_on_Both_Ends Maybe these are helpful starting points for using WPA with madwifi. I would suggest executing wpa_supplicant from a pre-up line in the /etc/netwrok/interfaces file if using a static connection, this has proven to be stable on my equipment at least. For example:- auto ath0 iface ath0 inet dhcp pre-up wpa_supplicant -Dmadwifi -iath0 -c/etc/wpa_supplicant.conf -B post-down pkill -x wpa_supplicant Thanks, Kel. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#345647: madwifi driver causes kernel oops
Graham wrote: Hi Kel, Thank you for the links. Well, in my experience these gui apps for configuring wireless on linux really cause more trouble than they are worth. Maybe, but: 1. You and I are fine with console based configuration tools, but many people, including the owner of this laptop, will not touch them. The majority of users really do want a GUI. 2. Software should never crash. Error messages are fine when something goes wrong, but a crash is never acceptable, especially in kernel mode. So "don't use a GUI config tool" is only valid as a temporary workaround, not as a permanent solution. Never did I offer that as a solution, it was only a comment. These KDE and GNOME apps are quite often causing problems, as they are attempting to configure all different wireless cards, each based on very different code bases, and can work well with some drivers but expose weaknesses in others. For debugging purposes I simply suggest that you use the console . . . That said, I'm here to help, not to belittle your efforts. Let me know if there's anything I can do. I'm thinking about having a look at the code (ath_ioctl_giwscan). I'm pretty good with C, though not at all familiar with Linux kernel code. But it might be worth a shot. Sure, but there is a madwifi-ng driver now in development, so the upstream developers are not really maintaining this code much more, but it undoubtedly remains the most stable madwifi "branch". But who knows, it could be an easy fix . . . -- graham Thank you for reporting this bug and actively seeking the cause of it. Thanks, Kel. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#318022: Kanotix acerhk package
Hi, http://kanotix.com/files/debian/acerhk/ That package was made by your's truly for the Kanotix project. Although I am not officially involved with debian, I currently co-maintain some other module packages (spca5xx and madwifi) on alioth. If a developer would like to sponsor and co-maintain this in a similar fashion I'd be more than happy to help out. acer-acpi module may also be of interest. (for amd64 users) Thanks, Kel. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#333237: Kanotix package for adm8211
Hi, Package for these drivers are here:- http://kanotix.com/files/debian/pool/main/a/adm8211/ I also track the experimental new version that depends on the common ieee80211 stack (>=2.6.14) here:- ftp://debian.tu-bs.de/project/kanotix/experimental/pool/main/a/adm8211/ If you would like to use some of my efforts, I'd love to help out. Please contact me if you are interested. Thanks, Kel. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#339599: ITP: rt2570
Package: wnpp Severity: wishlist Hi, http://kanotix.com/files/debian/pool/main/r/rt2570/ Above are packages I developed as part of the Kanotix project. If there is any interest in them to be in debian (alongside the existing rt2400 & rt2500 packages), feel free to contact me concerning these efforts. Thanks, Kel. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#333237: Kanotix package for adm8211
Jean-Marc Ranger wrote: Hi Kel, I'll definitely have a look at what you did. I'm fairly new at Debian packaging, so I sure can learn from what you did. My version of the 20050620 driver is available at http://web.ncf.ca/jmranger/adm8211/ if you're interessed to have a look. It was discussed on debian-mentors about a month ago - thread starts at http://lists.debian.org/debian-mentors/2005/10/msg00056.html - but no sponsor showed up, so package hasn't been integrated yet. A new upstream stable version is available at http://aluminum.sourmilk.net/adm8211/adm8211-20051031.tar.bz2 which I plan to package shortly. It'll probably depends on ieee80211-source, but I still have to figure out how it works when a module is both provided by the kernel and a separate package. I'd gladly accept hints on that if you have some available ! When that version is packaged, I'll restart searching for a sponsor. Stay tuned :) Jean-Marc Maybe you'd like to use alioth svn and work on this together? Thanks, Kel. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#340487: madwifi-source: Missing step on mapping eth1 to ath_pci
Bill Wohler wrote: Package: madwifi-source Version: 0.svn20051110-1 Severity: normal Thanks for packaging madwifi. /usr/share/doc/madwifi-source/README.Debian is missing a step. If I create an /etc/network/interfaces stanza of iface eth1 inet dhcp wireless_essid my-SSID wireless_key mh-key and run "ifup eth1", I get: Error for wireless request "Set Encode" (8B2A) : SET failed on device eth1 ; No such device. Can you either describe how you map eth1 to the ath_pci module in your README, or could you create an /etc/modprobe.d/madwifi file that contains the appropriate aliases (or whatever is necessary to make this happen automatically)? For some reason, adding "alias eth1 ath_pci" to /etc/modprobe.d/local isn't working for me... Hi Bill, The README would better use ath0 as an example instead of eth1. eth1 was only meant to be an example of usage, which is well documented in "man interfaces". So I'll fix that oversight, thanks. "ifrename"; install it, read up on it. That is the tool that can reliably map interfaces to permanent aliases by mac adress (and other identifiers). Thanks, Kel. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#340487: madwifi-source: Missing step on mapping eth1 to ath_pci
Bill Wohler wrote: Kel Modderman <[EMAIL PROTECTED]> wrote: The README would better use ath0 as an example instead of eth1. Yes, that would clear things up a lot. I thought perhaps I was missing something. I have been using ath0. "ifrename"; install it, read up on it. Thanks for the reference. Also, the most recent Subversion snapshot seems to require a wlanconfig call to map wifi0 to ath0. How do you think you're going to handle that? (Rhetorical question: I'll find out ;-) In the packages designed for Kanotix, this is done by an external program udev script. ftp://debian.tu-bs.de/project/kanotix/experimental/pool/non-free/m/madwifi-ng Thanks, Kel. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#334392: [Pkg-spca5xx-devel] Bug#334392: spca5xx-20050601.tar.gz compiles on powerpc64
Paul Brossier wrote:
for info, i tried earlier versions of spca5xx from
http://mxhaard.free.fr/spca50x/Download/?M=D and found out that the last
version compiling on -powerpc64 is spca5xx-20050601
[EMAIL PROTECTED]:~/spca5xx-20050601$ make
Building SPCA5XX driver for 2.5/2.6 kernel.
Remember: you must have read/write access to your kernel source tree.
make -C /lib/modules/`uname -r`/build SUBDIRS=/home/piem/spca5xx-20050601
modules
make[1]: Entering directory `/usr/src/linux-headers-2.6.12-1-powerpc64'
CC [M] /home/piem/spca5xx-20050601/drivers/usb/spca5xx.o
/home/piem/spca5xx-20050601/drivers/usb/spca5xx.c: In function
‘spca50x_configure_sensor’:
/home/piem/spca5xx-20050601/drivers/usb/spca5xx.c:5690: warning: ISO C90
forbids mixed declarations and code
/home/piem/spca5xx-20050601/drivers/usb/spca5xx.c: In function ‘spca5xx_probe’:
/home/piem/spca5xx-20050601/drivers/usb/spca5xx.c:5855: warning: ‘defaultpipe’
may be used uninitialized in this function
/home/piem/spca5xx-20050601/drivers/usb/spca5xx.c:5854: warning: ‘defaultrows’
may be used uninitialized in this function
/home/piem/spca5xx-20050601/drivers/usb/spca5xx.c:5853: warning: ‘defaultcols’
may be used uninitialized in this function
CC [M] /home/piem/spca5xx-20050601/drivers/usb/spcadecoder.o
LD [M] /home/piem/spca5xx-20050601/spca5xx.o
Building modules, stage 2.
MODPOST
CC /home/piem/spca5xx-20050601/spca5xx.mod.o
LD [M] /home/piem/spca5xx-20050601/spca5xx.ko
make[1]: Leaving directory `/usr/src/linux-headers-2.6.12-1-powerpc64'
so far, the camera (041e:4034 Creative instant) is working great in
pd-pdp, but i can't get camorama, gphoto2 or gtkam to detect it. i found
the following in dmesg, with similar lines for each usb devices
(including the camera):
ioctl32(gtkam:5245): Unknown cmd fd(6) cmd(c00c5512){00} arg(fff990c8) on
/proc/bus/usb/003/008
ciao, piem
Thanks for your time piem, very appreciated!
The upstream authours have been informed and are now investigating.
Thanks, Kel.
Bug#304819: spca5xx debian package
Hi, By the time I saw this, there were a volley of replies to this first attempt at contact. Stephen Birch wrote: >Hi Kel and Itay > >One of the packages I have been planning for Debian is the spca5xx >package for which I filed a ITP some time back. Since I believed my >NM application was shortly to be completed I decided to not use my >normal sponsor for this package preferring to wait until I could do my >own uploads. > >Here is the ITP and associated comments: > >http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=304819 > >To my dismay the NM process is still not complete, the AM >just has too much work on his plate to complete the application. > > Heh, i saw the comment on the spca5xx download page too ; ) (Waiting . . . Waiting . . . ) >Recently several people have talked to me about using my sponsor for >the spca5xx package and not keep waiting for the NM queue. Okay >.. so I am now moving on this and want to get the package in Debian ASAP. > >Rechecking the ITP I noticed that Itay Ben-Yaacov pointed out that you >guys both have a package already complete. There is no point in >reinventing the wheel so Id like to use your work. > > Cool, How can I be of service? >I plan on dropping the changelog (if that is ok) entries but, of >course, give full credit in the README. I am writing to make sure you >are okay with this direction and to make sure you are happy with the approach. > > Sounds like a crap idea to me. I don't care whether my particular package has never had contact with the official debian distribution before. I've tried my best to improve on my package with each release and adhere to the strict debian policies in part of the effort to make Kanotix 100% debian. Even if a package does not come from the official debian repositories, its up to Stefan and I to make sure it is of debian standard in every way. Having said that, should our efforts not be documented as if this was going to be released into debian itself? >If you guys want to help with this (or even co-maintain) I'll put the >package online for your review before uploading to my sponsor. Since >you guys have already done the hard work it should be up quite soon. > >Steve > > > Sure, make an Alioth account, I'd love to share the experience of maintaining a quality package with other people who share the same enjoyment and freedom that debian gives them. Well, I made a few small updates in the past hour to my package to make it more suitable to enter debian and am confident that my work is of high enough quality to make it trivial to add the finishing touches (depending on your packaginging style perhaps). That is not assuming anything about the work of the other gentlemen in this equation, Itay, who seems to have been made uncomfortable by previous dealings with prospective DD(s). Likewise, I have been introduced into the world of debian development in a sour way. The "pkg-madwifi" project on Alioth is based on my efforts and I did not even have the opportunity of being able to reply to the wannabe maintainers request to "snatch" my efforts, so for sending this message to me is appreciated. (Even now I do not have write access to that svn repository) Anyway, to cut the story short, I don't want to have another bad experience, so just put the project into svn on Alioth. Let everybody look at it, propose some items that could be improved or worked on and discuss what actually needs to be done and by who. Thanks, Kel. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#304819: spca5xx debian package
Hi all, Stephen Birch wrote: >Hi Guys > >Just to bring you all up to date. We have been using SVN on >svn.debian.org to coordinate the package and will be maintaining it as >a team using Alioth at: > >https://alioth.debian.org/projects/pkg-spca5xx/ > >If you wish you can check out the source from >svn+alioth://svn.debian.org/svn/pkg-spca5xx/spca5xx/. > > Just remember Steve that "svn+alioth" is specific to the [tunnel] section of your own subversion config. >Don't go to the alioth CVS archives, we will be deleting those, consider >them obsolete. > >The package itself was uploaded to Debian on Saturday night by Otavio >who helped review and polish the code, thanks Otavio. > >The biggest thankyou must go to Kel who did an absolutely first class >job of creating this package in the first place. I am certain you will >like what you see of his work. Thanks Kel > >Steve > > > > > Otavio, I did some more thinking about the recent revamp of the rules, and i'd like to propose a small optimisation. diff -Nru spca5xx-20050906.1-current/debian/changelog spca5xx-20050906.1-new/debian/changelog --- spca5xx-20050906.1-current/debian/changelog2005-09-25 20:20:56.0 +1000 +++ spca5xx-20050906.1-new/debian/changelog2005-09-25 20:20:18.0 +1000 @@ -1,3 +1,11 @@ +spca5xx (20050906.1-2) UNRELEASED; urgency=low + + [Kel Modderman] + * Move staging area for module source from current dir to +debian/tmp and remove clean target rule in debian/rules. + + -- Kel Modderman <[EMAIL PROTECTED]> Sun, 25 Sep 2005 20:07:24 +1000 + spca5xx (20050906.1-1) unstable; urgency=low * Initial release from the Debian spca5xx Maintainers based diff -Nru spca5xx-20050906.1-current/debian/rules spca5xx-20050906.1-new/debian/rules --- spca5xx-20050906.1-current/debian/rules2005-09-25 20:20:56.0 +1000 +++ spca5xx-20050906.1-new/debian/rules2005-09-25 20:20:18.0 +1000 @@ -8,22 +8,19 @@ install/spca5xx-source:: # Enforce executable bit on debian/rules, and create directory structure for # modules source -install -D -m 0755 debian/rules.modules modules/spca5xx/debian/rules +install -D -m 0755 debian/rules.modules debian/tmp/modules/spca5xx/debian/rules # Prepare the other debian stuff for f in debian/*.modules.in debian/control debian/compat \ debian/copyright debian/changelog; do \ -install -m 0644 $$f modules/spca5xx/debian/; \ +install -m 0644 $$f debian/tmp/modules/spca5xx/debian/; \ done # Prepare upstream source find . -path ./debian/\* -type d -prune -o -printf "%P\n" | \ egrep -v 'debian' | \ -cpio -admp modules/spca5xx/ +cpio -admp debian/tmp/modules/spca5xx/ # Prepare the debian source tarball -tar jcf debian/spca5xx-source/usr/src/spca5xx-source.tar.bz2 modules -rm -rf modules - -clean:: -rm -rf modules +cd debian/tmp/ && \ +tar jcf ../spca5xx-source/usr/src/spca5xx-source.tar.bz2 modules It would make me more comfortable if the module source tarball was assembled out of $(CURDIR), where upstream exists. I propose we stage the tarball in debian/tmp. Its more portable to apply to the numerous modules packages I maintain for Kanotix and does not allow the oppurtunity to remove upstream files in "modules" existed in it (of course you would be stupid not to check first). This of course not a critical change and i doubt we'll be releasing another revision until new upstream source is available, but I'd like to hear some opinions before I commit this patch to svn. Thanks, Kel. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#304819: spca5xx debian package
Hey Otavio, Otavio Salvador wrote: >Kel Modderman <[EMAIL PROTECTED]> writes: > > > >>Otavio, I did some more thinking about the recent revamp of the rules, >>and i'd like to propose a small optimisation. >> >> > >I agree with all this patch. Only one optimisation: you don't need to >use clean target since cdbs already clean all contents of debian/tmp/ >and debian/. > >So it'll work without your new clean:: target. > >Do a test and commit :-D > >Thanks a lot. > > Clean target was also removed (if not in my patch, i meant it also to be removed). Will do it soon. Thanks, Kel. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#405104: [Pkg-spca5xx-devel] Bug#405104: gspca-source: New upstream release available
On Sunday 31 December 2006 20:46, Samuel Mimram wrote: > Package: gspca-source > Severity: wishlist > > Hi, > > Could you please package the 1.00.11 version of gspca which addds > support for the zc0321 chipsets? Sure. Will do so as soon as I can. Thanks, Kel. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#404483: madwifi Linux 2.6.20 support
On Tuesday 26 December 2006 00:45, Junichi Uekawa wrote: > Package: madwifi-source > Version: 1:0.9.2+r1842.20061207-3 > Tags: patch > > > Hi, > > I needed Linux 2.6.20 support; attached is a dpatch file for support. > Thanks. proski (Pavel Roskin) from upstream has claimed this very task. I was waiting paiently for him to return from his break ;-). Thanks, Kel. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#403727: [pkg-wpa-devel] Bug#403727: Dropouts have stopped
On Monday 22 January 2007 23:31, Maik Zumstrull wrote: > As of now, for no reason I can see, the dropouts have stopped. > > I have neither changed my WPA and ifupdown configuration nor upgraded > directly related packages; but still, the problem is gone. I assume > this is due to some package update that seems unrelated, but somehow > isn't, like avahi-autoipd or dhclient3. Who knows? > > With the maintainers blessing, I'm gonna give it another week or two > and if the problem stays gone, I'm gonna close this bug. If you insist > on closing it now, fine, but don't be surprised by a reopen if the > problem returns. :-) Please keep it open until you're satisfied it is really gone. Thanks, Kel. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#407936: [pkg-wpa-devel] Bug#407936: wpasupplicant: does not configure interface correctly when it is available at boot time
tags 407936 - patch
thanks
On Monday 22 January 2007 23:52, Ivan Zaera Avellon wrote:
> Package: wpasupplicant
> Version: 0.5.5-4
> Severity: normal
> Tags: patch
>
>
> When wpasupplicant is launched from /etc/wpa_supplicant/functions.sh it
> tries to use flag -W, which is supposed to make it wait until the wpa_cli
> attaches to the socket. The thing is, that the -W is not documented in
> wpasupplicant, and thus, it does not work (at least in my system). This
> causes wpa_cli to miss the CONNECTED event when the wireless network is
> available from the very first moment. As the event is missed, wpa_action is
> not called and the interface is not configured.
>
> I suggest changing the file /etc/wpa_supplicant/functions.sh, in function
> init_wpa_cli, so that after wpa_cli is launched, we force a disconnect with
> wpa_cli to make wpasupplicant reconnect again and send the CONNECTED event.
> The proposed code would be:
>
> init_wpa_cli () {
> if [ -n "$WPA_ACTION_SCRIPT" ]; then
> local WPA_CLI_OPTIONS
> WPA_CLI_OPTIONS="-B -P $WPA_CLI_PIDFILE -i $WPA_IFACE"
>
> wpa_msg verbose "$WPA_CLI_BIN $WPA_CLI_OPTIONS -p
> $WPA_CTRL_DIR -a $WPA_ACTION_SCRIPT"
>
> start-stop-daemon --start --oknodo $DAEMON_VERBOSITY \
> --name $WPA_CLI_PNAME --startas $WPA_CLI_BIN
> --pidfile $WPA_CLI_PIDFILE \ -- $WPA_CLI_OPTIONS -p $WPA_CTRL_DIR -a
> $WPA_ACTION_SCRIPT
>
> if [ "$?" != "0" ]; then
> wpa_msg stderr "$WPA_CLI_BIN daemon failed to
> start" return 1
> else
> wpa_msg verbose "force disconnect to assure that
> wpa_cli receives CONNECTED event" $WPA_CLI_BIN -P $WPA_CLI_PIDFILE -i
> $WPA_IFACE disconnect fi
> fi
> }
>
I nack this patch and propose that -W should be documented and fixed (it seems
to work for me just fine, but is clearly undocumented).
Can you please disclose your configuration?
Thanks, Kel.
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#405932: madwifi-source: Null Pointer BUG() Oops in procfs cleanup on modprobe -r ath-pci
Hi, On Sunday 07 January 2007 23:03, tom schorpp wrote: > Package: madwifi-source > Version: 1:0.9.2+r1842.20061207-2 > Severity: important > > Jan 7 11:35:17 tom3 kernel: BUG: unable to handle kernel NULL pointer > dereference at virtual address 0005 > Jan 7 11:35:17 tom3 kernel: printing eip: > Jan 7 11:35:17 tom3 kernel: c018604f > Jan 7 11:35:17 tom3 kernel: *pde = > Jan 7 11:35:17 tom3 kernel: Oops: [#1] > Jan 7 11:35:17 tom3 kernel: SMP > Jan 7 11:35:17 tom3 kernel: Modules linked in: wlan_scan_ap wlan_scan_sta > ath_pci ath_rate_sample wlan ath_hal bnep rfcomm l2cap bluetooth > snd_mixer_oss ip6table_filter ip6_tables ipv6 ipt_MASQUERADE iptable_nat > ip_nat ipt_TCPMSS xt_state ip_conntrack nfnetlink xt_limit xt_tcpudp > iptable_filter ip_tables x_tables parport_pc parport pcspkr ehci_hcd > 8139too 8139cp mii snd_ens1371 snd_rawmidi snd_seq_device snd_ac97_codec > snd_ac97_bus snd_pcm snd_timer snd snd_page_alloc es1371 gameport soundcore > ac97_codec i2c_piix4 i2c_core usblp uhci_hcd usbcore shpchp pci_hotplug > intel_agp agpgart sd_mod scsi_mod ide_cd cdrom rtc ext3 jbd mbcache > ide_disk generic piix ide_core evdev Jan 7 11:35:17 tom3 kernel: CPU:0 > Jan 7 11:35:17 tom3 kernel: EIP:0060:[remove_proc_entry+46/395] > Tainted: PF VLI Jan 7 11:35:17 tom3 kernel: EFLAGS: 00010286 > (2.6.18-3-686 #1) > Jan 7 11:35:17 tom3 kernel: EIP is at remove_proc_entry+0x2e/0x18b > Jan 7 11:35:17 tom3 kernel: eax: ebx: ecx: > edx: c29f7f80 Jan 7 11:35:17 tom3 kernel: esi: c53aa2c0 edi: 0005 > ebp: c53aa000 esp: c5941e8c Jan 7 11:35:17 tom3 kernel: ds: 007b es: > 007b ss: 0068 > Jan 7 11:35:17 tom3 kernel: Process modprobe (pid: 1030, ti=c594 > task=c94c2550 task.ti=c594) > Jan 7 11:35:17 tom3 kernel: Stack: c29f7f80 0005 c53aa2c0 > c3c882c4 c53aa000 ccb16d79 c53aa2c0 > Jan 7 11:35:17 tom3 kernel:c3c882c0 ccb00fab c3c882c0 c3c882c0 > c61f8000 c53aa2c0 ccabb34c c3c88000 > Jan 7 11:35:17 tom3 kernel:c61f8000 c3c882c0 c3c88000 c61f8000 > 0080 ccb0100c c3c882c0 ccab7c77 > Jan 7 11:35:17 tom3 kernel: Call Trace: > Jan 7 11:35:17 tom3 kernel: [pg0+209247609/1070027776] > ieee80211_sysctl_vdetach+0x63/0xc7 [wlan] > Jan 7 11:35:17 tom3 kernel: [pg0+209158059/1070027776] > ieee80211_vap_detach+0x83/0xd4 [wlan] > Jan 7 11:35:17 tom3 kernel: [pg0+208872268/1070027776] > ath_vap_delete+0x135/0x290 [ath_pci] > Jan 7 11:35:17 tom3 kernel: [pg0+209158156/1070027776] > ieee80211_ifdetach+0x10/0x75 [wlan] > Jan 7 11:35:17 tom3 kernel: [pg0+208858231/1070027776] > ath_detach+0x69/0xd5 [ath_pci] Jan 7 11:35:17 tom3 kernel: > [pg0+208890371/1070027776] ath_pci_remove+0x11/0x61 [ath_pci] Jan 7 > 11:35:17 tom3 kernel: [pci_device_remove+22/40] > pci_device_remove+0x16/0x28 Jan 7 11:35:17 tom3 kernel: > [__device_release_driver+90/114] > __device_release_driver+0x5a/0x72 > Jan 7 11:35:17 tom3 kernel: [driver_detach+96/141] > driver_detach+0x60/0x8d Jan 7 11:35:17 tom3 kernel: > [bus_remove_driver+87/117] bus_remove_driver+0x57/0x75 Jan 7 11:35:17 tom3 > kernel: [driver_unregister+8/19] driver_unregister+0x8/0x13 Jan 7 > 11:35:17 tom3 kernel: [pci_unregister_driver+12/88] > pci_unregister_driver+0xc/0x58 Jan 7 11:35:17 tom3 kernel: > [pg0+208891277/1070027776] exit_ath_pci+0xf/0x22 [ath_pci] Jan 7 11:35:17 > tom3 kernel: [sys_delete_module+429/468] sys_delete_module+0x1ad/0x1d4 Jan > 7 11:35:17 tom3 kernel: [remove_vma+49/54] remove_vma+0x31/0x36 Jan 7 > 11:35:17 tom3 kernel: [do_munmap+385/411] do_munmap+0x181/0x19b Jan 7 > 11:35:17 tom3 kernel: [sysenter_past_esp+86/121] > sysenter_past_esp+0x56/0x79 Jan 7 11:35:17 tom3 kernel: Code: 53 83 ec 08 > 85 d2 89 14 24 89 44 24 04 75 13 8d 4c 24 04 89 e2 e8 4f ff ff ff 85 c0 0f > 85 5f 01 00 00 8b 7c 24 04 31 c0 83 c9 ff ae f7 d1 49 b8 00 00 2d c0 > 89 cd e8 59 af 0f 00 8b 3c 24 8b > Jan 7 11:35:17 tom3 kernel: EIP: [remove_proc_entry+46/395] > remove_proc_entry+0x2e/0x18b SS:ESP 0068:c5941e8c > > steps to reproduce: > create the usual 3 sta,mon,ap vaps with bssid option from wifi0 > change mac of sta vap with ifconfig > ifup inet static x.x.3.1 ip ap vap > iwconfig sta vap to associate some remote ap > ifconfig x.x.1.y ip and route sta vap, ping remote ap with > 20% packet > loss maybe use airodump-ng with mon vap or dont > ifdown ap vap, sta vap, mon vap, wifi0 > modprobe -r ath-pci > ... > should BUG() with reboot necessary > I think VAP technology is still just too unstable to be usable. This trace looks very similar to that of #407270, and I swear I've seen it on the madwifi.org bug tracker numerous times. Will look into it. Thanks, Kel. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#405932: madwifi-source: Null Pointer BUG() Oops in procfs cleanup on modprobe -r ath-pci
On Tuesday 23 January 2007 10:18, thomas schorpp wrote: > Kel Modderman wrote: > > Hi, > > > > On Sunday 07 January 2007 23:03, tom schorpp wrote: > >>Package: madwifi-source > >>Version: 1:0.9.2+r1842.20061207-2 > >>Severity: important > >> > >>Jan 7 11:35:17 tom3 kernel: BUG: unable to handle kernel NULL pointer > >>dereference at virtual address 0005 > >>Jan 7 11:35:17 tom3 kernel: printing eip: > >>Jan 7 11:35:17 tom3 kernel: c018604f > >>Jan 7 11:35:17 tom3 kernel: *pde = > >>Jan 7 11:35:17 tom3 kernel: Oops: [#1] > >>Jan 7 11:35:17 tom3 kernel: SMP > >>Jan 7 11:35:17 tom3 kernel: Modules linked in: wlan_scan_ap > >> wlan_scan_sta ath_pci ath_rate_sample wlan ath_hal bnep rfcomm l2cap > >> bluetooth snd_mixer_oss ip6table_filter ip6_tables ipv6 ipt_MASQUERADE > >> iptable_nat ip_nat ipt_TCPMSS xt_state ip_conntrack nfnetlink xt_limit > >> xt_tcpudp iptable_filter ip_tables x_tables parport_pc parport pcspkr > >> ehci_hcd 8139too 8139cp mii snd_ens1371 snd_rawmidi snd_seq_device > >> snd_ac97_codec snd_ac97_bus snd_pcm snd_timer snd snd_page_alloc es1371 > >> gameport soundcore ac97_codec i2c_piix4 i2c_core usblp uhci_hcd usbcore > >> shpchp pci_hotplug intel_agp agpgart sd_mod scsi_mod ide_cd cdrom rtc > >> ext3 jbd mbcache ide_disk generic piix ide_core evdev Jan 7 11:35:17 > >> tom3 kernel: CPU:0 Jan 7 11:35:17 tom3 kernel: EIP: > >> 0060:[remove_proc_entry+46/395] Tainted: PF VLI Jan 7 11:35:17 tom3 > >> kernel: EFLAGS: 00010286 (2.6.18-3-686 #1) > >>Jan 7 11:35:17 tom3 kernel: EIP is at remove_proc_entry+0x2e/0x18b > >>Jan 7 11:35:17 tom3 kernel: eax: ebx: ecx: > >> edx: c29f7f80 Jan 7 11:35:17 tom3 kernel: esi: c53aa2c0 edi: > >> 0005 ebp: c53aa000 esp: c5941e8c Jan 7 11:35:17 tom3 kernel: ds: > >> 007b es: 007b ss: 0068 > >>Jan 7 11:35:17 tom3 kernel: Process modprobe (pid: 1030, ti=c594 > >>task=c94c2550 task.ti=c594) > >>Jan 7 11:35:17 tom3 kernel: Stack: c29f7f80 0005 c53aa2c0 > >>c3c882c4 c53aa000 ccb16d79 c53aa2c0 > >>Jan 7 11:35:17 tom3 kernel:c3c882c0 ccb00fab c3c882c0 c3c882c0 > >>c61f8000 c53aa2c0 ccabb34c c3c88000 > >>Jan 7 11:35:17 tom3 kernel:c61f8000 c3c882c0 c3c88000 c61f8000 > >>0080 ccb0100c c3c882c0 ccab7c77 > >>Jan 7 11:35:17 tom3 kernel: Call Trace: > >>Jan 7 11:35:17 tom3 kernel: [pg0+209247609/1070027776] > >>ieee80211_sysctl_vdetach+0x63/0xc7 [wlan] > >>Jan 7 11:35:17 tom3 kernel: [pg0+209158059/1070027776] > >>ieee80211_vap_detach+0x83/0xd4 [wlan] > >>Jan 7 11:35:17 tom3 kernel: [pg0+208872268/1070027776] > >>ath_vap_delete+0x135/0x290 [ath_pci] > >>Jan 7 11:35:17 tom3 kernel: [pg0+209158156/1070027776] > >>ieee80211_ifdetach+0x10/0x75 [wlan] > >>Jan 7 11:35:17 tom3 kernel: [pg0+208858231/1070027776] > >>ath_detach+0x69/0xd5 [ath_pci] Jan 7 11:35:17 tom3 kernel: > >>[pg0+208890371/1070027776] ath_pci_remove+0x11/0x61 [ath_pci] Jan 7 > >>11:35:17 tom3 kernel: [pci_device_remove+22/40] > >>pci_device_remove+0x16/0x28 Jan 7 11:35:17 tom3 kernel: > >>[__device_release_driver+90/114] > >>__device_release_driver+0x5a/0x72 > >>Jan 7 11:35:17 tom3 kernel: [driver_detach+96/141] > >>driver_detach+0x60/0x8d Jan 7 11:35:17 tom3 kernel: > >>[bus_remove_driver+87/117] bus_remove_driver+0x57/0x75 Jan 7 11:35:17 > >> tom3 kernel: [driver_unregister+8/19] driver_unregister+0x8/0x13 Jan 7 > >> 11:35:17 tom3 kernel: [pci_unregister_driver+12/88] > >>pci_unregister_driver+0xc/0x58 Jan 7 11:35:17 tom3 kernel: > >>[pg0+208891277/1070027776] exit_ath_pci+0xf/0x22 [ath_pci] Jan 7 > >> 11:35:17 tom3 kernel: [sys_delete_module+429/468] > >> sys_delete_module+0x1ad/0x1d4 Jan 7 11:35:17 tom3 kernel: > >> [remove_vma+49/54] remove_vma+0x31/0x36 Jan 7 11:35:17 tom3 kernel: > >> [do_munmap+385/411] do_munmap+0x181/0x19b Jan 7 11:35:17 tom3 kernel: > >> [sysenter_past_esp+86/121] > >>sysenter_past_esp+0x56/0x79 Jan 7 11:35:17 tom3 kernel: Code: 53 83 ec > >> 08 85 d2 89 14 24 89 44 24 04 75 13 8d 4c 24 04 89 e2 e8 4f ff ff ff 85 > >> c0 0f 85 5f 01 00 00 8b 7c 24 04 31 c0 83 c9 ff ae f7 d1 49 b8 00 > >> 00 2d c0 89 cd e8 59 af 0f 00 8b 3c 24 8b > >>Jan 7 11:35:17 tom3 kernel: EIP: [remove_proc_entry+46/395] > >>remove_proc_entry+0x2e/0x18b SS:ESP 0068:c5941e8c > >> > >>
Bug#407936: [pkg-wpa-devel] Bug#407936: wpasupplicant: does not configure interface correctly when it is available at boot time
On Tuesday 23 January 2007 20:31, Ivan Zaera Avellon wrote: > Hi Kel: > > It's OK for me to send you my configuration, but I need to know what you > want exactly. Your configuration looks fine. buzzard:/home/kel# wpa_supplicant -W -ieth1 -Dwext -c/etc/wpa_supplicant/wpa_supplicant-dummy.conf -d Initializing interface 'eth1' conf '/etc/wpa_supplicant/wpa_supplicant-dummy.conf' driver 'wext' ctrl_interface 'N/A' bridge 'N/A' Configuration file '/etc/wpa_supplicant/wpa_supplicant-dummy.conf' -> '/etc/wpa_supplicant/wpa_supplicant-dummy.conf' Reading configuration file '/etc/wpa_supplicant/wpa_supplicant-dummy.conf' ctrl_interface='/var/run/wpa_supplicant' Initializing interface (2) 'eth1' EAPOL: SUPP_PAE entering state DISCONNECTED EAPOL: KEY_RX entering state NO_KEY_RECEIVE EAPOL: SUPP_BE entering state INITIALIZE EAP: EAP entering state DISABLED EAPOL: External notification - portEnabled=0 EAPOL: External notification - portValid=0 SIOCGIWRANGE: WE(compiled)=21 WE(source)=18 enc_capa=0xf capabilities: key_mgmt 0xf enc 0xf WEXT: Operstate: linkmode=1, operstate=5 Own MAC address: 00:0e:35:18:2c:a3 wpa_driver_wext_set_wpa wpa_driver_wext_set_key: alg=0 key_idx=0 set_tx=0 seq_len=0 key_len=0 wpa_driver_wext_set_key: alg=0 key_idx=1 set_tx=0 seq_len=0 key_len=0 wpa_driver_wext_set_key: alg=0 key_idx=2 set_tx=0 seq_len=0 key_len=0 wpa_driver_wext_set_key: alg=0 key_idx=3 set_tx=0 seq_len=0 key_len=0 wpa_driver_wext_set_countermeasures wpa_driver_wext_set_drop_unencrypted Setting scan request: 0 sec 10 usec Added interface eth1 CTRL_IFACE - eth1 - wait for monitor That will wait until i use wpa_cli to connect to the control socket, which is the desired effect. Are you telling me this does not work for you? Thanks, Kel. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#402619: wpasupplicant: EAP-TTLS fails with encrypted passwords of tunnelled identity
On Tuesday 12 December 2006 03:17, Thomas Esselen wrote: > Package: wpasupplicant > Version: 0.5.5-3 > Severity: important > > Hi, > > please upgrade to a 0.6.0 snapshot since EAP-TTLS and encrypted passwords > for the tunnelled identity do not work with earlier releases: > > * fixed EAP-PEAP/TTLS/FAST to use the correct EAP identifier in > tunnelled identity request (previously, the identifier from the > outer method was used, not the tunnelled identifier which could be > different) > > Since encrypted password databases and missing client certificates are not > that unusual, it's an essential feature. Building an updated package works > fine if you drop the 11_erroneous_manpage_ref patch. > This report seems to have two motives. One is to report that EAP-PEAP/TTLS/FAST is not working, the other is to update to 0.6.0. I am sorry, a 0.6.X based wpasupplicant will not be in debian's archive until after all the ETCH release fuss is over. Hopefully an upload to experimental can be arranged though. Thanks, Kel. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#403045: [pkg-wpa-devel] Bug#403045: wpasupplicant: race condition in wpa_action disconnect between ifdown and if_post_down_up
Hi Henning, On Thursday 14 December 2006 20:33, Henning Glawe wrote: > I have configured a roaming wpa configuration on my laptop using > > allow-hotplug wlan0 > iface wlan0 inet manual > wpa-driver wext > wpa-roam /etc/wpa_supplicant.conf > > in /etc/network/interfaces. > > If a disconnect event occurs, wpa_action is called with the action > DISCONNECTED, which "ifdown"s the interface and then should immediately > re-enable the scanning mode by calling > /etc/wpa_supplicant/functions.sh::if_post_down_up Yep. Definitely a candidate area for some raciness. > > the problem is, at least in my case, that the link is _down_ afterwards, > so wpasupplicant is not able to scan further. This seems to be caused by > the interface not being completely downed yet when ifdown finishes; > putting a 'sleep 1' into functions.sh::ifdown immediately after the call > to /sbin/ifdown "solves" this problem. Yeah, I'm not a fan of unconditional sleeps though. Do you have iproute installed? That slighly changes behaviour of if_post_down_up, causing the interface to be flushed before 'upping' it again. Perhaps adding a `ifconfig $WPA_IFACE down' on the line before `ifconfig $WPA_IFACE up' in if_post_down_up would help in cases where iproute is not installed. In any case, ifdown should not exit until it has fully completed what it had to do with the interface, at least in my opinion. Thanks, Kel. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#386090: [pkg-wpa-devel] Bug#386090: scanning, mode changing influences problem with association
On Thursday 14 December 2006 22:19, Thomas Kallenberg wrote: > Could this be a driver issue? I have the same problem and I'm using the > madwifi-svn driver with wpasupplicant driver from unstable and > network-manager from etch. It is almost 100% likely to be an issue with the madwifi driver. > > I found this bugreport from madwifi driver: http://madwifi.org/ticket/1030 > > The issue can also be temporarily fixed by setting the driver in "g" mode > only: iwpriv $wlan mode 3, > then the network-manager can connect to the unencrypted network. > > If I dont do this, i can see with iwconfig, the "a"-mode is more often > scanned by iwconfig than the "b/g"-mode Interesting observation. and no real surprise to the madwifi people I think. Scanning and mode changing is currently a big pile of mess for those familiar with the internal code of the madwifi driver. Thanks, Kel. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#403313: [pkg-wpa-devel] Bug#403313: segfault if the interface is not present
Hi Eduard, On Saturday 16 December 2006 18:37, Eduard Bloch wrote: > I just discovered that current wpa_supplicant just segfaults if the > specified interface is not available at all. Here the log and strace > log, as executed by ifup: > > ifup eth1=kpax > ioctl[SIOCSIWPMKSA]: No such device > ioctl[SIOCSIWMODE]: No such device > Could not configure driver to use managed mode > ioctl[SIOCGIFFLAGS]: No such device > Could not set interface 'eth1' UP > ioctl[SIOCGIWRANGE]: No such device > ioctl[SIOCGIFINDEX]: No such device > /etc/wpa_supplicant/functions.sh: line 160: 27028 Segmentation fault > start-stop-daemon --start --oknodo $DAEMON_VERBOSITY --name > $WPA_SUP_PNAME --startas $WPA_SUP_BIN --pidfile $WPA_SUP_PIDFILE -- > $WPA_SUP_OPTIONS -D $WPA_SUP_DRIVER $WPA_SUP_CONF > wpa_supplicant: /sbin/wpa_supplicant daemon failed to start > run-parts: /etc/network/if-pre-up.d/wpasupplicant exited with return > code 1 > Internet Systems Consortium DHCP Client V3.0.4 > Copyright 2004-2006 Internet Systems Consortium. > All rights reserved. > For info, please visit http://www.isc.org/sw/dhcp/ > > SIOCSIFADDR: No such device > eth1: ERROR while getting interface flags: No such device > eth1: ERROR while getting interface flags: No such device > Confirmed. I've pinged upstream about this. Would be nicer if it had a sanity check before crashing and burning. $ sudo wpa_supplicant -c/etc/wpa_supplicant/wpa_supplicant.conf -Dwext -ifoo0 ioctl[SIOCSIWPMKSA]: No such device ioctl[SIOCSIWMODE]: No such device Could not configure driver to use managed mode ioctl[SIOCGIFFLAGS]: No such device Could not set interface 'foo0' UP ioctl[SIOCGIWRANGE]: No such device ioctl[SIOCGIFINDEX]: No such device Segmentation fault Thanks, Kel. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#403316: [pkg-wpa-devel] Bug#403316: complain on unknown ifupdown directives
Hi Eduard, On Saturday 16 December 2006 19:14, Eduard Bloch wrote: > I just hat to swear once again about wpa_supplicant. After consolidation > of my config some weeks ago I have kept "wpa-essid" directions there, > and I assumed that they are correct because nothing complained. However, > it does not work! wpa-ssid seems to be the correct one but that is not > obvious, and "essid" is the usual word for it, why should I look for > "ssid"? . . . because the wpasupplicant package documentation describes things with "ssid" and not "essid". The configurable options are described at: /usr/share/doc/wpasupplicant/README.modes.gz > > IMO wpa_supplicant should either accept wpa-essid (since those who are > switching from WEP had wep-essid in the config, not wep-ssid, *sic*), or > complain about unknown options but not let the user puzzle over the > weird and unexplainable misbehaviour. It will accept 'wpa-essid *' with the below patch. There are just way too many options supported by the wpa_supplicant ifupdown hooks to complain on unknown directives, IMHO, unless someone has a bright idea for whitelisting the currently supported options without introducing a huge maintenance burden (the scripts are aready quite large, at least one other person has made that quite clear to me). For this reason, I changed the bug title. Perhaps the script(s) should be a bit more verbose by default? Thanks, Kel. Index: functions.sh === --- functions.sh(revision 777) +++ functions.sh(working copy) @@ -459,6 +459,11 @@ IF_WPA_AP_SCAN="0" wpa_msg verbose "forcing ap_scan=0 (required for wired IEEE8021X auth)" fi + + if [ -n "$IF_WPA_ESSID" ]; then + # #403316, be similar to wireless tools + IF_WPA_SSID="$IF_WPA_ESSID" + fi wpa_cli_do "$IF_WPA_AP_SCAN" raw \ ap_scan wpa-ap-scan -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#403316: [pkg-wpa-devel] Bug#403316: complain on unknown ifupdown directives
On Monday 18 December 2006 07:39, Kel Modderman wrote: >For this reason, I changed the bug title. Didn't change it, becasue we may still yet have bright ideas ;-) Kel. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#403301: [pkg-wpa-devel] Bug#403301: wpasupplicant: segfaults with Cisco Aironet
severity 403301 important thanks Hi Matteo, Lowered severity, this does not meet grave bug criteria, IMHO. The package works fine with supported devices and did not cause you any harm. On Saturday 16 December 2006 11:50, Matteo Croce wrote: > Package: wpasupplicant > Version: 0.5.5-4 > Severity: grave > Justification: renders package unusable > > What's wrong here? > > [~]$ sudo wpa_supplicant -Dwext -ieth0 > -c/etc/wpa_supplicant/wpa_supplicant.conf ioctl[SIOCSIWAUTH]: Operation not > supported > WEXT auth param 7 value 0x1 - ioctl[SIOCSIWAUTH]: Operation not supported > WEXT auth param 4 value 0x0 - Failed to initialize control interface > '/var/run/wpa_supplicant'. You may have another wpa_supplicant process > already running or the file was left by an unclean termination of > wpa_supplicant in which case you will need to manually remove this file > before starting wpa_supplicant again. > Your device (its firmware) presumably does not support WPA. During some researching of these cisco aironet devices, I found a nice table of WPA support here: http://www.ippp.dur.ac.uk/Computing/wirelessLinux.html Its features are also well described here: http://www.hpl.hp.com/personal/Jean_Tourrilhes/Linux/Linux.Wireless.drivers.802.11b.html#Arlan802 Thanks, Kel. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#403313: [pkg-wpa-devel] Bug#403313: segfault if the interface is not present
Hi, > $ sudo wpa_supplicant -c/etc/wpa_supplicant/wpa_supplicant.conf -Dwext > -ifoo0 ioctl[SIOCSIWPMKSA]: No such device > ioctl[SIOCSIWMODE]: No such device > Could not configure driver to use managed mode > ioctl[SIOCGIFFLAGS]: No such device > Could not set interface 'foo0' UP > ioctl[SIOCGIWRANGE]: No such device > ioctl[SIOCGIFINDEX]: No such device > Segmentation fault Apparently this has been fixed upstream[1]. So if I or someone else from our team finds time, and more importantly the patch that fixed it (the upstream VSC is in a state of disrepair right now, iirc), it can be applied to the current package. Not many hints from his reply as to what the actual cause was. I may as well ask him directly . . . Thanks, Kel. [1] http://lists.shmoo.com/pipermail/hostap/2006-December/014761.html -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#403727: [pkg-wpa-devel] Bug#403727: Disconnects every few seconds on madwifi
Hi Maik, On Tuesday 19 December 2006 21:45, Maik Zumstrull wrote: > Package: wpasupplicant > Version: 0.5.5-4 > > When using wpa_supplicant in roaming mode on current Debian madwifi > (see attachment: package-versions), the connection drops every thirty > seconds or so. MadWifi sucks a bit in certain situations. Numerous people have reported scanning/association/mode changing issues. > This behavior is completely reproducible and occurs on any networks I > have tested it with, among them: > - My university WLAN with WPA-EAP > - My home network with WPA-PSK > - My university WLAN without any encryption > - The network of a local cafe using WEP-40 > > Each test on the university network has been performed in different > buildings, which use compatible configurations, but completely > different hardware (LANCOM vs. Trapeze Networks; DHCP and Radius > servers are shared). > > Where this is an option (i.e. the above networks without actual WPA), I > also tested using only the driver and ifupdown, without starting > wpa_supplicant. In this scenario, the dropouts do not occur. Dropouts do not occur? Or dropouts are not "noticed" because ifup/ifdown is not called when the driver borks? The roaming setup you use is very sensitive to driver stability, or lack of. Using static ifupdown stanzas on the other hand is quite insensitive to transient dropouts. Is it your opinion that these transient lapses in operation _only_ occur in conjunction with wpa_supplicant? Do you experience any momentary pauses in operation when not using wpa_supplcant? > > Note: I am aware that madwifi should theoretically be usable with both > -Dmadwifi and -Dwext, and that the latter is actually the recommended > configuration. On my system, -Dwext doesn't work at all, any > association attempt fails. With -Dmadwifi, the network is usable (for > seconds at a time) with the dropouts this report is about. > > Further attached information: > - The wpa_supplicant and ifupdown configuration files (shortened to > relevant sections, with private information removed; access to full > files can be granted via private mail if this is deemed necessary.) > - The output of a session of wpa_cli with debug level 0, time-stamped. > I waited for several dropouts to occur before ending the session. > The time-stamps appear to be pretty useless since wpa_cli seems to > dump its output in big chunks at a time. > > In the hope that I didn't just send this report and it turns out to be > a small dumb misconfiguration on my part, The attached files show no obvious configuration errors, so no, you have done nothing dumb in my opinion. Thanks, Kel. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#397274: trac: failure to upload attachments
Package: trac Version: 0.10-3 Severity: normal I was struck by a baffling problem described at http://trac.edgewall.org/ticket/3984 Summary: it is impossible to attach anything to the trac system with the combination of trac 0.10 and python 2.4.4. Attempting to do so would cause the following error message (in apache's logs): [error] [client 192.168.0.254] PythonHandler trac.web.modpython_frontend: TypeError: readline() takes exactly 1 argument (2 given), referer: ... The fix is queued for 0.10.1, and would be nice to have even earlier than that release, especially if the release is too late to squeeze into etch. Patch is attached. Taken from http://trac.edgewall.org/changeset/4038 Thanks, Kel. diff -Nrup trac-0.10.orig/trac/web/modpython_frontend.py trac-0.10/trac/web/modpython_frontend.py --- trac-0.10.orig/trac/web/modpython_frontend.py 2006-07-27 04:00:02.0 +1000 +++ trac-0.10/trac/web/modpython_frontend.py 2006-11-06 15:00:22.0 +1000 @@ -33,8 +33,8 @@ class InputWrapper(object): def read(self, size=-1): return self.req.read(size) -def readline(self): -return self.req.readline() +def readline(self, size=-1): +return self.req.readline(size) def readlines(self, hint=-1): return self.req.readlines(hint)
Bug#396055: [PATCH]: include sioq.[ch] in module tarball
tags 396055 + patch thanks Hi, Please apply attached patch. I think svenl's post above does not apply here, I saw the two files in the orig.tar.gz of current package with my own eyes. Kel. diff -u unionfs-1.3.20061029.0124+debian/debian/rules unionfs-1.3.20061029.0124+debian/debian/rules --- unionfs-1.3.20061029.0124+debian/debian/rules +++ unionfs-1.3.20061029.0124+debian/debian/rules @@ -61,7 +61,7 @@ # Copy files mkdir linux-2.6 cp Makefile.kernel linux-2.6/Makefile - cp branchman.c commonfops.c copyup.c dentry.c dirfops.c dirhelper.c file.c inode.c lookup.c main.c persistent_inode.c print.c rdstate.c rename.c stale_inode.c subr.c super.c unionfs.h unionfs_debug.h unionfs_imap.h unionfs_macros.h unlink.c xattr.c linux-2.6 + cp branchman.c commonfops.c copyup.c dentry.c dirfops.c dirhelper.c file.c inode.c lookup.c main.c persistent_inode.c print.c rdstate.c rename.c sioq.c sioq.h stale_inode.c subr.c super.c unionfs.h unionfs_debug.h unionfs_imap.h unionfs_macros.h unlink.c xattr.c linux-2.6 mv Makefile Makefile.upstream cp debian/Makefile Makefile diff -u unionfs-1.3.20061029.0124+debian/debian/changelog unionfs-1.3.20061029.0124+debian/debian/changelog --- unionfs-1.3.20061029.0124+debian/debian/changelog +++ unionfs-1.3.20061029.0124+debian/debian/changelog @@ -1,3 +1,12 @@ +unionfs (1.3.20061029.0124+debian-1.1) unstable; urgency=low + + * Non-maintainer upload. + * Include sioq.[ch] in line of configure-stamp debian/rules target that is +responsible for copying required upstream contents into debian module +source tarball staging area. + + -- Kel Modderman <[EMAIL PROTECTED]> Sun, 12 Nov 2006 12:21:59 +1000 + unionfs (1.3.20061029.0124+debian-1) unstable; urgency=low * New upstream snapshot:
Bug#398241: madwifi-source: Build fails on powerpc-be-elf (PPC32) with message "TARGET powerpc-elf is invalid"
Hi Ian, On Monday 13 November 2006 03:20, Ian MacDonald wrote: > Package: madwifi-source > Version: 1:0.9.2+r1784.20061027-1 > Severity: important > > The following is from the buildlog after executing #m-a a-i madwifi > > dh_testroot > dh_clean > /usr/bin/make -C /usr/src/modules/madwifi clean \ > KERNELPATH=/lib/modules/2.6.18-1-powerpc/build > KERNELRELEASE=2.6.18-1-powerpc > KERNELCONF=/lib/modules/2.6.18-1-powerpc/build/.config > ATH_RATE=ath_rate/sample > make[2]: Entering directory `/usr/src/modules/madwifi' > Makefile.inc:199: *** TARGET powerpc-elf is invalid, valid > targets are: alpha-elf ap30 ap43 ap51 ap61 arm9-le-thumb-elf > armv4-be-elf armv4-le-elf i386-elf mips1-be-elf mips1-le-elf > mips-be-elf mipsisa32-be-elf mipsisa32-le-elf mips-le-elf > powerpc-be-eabi powerpc-be-elf powerpc-le-eabi sh4-le-elf > sparc64-be-elf sparc-be-elf x86_64-elf xscale-be-elf > xscale-le-elf. Stop. > > Looking at the differences between the 1704 (which built fine) and 1784 > builds I noted the following changes: The /scripts/get_arch_target.sh was > replaced with /scripts/get_arch.sh > > In here there was previously some logic to add the "endianness" to the > TARGET; i.e. change TARGET=powerpc-elf to TARGET=powerpc-be-elf. This logic > seems to have been purged, or possibly moved elsewhere. > > Note that the debian patch07 to get_arch_target.sh (which no longer > exists after the rename) was in the changelog. Not sure if that was > still being patched, but if so needs to be updated. > > The workaround for PPC32-be users familiar with the module building > process is to just to drop a > TARGET=powerpc-be-elf into the /usr/src/modules/madwifi/Makefile.inc and > rebuild madwifi.tar.bz2, and re-execute m-a a-i madwifi. I forwarded this onto the upstream mailing list this morning[1] where Pavel Roskin stated[2] this is a problem he wants to fix very soon. Thanks, Kel. [1] http://article.gmane.org/gmane.linux.drivers.madwifi.devel/3449 [2] http://article.gmane.org/gmane.linux.drivers.madwifi.devel/3450 -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#400752: linux-modules-extra-2.6: include ndiswrapper
On Friday 01 December 2006 21:30, Bastian Blank wrote: > tags 400752 moreinfo > thanks > > On Wed, Nov 29, 2006 at 01:17:20AM +1000, Kel Modderman wrote: > > Package: linux-modules-extra-2.6 > > Severity: wishlist > > Tags: patch > > > > Please consider including ndiswrapper. Patch attached, based on existing > > support for spca5xx. > > There are reports that ndiswrapper won't work with 4k stack, please > prove. Yes, thats right. > Also I'm not sure if this may go into main at all, see ipw3945 > for the reasons. ipw3945 is in contrib, ndiswrapper in main. If you don't like this proposal (i knew it would have little chance anyway) then please tag wontfix. Thanks, Kel. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#401345: [Pkg-spca5xx-devel] Bug#401345: builds fine here..
On Sunday 03 December 2006 12:11, Andreas Henriksson wrote: > I can't reproduce your problem with spca5xx-source. How are you > building? > > I've tried building the spca5xx-source in an unstable amd64 pbuilder, > then installing the spca5xx-source package and building that with > module-assistant which > produces /usr/src/modass/spca5xx-modules-2.6.18-3-amd64_20060501-2 > +2.6.18-6_amd64.deb > > How did you reach the error? I too cannot reproduce error on amd64 or i386 with various 2.6.18 and 2.6.19 based kernels. BTW Andreas, gspca should be used now. It is the successor of spca5xx. Thanks, Kel -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#401441: wpasupplicant: Update to 0.5.5-3 breaks wireless connectivity
tags 400752 moreinfo thanks On Monday 04 December 2006 01:33, Gerrit Jan Baarda wrote: > Package: wpasupplicant > Version: 0.5.5-2 > Severity: important > > After upgrading to 0.5.5-3 my laptop (IPW2200) will not cannect to the > WLAN anymore. > > Here's the output of ifup/down: > > > wpa_supplicant: cannot read contents of managed > run-parts: /etc/network/if-down.d/wpasupplicant exited with return code > 1 > Not very helpful ouput. Please show your /etc/network/interfaces configuration, and output of 'ifup --verbose ethX' where ethX is the interface name of your NIC. Also, you can add 'wpa-maint-debug 1' to your interfaces stanza, and copy and paste the very verbose output of 'ifup ethX'. Thanks, Kel. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#401441: wpasupplicant: Update to 0.5.5-3 breaks wireless connectivity
tags 401441 moreinfo thanks Errm, helps when i use the correct bug number for manipulating tags (and luckily the tag i sent to the worng bug report was not unrelevant). -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#401413: wpasupplicant: Settings for wired network are ignored
tags 401413 patch thanks Hi Torquil, On Sunday 03 December 2006 21:19, Torquil Macdonald Sørensen wrote: > I am trying to connect to a wired network with IEEE8021X authentication. Ok. Something I admit to having very little experience with. > Thus I have no wpa-ssid line in /etc/network/interfaces, following the > advise given here: > http://lists.shmoo.com/pipermail/hostap/2006-November/014522.html > > But looking at the function conf_wpa_supplicant() in > /etc/wpasupplicant/functions.sh, the effect of not setting the ssid is > that none of the options, e.g. wpa-key-mgmt, wpa-identity, wpa-eap,... > are read from /etc/network/interfaces. I have the following paragraph in > the interfaces file: > > iface eth0 inet dhcp > wpa-ap-scan 0 > wpa-driver wired > wpa-key-mgmt IEEE8021X > wpa-eap PEAP > wpa-phase1 peaplabel=0 > wpa-phase2 auth=MSCHAPV2 > wpa-eapol-flags 0 > wpa-identity [secret] > wpa-password [secret] > > Best regards, Please try using attached diff to /etc/wpasupplicant/functions.sh Can you paste output of 'ifup --verbose eth0' and possibly add 'wpa-maint-debug 1' and give mass output from ifupdown.sh|functions.sh (set -x). Thanks, Kel. Index: functions.sh === --- functions.sh (revision 774) +++ functions.sh (working copy) @@ -188,11 +188,6 @@ if [ -n "$IF_WPA_DRIVER" ]; then WPA_SUP_DRIVER="$IF_WPA_DRIVER" wpa_msg verbose "wpa-driver $WPA_SUP_DRIVER" - - if [ "$IF_WPA_DRIVER" = "wired" ]; then -IF_WPA_AP_SCAN="0" -wpa_msg verbose "forcing ap_scan=0 (required for wired IEEE8021X auth)" - fi else WPA_SUP_DRIVER="wext" wpa_msg verbose "using default driver type: wpa-driver $WPA_SUP_DRIVER" @@ -459,6 +454,11 @@ if [ -n "$WPA_ACTION_SCRIPT" ]; then return 0 fi + + if [ "$IF_WPA_DRIVER" = "wired" ]; then + IF_WPA_AP_SCAN="0" + wpa_msg verbose "forcing ap_scan=0 (required for wired IEEE8021X auth)" + fi wpa_cli_do "$IF_WPA_AP_SCAN" raw \ ap_scan wpa-ap-scan @@ -466,7 +466,7 @@ wpa_cli_do "$IF_WPA_PREAUTHENTICATE" raw \ preauthenticate wpa-preauthenticate - if [ -n "$IF_WPA_SSID" ]; then + if [ -n "$IF_WPA_SSID" ] || [ "$IF_WPA_DRIVER" = "wired" ]; then case "$IF_WPA_SSID" in '"'*'"')
Bug#390884: [pkg-wpa-devel] Bug#390884: doesn't work well with acpi-support
On Friday 20 October 2006 20:41, Per Olofsson wrote: > Kel Modderman: > > Try something like: > > > > for x in $INTERFACES; do > > if test -x /sbin/wpa_action && \ > > wpa_action $x check; then > > wpa_action $x stop > > else > > ifdown $x > > fi > > done > > Works fine! Thanks! How shall we proceed from this point. Should wpasupplicant package provide a script hook, or should the above code be submitted as a patch to acpi-support package? Any other ideas? Thanks, Kel. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#401645: [pkg-wpa-devel] Bug#401645: wpasupplicant is stopped too early at reboot/shutdown
On Tuesday 05 December 2006 10:30, Przemyslaw Bruski wrote: > Package: wpasupplicant > Version: 0.5.5-2 > Severity: normal > > Currently, wpasupplicant is stopped before unmountnfs.sh script is run. > This means that the network connection for NFS mounts may be gone by the > time we try to unmount them and can cause the system to hang at reboot or > shutdown. > It seems that wpa-ifupdown (current priority 15) should be run later than > umountnfs.sh (current priority 31) . Of course you are right. However, sendsigs is run at sequence number 20, and it kills the wpa_supplicant process. So, we can remove wpa-ifupdown alltogether when the daemon is not killed prematurely by sendsigs. Until then, we opted to at least put down the interface cleanly. Any better ideas? Thanks, Kel. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#401645: wpasupplicant is stopped too early at reboot/shutdown
On Wednesday 06 December 2006 08:25, Przemyslaw Bruski wrote: > Hi Kel, > > > Of course you are right. However, sendsigs is run at sequence number 20, > > and it kills the wpa_supplicant process. > > Not anymore - http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=367944. > The maintainers have moved it to sequence number 37. Now umountnfs.sh > kills the processes that have to be killed in order to unmount the > filesystems. The new order is: > > 15 wpasupplicant > 31 umountnfs.sh > 37 sendsigs > > And it should be: > > 31 umountnfs.sh > xx wpasupplicant > 37 sendsigs I though I was either crazy, or you were whispering sweet nothings in my ear, because on my boxen sendsigs was still at sequence number 20. Then I found this in /usr/share/doc/initscripts/changelog.Debian.gz: sysvinit (2.86.ds1-35) unstable; urgency=medium * Undo use of fuser to kill processes in umountnfs before unmounting partitions, as it will kill init and /etc/init.d/rc during shutdown if root is on NFS or tmpfs file systems are bind-mounted into chroots. Use sendsigs and move it before umountnfs, and thus reopen bugs #258420, #367944. (Closes: #392861) -- Petter Reinholdtsen <[EMAIL PROTECTED]> Sun, 26 Nov 2006 20:06:00 +0100 Thanks, Kel. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#401809: [pkg-wpa-devel] Bug#401809: wpasupplicant: New upstream release available (0.5.6)
On Wednesday 06 December 2006 12:20, Sam Morris wrote: > Package: wpasupplicant > Version: 0.5.6-0 > Severity: wishlist > > Version 0.5.6 is available. I built an updated package that seems to work > fine by simply uupdating and then removing the (incorporated-upstream) > patch 'patch 11_erroneous_manpage_ref.patch'. It has been prepared in our SVN trunk, but will probably be uploaded post-etch, unless there is a compelling reason to do otherwise. Thanks, Kel. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#401441: [pkg-wpa-devel] Bug#401441: wpasupplicant: Update to 0.5.5-3 breaks wireless connectivity
On Saturday 09 December 2006 06:33, Gerrit Jan Baarda wrote: > Op maandag 4 december 2006 02:49, schreef Kel Modderman: > > Not very helpful ouput. > > > > Please show your /etc/network/interfaces configuration, and output > > of 'ifup --verbose ethX' where ethX is the interface name of your NIC. > > Please find attached the requested file and output. > > Hope this helps, Yes it does, thanks. Plese remove the line `wpa-conf managed' from your stanza. It was designed out of the new style of wpasupplicant/ifupdown config very early in development. Sorry for any confusion. Thanks, Kel. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#398466: NMU Ready
On Saturday 09 December 2006 08:00, Matt Brown wrote: > The fix described in the third post is incorrect. The backported patches > applied in -3 have already reordered this part of the code so that it > works correctly with madwifi. > > Unfortunately that backport missed the final component of the fix, which > was to all the hostapd_flush_old_stations call to fail when setting up > an interface. eg: > > http://hostap.epitest.fi/cgi-bin/viewcvs.cgi/hostap/hostapd/hostapd.c.diff? >r2=1.168&r1=1.167&diff_format=u > > I will upload an NMU fixing this shortly. NMU diff is attached Thanks very much. Kel. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#405104: [Pkg-spca5xx-devel] Bug#405104: gspca-source: New upstream release available
> > Package: gspca-source > > Severity: wishlist > > > > Hi, > > > > Could you please package the 1.00.11 version of gspca which addds > > support for the zc0321 chipsets? > > Sure. Will do so as soon as I can. > New upstream has been prepared in pkg-spca5xx SVN on svn.d.o. A package will be located at the following location until it is uploaded: http://users.tpg.com.au/sigm/debian/pkg-spca5xx/gspca_01.00.11-1.dsc Otavio, could you please review and upload this when time permits? Thanks, Kel. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#392759: [Pkg-spca5xx-devel] Bug#392759: spca5xx-source: Please package the gspcav1 driver.
On Wednesday 10 January 2007 06:12, Torsten Werner wrote: > Hi, > > > the bug report is now almost 90 days old. Do you plan to package the > newer driver? What, this one? http://packages.debian.org/unstable/graphics/gspca-source I guess #392759 can be closed . . . Thanks, Kel. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#405104: [Pkg-spca5xx-devel] Bug#405104: gspca-source: New upstream release available
On Tuesday 09 January 2007 11:30, Kel Modderman wrote: > > > Package: gspca-source > > > Severity: wishlist > > > > > > Hi, > > > > > > Could you please package the 1.00.11 version of gspca which addds > > > support for the zc0321 chipsets? > > > > Sure. Will do so as soon as I can. > > New upstream has been prepared in pkg-spca5xx SVN on svn.d.o. A package > will be located at the following location until it is uploaded: > > http://users.tpg.com.au/sigm/debian/pkg-spca5xx/gspca_01.00.11-1.dsc > > Otavio, could you please review and upload this when time permits? As per Michel's tip, the package was updated once again: http://users.tpg.com.au/sigm/debian/pkg-spca5xx/gspca_01.00.12-1.dsc or pkg-spca5xx gspca/trunk Thanks, Kel. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#400320: ndiswrapper: changing interface name from wlan0 to wlan1 since 1.23 to 1.28 update
On Saturday 25 November 2006 20:51, Fathi Boudra wrote: > There's something new in dmesg like "changing interface name": > ndiswrapper version 1.28 loaded (preempt=no,smp=yes) > ndiswrapper: driver sis163u (TRENDnet,11/20/2005,5.1.1039.1050) loaded > wlan0: vendor: 'Wireless Driver' > wlan0: ethernet device d8:f8:ba:d8:f8:ba using NDIS driver sis163u, > 0457:0163.F.conf > wlan0: encryption modes supported: WEP; TKIP with WPA, WPA2, WPA2PSK; > AES/CCMP with WPA, WPA2, WPA2PSK > ndiswrapper: changing interface name from 'wlan0' to 'wlan1' > ndiswrapper (wrap_procfs_add_ndis_device:364) wlan1 alread registred? > usbcore: registred new driver ndiswrapper > > Any clue to resolve the issue ? Perhaps check /etc/udev/rules.d/z25_persistent-net.rules for anomolies. Thanks, Kel. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#386092: [pkg-wpa-devel] Bug#386092: wpasupplicant: does not properly clean up interface on shutdown
On Sunday 26 November 2006 00:45, Marc Haber wrote: >> This looks like it would be an artifact of the problem you reported as >> #386090. I don't think I can answer this with any integrity without further >> information, as addressed on your previous bug report. > >I think that all information requested in #386090 was delivered. Is >there still something missing? If I knew all the answers, you would be the first to know. Kel. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#400750: linux-modules-extra-2.6: remove spca5xx
Package: linux-modules-extra-2.6 Severity: wishlist Tags: patch Please remove spca5xx. The gspca module (from same author) supercedes it. Patch to include gspca will be in a seperate report. Thanks, Kel. diff -Nrup linux-modules-extra-2.6-2.6.18.orig/defines linux-modules-extra-2.6-2.6.18/defines --- linux-modules-extra-2.6-2.6.18.orig/defines 2006-10-05 19:23:49.0 +1000 +++ linux-modules-extra-2.6-2.6.18/defines 2006-11-29 00:53:36.0 +1000 @@ -1,7 +1,6 @@ [base] modules: redhat-cluster - spca5xx squashfs unionfs diff -Nrup linux-modules-extra-2.6-2.6.18.orig/spca5xx/copyright linux-modules-extra-2.6-2.6.18/spca5xx/copyright --- linux-modules-extra-2.6-2.6.18.orig/spca5xx/copyright 2006-08-22 08:09:20.0 +1000 +++ linux-modules-extra-2.6-2.6.18/spca5xx/copyright1970-01-01 10:00:00.0 +1000 @@ -1,43 +0,0 @@ -This package was debianised by Otavio Salvador on Tue, 20 Dec 2005. - -It is maintained by the Debian spca5xx Maintainers on alioth.debian.org. -<[EMAIL PROTECTED]> - -This source package is Debian native, but relies on the spca5xx project's -source code to produce binaries. - -Copyright Holders: - -Stephen Birch <[EMAIL PROTECTED]> -Kel Modderman <[EMAIL PROTECTED]> -Otavio Salvador <[EMAIL PROTECTED]> -Itay Ben-Yaacov <[EMAIL PROTECTED]> - -This package is licenced under the terms of the GNU General Public Licence. - -On Debian systems, the complete text of the GNU GPL can be found in -/usr/share/common-licenses/GPL. - -spca5xx source code copyright -- -Copyright Holders: - -Current spca5xx maintainer and project lead: -Michel Xhaard <[EMAIL PROTECTED]> -Michel Xhaard (mxhaard) -Reza Jelveh (timebomb) -Tomas Groth (tgc) - -Original authors: -Joel Crisp <[EMAIL PROTECTED]> -Current spca50x maintainer and project lead: -Miah Gregory <[EMAIL PROTECTED]> -Francois Beerten <[EMAIL PROTECTED]> -Miah Gregory <[EMAIL PROTECTED]> -Till Adam <[EMAIL PROTECTED]> -The jpeg decoder was originally written by Michael Schroeder <[EMAIL PROTECTED]> -and adjusted to our purposes. All bugs are ours, all features his. - -This source code is licenced under the terms of the GNU GPL. -On Debian systems, the complete text of the GNU GPL can be found in -/usr/share/common-licenses/GPL. diff -Nrup linux-modules-extra-2.6-2.6.18.orig/spca5xx/defines linux-modules-extra-2.6-2.6.18/spca5xx/defines --- linux-modules-extra-2.6-2.6.18.orig/spca5xx/defines 2006-08-22 08:09:20.0 +1000 +++ linux-modules-extra-2.6-2.6.18/spca5xx/defines 1970-01-01 10:00:00.0 +1000 @@ -1,12 +0,0 @@ -[base] -arches: - amd64 - i386 - powerpc -desc: spca5xx video for linux (v4l) driver -longdesc: - spca5xx provides support for webcams and digital cameras based on - the spca5xx range of chips manufactured by SunPlus Sonix Z-star - Vimicro Conexant Etoms and Transvision. - . - Homepage: http://mxhaard.free.fr/spca5xx.html diff -Nrup linux-modules-extra-2.6-2.6.18.orig/spca5xx/rules linux-modules-extra-2.6-2.6.18/spca5xx/rules --- linux-modules-extra-2.6-2.6.18.orig/spca5xx/rules 2006-08-22 08:09:20.0 +1000 +++ linux-modules-extra-2.6-2.6.18/spca5xx/rules1970-01-01 10:00:00.0 +1000 @@ -1 +0,0 @@ -$(SOURCE_STAMP): TAR = /usr/src/$(MODULE)-source.tar.bz2
Bug#400751: linux-modules-extra-2.6: include gspca
Package: linux-modules-extra-2.6 Severity: wishlist Tags: patch Please consider including the gspca module. Patch attached (based on same structure spca5xx used). gspca module should enter testing anytime now. Thanks, Kel. diff -Nrup linux-modules-extra-2.6-2.6.18.orig/defines linux-modules-extra-2.6-2.6.18/defines --- linux-modules-extra-2.6-2.6.18.orig/defines 2006-11-29 00:53:36.0 +1000 +++ linux-modules-extra-2.6-2.6.18/defines 2006-11-29 00:55:21.0 +1000 @@ -1,5 +1,6 @@ [base] modules: + gspca redhat-cluster squashfs unionfs diff -Nrup linux-modules-extra-2.6-2.6.18.orig/gspca/copyright linux-modules-extra-2.6-2.6.18/gspca/copyright --- linux-modules-extra-2.6-2.6.18.orig/gspca/copyright 1970-01-01 10:00:00.0 +1000 +++ linux-modules-extra-2.6-2.6.18/gspca/copyright 2006-10-04 10:01:44.0 +1000 @@ -0,0 +1,62 @@ +This package was debianized by Kel Modderman <[EMAIL PROTECTED]> on +Wed, 4 Oct 2006 12:35:59 +1000. + +It was downloaded from http://mxhaard.free.fr/download.html + +Upstream Author: Michel Xhaard <[EMAIL PROTECTED]> + +The following files contain multiple copyright holders: + +decoder/gspcadecoder.c + Copyright (C) 2003 2004 2005 Michel Xhaard [EMAIL PROTECTED] + Sonix Decompressor by Bertrik.Sikken. (C) 2004 + Pixart Decompressor by Bertrik.Sikken. Thomas Kaiser (C) 2005 + Spca561decoder (C) 2005 Andrzej Szombierski [EMAIL PROTECTED] + +Mars-Semi/mr97311.h + Copyright (C) 2005 <[EMAIL PROTECTED]> + +Pixart/pac207.h + Copyright (C) 2005 Thomas Kaiser [EMAIL PROTECTED] + Copyleft (C) 2005 Michel Xhaard [EMAIL PROTECTED] + +Sonix/sonix.h + Copyright (C) 2003 2004 Michel Xhaard [EMAIL PROTECTED] + Stefano Mozzi (C) 2004 + +Vimicro/cs2102.h + Copyright (C) 2004 2005 Michel Xhaard [EMAIL PROTECTED] + Copyright (C) 2005 Alvaro Salmador [EMAIL PROTECTED] + +Vimicro/pas106b.h + Copyright (C) 2005 Thomas Kaiser [EMAIL PROTECTED] + +Vimicro/tas5130c_fv0250.h + Copyright (C) 2004 Michel Xhaard [EMAIL PROTECTED] + Copyright (C) 2006 Serge Suchkov [EMAIL PROTECTED] + +All other files contained in this distribution are: + + Copyright (C) 2004 - 2006 Michel Xhaard [EMAIL PROTECTED] + +License: + + This package is free software; you can redistribute it and/or modify + it under the terms of the GNU General Public License as published by + the Free Software Foundation; either version 2 of the License, or + (at your option) any later version. + + This package is distributed in the hope that it will be useful, + but WITHOUT ANY WARRANTY; without even the implied warranty of + MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the + GNU General Public License for more details. + + You should have received a copy of the GNU General Public License + along with this package; if not, write to the Free Software + Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA + +On Debian systems, the complete text of the GNU General +Public License can be found in `/usr/share/common-licenses/GPL'. + +The Debian packaging is (C) 2006, Kel Modderman <[EMAIL PROTECTED]> and +is licensed under the GPL, see above. diff -Nrup linux-modules-extra-2.6-2.6.18.orig/gspca/defines linux-modules-extra-2.6-2.6.18/gspca/defines --- linux-modules-extra-2.6-2.6.18.orig/gspca/defines 1970-01-01 10:00:00.0 +1000 +++ linux-modules-extra-2.6-2.6.18/gspca/defines2006-11-29 00:44:48.0 +1000 @@ -0,0 +1,13 @@ +[base] +arches: + amd64 + i386 + powerpc +desc: gspca video for linux (v4l) driver +longdesc: + The gpsca video for linux (v4l) driver, provides support for + webcams and digital cameras based on the spca5xx range of chips + manufactured by SunPlus, Sonix, Z-star, Vimicro, Conexant, Etoms, + Mars-semi, Pixart and Transvision. + . + Homepage: http://mxhaard.free.fr/index.html diff -Nrup linux-modules-extra-2.6-2.6.18.orig/gspca/rules linux-modules-extra-2.6-2.6.18/gspca/rules --- linux-modules-extra-2.6-2.6.18.orig/gspca/rules 1970-01-01 10:00:00.0 +1000 +++ linux-modules-extra-2.6-2.6.18/gspca/rules 2006-11-29 00:42:48.0 +1000 @@ -0,0 +1 @@ +$(SOURCE_STAMP): TAR = /usr/src/$(MODULE)-source.tar.bz2
Bug#400752: linux-modules-extra-2.6: include ndiswrapper
Package: linux-modules-extra-2.6 Severity: wishlist Tags: patch Please consider including ndiswrapper. Patch attached, based on existing support for spca5xx. Thanks, Kel. diff -Nrup linux-modules-extra-2.6-2.6.18.orig/defines linux-modules-extra-2.6-2.6.18/defines --- linux-modules-extra-2.6-2.6.18.orig/defines 2006-11-29 00:55:21.0 +1000 +++ linux-modules-extra-2.6-2.6.18/defines 2006-11-29 00:56:22.0 +1000 @@ -1,6 +1,7 @@ [base] modules: gspca + ndiswrapper redhat-cluster squashfs unionfs diff -Nrup linux-modules-extra-2.6-2.6.18.orig/ndiswrapper/copyright linux-modules-extra-2.6-2.6.18/ndiswrapper/copyright --- linux-modules-extra-2.6-2.6.18.orig/ndiswrapper/copyright 1970-01-01 10:00:00.0 +1000 +++ linux-modules-extra-2.6-2.6.18/ndiswrapper/copyright2006-10-28 01:53:50.0 +1000 @@ -0,0 +1,63 @@ +This package was debianized by Erik Rigtorp <[EMAIL PROTECTED]> on +Mon, 23 Feb 2004 17:48:38 +0100. + +This package is currently maintained by Andres Salomon <[EMAIL PROTECTED]> +and Kel Modderman <[EMAIL PROTECTED]> as of Oct. 2006. + +It was downloaded from http://ndiswrapper.sourceforge.net/ + +The upstream authors: +Pontus Fuchs - Main developer. +Giridhar Pemmasani - Main developer. + +The following files contained within the ndiswrapper source package are +part of the GNU C Library and covered by the GNU Lesser General Public +License: + + driver/pe_linker.h + driver/divdi3.c + driver/longlong.h + +Copyright (C) 1991, 1992, 1994, 1995, 1996, 1997, 1998, 1999, 2000 +Free Software Foundation, Inc. + +The GNU C Library is free software; you can redistribute it and/or +modify it under the terms of the GNU Lesser General Public +License as published by the Free Software Foundation; either +version 2.1 of the License, or (at your option) any later version. + +The GNU C Library is distributed in the hope that it will be useful, +but WITHOUT ANY WARRANTY; without even the implied warranty of +MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the GNU +Lesser General Public License for more details. + +You should have received a copy of the GNU Lesser General Public +License along with the GNU C Library; if not, write to the Free +Software Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA +02110-1301 USA + +On Debian systems, the full text of the LGPL can be found in +/usr/share/common-licenses/LGPL + +The remaining files contained within the ndiswrapper source package are +GPL licensed. + +Copyright (C) 2003-2005 Pontus Fuchs, Giridhar Pemmasani +Copyright (C) 2006 Giridhar Pemmasani + +This program is free software; you can redistribute it and/or modify +it under the terms of the GNU General Public License as published by +the Free Software Foundation; either version 2 of the License, or +(at your option) any later version. + +This program is distributed in the hope that it will be useful, +but WITHOUT ANY WARRANTY; without even the implied warranty of +MERCHANTABILITY or FITNESS FOR A PARTICULAR PURPOSE. See the +GNU General Public License for more details. + +You should have received a copy of the GNU General Public License +along with this program; if not, write to the Free Software +Foundation, Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA + +On Debian systems, the full text of the GPL can be found in +/usr/share/common-licenses/GPL diff -Nrup linux-modules-extra-2.6-2.6.18.orig/ndiswrapper/defines linux-modules-extra-2.6-2.6.18/ndiswrapper/defines --- linux-modules-extra-2.6-2.6.18.orig/ndiswrapper/defines 1970-01-01 10:00:00.0 +1000 +++ linux-modules-extra-2.6-2.6.18/ndiswrapper/defines 2006-11-29 00:49:02.0 +1000 @@ -0,0 +1,14 @@ +[base] +arches: + amd64 + i386 +desc: +longdesc: ndis wlan 802.11abg wrapper for linux + Some vendors do not release specifications of the hardware or provide a + Linux driver for their wireless network cards. This project implements + Windows kernel API and NDIS (Network Driver Interface Specification) API + within Linux kernel. A Windows driver for wireless network card is then + linked to this implementation so that the driver runs natively, as though + it is in Windows, without binary emulation. + . + Homepage: http://ndiswrapper.sf.net diff -Nrup linux-modules-extra-2.6-2.6.18.orig/ndiswrapper/rules linux-modules-extra-2.6-2.6.18/ndiswrapper/rules --- linux-modules-extra-2.6-2.6.18.orig/ndiswrapper/rules 1970-01-01 10:00:00.0 +1000 +++ linux-modules-extra-2.6-2.6.18/ndiswrapper/rules2006-11-29 00:42:48.0 +1000 @@ -0,0 +1 @@ +$(SOURCE_STAMP): TAR = /usr/src/$(MODULE)-source.tar.bz2
Bug#394606: (no subject)
On Sunday 29 October 2006 13:31, Nathaniel W. Filardo wrote: > According to http://madwifi.org/ticket/925 this is fixed in r1755. Yeah, I was the one who tested and applied the patch. Kel. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#393491: [pkg-wpa-devel] Bug#393491: doesn't exit when ifup is cancelled
On Tuesday 17 October 2006 01:22, martin f krafft wrote: > Package: wpasupplicant > Version: 0.5.5-2 > Severity: normal > > If I use ifupdown integration, wpa_supplicant starts up nicely as > expected. It associates with the AP and then dhclient (called by > ifup) tries to get a lease. However, if I cancel dhclient, > wpa_supplicant continues to live. It would be nice if wpa_supplicant > could tie in with ifup in such a way that a non-zero exit code from > dhclient (or whatever other configuration method is being used) > would kill wpa_supplicant as well. This smells and sounds like a feature request for ifupdown, as there is no way to tell if ifupdown has failed at some stage, because it returns no signal to existing children, or even scripts waiting to be called. Perhaps this request should be reassigned to ifupdown package? Thanks, Kel. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#396137: Does not connect in roaming mode, only after wpa_cli -i $iface scan
On Monday 30 October 2006 11:50, Michael Biebl wrote: > Package: wpasupplicant > Version: 0.5.5-2 > Severity: normal > > I tried the new modes of wpa_supplicant using /e/n/i. > Using "wpa-conf /path/to/config" works fine but unfortunately blocks the > boot process. But when I use the new roaming mode (which is quite nicely > implemented btw.), my card, a ipw2100, does not associate. > If I login and run "wpa_cli -i wlan0 scan" manually, I get a connection a > few seconds later. So my guess is, that in roaming mode the card is not > properly initialized to do scanning. Curious, does a "ifconfig wlan0 up" achieve same result as invoking scan via wpa_cli? Thanks, Kel. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#394836: libqt4-dev: qmake : cannot find -lmysqlclient_r
Hi, This is causing wpasupplicant to FTBFS (wpagui requires libqt4-dev). I'd love to do some finishing touches to wpasuppliant before etch, but cannot while this is blocking it. Kel. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#396137: Does not connect in roaming mode, only after wpa_cli -i $iface scan
On Wednesday 01 November 2006 02:22, Michael Biebl wrote: > See also http://bugs.debian.org/cgi-bin/bugreport.cgi?bug=342887 > > Maybe we should add #342887 as blocker for this bug? Looks like that is exactly why you have problems, interesting (and damn frustrating!). Please do add that report as blocker for this problem. Thanks, Kel. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#396648: ITP: rt73 -- Linux device driver for Ralink RT73 a/b/g WLAN Card
On Thursday 02 November 2006 08:55, Piotr Roszatycki wrote: > Package: wnpp > Severity: wishlist > Owner: Piotr Roszatycki <[EMAIL PROTECTED]> > > * Package name: rt73 > Upstream author : Paul Lin <[EMAIL PROTECTED]> > Version : 1.0.3.6 > * URL : > http://www.ralinktech.com/drivers/Linux/RT73_Linux_STA_Drv1.0.3.6.tar.gz * > License : GPL > Programming Lang: C > Description : Linux device driver for Ralink RT73 a/b/g WLAN Card > > I am the owner of USB-stick Wi-Fi network interface (Edimax EW-7318Ug). The > only working driver is Ralink RT73 original driver. I'd like to see this > driver in Debian distribution. > > I want to provide rt73-source package which is compatible with > module-assistant. The resulting package (rt73-module-$VERSION) contains > rt73.ko driver. The driver loads firmware from separate file and has > included the blob with the default firmware if separate file is not > available. > > I think the driver can go to contrib with removed the blob from its sources > and with the firmware rt73.bin file can go to non-free as rt73-firmware > package. > > The rt73.bin file is marked as GPL. There is no real source code included > but this license implies that it is redistributable file at least as > non-free. I notice you quote upstream origin is ralinktech.com, but what about the rt73 drivers from rt2x00 project[1], that are maintained and bugfixed by a bunch of cool hackers, and are the origin of the existing rt2400, rt2500, rt2570 and rt2x00 source packages already in debian? Thanks, Kel. [1] http://rt2x00.serialmonkey.com/ -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#398466: hostapd 0.5.5-3 serious regression with madwifi
Package: hostapd Version: 1:0.5.5-3 Severity: grave Justification: renders package unusable The subtle changes between 0.5.5-2 and 0.5.5-3 have exposed a showstopping bug when used in conjunction with certain madwifi driver versions (specifically 0.9.2+r1784.20061027-1 currently in debian). This should not pass into testing, where 0.5.5-2 is working perfectly. Further information will follow. Thanks, Kel. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#398466: hostapd 0.5.5-3 serious regression with madwifi
On Tuesday 14 November 2006 08:43, Kel Modderman wrote: > Package: hostapd > Version: 1:0.5.5-3 > Severity: grave > Justification: renders package unusable > > The subtle changes between 0.5.5-2 and 0.5.5-3 have exposed a > showstopping bug when used in conjunction with certain madwifi driver > versions (specifically 0.9.2+r1784.20061027-1 currently in debian). > > This should not pass into testing, where 0.5.5-2 is working perfectly. > > Further information will follow. It is exactly this problem: http://lists.shmoo.com/pipermail/hostap/2006-October/014354.html I propose that we revert recent backport of fixes/enhancements to the driver_madwifi code, so that we can at leas take advantage of the partial hostapd support (everything != plaintext) that has proven to be working well in the released version 0.5.5. Thanks, Kel. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#398820: [pkg-wpa-devel] Bug#398820: wpasupplicant: WPA works but WEP key do not
On Thursday 16 November 2006 05:38, Anand Kumria wrote:
> I use the ipw2200 driver (from 2.6.18-rc2) and with the following in
> /etc/network/interface I can intermittedly associate but never get an IP
> address allocation via DHCP:
>
> iface wlan0 inet dhcp
> wpa-ssid MyWiFi
> wpa-psk ABACADAEAF
> up ifmetric wlan0 1
This configuration is for associating and authenticating with access point
using the WPA or WPA-2 (Wifi Protected Access) encryption standard[1] using
PSK (Pre Shared Key). Client side authentication management is via
wpa_supplicant.
If you used this config to connect to a WEP encrypted access point, you would
periodically associate, but fail to authenticate soon after. This process
would cycle indefinitely.
>
>
> However, if I use this instead, everything Just Works:
>
> iface wlan0 inet dhcp
> wireless-ssid MyWiFi
> wireless-mode Managed
> wireless-key1 ABACADAEAF
> up ifmetric wlan0 1
This configuration is for associating and authenticating with an access point
using the WEP (Wired Equivalent Privacy) encryption standard[2]. Client side
authentication settings are managed via iwconfig from wireless-tools.
>
> Let me know what, if anything, you want me to test. I'm unsure where to
> begin and/or what I might need to provide.
>
Since you seem to be comparing apples to oranges, there is clearly no tests to
be done to fix the problem you describe above, as the only problem I can see
is misinformation.
Do you have a reason for using wpa_supplicant for a static configuration
defined in /etc/network/interfaces when the stanza using wireless-tools magic
hooks Just Works?
If you did, a wpa_supplicant.conf block for connecting to a WEP access point
would look like:
network={
ssid="MyWiFi"
key_mgmt=NONE
wep_key0=ABACADAEAF
wep_tx_keyidx=0
}
Translated to be used from /etc/network/interfaces:
iface wlan0 inet dhcp
wpa-ssid MyWiFi
wpa-key-mgmt NONE
wpa-wep-key0 ABACADAEAF
wpa-wep-tx-keyidx 0
And although the above is a theroetically supported configuration (via the
wpasupplicant/ifupdown scripts) I still question why you would prefer this
method for a statically defined network when wireless-tools is all that is
required.
Thanks, Kel.
[1] http://en.wikipedia.org/wiki/Wi-Fi_Protected_Access
[2] http://en.wikipedia.org/wiki/Wired_Equivalent_Privacy
--
To UNSUBSCRIBE, email to [EMAIL PROTECTED]
with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#404483: is built but does not work
On Wednesday 07 February 2007 20:11, Max Alekseyev wrote: > I've tried to use the proposed patch with the released Linux kernel 2.6.20 > from kernel.org While it does help to build the madwifi modules, they do > not work properly. Namely, I get the following error when the modules > start: > > wifi%%d: unable to attach hardware: '' (HAL status 3222512051) > > and no wifi device is created. > I do not know if this error is related to the patch. If not, should I file > a new bugreport? > > P.S. The wifi device works perfectly with madfiwi driver under kernel > 2.6.19 (on the same system with the same settings). madwifi upstream (SVN) is compatible with 2.6.20. I am working with some others to get a new upstream release out, then we can get it into debian. Get a recent testing snapshot from here in the meantime: http://users.tpg.com.au/sigm/debian/pkg-madwifi/ http://users.tpg.com.au/sigm/debian/pkg-madwifi/madwifi_0.9.2+r2085.20070207-1.dsc Thanks, Kel. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#410113: [Pkg-spca5xx-devel] Bug#410113: gspca-source: does not build with 2.6.20
tags 410113 moreinfo thanks On Thursday 08 February 2007 05:28, Torsten Werner wrote: > Package: gspca-source > Version: 01.00.12-1 > Severity: normal > > Hi, > > it does not build any more. > Attach some build output/proof please? # Build the module /usr/bin/make -C /home/kel/src/modules/gspca KERNEL_VERSION=2.6.20-kel-1 KERNELDIR=/home/kel/src/linux make[4]: Entering directory `/home/kel/src/modules/gspca' /usr/bin/make -C /home/kel/src/linux SUBDIRS=/home/kel/src/modules/gspca CC=gcc-4.1 modules make[5]: Entering directory `/home/kel/src/linux-2.6.20-kel-1' CC [M] /home/kel/src/modules/gspca/gspca_core.o CC [M] /home/kel/src/modules/gspca/decoder/gspcadecoder.o LD [M] /home/kel/src/modules/gspca/gspca.o Building modules, stage 2. MODPOST 1 modules CC /home/kel/src/modules/gspca/gspca.mod.o LD [M] /home/kel/src/modules/gspca/gspca.ko make[5]: Leaving directory `/home/kel/src/linux-2.6.20-kel-1' make[4]: Leaving directory `/home/kel/src/modules/gspca' # Install the module Thanks, Kel. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#410164: ndiswrapper-source: New upstream version available
On Thursday 08 February 2007 19:56, Kai Weber wrote: > Package: ndiswrapper-source > Version: 1.30-1 > Severity: wishlist > > Hello, > > a new upstream version for ndiswrapper is available: 1.37. This version > fixes incompatibilty with kernel version 2.6.20, and the annoying hang, > when devicenames are changed. > > Could you please package it? As you wish, sire. http://users.tpg.com.au/sigm/debian/ndis/ http://users.tpg.com.au/sigm/debian/ndis/ndiswrapper_1.37-1.dsc Please let me know how/if it works for you. Thanks, Kel. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#332668: [ndiswrapper]: Causes kernel oops intermittently
Hi Neil, Is ndiswrapper still unstable for you? or #332668 still valid? Thanks, Kel. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#345647: [madwifi]: madwifi driver causes kernel oops
Hi Graham, I am wondering, is the current madwifi still unstable as hell for you? Is this bug still valid? Thanks, Kel. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#401397: [ndiswrapper]: Unable to remove ndiswrapper module
Hi Andrea, Is this also the case with: http://users.tpg.com.au/sigm/debian/ndis/ http://users.tpg.com.au/sigm/debian/ndis/ndiswrapper_1.37-1.dsc Thanks, Kel. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#407936: [pkg-wpa-devel] Bug#407936: wpasupplicant: does not configure interface correctly when it is available at boot time
On Monday 22 January 2007 23:52, Ivan Zaera Avellon wrote: > Package: wpasupplicant > Version: 0.5.5-4 > Severity: normal > Tags: patch > > > When wpasupplicant is launched from /etc/wpa_supplicant/functions.sh it > tries to use flag -W, which is supposed to make it wait until the wpa_cli > attaches to the socket. The thing is, that the -W is not documented in > wpasupplicant, and thus, it does not work (at least in my system). This > causes wpa_cli to miss the CONNECTED event when the wireless network is > available from the very first moment. As the event is missed, wpa_action is > not called and the interface is not configured. I reproduced this problem. You did not supply a 'ctrl_interface' value in your configuration, therefore no UNIX socket for communication with wpa_cli was created, and wpa_supplicant did not take notice of the '-W' (wait for wpa_cli attachment to ctrl_interface) option accordingly. Please confirm my findings. I updated the documentation for wpa-roam as below: Index: debian/README.modes === --- debian/README.modes (revision 778) +++ debian/README.modes (working copy) @@ -262,6 +262,11 @@ cp /usr/share/doc/wpasupplicant/examples/wpa_supplicant.conf.template \ /etc/wpa_supplicant/wpa_supplicant.conf +NOTE: it is critical that the used wpa_supplicant.conf defines the location of + the 'ctrl_interface' so that a communication socket is created for the + wpa_cli (wpa-roam daemon) to attach. The mentioned example conf file, + wpa_supplicant.conf.template, has this set to a sane default. + It is required to edit this configuration file, and add the network blocks for all known networks. If you do not understand what this means, start reading the wpa_supplicant.conf(5) manpage now. Thanks, Kel. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#412179: [pkg-wpa-devel] Bug#412179: D-Bus interface
Hi Michael,
On Saturday 03 March 2007 12:22, Michael Biebl wrote:
> Hi,
>
> you will also very likely need the attached patch:
> Debian does not use pam_console but uses group membership to control
> access to D-Bus. Activating both options in the conf file makes it work
> on Debian and Ubuntu.
Thanks very much.
>
> About activating the service, you will very likely have to provide a
> D-Bus init script (for /etc/dbus-1/event.d/) comparable to the one from
> dhcdbd.
Ok. How would the sequnce number of the wpa_supplicant event.d scriplet be
determined?
Attached is the patch I recently commited to SVN, can you please check it?
Also, an experimental package has been prepared at:
http://users.tpg.com.au/sigm/debian/pkg-wpa/wpasupplicant_0.6.0~cvs20070224-1.dsc
> I don't think that NetworkManager uses D-Bus's service autostart
> activation, but you can install the attached wpa_supplicant.service to
> /usr/share/dbus-1/service/ anyway, for applications that use that
> mechanism.
Added.
Thanks, Kel.
Index: debian/changelog
===
--- debian/changelog (revision 799)
+++ debian/changelog (working copy)
@@ -29,13 +29,16 @@
* Install a service file to /usr/share/dbus-1/services/ for dbus aware
applications that may take advantage of that in the future (Michael
Biebl).
+ * Add a dbus event hook for starting wpa_supplicant as a system service.
+ * Add prerm and postinst handling for reloading dbus daemon, and restarting
+or stopping the wpa_supplicant dbus daemon on configure/remove.
* Add support to ifupdown.sh for `wpa-mode' and `wpa-frequency' options used
in IBSS mode. Note that ifupdown.sh does not do any sanity checking for
the other many requirements for using wpa_supplicant in IBSS mode.
* Update XS-Vcs-* fields in control file, add Vcs-Browser token.
* Move debian spcific ifupdown sh glue into debian/ifupdown/.
- -- Kel Modderman <[EMAIL PROTECTED]> Sun, 4 Mar 2007 14:06:46 +1000
+ -- Kel Modderman <[EMAIL PROTECTED]> Sun, 4 Mar 2007 15:17:27 +1000
wpasupplicant (0.5.5-4) unstable; urgency=low
Index: debian/rules
===
--- debian/rules (revision 799)
+++ debian/rules (working copy)
@@ -25,6 +25,8 @@
debian/wpasupplicant/sbin/wpa_action
install --mode=644 -D dbus-wpa_supplicant.conf \
debian/wpasupplicant/etc/dbus-1/system.d/wpa_supplicant.conf
+ install --mode=755 -D debian/dbus/wpa_supplicant.dbus-event \
+ debian/wpasupplicant/etc/dbus-1/event.d/23wpa_supplicant
install --mode=644 -D debian/dbus/wpa_supplicant.service \
debian/wpasupplicant/usr/share/dbus-1/services/wpa_supplicant.service
dh_installinit --name=wpa-ifupdown --no-start \
Index: debian/dbus/wpa_supplicant.dbus-event
===
--- debian/dbus/wpa_supplicant.dbus-event (revision 0)
+++ debian/dbus/wpa_supplicant.dbus-event (revision 0)
@@ -0,0 +1,56 @@
+#!/bin/sh
+#
+# wpa_supplicant D-Bus daemon
+#
+# Debian/Ubuntu wpasupplicant Maintainers <[EMAIL PROTECTED]>
+#
+
+set -e
+
+PATH=/usr/local/sbin:/usr/local/bin:/sbin:/bin:/usr/sbin:/usr/bin
+DESC="wpa_supplicant D-Bus daemon"
+NAME="wpa_supplicant"
+PIDFILE="/var/run/$NAME.dbus.pid"
+DAEMON="/sbin/$NAME"
+DAEMON_OPTS="-u -B -P $PIDFILE"
+SCRIPTNAME="/etc/dbus-1/event.d/23$NAME"
+
+test -x $DAEMON || exit 0
+
+. /lib/lsb/init-functions
+
+d_start() {
+ start-stop-daemon --start --quiet --pidfile $PIDFILE \
+ --exec $DAEMON -- $DAEMON_OPTS
+}
+
+d_stop() {
+ start-stop-daemon --stop --quiet --pidfile $PIDFILE \
+ --oknodo --exec $DAEMON
+}
+
+case "$1" in
+ start)
+ log_daemon_msg "Starting $DESC" "$NAME"
+ d_start
+ log_end_msg $?
+ ;;
+ stop)
+ log_daemon_msg "Stopping $DESC" "$NAME"
+ d_stop
+ log_end_msg $?
+ ;;
+ restart|force-reload)
+ log_daemon_msg "Restarting $DESC" "$NAME"
+ d_stop
+ sleep 5
+ d_start
+ log_end_msg $?
+ ;;
+ *)
+ echo "Usage: $SCRIPTNAME {start|stop|restart|force-reload}" >&2
+ exit 1
+ ;;
+esac
+
+exit 0
Index: debian/wpasupplicant.postinst
===
--- debian/wpasupplicant.postinst (revision 796)
+++ debian/wpasupplicant.postinst (working copy)
@@ -43,6 +43,16 @@
if dpkg --compare-versions "$2" lt "0.4.8-1"; then
rm_init_script
fi
+
+ # Ask the bus to reload the config file
+ if [ -x /etc/init.d/dbus ]; then
+ invoke-rc.d dbus force-reload || true
+ fi
+
+ # Restart wpa_supplicant D-Bus service
+ if [ -x /etc/dbus-1/event.d/23wpa_supplicant ]; then
+ /etc/dbus-1/event.d/23wpa_supplicant restart
+ fi
;;
abort-upgrade|abort-deconfigure|abort-remove)
Index: debian/wp
Bug#412179: [pkg-wpa-devel] Bug#412179: D-Bus interface
On Sunday 04 March 2007 16:17, Kel Modderman wrote: > Hi Michael, > > On Saturday 03 March 2007 12:22, Michael Biebl wrote: > > Hi, > > > > you will also very likely need the attached patch: > > Debian does not use pam_console but uses group membership to control > > access to D-Bus. Activating both options in the conf file makes it work > > on Debian and Ubuntu. > > Thanks very much. > > > About activating the service, you will very likely have to provide a > > D-Bus init script (for /etc/dbus-1/event.d/) comparable to the one from > > dhcdbd. > > Ok. How would the sequnce number of the wpa_supplicant event.d scriplet be > determined? > > Attached is the patch I recently commited to SVN, can you please check it? > Does this scriptlet need to define a wpa_supplicant global control interface also (-g) ? Kel. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#412179: [pkg-wpa-devel] Bug#412179: D-Bus interface
On Sunday 04 March 2007 21:17, Kel Modderman wrote: > On Sunday 04 March 2007 16:17, Kel Modderman wrote: > > Hi Michael, > > > > On Saturday 03 March 2007 12:22, Michael Biebl wrote: > > > Hi, > > > > > > you will also very likely need the attached patch: > > > Debian does not use pam_console but uses group membership to control > > > access to D-Bus. Activating both options in the conf file makes it work > > > on Debian and Ubuntu. > > > > Thanks very much. > > > > > About activating the service, you will very likely have to provide a > > > D-Bus init script (for /etc/dbus-1/event.d/) comparable to the one from > > > dhcdbd. > > > > Ok. How would the sequnce number of the wpa_supplicant event.d scriplet > > be determined? > > > > Attached is the patch I recently commited to SVN, can you please check > > it? > > Does this scriptlet need to define a wpa_supplicant global control > interface also (-g) ? Heh. After checking out networkmanager trunk, and reading some snippets of code it seems the entire point of having the dbus communication interface is to avoid using the old style of NM/wpa_supplicant communication behaviour which required starting a private wpa_supplicant process using a global ctrl_interface etc etc. So I guess my question above can be considered a brain fart. Kel. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#412179: [pkg-wpa-devel] Bug#412179: D-Bus interface
On Monday 05 March 2007 01:05, Michael Biebl wrote: > > > > Ok. How would the sequnce number of the wpa_supplicant event.d scriplet > > be determined? > > NetworkManager 0.7.x is currently the only application I know of, which > uses the D-Bus interface of wpa_supplicant. It runs at 25, so, yeah, 23 > should be fine. Good. I just pulled 23 out of my behind ;-) > > > Attached is the patch I recently commited to SVN, can you please check > > it? > > > > Also, an experimental package has been prepared at: > > > > http://users.tpg.com.au/sigm/debian/pkg-wpa/wpasupplicant_0.6.0~cvs200702 > >24-1.dsc > > Seems to work fine here, although I can't really test the D-Bus > interface. NetworkManager 0.7 from SVN is currently horribly broken and > immediately crashes after startup (not because of wpa_supplicant I might > add). > > Maybe it would make sense to provide a /etc/default/wpasupplicant with a > var DAEMON_START or the like which defaults to 0. The D-Bus init script > would check this var and so it would be easy to enable/disable the D-Bus > service. Ok. In the future, how would we make sure that NetworkManager "JustWorks" (as is their philosphy on homepage) when the backend it depends on, wpa_supplicant, is disabled by default? Will the user be presented with an obtuse error message by NetworkManager indicating that the wpa_supplicant interface is not available and be forced into editing one or more config files to get it working? > IIRC avahi-daemon does it similar. Ok. # 0 = don't start, 1 = start AVAHI_DAEMON_START=1 To suggest an answer to my pesky questions above, would could ship a conffile similar to this now, but disabled, and when networkmanager 0.7.X is in the archive "flip the switch" and upload new wpasupplicant with conffile set to activate wpa_supplicant dbus daemon by default. > With no application using the D-Bus interface atm. (NM 0.7 will still > take some time to be released) I think people would complain if we start > wpa_supplicant by default. Ack. I would complain ;-) > On the other hand, if wpa_action could be made to reuse the running > D-Bus enabled wpa_supplicant instance instead of spawning its own copy > (dunno if that would be possible/sensible) it would be different. I don't think that is feasable a present. Thanks, Kel. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#412179: [pkg-wpa-devel] Bug#412179: D-Bus interface
On Monday 05 March 2007 18:57, Michael Biebl wrote: > > To suggest an answer to my pesky questions above, would could ship a > > conffile similar to this now, but disabled, and when networkmanager 0.7.X > > is in the archive "flip the switch" and upload new wpasupplicant with > > conffile set to activate wpa_supplicant dbus daemon by default. > > Yeah, this would be one possibility and I had something like this in my > mind initially. We'd just have to coordinate the releases somehow when > NM 0.7 is officially released (maybe a versioned dependency on > wpasupplicant with the switch on would be an option). Yep, this is what I understood so far. > > Another possible solution I see, is to ship the dbus related files > (/etc/dbus-1/event.d/*, /etc/dbus-1/system.d/* and > /usr/share/dbus-1/services/) in a separate package, let's call it > wpasupplicant-dbus, and network-manager 0.7 would then depend on this > package. I started thinking this way this morning too. > The question is, if a separate package for 3 small text files is justified. Method #1 - system daemon via wpasupplicant ## Pros: Save going through NEW again. No need to maintain another, pretty damn small binary package. Cons: Cannot ensure that the wpa_supplicant dbus aware system daemon is started upon installation of an app that needs it, we can do our best with co-ordination of package uploads. Once an app that needs wpa_supplicant's dbus interface is in the debian archive, we are faced with the situation where we must enable the system daemon always, regardless of whether or not such an app is actually installed, or force the admin to activate it via conffile after watching the app that needs it fail spectacuarly. Method #2 - system daemon via wpasupplicant-dbus # Pros: Any app that needs wpa_supplicant's dbus interface can be sure this package, wpasupplicant-dbus, enables that functionality unconditionally. We avoid having to start the daemon always even though not one single package on the system requires that, in the off chance the admin may install a package that does. We don't need to edit a conffile to disable the system daemon. pkg-wpa and pkg-utopia don't have to co-ordinate uploads so tightly. Cons: We must maintain and provide a tiny package. Package must go through NEW again. My opinion; I tend to lean towards providing the seperate binary package, wpasupplicant-dbus, even though it would be tiny. The benefits seem to overwhelme the old package maintainance adage of not splitting out code if it is sufficiently small. Thanks, Kel. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#369054: [pkg-wpa-devel] Bug#369054: wpasupplicant: Loosing wifi with "CTRL-EVENT-DISCONNECTED - Disconnect event - remove keys" message
On Wednesday 28 February 2007 08:45, Patrick Büker wrote: > Package: wpasupplicant > Version: 0.5.5-2 > > > I get the message on one box running etch and madwifi. > > Sometimes I get a connection but then looses connection with > CTRL-EVENT-DISCONNECT - Disconnect event - remove keys This bug report provides insufficient information to be helpful. How do you start wpa_supplicant? With what settings? What is _exact_ output of wpa_supplicant messages? Used -d debug option? Kel.
Bug#413689: [pkg-wpa-devel] Bug#413689: wpasupplicant should depent to wireless-tools
On Wednesday 07 March 2007 02:01, Bernhard wrote: > Package: wpasupplicant > Version: 0.5.5-2 > Severity: minor > > The package wpasupplicant should depend to the wireless-tools. > > >From my side, it makes no sense to install wpasupplicant without > > wireless-tools. I will make wireless-tools a Suggests, but not more. wpasupplicant certainly does not need iwconfig and co. to function, therefore it is no dependency. Kel. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#403045: [pkg-wpa-devel] Bug#403045: wpasupplicant: race condition in wpa_action disconnect between ifdown and if_post_down_up
On Friday 15 December 2006 18:19, Henning Glawe wrote: > On Fri, Dec 15, 2006 at 01:33:12PM +1000, Kel Modderman wrote: > > > the problem is, at least in my case, that the link is _down_ > > > afterwards, so wpasupplicant is not able to scan further. This seems to > > > be caused by the interface not being completely downed yet when ifdown > > > finishes; putting a 'sleep 1' into functions.sh::ifdown immediately > > > after the call to /sbin/ifdown "solves" this problem. > > > > Yeah, I'm not a fan of unconditional sleeps though. > > me neither, thats why I set the word solves in doublequotes ;) > > > Do you have iproute installed? That slighly changes behaviour of > > if_post_down_up, causing the interface to be flushed before 'upping' it > > again. > > iproute was installed when I discovered the race. > > > In any case, ifdown should not exit until it has fully completed what it > > had to do with the interface, at least in my opinion. > > I fully agree; I was also quite surprized about this fact when I did the > research for this report. What is output of `wpa_cli -i $iface status' when this condition results? (you may have to provide -p /path/to/ctrl/interface if you use a custom ctrl_interface) Thanks, Kel. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#409076: [pkg-wpa-devel] Bug #409076: Necessary to set ESSID in /etc/network/interfaces
Hi Bernhard, On Saturday 17 March 2007 16:47, Bernhard wrote: > Hello, > > This bugreport stays at "more information needed". > Which additional information is needed? > > Please let me know. This bug report caught me by surprise, it seems that is was transferred over here from another package. I have read the bug history, but have found no really substantial information about the claim that "wireless_essid FOO" (using wireless-tools) is required for operation of wpa_supplicant. However, I suspect that the massive revamp of the wpasupplicant package that happened before etch is what is confusing matters here. Please first start by looking at: /usr/share/doc/wpasupplicant/NEWS.Debian.gz Starting from version 0.4.8, a system wide, individual wpa_supplicant process is no longer available. Rather, settings for WPA are done (similarly to wireless-tools) via wpa-ssid SSID, wpa-psk PSK, wpa-* BAR etc. lines in /etc/network/interfaces. Take a look at the following for a description of how this new schema works: /usr/share/doc/wpasupplicant/README.modes.gz For example, my desktop machine has something similar to: auto eth1 iface eth1 inet dhcp wpa-ssid MyNet wpa-psk secretpasswordformynet in /etc/network/interfaces, and when ifupdown starts at boot time wpa_supplicant is started with the above configuration and my connection is negotiated. If neither of the mentioned documents sheds any more light on your problem, please describe your WPA setup a bit more: How is wpa_supplicant started? What is the content of your wpa_supplicant configuration, and where is it located? Thanks, Kel. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#416234: [pkg-wpa-devel] Bug#416234: wpasupplicant: wpa-ifupdown init script starts, but should stop, on runlevels 0 and 6
Hi Brian, On Monday 26 March 2007 15:15, Brian Cox wrote: > Package: wpasupplicant > Version: 0.5.5-4 > Severity: normal > > > This package's init script, /etc/init.d/wpa-ifupdown, is configured to > start rather than stop during runlevels 0 and 6. This is especially > perplexing since the init script itself does absolutely nothing for > 'start' All of the action happens when the script is called with > 'stop'. Perplexing yes, technical problem no. Attempted explanation follows. > > The problem appears to be in the postinst hook: > > # Automatically added by dh_installinit > if [ -x "/etc/init.d/wpa-ifupdown" ]; then > update-rc.d wpa-ifupdown start 15 0 6 . >/dev/null || exit $? > fi > # End automatically added section > > The call to update-rc.d should specify a stop set, not a start set. It could be either. Using a 'stop' set would cause the init script to by prefixed with K, and not S. It would be executed earlier than intended. Look at ifupdown's postinst as another example of this sysv perplexity: # Automatically added by dh_installinit if [ -x "/etc/init.d/ifupdown" ]; then update-rc.d ifupdown start 39 S . start 36 0 6 . >/dev/null || exit $? fi # End automatically added section That will actually schedule /etc/init.d/ifupdown to be given the 'stop' argument in runlevels 0 and 1. A clearer example is probably best from initscripts: updatercd sendsigs start 20 0 6 . It has a no-op 'start': case "$1" in start) # No-op ;; ... The above examples were used a basis for introducing this sysv curiosity into wpasupplicant (for better or worse). Sequence level 15 was chosen, so it wpasupplicant could be gracefully terminated before S20sendsigs clobbered the process. As per lsb header of wpa-ifupdown init script: # Description: Run ifdown on interfaces authenticated via # wpa_supplicant. Sendsigs terminates wpa_supplicant # processes before networking is stopped causing each # network interface authenticated via a wpa_supplicant # daemon to be terminated abrubtly. HTH. Thanks, Kel. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#416489: [Pkg-spca5xx-devel] Bug#416489: gspca-source: Build error on ARM
Hi, On Wednesday 28 March 2007 20:28, Michel Xhaard wrote: > > > > > > Attached patch fixed my build problems on ARM. > > > > I suggest to forward this upstream, too. Dollar signs in variable names > > are not such a good idea, IHMO. > > > > > > HTH, Uwe. > > Uwe, > Thanks for the patch, i will FIX the next revision. As a lesson, i know now > M$ could be better with MS :) > regards Thanks for picking that up already Michel. Funny bug ;-) Kel. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#409076: Necessary information
On Sunday 01 April 2007 19:52, Bernhard wrote: > Hello, Kel > > On my system, the WPA Supplicant is started manually in /etc/interfaces. > My configuration of the network interface is shown in the following lines: >iface eth2 inet dhcp >pre-up wpa_supplicant -ieth2 -Dwext > -c/etc/wpa_supplicant/wpa_supplicant.conf -B >wireless-essid mynetworkessid > > Without the wireless-essid, no connection to the access point is > established. Did you read the information given in the previous mail? If you read it carefully, then I do not think your configuration would still look the same. Thanks, Kel. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#412179: [pkg-wpa-devel] Bug#412179: install dbus files by default
Hi Riccardo, On Saturday 24 February 2007 21:28, Riccardo Setti wrote: > Package: wpasupplicant > Version: 0.5.5-4 > Severity: wishlist > Tags: patch > > hello, > > please add this patch in the next upload of wpasupplicant, it adds > support for use wpasupplicant via dbus. Patch applied. > > wpasupplicant should be started with -u switch, don't know how i can > do this "by default". > I assume this requirement is for successful use of Network Manager. Does NM provide facility to start wpa_supplicant as a system service or is there something the wpasupplicant package needs to provide in addition to just supporting the dbus interface? Thanks, Kel. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#414998: madwifi-source: AR5005G got Hardware revision not supported
On Thursday 15 March 2007 21:32, [EMAIL PROTECTED] wrote: > Package: madwifi-source > Version: 1:0.9.2+r1842.20061207-2 > Severity: normal > > Other folks have reported success with the same laptop "Acer TravelMate > 2310". lspci output for the device is: > > 00:0b.0 Ethernet controller: Atheros Communications, Inc. AR5005G > 802.11abg NIC (rev 01) > > Here is the kernel log: > > ath_hal: module license 'Proprietary' taints kernel. > ath_hal: 0.9.18.0 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, > RF5413) > wlan: 0.8.4.2 (0.9.3) > ath_rate_sample: 1.2 (0.9.3) > ath_pci: 0.9.4.5 (0.9.3) > PCI: Enabling device :00:0b.0 (0010 -> 0012) > ACPI: PCI Interrupt :00:0b.0[A] -> GSI 17 (level, low) -> IRQ 201 > wifi%d: unable to attach hardware: 'Hardware revision not supported' > (HAL status 13) > ACPI: PCI interrupt for device :00:0b.0 disabled > > Suggestions please? The HAL that is complaining about lack of support for said hardware is binary only, and thus out of control of the people who would care most about your problem. Therefore, whilst I care for your problem, I cannot even make any good changes or even suggestions about what you can do right now to make your wifi equipment work in linux, other than ndiswrapper. Thanks, Kel. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#414998: go upstream
On Friday 16 March 2007 00:17, Joshua N Pritikin wrote: > I found this thread which looks promising: > > http://thread.gmane.org/gmane.linux.drivers.madwifi.user/11599 > > I know binary drivers suck but you could at least suggest that I look > upstream if you don't know what to do. That is just common sense anyway ;-) Kel. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#419057: ndiswrapper-source: Fails to compile with Upstream Kernel source 2.6.20.6
severity 419057 wishlist thanks Hi Subhashis, On Saturday 14 April 2007 00:19, Subhashis Roy wrote: > Package: ndiswrapper-source > Version: 1.28-1 > Severity: grave > Justification: renders package unusable ...when used with stuff outside of what is in etch. This is not a grave shortcoming of ndiswrapper-source, how can it be expected to work with a kernel that was not present in debian at the time the archive was frozen to new updates? > > Presently the running kernel is 2.6.17.11 (from kernel.org) on a > Pentium-IV. However, building the Etch ndiswrapper kernel source with > the default linux-2.6.20.6 source using 'kpkg' failed with the following > message. > > --- > make[3]: Entering directory `/usr/src/modules/ndiswrapper' > /usr/bin/make -C /usr/src/linux-2.6.20.6 > SUBDIRS=/usr/src/modules/ndiswrapper make[4]: Entering directory > `/usr/src/linux-2.6.20.6' > LD /usr/src/modules/ndiswrapper/built-in.o > CC [M] /usr/src/modules/ndiswrapper/crt.o > CC [M] /usr/src/modules/ndiswrapper/hal.o > CC [M] /usr/src/modules/ndiswrapper/iw_ndis.o > CC [M] /usr/src/modules/ndiswrapper/loader.o > CC [M] /usr/src/modules/ndiswrapper/ndis.o > /usr/src/modules/ndiswrapper/ndis.c:39:47: error: macro "INIT_WORK" passed > 3 arguments, but takes just 2 /usr/src/modules/ndiswrapper/ndis.c: In > function 'ndis_init': > /usr/src/modules/ndiswrapper/ndis.c:39: error: 'INIT_WORK' undeclared > (first use in this function) /usr/src/modules/ndiswrapper/ndis.c:39: error: > (Each undeclared identifier is reported only once > /usr/src/modules/ndiswrapper/ndis.c:39: error: for each function it appears > in.) /usr/src/modules/ndiswrapper/ndis.c: In function > 'NdisMIndicateStatus': /usr/src/modules/ndiswrapper/ndis.c:1862: warning: > unused variable 'radio_status' make[5]: *** > [/usr/src/modules/ndiswrapper/ndis.o] Error 1 > make[4]: *** [_module_/usr/src/modules/ndiswrapper] Error 2 > make[4]: Leaving directory `/usr/src/linux-2.6.20.6' > make[3]: *** [default] Error 2 > make[3]: Leaving directory `/usr/src/modules/ndiswrapper' > make[2]: *** [binary-modules] Error 2 > make[2]: Leaving directory `/usr/src/modules/ndiswrapper' > make[1]: *** [kdist_build] Error 2 > - Then use the version from sid/unstable. Kel. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#418641: [pkg-wpa-devel] Bug#418641: group "netdev" in wpasupplicant configuration file
On Wednesday 11 April 2007 08:49, giggz wrote: > Package: wpasupplicant > Version: 0.6.0~cvs20070224-2 > Severity: normal > > Hi, > > Since a recent update, I have this message during the boot : > Starting system message bus :Dbus Unknown group "netdev" in message bus > configuration file So I have done a "grep -ir netdev /etc/*" and I found > that /etc/dbus-1/system.d/wpa_supplicant.conf have a reference to this > group. > > So I don't known if this bug is a wpasupplicant bug or dbus bug... wpasupplicant may provide that file, the only way it is used is via dbus. Kel. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#409076: [pkg-wpa-devel] Bug#409076: Necessary information
On Friday 13 April 2007 23:07, Bernhard wrote: > Hello, Kel > > > I have changed my configuration in /etc/network/interfaces. > The modified network configuration is in the attachement. > > After reboot, i have started the wpa supplicant in a root terminal: >wpa_supplicant -Dwext -ieth2 > -c/etc/wpa_supplicant/wpa_supplicant.conf -ddd >wpa_debug.txt > The output is in the attachement. > > The configuration file for the wpa supplicant is in the attachement, too. > > Used Hardware: >- Notebook WLAN Intel IPW2200BG >- Access point: Fritz!Box WLAN 3030 Version 2 >- Encryption is WPA with TKIP >- ESSID is hidden Did you try the advice in the section "Hidden ssids" in /usr/share/doc/wpasupplicant/README.modes.gz ? For your convenience: Hidden ssids For reference, see #358137. In order to be able to associate to hidden ssids, please try to set the option 'ap_scan=1' in the global section, and 'scan_ssid=1' in your network block section of your wpa_supplicant.conf file. If you are using the managed mode, you can do so by these stanzas: iface eth1 inet dhcp wpa-conf managed wpa-ap-scan 1 wpa-scan-ssid 1 # ... additional options for your setup According to #368770, association can take a very long time to associate to WEP secured networks. In some cases, setting the parameter 'ap_scan=2' in the config file, (or using a 'wpa-ap-scan 2' stanza, which is equivalent) can greatly help to speed up association. Thanks, Kel. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#418641: [pkg-wpa-devel] Bug#418641: group "netdev" in wpasupplicant configuration file
Restoring CC's to bug + list. On Saturday 14 April 2007 09:03, giggz wrote: > I saw that there was a similar bug for avahi-daemon (#385495 for > example). And a patch from dhcdb was given : > > --8<---cut here---start->8--- > --- avahi-daemon.postinst 2006-10-10 23:28:51.0 +0200 > +++ avahi-daemon.postinst_gismo 2006-10-10 23:32:15.0 +0200 > @@ -26,6 +26,11 @@ > usermod -d /var/run/avahi-daemon avahi > fi > > +# create the netdev group used by dbus > +if ! getent group netdev > /dev/null; then > +addgroup --quiet --system netdev > +fi > + > # Ask the bus to reload the config file > if [ -x "/etc/init.d/dbus" ]; then >invoke-rc.d dbus force-reload || true > --8<---cut here---end--->8--- > > what about a similar patch for wpasupplicant... ? I think we may have to now that wpasupplicant exposes the config file /etc/dbus-1/system.d/wpa_supplicant.conf, we also must provide the group that is required by that file. wpasupplicant itself really does not require that group to function, but perhaps we can try and take advantage of it in other areas != dbus related. Thanks, Kel. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#417087: madwifi-source: module load problem with 2.6.20
On Monday 02 April 2007 00:47, Anders Boström wrote: > Package: madwifi-source > Version: 1:0.9.2+r2156.20070225-1 > Severity: important > > After upgrade to 2.6.20.2 and madwifi 1:0.9.2+r2156.20070225-1, my > computer hang during boot, at module load of the madwifi modules. > > Ctrl-C breaks up the hang, but X fails to start after this. > > If I disable loading of the madwifi-modules during boot, the system > boot fine. > > 'modprobe ath_pci' hangs, and Ctrl-C don't work. kill of the > khelper-started modprobe-process breaks up the hang. > > I can get the madwifi-driver working by this sequence: > > # modprobe wlan > # insmod /lib/modules/2.6.20.2/kernel/drivers/net/ath_hal.ko > # insmod /lib/modules/2.6.20.2/kernel/drivers/net/ath_rate_sample.ko > # ifup ath0 > > modprobe of ath_rate_sample or ath_hal tries to load ath_pci and > hangs. This is strange as neither ath_rate_sample nor ath_hal is > dependent of ath_pci according to modinfo. > > If seems like ath_pci fails due to missing ath_rate_sample when I run > 'modprobe ath_pci' without prior manual load of ath_rate_sample, see > dmesg output below. > > dmesg (when not working): > wlan: 0.8.4.2 (0.9.3) > ath_hal: 0.9.18.0 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) > ath_pci: 0.9.4.5 (0.9.3) > ACPI: PCI Interrupt :00:0b.0[A] -> GSI 19 (level, low) -> IRQ 20 > Error loading module "ath_rate_sample" > ACPI: PCI interrupt for device :00:0b.0 disabled > > dmesg (when working): > wlan: 0.8.4.2 (0.9.3) > ath_hal: 0.9.18.0 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, RF5413) > ath_rate_sample: 1.2 (0.9.3) > ath_pci: 0.9.4.5 (0.9.3) > ACPI: PCI Interrupt :00:0b.0[A] -> GSI 19 (level, low) -> IRQ 20 > wifi0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps > wifi0: 11g rates: 1Mbps 2Mbps 5.5Mbps 11Mbps 6Mbps 9Mbps 12Mbps 18Mbps > 24Mbps 36Mbps 48Mbps 54Mbps wifi0: turboG rates: 6Mbps 12Mbps 18Mbps 24Mbps > 36Mbps 48Mbps 54Mbps wifi0: H/W encryption support: WEP AES AES_CCM TKIP > wifi0: mac 5.9 phy 4.3 radio 4.6 > wifi0: Use hw queue 1 for WME_AC_BE traffic > wifi0: Use hw queue 0 for WME_AC_BK traffic > wifi0: Use hw queue 2 for WME_AC_VI traffic > wifi0: Use hw queue 3 for WME_AC_VO traffic > wifi0: Use hw queue 8 for CAB traffic > wifi0: Use hw queue 9 for beacons > wifi0: Atheros 5212: mem=0xec00, irq=20 > > lspci -v: > 00:0b.0 Ethernet controller: Atheros Communications, Inc. AR5212 802.11abg > NIC (rev 01) Subsystem: Global Sun Technology Inc Trust Speedshare Turbo > Pro Wireless PCI Adapter Flags: bus master, medium devsel, latency 168, IRQ > 20 > Memory at ec00 (32-bit, non-prefetchable) [size=64K] > Capabilities: [44] Power Management version 2 > > Please let me know if I can perform any other test in order to help in > debugging this. Something could be wrong with your new kernel's configuration, or madwifi itself has problem keeping inter-module dependencies. There were early reports of the latter when recent changes were introduced, and were promptly fixed. This package contains those fixes iirc. You could try using a snapshot of current madwifi.org trunk with your kernel, and if problems persist please request support on madwifi-users where madwifi developers can provide some input. Thanks, Kel.
Bug#409076: [pkg-wpa-devel] Bug#409076: New WPA configuration
Hi Bernhard, On Friday 06 April 2007 04:39, Bernhard wrote: > Hello, Kel > > I have tested it with my Notebook again. > > My new configuration of the network interface is shown in the following > lines: >iface eth2 inet dhcp >wpa-ssid mynetworkessid >wpa-psk mysecretpassword >wireless-essid mynetworkessid > > With the configuration above, a connection to my access point is > established. > Without the wireless-essid, no connection to the access point is > established. That implies that wpa_supplicant somehow is not able to associate with the access point in question by itself, which is strange. > > I see, that the severity of this bug report stays at "Normal". > Because this is not a really issue, you can set this bug report to > "Minor" or "Wishlist item". I think the current severity is ok. It could be that you have found a severe problem that stops wpa_supplicant from operating properly with your hardware, or it could be a simple mis-configuration. > > Questions from my side with this kind of configuration: > Is the content of /etc/wpa_supplicant/wpa_supplicant.conf ignored? Yes. As described in /usr/share/doc/wpasupplicant/README.modes.gz section "How It Works". > Which driver is used as default, if the parameter wpa-driver is not set? wext, as per section "1. Specifying the wpa_supplicant driver backend" of /usr/share/doc/wpasupplicant/README.modes.gz. > > If you need more information, let me know. > Thank you for the support. I think what needs to happen is manual debugging of wpa_supplicant. You may start the supplicant by hand with your old config file (/etc/wpa_supplicant/wpa_supplicant.conf) with '-ddd' as an option, like: wpa_supplicant -Dwext -ieth2 -c/etc/wpa_supplicant/wpa_supplicant.conf -ddd Capture the debug output and paste it into a text file. This assumes that the daemon has not already been started by another method, so ifdown the interface, make sure no wpa_supplicant processes are running before trying to debug. Please also disclose the contents of /etc/wpa_supplicant/wpa_supplicant.conf and describe what hardware is used at client and access point side, what level of encryption is employed etc etc. Thanks, Kel. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#384504: hostapd not working with madwifi
On Monday 28 August 2006 00:29, Celejar wrote: > Wireless card is Trendware TEW443-PI. Chipset is Atheros AR5212 802.11abg > NIC (rev 01). pciid is 168c:0013. Kernel is 2.6.12-1-386. 'madwifi-source' > is 0.svnr1697.0.9.2-1. > > 'modprobe ath_pci autocreate=ap'; here's dmesg: > > ath_hal: 0.9.17.2 (AR5210, AR5211, AR5212, RF5111, RF5112, RF2413, > > RF5413) ath_rate_sample: 1.2 (svn r1697) > > ath_pci: 0.9.4.5 (svn r1697) > > PCI: Found IRQ 5 for device :00:0d.0 > > wifi0: 11b rates: 1Mbps 2Mbps 5.5Mbps 11Mbps > > wifi0: 11g rates: 1Mbps 2Mbps 5.5Mbps 11Mbps 6Mbps 9Mbps 12Mbps 18Mbps > > 24Mbps 36Mbps 48Mbps 54Mbps wifi0: turboG rates: 6Mbps 12Mbps 18Mbps > > 24Mbps 36Mbps 48Mbps 54Mbps wifi0: H/W encryption support: WEP AES > > AES_CCM TKIP > > wifi0: mac 7.9 phy 4.5 radio 5.6 > > wifi0: Use hw queue 1 for WME_AC_BE traffic > > wifi0: Use hw queue 0 for WME_AC_BK traffic > > wifi0: Use hw queue 2 for WME_AC_VI traffic > > wifi0: Use hw queue 3 for WME_AC_VO traffic > > wifi0: Use hw queue 8 for CAB traffic > > wifi0: Use hw queue 9 for beacons > > wifi0: Atheros 5212: mem=0xe590, irq=5 > > 'grep '^[^#]' /etc/hostapd/hostapd.conf': > > interface=ath0 > > driver=madwifi > > logger_syslog=-1 > > logger_syslog_level=2 > > logger_stdout=-1 > > logger_stdout_level=2 > > debug=0 > > dump_file=/tmp/hostapd.dump > > ctrl_interface=/var/run/hostapd > > ctrl_interface_group=0 > > ssid= > > macaddr_acl=0 > > auth_algs=3 > > eapol_key_index_workaround=0 > > eap_server=0 > > own_ip_addr=127.0.0.1 > > 'iwconfig': > > lono wireless extensions. > > > > eth0 no wireless extensions. > > > > sit0 no wireless extensions. > > > > wifi0 no wireless extensions. > > > > ath0 IEEE 802.11g ESSID:"" > > Mode:Master Channel:0 Access Point: Not-Associated > > Bit Rate:0 kb/s Tx-Power:18 dBm Sensitivity=0/3 > > Retry:off RTS thr:off Fragment thr:off > > Encryption key:off > > Power Management:off > > Link Quality=0/94 Signal level=-95 dBm Noise level=-95 dBm > > Rx invalid nwid:0 Rx invalid crypt:0 Rx invalid frag:0 > > Tx excessive retries:0 Invalid misc:0 Missed beacon:0 > > 'ifconfig ath0': > > ath0 Link encap:Ethernet HWaddr xx:xx:xx:xx:xx:xx > > inet addr:192.168.0.4 Bcast:192.168.0.255 Mask:255.255.255.0 > > BROADCAST MULTICAST MTU:1500 Metric:1 > > RX packets:0 errors:0 dropped:0 overruns:0 frame:0 > > TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 > > collisions:0 txqueuelen:0 > > RX bytes:0 (0.0 b) TX bytes:0 (0.0 b) > > I do 'hostapd -dd /etc/hostapd/hostapd.conf' and get: > > Configuration file: /etc/hostapd/hostapd.conf > > ctrl_interface_group=0 > > madwifi_set_iface_flags: dev_up=0 > > Using interface ath0 with hwaddr xx:xx:xx:xx:xx:xx and ssid '' > > Flushing old station entries > > madwifi_sta_deauth: addr=ff:ff:ff:ff:ff:ff reason_code=3 > > ioctl[IEEE80211_IOCTL_SETMLME]: Invalid argument > > Could not connect to kernel driver. > > Deauthenticate all stations > > rmdir[ctrl_interface]: No such file or directory > > madwifi_set_iface_flags: dev_up=0 http://lists.shmoo.com/pipermail/hostap/2006-August/013897.html I would say this is more a problem of madwifi => it is not supporting plaintext mode. Thanks, Kel. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#383810: madwifi-source: unsatisfied dependency in generated madwifi-module on amd64
Hi Loic and Aurel, On Monday 21 August 2006 21:20, Loïc Minier wrote: > On Mon, Aug 21, 2006, Kel Modderman wrote: > > Loic contacted me on IRC with a proposal to split the tools into an own > > source package that would enter contrib, and thus be autobuilt. Is this > > something you agree with? If so, then please don't needlessly waste > > effort until the new source packages are prepared. > > Aurel suggested the split (I should have mentionned that), I suppose he > agrees with it. :) I have a problem, and would appreciate some guidance please. In athstats.c we have: #include "ah_desc.h" This is a legally immutable file, not fit for contrib. Therefore, simply splitting the tools from kernel module source tree becomes non-trivial. Note that all other tools are okay; they are BSD/GPL and include only equally licensed headers. Only wlanconfig is absolutely essential to normal operation of the module. Some ideas I had: 1) cripple the athstats tool, so that is cannot report phyerrors derived from HAL 2) have a madwifi-tools in contrib, and madwifi-tools-nonfree (derived from madwifi source package) in non-free 3) Re-introduce madwifi-dev (arch=all) in the non-free madwifi source package, use it as a build-depends for the madwifi-tools source package that would be in contrib I prefer #3, it seems cleaner to me (no crippling or duplication) as long as it is acceptable in your opinion(s). Thanks, Kel.
Bug#385599: madwifi-source: Problem is with 1587 and 1687
On Monday 04 September 2006 00:28, Carlos Moffat wrote: > On Sun, 2006-09-03 at 16:06 +0200, Loïc Minier wrote: > > Hi, > > > > On Sun, Sep 03, 2006, Carlos Moffat wrote: > > > I have two interfaces coming up: wifi0 and ath0. Both are up, as far as > > > I can tell. Both have the same name regardless of what version of the > > > driver I used. > > > > You will probably see once of the interfaces having a longer HWaddr in > > ifconfig -a output, probably ending in "00-00-00-00-00-00-00-00", you > > should run dhclient on the other interface. > > > > If this fail, could you please send your dmesg output on module > > loading? > > > >Thanks, > > Here it is. The interface you talk about is called 'wifi0' in my > machine. > > Thanks a lot for your help. There are a few nasty issues concerning association (or lack of) reported to the madwifi.org trac system [1,2]. The fact that you reported the use of NetworkManager suggests to me that this may be related to the introduction of the WEXT ioctl's for use with wpa_supplicant (this changed slightly around r1527 or so). When NetwrokManager is active, isn't every interface under its control "bound" by a wpa_supplicant process? Therefore running dhclient manually while NetworkManager subsystem is still active may never succeed. Just my 2c, I hope these showstopping issues get ironed out of madwifi very soon . . . Thanks, Kel. [1] http://madwifi.org/ticket/776 [2] http://madwifi.org/ticket/698
Bug#385599: madwifi-source: Problem is with 1587 and 1687
On Sunday 03 September 2006 22:41, Loïc Minier wrote:
> Hi,
>
> On Fri, Sep 01, 2006, Carlos Moffat wrote:
> > Just to check, I tried madwifi-ng-{source,tools} r1587 from
> > snapshot.debian.net. That one didn't work either. I had to go back to
> > r1500 to be able to connect again. I hope this info helps.
>
> Did you bring the master interface up first? There are now two
> interfaces by default which you should see in "ifconfig -a", on my
> system, these are named ath1 and ath0_rename by default. You should
> bring both interfaces up (via ifconfig $interface up for example)
> before calling dhclient on the "VAP" interface (on my system,
> it's named ath0_rename by default).
>
>Bye,
Loic, maybe you have been stung by a problem similar to:
http://madwifi.org/wiki/UserDocs/Distro/Debian/TroubleshootingInstallation#rename_netif
I did plead with Md to have madwifi VAP's excused from the persistent-net udev
rule, but my argument was not sufficient enough for him to be bothered by it
at that time.
Thanks, Kel.
Bug#386156: hostapd is missing versioned depends: on lsb-base
On Wednesday 06 September 2006 03:32, Andreas Janssen wrote: > Package: hostapd > Version: 1:0.5.5-1 > Severity: serious > Justification: Policy 3.5 > > > hostapd 0.5.5 needs init script functions that are not available > in older versions of lsb-base. Running a backport on Sarge > results in: > > /etc/init.d/hostapd: line 38: log_daemon_msg: command not found > /etc/init.d/hostapd: line 44: log_progress_msg: command not found > > As hostapd needs lsb-base and lsb-base is not marked essential, > hostapd must depend on lsb-base. Because it only works with newer > versions of lsb-base the depends: should be versioned. > Thanks, applied and ready for upload. (depend on version >= 3.0-3 as per advice and lsb-base changelog) @ Faidon, please update from pkg-wpa/hostapd svn when time permits. Thanks, Kel. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#386164: [pkg-wpa-devel] Bug#386164: wpasupplicant is missing versioned depends: on lsb-base
On Wednesday 06 September 2006 05:24, Andreas Janssen wrote: > The missing functions log_action_begin and log_action_end were > introduced in lsb-base 3.0-6. Ok, thanks. wpasupplicant packaging has been updated accordingly. Kel. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#386227: [Pkg-spca5xx-devel] Bug#386227: spca5xx-source: Compile failure with kernel 2.6.18
On Thursday 07 September 2006 17:37, Michel Xhaard wrote: > Le Mercredi 6 Septembre 2006 05:54, Brad Sawatzky a écrit : > > Package: spca5xx-source > > Version: 20060501-1 > > Severity: important > > Tags: patch > > > > > > Some v4l header information got shuffled around in kernel 2.6.18. The > > attached patch updates spca5xx.h to include media/v4l2-common.h. Seems > > to work after that. > > > > You may want to check to see if the v4l changes came in during 2.6.17 and > > update the patch accordingly. > > > > -- Brad > > > > -- System Information: > > Debian Release: testing/unstable > > APT prefers testing > > APT policy: (500, 'testing'), (80, 'unstable') > > Architecture: amd64 (x86_64) > > Shell: /bin/sh linked to /bin/bash > > Kernel: Linux 2.6.18-rc5 > > Locale: LANG=en_US.UTF-8, LC_CTYPE=en_US.UTF-8 (charmap=UTF-8) > > > > Versions of packages spca5xx-source depends on: > > ii bzip2 1.0.3-3high-quality block-sorting > > file co ii debhelper 5.0.37.3 helper programs for > > debian/rules ii module-assistant 0.10.6 tool to make > > module package creati > > > > spca5xx-source recommends no packages. > > > > -- no debconf information > > Hi Brad, > Thanks for your patch :) > Best regards Yeah, thanks for that. I'll see if I can get it in before 2.6.18 is officially released. Thanks, Kel.
Bug#390787: Unusable: "ath_pci: disagrees about version of symbol "
On Tuesday 03 October 2006 11:46, Chip Salzenberg wrote: > Package: madwifi-source > Version: 1:0.9.2+r1710.20060914-1 > Severity: grave > Justification: renders package unusable > > The drivers seem to build OK for kernel 2.6.16-2-686, but when I try to > actually use them, I get a raft of "disagrees about version of symbol" > reports, and some of the modules in the package refuse to load. To wit: > > Oct 2 18:35:54 kernel: pccard: CardBus card inserted into slot 0 > Oct 2 18:35:54 kernel: ath_hal: 0.9.17.2 (AR5210, AR5211, AR5212, RF5111, > RF5112, RF2413, RF5413) Oct 2 18:35:54 kernel: wlan: 0.8.4.2 (0.9.3) > Oct 2 18:35:54 kernel: ath_rate_sample: 1.2 (0.9.3) > Oct 2 18:35:54 kernel: ath_pci: disagrees about version of symbol > ath_rate_tx_complete Oct 2 18:35:54 kernel: ath_pci: Unknown symbol > ath_rate_tx_complete Oct 2 18:35:54 kernel: ath_pci: disagrees about > version of symbol ieee80211_encap Oct 2 18:35:54 kernel: ath_pci: Unknown > symbol ieee80211_encap > Oct 2 18:35:54 kernel: ath_pci: disagrees about version of symbol > ieee80211_input Oct 2 18:35:54 kernel: ath_pci: Unknown symbol > ieee80211_input > Oct 2 18:35:54 kernel: ath_pci: disagrees about version of symbol > ieee80211_ifattach Oct 2 18:35:54 kernel: ath_pci: Unknown symbol > ieee80211_ifattach Oct 2 18:35:55 kernel: ath_pci: disagrees about version > of symbol ieee80211_beacon_update Oct 2 18:35:55 kernel: ath_pci: Unknown > symbol ieee80211_beacon_update Oct 2 18:35:55 kernel: ath_pci: disagrees > about version of symbol ieee80211_find_channel Oct 2 18:35:55 kernel: > ath_pci: Unknown symbol ieee80211_find_channel Oct 2 18:35:55 kernel: > ath_pci: disagrees about version of symbol ieee80211_find_rxnode Oct 2 > 18:35:55 kernel: ath_pci: Unknown symbol ieee80211_find_rxnode Oct 2 > 18:35:55 kernel: ath_pci: disagrees about version of symbol ath_rate_attach > Oct 2 18:35:55 kernel: ath_pci: Unknown symbol ath_rate_attach > Oct 2 18:35:55 kernel: ath_pci: disagrees about version of symbol > ieee80211_vap_setup Oct 2 18:35:55 kernel: ath_pci: Unknown symbol > ieee80211_vap_setup Oct 2 18:35:55 kernel: ath_pci: disagrees about > version of symbol ieee80211_ifdetach Oct 2 18:35:55 kernel: ath_pci: > Unknown symbol ieee80211_ifdetach Oct 2 18:35:55 kernel: ath_pci: > disagrees about version of symbol ieee80211_free_node Oct 2 18:35:55 > kernel: ath_pci: Unknown symbol ieee80211_free_node Oct 2 18:35:55 kernel: > ath_pci: disagrees about version of symbol ieee80211_input_monitor Oct 2 > 18:35:55 kernel: ath_pci: Unknown symbol ieee80211_input_monitor Oct 2 > 18:35:55 kernel: ath_pci: disagrees about version of symbol > ath_rate_newassoc Oct 2 18:35:55 kernel: ath_pci: Unknown symbol > ath_rate_newassoc > Oct 2 18:35:55 kernel: ath_pci: disagrees about version of symbol > ieee80211_crypto_newkey Oct 2 18:35:55 kernel: ath_pci: Unknown symbol > ieee80211_crypto_newkey Oct 2 18:35:55 kernel: ath_pci: disagrees about > version of symbol ieee80211_crypto_setkey Oct 2 18:35:55 kernel: ath_pci: > Unknown symbol ieee80211_crypto_setkey Oct 2 18:35:55 kernel: ath_pci: > disagrees about version of symbol ath_rate_dynamic_proc_register Oct 2 > 18:35:55 kernel: ath_pci: Unknown symbol ath_rate_dynamic_proc_register Oct > 2 18:35:55 kernel: ath_pci: disagrees about version of symbol > ieee80211_dump_pkt Oct 2 18:35:55 kernel: ath_pci: Unknown symbol > ieee80211_dump_pkt Oct 2 18:35:55 kernel: ath_pci: disagrees about version > of symbol ieee80211_ioctl_create_vap Oct 2 18:35:55 kernel: ath_pci: > Unknown symbol ieee80211_ioctl_create_vap Oct 2 18:35:55 kernel: ath_pci: > disagrees about version of symbol ieee80211_dfs_test_return Oct 2 18:35:55 > kernel: ath_pci: Unknown symbol ieee80211_dfs_test_return Oct 2 18:35:55 > kernel: ath_pci: disagrees about version of symbol ieee80211_stop_running > Oct 2 18:35:55 kernel: ath_pci: Unknown symbol ieee80211_stop_running Oct > 2 18:35:55 kernel: ath_pci: disagrees about version of symbol > ieee80211_cipher_none Perhaps you have handbuilt modules littering your kernel's module libdir, or you did not first remove all previous modules from kernel space before loading new modules? Kel. -- To UNSUBSCRIBE, email to [EMAIL PROTECTED] with a subject of "unsubscribe". Trouble? Contact [EMAIL PROTECTED]
Bug#390792: powersaved: allow ipw2200 module to suspend without forceful removal
Package: powersaved
Version: 0.14.0-2
Severity: wishlist
Currently, powersaved has ipw2200 in a suspend blacklist, and it is
removed from kernel space before suspend and reinserted after resume. I
believe this is needlessly causing headaches for the end user, as
ipw2200 has supported suspend/resume since upstream version 1.0.5, or
any version in mainline linux >=2.6.15 iirc.
The forceful removal/reinsertion only serves to break any meaningful
wireless link the ipw2200 device had established at the time of suspend,
and would require all users to setup some hooks to restart networking.
As the ipw2200 supported hardware is quite common, and next debian
release will most certainly come with a recent version of the module
that behaves well w.r.t to suspend, I'd like to request that it is no
longer blacklisted by powersaved.
Patch is attached.
Thanks, Kel.
diff -Nrup powersave-0.14.0-orig/config_files/sleep powersave-0.14.0/config_files/sleep
--- powersave-0.14.0-orig/config_files/sleep 2006-09-04 20:13:55.0 +1000
+++ powersave-0.14.0/config_files/sleep 2006-09-14 13:45:59.0 +1000
@@ -16,7 +16,7 @@
## Path: System/Powermanagement/Powersave/Sleep_Modes
### Type: string
-## Default: "usb_storage sbp2 ohci_hcd uhci_hcd stir4200 ohci1394 ipw2200 rt2500 prism54 ath_pci r8169 lt_modem Intel536 Intel537 ndiswrapper"
+## Default: "usb_storage sbp2 ohci_hcd uhci_hcd stir4200 ohci1394 rt2500 prism54 ath_pci r8169 lt_modem Intel536 Intel537 ndiswrapper"
## ServiceRestart:
#
# These modules will be unloaded before entering suspend to disk
@@ -26,7 +26,7 @@ UNLOAD_MODULES_BEFORE_SUSPEND2DISK=""
## Path: System/Powermanagement/Powersave/Sleep_Modes
### Type: string
-## Default: "usb_storage sbp2 ohci_hcd uhci_hcd stir4200 ohci1394 ipw2200 rt2500 prism54 ath_pci r8169 lt_modem Intel536 Intel537 ndiswrapper"
+## Default: "usb_storage sbp2 ohci_hcd uhci_hcd stir4200 ohci1394 rt2500 prism54 ath_pci r8169 lt_modem Intel536 Intel537 ndiswrapper"
## ServiceRestart:
#
# These modules will be unloaded before entering the corresponding
@@ -36,7 +36,7 @@ UNLOAD_MODULES_BEFORE_SUSPEND2RAM=""
## Path: System/Powermanagement/Powersave/Sleep_Modes
### Type: string
-## Default: "usb_storage sbp2 ohci_hcd uhci_hcd stir4200 ohci1394 ipw2200 rt2500 prism54 ath_pci r8169 lt_modem Intel536 Intel537 ndiswrapper"
+## Default: "usb_storage sbp2 ohci_hcd uhci_hcd stir4200 ohci1394 rt2500 prism54 ath_pci r8169 lt_modem Intel536 Intel537 ndiswrapper"
## ServiceRestart:
#
# These modules will be unloaded before entering the corresponding
diff -Nrup powersave-0.14.0-orig/scripts/sleep_helper_functions powersave-0.14.0/scripts/sleep_helper_functions
--- powersave-0.14.0-orig/scripts/sleep_helper_functions 2006-09-04 20:13:55.0 +1000
+++ powersave-0.14.0/scripts/sleep_helper_functions 2006-09-14 13:45:43.0 +1000
@@ -252,9 +252,9 @@ remount_fatfs(){
# function to set the variables according to what
# we are going to do.
# internally, use only in sleep_helper_functions
-DEFAULT_S2D_UNLOAD="usb_storage sbp2 ohci_hcd uhci_hcd stir4200 ohci1394 ipw2200 rt2500 prism54 ath_pci r8169 lt_modem Intel536 Intel537 ndiswrapper"
-DEFAULT_S2R_UNLOAD="usb_storage sbp2 ohci_hcd uhci_hcd stir4200 ohci1394 ipw2200 rt2500 prism54 ath_pci r8169 lt_modem Intel536 Intel537 ndiswrapper"
-DEFAULT_STB_UNLOAD="usb_storage sbp2 ohci_hcd uhci_hcd stir4200 ohci1394 ipw2200 rt2500 prism54 ath_pci r8169 lt_modem Intel536 Intel537 ndiswrapper"
+DEFAULT_S2D_UNLOAD="usb_storage sbp2 ohci_hcd uhci_hcd stir4200 ohci1394 rt2500 prism54 ath_pci r8169 lt_modem Intel536 Intel537 ndiswrapper"
+DEFAULT_S2R_UNLOAD="usb_storage sbp2 ohci_hcd uhci_hcd stir4200 ohci1394 rt2500 prism54 ath_pci r8169 lt_modem Intel536 Intel537 ndiswrapper"
+DEFAULT_STB_UNLOAD="usb_storage sbp2 ohci_hcd uhci_hcd stir4200 ohci1394 rt2500 prism54 ath_pci r8169 lt_modem Intel536 Intel537 ndiswrapper"
DEFAULT_S2D_RESTART="slmodemd irda upsd apcupsd"
DEFAULT_S2R_RESTART="slmodemd irda upsd apcupsd"
DEFAULT_STB_RESTART="slmodemd irda upsd apcupsd"
