<?xml version="1.0" encoding="UTF-8" standalone="yes" ?>
<!DOCTYPE bugzilla SYSTEM "http://bugs.gentoo.org/bugzilla.dtd">

<bugzilla version="2.22.7"
          urlbase="http://bugs.gentoo.org/"
          maintainer="bugzilla@gentoo.org"
>

    <bug>
          <bug_id>143698</bug_id>
          
          <creation_ts>2006-08-12 10:52 0000</creation_ts>
          <short_desc>sys-apps/baselayout-1.12.4-r2 wireless regression: madwifi ap association</short_desc>
          <delta_ts>2006-12-14 17:15:09 0000</delta_ts>
          <reporter_accessible>1</reporter_accessible>
          <cclist_accessible>1</cclist_accessible>
          <classification_id>1</classification_id>
          <classification>Unclassified</classification>
          <product>Gentoo Linux</product>
          <component>baselayout</component>
          <version>2006.0</version>
          <rep_platform>x86</rep_platform>
          <op_sys>Linux</op_sys>
          <bug_status>RESOLVED</bug_status>
          <resolution>UPSTREAM</resolution>
          
          
          
          <priority>P2</priority>
          <bug_severity>normal</bug_severity>
          <target_milestone>---</target_milestone>
          
          
          
          <everconfirmed>1</everconfirmed>
          <reporter>earny@net4u.de</reporter>
          <assigned_to>uberlord@gentoo.org</assigned_to>
          <cc>cbm@m.fsf.org</cc>
    
    <cc>johnsonnenschein@gmail.com</cc>
    
    <cc>mobile@gentoo.org</cc>

      

      
          <long_desc isprivate="0">
            <who>earny@net4u.de</who>
            <bug_when>2006-08-12 10:52:04 0000</bug_when>
            <thetext>First of all: 
No problems with sys-apps/baselayout-1.11.15-r3.
At any time i can do an

halso:~ # ifconfig ath0 up &amp;&amp; sleep 1 &amp;&amp; iwconfig ath0 essid net4u2 &amp;&amp; sleep 5 &amp;&amp; dhcpcd ath0

and the network is up.

Kernel: 2.6.18-rc4 (vanilla)
madwifi: Latest svn (Rev: 1704 at the moment)
net-wireless/wireless-tools-29_pre10

/etc/conf.d/net:

config_ath0=( &quot;dhcp&quot; )
dhcpcd_ath0=&quot;-t 30 -h halsowa&quot;
sleep_scan_ath0=&quot;10&quot;
sleep_associate_ath0=&quot;20&quot;
preferred_aps=( &quot;net4u2&quot; &quot;mocisoft&quot; )
associate_order=&quot;preferedonly&quot;

halso:~ # /etc/init.d/net.ath0 start
 * Caching service dependencies ...[ ok ]
 * Starting ath0
 *   Loading networking modules for ath0
 *     modules: apipa arping bridge ccwgroup tuntap macchanger macnet rename iwconfig essidnet iptunnel iproute2 pppd system vlan dhcpcd ip6to4
 *       iwconfig provides wireless
 *       iproute2 provides interface
 *       pppd provides ppp
 *       dhcpcd provides dhcp
 *   Configuring ath0 for MAC address 00:05:4E:47:C0:D5 ...[ ok ]
 *   Configuring wireless network for ath0
 *   Scanning for access points
 *     Found &quot;net4u2&quot; at 00:0F:3D:09:CF:27 (managed)
 *     Found &quot;WLAN&quot; at 00:12:BF:57:76:91 (managed, encrypted)
 *   Connecting to &quot;net4u2&quot; in managed mode (WEP Disabled) ...  [ !! ]
 *   Couldn&apos;t associate with any access points on ath0
 *   Failed to configure wireless for ath0  [ !! ]


To debug i have patched iwconfig.sh :

halso:/lib/rcscripts/net # diff -u iwconfig.sh.orig iwconfig.sh
--- iwconfig.sh.orig    2006-08-12 17:48:03.000000000 +0200
+++ iwconfig.sh 2006-08-12 17:50:40.000000000 +0200
@@ -7,15 +7,19 @@
 # Fix any potential localisation problems
 # Note that LC_ALL trumps LC_anything_else according to locale(7)
 iwconfig() {
+       logger -t iwsh &quot;iwconfig $@&quot;
        LC_ALL=C /sbin/iwconfig &quot;$@&quot;
 }
 iwgetid() {
+       logger -t iwsh &quot;iwgetid $@&quot;
        LC_ALL=C /sbin/iwgetid &quot;$@&quot;
 }
 iwlist() {
+       logger -t iwsh &quot;iwlist $@&quot;
        LC_ALL=C /sbin/iwlist &quot;$@&quot;
 }
 iwpriv() {
+       logger -t iwsh &quot;iwpriv $@&quot;
        LC_ALL=C /sbin/iwpriv &quot;$@&quot;
 }


Result:

Aug 12 18:42:38 halso iwsh: iwconfig ath0 txpower auto
Aug 12 18:42:38 halso iwsh: iwconfig ath0 rate auto
Aug 12 18:42:38 halso iwsh: iwconfig ath0 rts auto
Aug 12 18:42:38 halso iwsh: iwconfig ath0 frag auto
Aug 12 18:42:38 halso iwsh: iwconfig ath0
Aug 12 18:42:38 halso iwsh: iwconfig ath0 essid any
Aug 12 18:42:48 halso iwsh: iwlist ath0 scan
Aug 12 18:42:48 halso iwsh: iwgetid --mode ath0
Aug 12 18:42:48 halso iwsh: iwconfig ath0 key off
Aug 12 18:42:48 halso iwsh: iwconfig ath0 freq 2.412 GHz (Channel 1)
Aug 12 18:42:48 halso iwsh: iwconfig ath0 ap 00:0F:3D:09:CF:27
Aug 12 18:42:48 halso iwsh: iwconfig ath0 essid net4u2
Aug 12 18:43:09 halso rc-scripts: Couldn&apos;t associate with any access points on ath0
Aug 12 18:43:09 halso rc-scripts: Failed to configure wireless for ath0
Aug 12 18:43:09 halso iwsh: iwconfig ath0 txpower auto
Aug 12 18:43:09 halso iwsh: iwconfig ath0 rate auto
Aug 12 18:43:09 halso iwsh: iwconfig ath0 rts auto
Aug 12 18:43:09 halso iwsh: iwconfig ath0 frag auto
Aug 12 18:43:09 halso iwsh: iwconfig ath0 txpower off


Yes, there is a bug: &quot;iwconfig ath0 freq 2.412 GHz (Channel 1)&quot; but that is not the problem.
If i comment out that line the problem still exists.

cat /sys/class/net/ath0/carrier 
works, will be &quot;1&quot; if association succeeds.

Looks like a racecondition, if i execute the logged commands by hand, the association works....

A &quot;watch --interval 1 iwconfig ath0&quot; shows that sometimes the card associates to the ap
during scan. But this association drops immediatly, if the scripts calls iwlist ath0 scan
(or one of the commands direct behind), and will never come back. I can see the freq changes, it
stops at 2.412GHz, but not accociated.

Now i&apos;m lost. Some ideas?</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>earny@net4u.de</who>
            <bug_when>2006-08-12 10:57:01 0000</bug_when>
            <thetext>Created an attachment (id=94078)
emerge --info

</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>toralf.foerster@gmx.de</who>
            <bug_when>2006-08-12 13:05:14 0000</bug_when>
            <thetext>What&apos;s about creating a similar entry (!net.wlan0) in /etc/conf.d/net as described here : https://bugs.gentoo.org/show_bug.cgi?id=143666#add_comment</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>cbm@m.fsf.org</who>
            <bug_when>2006-08-12 19:59:45 0000</bug_when>
            <thetext>I think I&apos;m seeing this too.  I&apos;m using madwifi-ng-0.9.2 and baselayout-1.12.4-r2.

my /etc/conf.d/wireless:
key_atropa=&quot;xxxx-xxxx-xxxx-xxxx-xxxx-xxxx-xx enc open&quot;
dhcpcd_atropa=&quot;-t 16&quot;
config_atropa=( &quot;dhcp&quot; )
#dhcpcd_ath0=&quot;-t 16&quot;
#config_ath0=&quot;dhcp&quot;
preferred_aps=( &quot;atropa&quot; )
associate_order=&quot;preferredonly&quot;

results in:
aconite conf.d # /etc/init.d/net.ath0 restart
 * Starting ath0
 *   Configuring wireless network for ath0
 *   Couldn&apos;t associate with any access points on ath0
 *   Failed to configure wireless for ath0      

But everything in iwconfig ath0 looks setup correctly.  I can manually &quot;dhcpcd ath0&quot; and it connects (in other words, essid, WEP key etc are setup correctly by the baselayout script).  Its just the baselayout script that won&apos;t connect to an AP, everything works if I do it manually.

I don&apos;t really understand Comment #2&apos;s reference to bug #143666 because this doesn&apos;t seem to be anything to do with *PLUG...  But just in case:
aconite conf.d # grep -e ^RC_COLD -e ^RC_HOT -e ^RC_PL /etc/conf.d/rc
RC_HOTPLUG=&quot;no&quot;
RC_COLDPLUG=&quot;no&quot;
RC_PLUG_SERVICES=&quot;&quot;

emerge info:
Portage 2.1.1_pre4-r4 (default-linux/x86/2006.0, gcc-4.1.1/vanilla, glibc-2.4-r3, 2.6.17.8 i686)
=================================================================
System uname: 2.6.17.8 i686 AMD Athlon(tm) Processor
Gentoo Base System version 1.12.4
Last Sync: Fri, 11 Aug 2006 18:30:08 +0000
distcc 2.18.3 i686-pc-linux-gnu (protocols 1 and 2) (default port 3632) [enabled]
app-admin/eselect-compiler: 2.0.0_rc2-r1
dev-lang/python:     2.4.3-r1
dev-python/pycrypto: 2.0.1-r5
dev-util/ccache:     [Not Present]
dev-util/confcache:  [Not Present]
sys-apps/sandbox:    1.2.18.1
sys-devel/autoconf:  2.13, 2.60
sys-devel/automake:  1.4_p6, 1.5, 1.6.3, 1.7.9-r1, 1.8.5-r3, 1.9.6-r2
sys-devel/binutils:  2.17
sys-devel/gcc-config: 2.0.0_rc1
sys-devel/libtool:   1.5.22
virtual/os-headers:  2.6.17
ACCEPT_KEYWORDS=&quot;x86 ~x86&quot;
AUTOCLEAN=&quot;yes&quot;
CBUILD=&quot;i686-pc-linux-gnu&quot;
CFLAGS=&quot;-march=i686 -O2 -pipe&quot;
CHOST=&quot;i686-pc-linux-gnu&quot;
CONFIG_PROTECT=&quot;/etc /usr/kde/3.5/env /usr/kde/3.5/share/config /usr/kde/3.5/shutdown /usr/lib/globus-2.4/etc /usr/lib/mozilla/defaults/pref /usr/share/X11/xkb /usr/share/config&quot;
CONFIG_PROTECT_MASK=&quot;/etc/env.d /etc/env.d/java/ /etc/eselect/compiler /etc/gconf /etc/java-config/vms/ /etc/revdep-rebuild /etc/terminfo /etc/texmf/web2c&quot;
CXXFLAGS=&quot;-march=i686 -O2 -pipe&quot;
DISTDIR=&quot;/usr/portage/distfiles&quot;
FEATURES=&quot;autoconfig collision-protection distcc distlocks metadata-transfer sandbox sfperms strict userpriv usersandbox&quot;
GENTOO_MIRRORS=&quot;http://gentoo.mirrors.easynews.com/linux/gentoo/ http://gentoo.chem.wisc.edu/gentoo/ ftp://gentoo.mirrors.tds.net/gentoo ftp://194.117.143.71/mirrors/gentoo&quot;
LINGUAS=&quot;&quot;
MAKEOPTS=&quot;-j1&quot;
PKGDIR=&quot;/usr/portage/packages&quot;
PORTAGE_RSYNC_OPTS=&quot;--recursive --links --safe-links --perms --times --compress --force --whole-file --delete --delete-after --stats --timeout=180 --exclude=&apos;/distfiles&apos; --exclude=&apos;/local&apos; --exclude=&apos;/packages&apos;&quot;
PORTAGE_TMPDIR=&quot;/var/tmp&quot;
PORTDIR=&quot;/usr/portage&quot;
PORTDIR_OVERLAY=&quot;/usr/local/portage /usr/local/ag-portage&quot;
SYNC=&quot;rsync://rsync.gentoo.org/gentoo-portage&quot;
USE=&quot;x86 3dnow X Xaw3d a52 aac aalib acpi alsa apache2 apm arts audiofile avahi avi berkdb bitmap-fonts bzip2 cairo cdr cjk cli crypt cups curl dbus dga dlloader dri dts dv dvb dvd dvdr eds elibc_glibc emacs emboss encode esd exif expat f77 faad fbcon ffmpeg fftw flac fortran gcj gd gdbm gif gimpprint ginac glut gmp gnome gnustep gnutls gphoto2 gpm gstreamer gtk gtk2 gtkhtml hal idn imagemagick imlib input_devices_evdev input_devices_keyboard input_devices_mouse isdnlog jack java jpeg kernel_linux lcms leim libcaca libg++ libwww lirc lirc_devices_realmagic live mad matroska mikmod mmx mng mono motif mozilla mp3 mpeg mysql nas ncurses nls nptl offensive ogg openal opengl oss pam pcre pdf pdflib perl plotutils png ppds pppd python qhull qt3 quicktime radeon readline reflection rtc samba scanner sdk sdl session slang speex spell spl sqlite sse ssl svg tcl tcltk tcpd tetex theora threads tiff tk truetype truetype-fonts type1-fonts udev unicode usb userland_GNU v4l v4l2 vcd video_cards_fbdev video_cards_i810 video_cards_mach64 video_cards_radeon video_cards_v4l video_cards_vesa video_cards_vga vorbis wmf wxwindows xinerama xml xmms xorg xosd xprint xv xvid zlib&quot;
Unset:  CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LANG, LC_ALL, LDFLAGS, PORTAGE_RSYNC_EXTRA_OPTS
</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>uberlord@gentoo.org</who>
            <bug_when>2006-08-13 03:04:53 0000</bug_when>
            <thetext>Does it work again if you comment out lines 296 - 299 in /lib/rcscripts/net/iwconfig.sh ?

Also, some please attach the full output of &quot;iwlist ath0 scan&quot; please</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>uberlord@gentoo.org</who>
            <bug_when>2006-08-13 07:48:17 0000</bug_when>
            <thetext>Created an attachment (id=94150)
Fix frequency detection

This should fix the &quot;iwconfig ath0 freq 2.412 GHz (Channel 1)&quot; bug as described above. Please test and report back.

I have a madwifi card, but it powers my AP. I&apos;ll see if I can replicate it in the week when I can get a keyboard and screen to it, otherwise I&apos;ll happily review any patches that come in.</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>earny@net4u.de</who>
            <bug_when>2006-08-13 15:40:19 0000</bug_when>
            <thetext>Created an attachment (id=94182)
if_down_up_hack.patch

Ok, found it. The new baselayout misses two lines of code:

@@ -486,6 +496,10 @@
                esac
        done &lt; &lt;(iwlist &quot;${iface}&quot; scan 2&gt;/dev/null)

+       # HUP the interface as some drivers/cards need it
+       interface_down ${iface}
+       interface_up ${iface}
+
        if ${error}; then
                ewarn &quot;${iface} does not support scanning&quot;
                x=&quot;adhoc_essid_${ifvar}&quot;


It is of curse a dirty hack, but madwifi need it. Try something like this:

~# iwlist ath0 scan ; iwconfig ath0 essid net4u2

with an up interface (assiociated or not).
That will sussessful stop any assiociation and will _not_ reassiociate to
any ap. There is a problem in the madwifi-driver... maybe this one?:

http://madwifi.org/changeset/1665

Another problem, that is hidden with this down/up hack:

Before scanning the script does:

       # Set the essid to any. This is required for scanning
        iwconfig &quot;${iface}&quot; essid any

        veinfo &quot;Scanning for access points&quot;

Now the essid is any, an if you have a longer scan_time set the card may
already associate to the ap ANY during the scan sleep;)

If the scan is finished, the script sets the essid and checks immediatly for
a valid association. This is racy: Sometimes he finds the old one, and then
the rest of the script is a little bit confused....

It wold be a good idea to inhibit a association during scan (but how?).
The call to preassociate() is maybe also wrong: It is called after
iwconfig &quot;${iface}&quot; essid &quot;${ESSID}&quot;
With a fast card (never have seen one :) the association may already
has done.

The patch in the attachment is including the freq-patch (yes, it works)</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>uberlord@gentoo.org</who>
            <bug_when>2006-08-13 15:55:15 0000</bug_when>
            <thetext>(In reply to comment #6)
&gt; Created an attachment (id=94182) [edit]
&gt; if_down_up_hack.patch
&gt; 
&gt; Ok, found it. The new baselayout misses two lines of code:
&gt; 
&gt; @@ -486,6 +496,10 @@
&gt;                 esac
&gt;         done &lt; &lt;(iwlist &quot;${iface}&quot; scan 2&gt;/dev/null)
&gt; 
&gt; +       # HUP the interface as some drivers/cards need it
&gt; +       interface_down ${iface}
&gt; +       interface_up ${iface}
&gt; +
&gt;         if ${error}; then
&gt;                 ewarn &quot;${iface} does not support scanning&quot;
&gt;                 x=&quot;adhoc_essid_${ifvar}&quot;
&gt; 
&gt; 
&gt; It is of curse a dirty hack, but madwifi need it.

The bad news is that whilst madwifi needs it, it breaks rt2500 and some versions of acx100. So that&apos;s not going to fly right now - it&apos;s going to have to be fixed upstream.

&gt;There is a problem in the madwifi-driver... maybe this one?:
&gt;
&gt;http://madwifi.org/changeset/1665

That patch is in 0.9.2 - or are you saying this breaks it?

&gt; Another problem, that is hidden with this down/up hack:
&gt; 
&gt; Before scanning the script does:
&gt; 
&gt;        # Set the essid to any. This is required for scanning
&gt;         iwconfig &quot;${iface}&quot; essid any
&gt; 
&gt;         veinfo &quot;Scanning for access points&quot;
&gt; 
&gt; Now the essid is any, an if you have a longer scan_time set the card may
&gt; already associate to the ap ANY during the scan sleep;)

Again, that is something that most other drivers require - as the essid has to be set to ANY or they will not rescan successfully and just use the last scan list prior to association.</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>earny@net4u.de</who>
            <bug_when>2006-08-13 16:29:59 0000</bug_when>
            <thetext>(In reply to comment #7)

&gt; &gt;http://madwifi.org/changeset/1665
&gt; 
&gt; That patch is in 0.9.2 - or are you saying this breaks it?
&gt; 

No, i had tried r1663 - r1665, the problem is the same. But the comment states, that there are still problems;)

And yes, i dont like the down/up-hack. If someone can confirm the weird behavior of the madwifi driver after scan a bugreport upstream is the right bug fix.

&gt; 
&gt; Again, that is something that most other drivers require - as the essid has to
&gt; be set to ANY or they will not rescan successfully and just use the last scan
&gt; list prior to association.
&gt; 

The easiest way to fix this is in iwconfig_wait_for_association().
Reverse the lines:

        while true; do
                iwconfig_test_associated &quot;${iface}&quot; &amp;&amp; return 0
                sleep 1

and the race is almost gone. (wait for at least 1sec)</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>cbm@m.fsf.org</who>
            <bug_when>2006-08-13 18:05:59 0000</bug_when>
            <thetext>As per comment #4, commenting out the &quot;# Use sysfs if we can&quot; block of code had no effect, still doesn&apos;t work.

aconite ~ # iwlist ath0 scan
ath0      Scan completed :
          Cell 01 - Address: 00:0C:41:1A:82:A0
                    ESSID:&quot;REDSCAPE1&quot;
                    Mode:Master
                    Frequency:2.437 GHz (Channel 6)
                    Quality=24/94  Signal level=-71 dBm  Noise level=-95 dBm
                    Encryption key:on
                    Bit Rates:1 Mb/s; 2 Mb/s; 5.5 Mb/s; 11 Mb/s
                    Extra:bcn_int=100
          Cell 02 - Address: 00:14:BF:38:CA:3B
                    ESSID:&quot;atropa&quot;
                    Mode:Master
                    Frequency:2.462 GHz (Channel 11)
                    Quality=38/94  Signal level=-57 dBm  Noise level=-95 dBm
                    Encryption key:on
                    Bit Rates:1 Mb/s; 2 Mb/s; 5.5 Mb/s; 11 Mb/s; 18 Mb/s
                              24 Mb/s; 36 Mb/s; 54 Mb/s; 6 Mb/s; 9 Mb/s
                              12 Mb/s; 48 Mb/s
                    Extra:bcn_int=100
          Cell 03 - Address: 00:0F:3D:BB:46:70
                    ESSID:&quot;martin&quot;
                    Mode:Master
                    Frequency:2.437 GHz (Channel 6)
                    Quality=1/94  Signal level=-94 dBm  Noise level=-95 dBm
                    Encryption key:on
                    Bit Rates:1 Mb/s; 2 Mb/s; 5.5 Mb/s; 11 Mb/s; 22 Mb/s
                    Extra:bcn_int=100

Re comment #5: I don&apos;t see the channel bug so I can&apos;t test.

Re comment #6: I can confirm this:
~# iwlist ath0 scan ; iwconfig ath0 essid atropa
causes it to not associate with my AP

Also, the up/down &quot;fix&quot; indeed works for me, will use that until something better comes along.

Re comment #8: switching the sleep 1 and the iwconfig_test_... line doesn&apos;t fix anything for me.</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>uberlord@gentoo.org</who>
            <bug_when>2006-08-14 00:03:27 0000</bug_when>
            <thetext>Does this help any? Place it in /etc/conf.d/net

preup() { 
    if [[ ${IFACE} == &quot;ath0&quot; ]] ; then 
       # Some atheros cards need an extra up 
       # NOTE: the card is upped a few times anyway, so this *should* be redundant 
       interface_up &quot;${IFACE}&quot; 
       # Maybe give it time to settle 
       sleep 2 
    fi 
 }</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>gentoo@schirmeier.com</who>
            <bug_when>2006-08-14 03:36:02 0000</bug_when>
            <thetext>I see similar behaviour since the update to baselayout-1.12.4-r2 (updating to -r3 did not change this); the preup() function (comment #10) does not help at all.

 * Starting ath0
 *   Running preup function                          [ ok ]
 *   Starting wpa_supplicant on ath0 ...             [ ok ]
 *   Starting wpa_cli on ath0 ...                    [ ok ]
 *     Failed to configure ath0 in the background    [ !! ]

Running &apos;dhcpcd ath0&apos; afterwards makes everything work.

/etc/conf.d/net:
modules=( &quot;wpa_supplicant&quot; )
wpa_supplicant_ath0=&quot;-Dmadwifi&quot;
wpa_timeout_ath0=60
config_eth0=( &quot;192.168.0.1&quot; )
config_ath0=( &quot;dhcp&quot; )
dhcp_eth0=&quot;release nontp&quot;
dhcp_ath0=&quot;release nontp&quot;
preup() { [omitted] }

/etc/conf.d/wireless:
essid_ath0=&quot;xxx&quot;
channel_ath0=&quot;9&quot;
sleep_scan_ath0=&quot;1&quot;
associate_timeout_ath0=&quot;30&quot;</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>uberlord@gentoo.org</who>
            <bug_when>2006-08-14 06:36:33 0000</bug_when>
            <thetext>(In reply to comment #11)
&gt; I see similar behaviour since the update to baselayout-1.12.4-r2 (updating to
&gt; -r3 did not change this); the preup() function (comment #10) does not help at
&gt; all.
&gt; 
&gt;  * Starting ath0
&gt;  *   Running preup function                          [ ok ]
&gt;  *   Starting wpa_supplicant on ath0 ...             [ ok ]
&gt;  *   Starting wpa_cli on ath0 ...                    [ ok ]
&gt;  *     Failed to configure ath0 in the background    [ !! ]

Totatlly unrelated as this bug is about using iwconfig and your error is with wpa_supplicant.</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>cbm@m.fsf.org</who>
            <bug_when>2006-08-14 10:24:09 0000</bug_when>
            <thetext>Upgrade to baselayout-1.12.4-r3 didn&apos;t help.

Comment #10: yes, adding that preup seems to make it work:
aconite conf.d # /etc/init.d/net.ath0 restart
 * Stopping ath0
 *   Bringing down ath0
 *     Stopping dhcpcd on ath0 ...                                                                        [ ok ] *     Shutting down ath0 ...                                                                             [ ok ] * Starting ath0
 *   Running preup function                                                                               [ ok ] *   Configuring wireless network for ath0
 *     ath0 connected to ESSID &quot;atropa&quot; at 00:14:BF:38:CA:3B
 *     in managed mode on channel 11 (WEP enabled - open)
 *   Bringing up ath0
 *     dhcp
 *       Running dhcpcd ...
Info, MAC address = 00:0f:3d:e1:1b:46
Debug, broadcasting DHCP_REQUEST for 192.168.0.200
Debug, broadcastAddr option is missing in DHCP server response. Assuming 192.168.0.255
Debug, dhcpIPaddrLeaseTime=4294967295 in DHCP server response.
Debug, dhcpT1value is missing in DHCP server response. Assuming 2147483647 sec
Debug, dhcpT2value is missing in DHCP server response. Assuming 3758096383 sec
Debug, DHCP_ACK received from  (192.168.0.1)
Debug, broadcasting ARPOP_REQUEST for 192.168.0.200
Info, verified 192.168.0.200 address is not in use
Info, your IP address = 192.168.0.200
Debug, orig hostname = aconite
Debug, about to exec &quot;/etc/dhcpc/dhcpcd.exe /var/lib/dhcpc/dhcpcd-ath0.info up&quot;                           [ ok ] *       ath0 received address 192.168.0.200/24

Is there still an issue here to report upstream?</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>uberlord@gentoo.org</who>
            <bug_when>2006-08-14 10:42:47 0000</bug_when>
            <thetext>(In reply to comment #13)
&gt; Is there still an issue here to report upstream?

Yes.

The issue is that people have two similar issues with madwifi - one fix requires that preup code and the other requires that interface down/up hack. 
Some people need one or the other - I know of one person who requires both.

The odd thing is that my atheros based (early card works quite happily without either, so I&apos;m guessing that it&apos;s a driver/hardware issue. FWIW it&apos;s a NetGear WG311v1 - Atheros Communications, Inc. AR5212 802.11abg NIC (rev 01)

Someone should report this upstream and reference it here. I&apos;d appreciate that as my card is also my AP in a headless server making testing/debugging difficult at best - also I don&apos;t seem to suffer from the bug.</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>cbm@m.fsf.org</who>
            <bug_when>2006-08-14 11:44:47 0000</bug_when>
            <thetext>Ok, I submitted this ticket to upstream madwifi:
http://madwifi.org/ticket/823

Anyone who understands the issue more than I, please post relevant info there.</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>uberlord@gentoo.org</who>
            <bug_when>2006-08-14 12:23:33 0000</bug_when>
            <thetext>(In reply to comment #15)
&gt; Ok, I submitted this ticket to upstream madwifi:
&gt; http://madwifi.org/ticket/823

Thanks. I&apos;m going to close this bug as upstream. Re-open / comment if upstream changes status on it.

BTW, don&apos;t emerge dhcpcd with the debug USE flag - it won&apos;t actually work as a dhcp client ;)</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>earny@net4u.de</who>
            <bug_when>2006-08-14 12:35:55 0000</bug_when>
            <thetext>Here in the office i can&apos;t reproduce it with the gentoo scripts, they just work...
So maybe the problem depends on the ap&apos;s flying around in the air.

But then &apos;upstream bug&apos; still exists:

halso:~ # ifconfig ath0 up
halso:~ # iwlist ath0 scan; sleep 4; iwconfig ath0 essid mocisoft
ath0      Scan completed :
          Cell 01 - Address: 00:0F:3D:AC:82:9F
                    ESSID:&quot;mocisoft&quot;
                    Mode:Master
                    Frequency:2.412 GHz (Channel 1)
                    Quality=33/94  Signal level=-62 dBm  Noise level=-95 dBm
                    Encryption key:off
                    Bit Rates:1 Mb/s; 2 Mb/s; 5.5 Mb/s; 11 Mb/s; 6 Mb/s
                              12 Mb/s; 24 Mb/s; 36 Mb/s; 9 Mb/s; 18 Mb/s
                              48 Mb/s; 54 Mb/s
                    Extra:bcn_int=100

halso:~ #

iwevents:
(-- if up --)
21:21:06.182749   ath0     New Access Point/Cell address:00:0F:3D:AC:82:9F
21:21:17.643102   ath0     Scan request completed
(-- scan / essid --)
21:21:34.540935   ath0     New Access Point/Cell address:Not-Associated
21:21:34.541310   ath0     Set ESSID:&quot;mocisoft&quot;

halso:~ # cat /sys/class/net/ath0/carrier
0

--------------------------

But!

halso:~ # ifconfig ath0 up
halso:~ # iwconfig ath0 essid does_not_exists
halso:~ # iwlist ath0 scan; iwconfig ath0 essid mocisoft
ath0      Scan completed :
          Cell 01 - Address: 00:0F:3D:AC:82:9F
                    ESSID:&quot;mocisoft&quot;
                    Mode:Master
                    Frequency:2.412 GHz (Channel 1)
                    Quality=40/94  Signal level=-55 dBm  Noise level=-95 dBm
                    Encryption key:off
                    Bit Rates:1 Mb/s; 2 Mb/s; 5.5 Mb/s; 11 Mb/s; 6 Mb/s
                              12 Mb/s; 24 Mb/s; 36 Mb/s; 9 Mb/s; 18 Mb/s
                              48 Mb/s; 54 Mb/s
                    Extra:bcn_int=100

halso:~ # cat /sys/class/net/ath0/carrier
1

iwevents:
21:25:56.956566   ath0     New Access Point/Cell address:Not-Associated
21:25:56.956956   ath0     Set ESSID:&quot;does_not_exists&quot;
21:26:16.521428   ath0     Set ESSID:&quot;mocisoft&quot;
21:26:17.896819   ath0     Scan request completed
21:26:17.902447   ath0     New Access Point/Cell address:00:0F:3D:AC:82:9F


Will try later @ home again....</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>cbm@m.fsf.org</who>
            <bug_when>2006-08-14 13:14:35 0000</bug_when>
            <thetext>Re comment #16: I don&apos;t have debug USE flag on, I just pass -d to dhcpcd in (dhcpcd_atropa=&quot;-d -t 16&quot;).  Its a habit I got into on my laptop trying to connect to weak APs: I can see whats going on a bit better instead of just waiting for it to timeout.  I don&apos;t think its affects dhcpcd&apos;s functionality.

Re comment #17: Is sleep 4 your limit between working and not working?
Setting the essid to something nonexistant has no effect for me.  It still works or fails depending on weather I use &lt; 1.9 or &gt; 1.9</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>earny@net4u.de</who>
            <bug_when>2006-08-14 13:57:27 0000</bug_when>
            <thetext>&gt; 
&gt; Re comment #17: Is sleep 4 your limit between working and not working?
&gt; Setting the essid to something nonexistant has no effect for me.  It still
&gt; works or fails depending on weather I use &lt; 1.9 or &gt; 1.9
&gt; 

A scripts says more than thousands words :-)

halso:~ # ifconfig ath0 up
halso:~ # iwlist ath0 scan | grep ESSID; sleep 10; iwconfig ath0 essid mocisoft ; sleep 1 ; echo &quot;carrier: $(&lt;/sys/class/net/ath0/carrier)&quot;; sleep 20; echo &quot;carrier: $(&lt;/sys/class/net/ath0/carrier)&quot;
                    ESSID:&quot;mocisoft&quot;
carrier: 0
carrier: 0
halso:~ # iwlist ath0 scan | grep ESSID; sleep 11; iwconfig ath0 essid mocisoft ; sleep 1 ; echo &quot;carrier: $(&lt;/sys/class/net/ath0/carrier)&quot;; sleep 20; echo &quot;carrier: $(&lt;/sys/class/net/ath0/carrier)&quot;
                    ESSID:&quot;mocisoft&quot;
carrier: 1
carrier: 1
halso:~ # iwconfig ath0 essid xyz; sleep 1 ; iwlist ath0 scan | grep ESSID; iwconfig ath0 essid mocisoft ; sleep 1 ; echo &quot;carrier: $(&lt;/sys/class/net/ath0/carrier)&quot;; sleep 20; echo &quot;carrier: $(&lt;/sys/class/net/ath0/carrier)&quot;
                    ESSID:&quot;mocisoft&quot;
carrier: 0
carrier: 1
</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>earny@net4u.de</who>
            <bug_when>2006-08-14 14:11:14 0000</bug_when>
            <thetext>Ups:
It is a IBM Thinkpad R50p,
02:02.0 Ethernet controller: Atheros Communications, Inc. AR5212 802.11abg NIC (rev 01)
</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>earny@net4u.de</who>
            <bug_when>2006-08-15 09:07:55 0000</bug_when>
            <thetext>Created an attachment (id=94330)
madwifi_preempt_scan_remove.patch

(In reply to comment #17)
&gt; Here in the office i can&apos;t reproduce it with the gentoo scripts, they just
&gt; work...
&gt; So maybe the problem depends on the ap&apos;s flying around in the air.

This ist complety _wrong_. The fix is
http://madwifi.org/ticket/776

Try to reboot after applying the patch, un/load the modules may not fix it ;)

Attached the shortes patch found to resolve the gentoo-script problem.</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>cbm@m.fsf.org</who>
            <bug_when>2006-08-16 09:22:33 0000</bug_when>
            <thetext>Comment #21: removing preempt_scan does seem to avoid/fix the problem, will report upstream.</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>cbm@m.fsf.org</who>
            <bug_when>2006-08-16 09:27:33 0000</bug_when>
            <thetext>Hmmm on second thought, while removing preempt_scan does seem to fix the gentoo issue in this bug, it doesn&apos;t seem to have any effect on my upstream but at http://madwifi.org/ticket/823.  Maybe these are two seperate issues.</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>uberlord@gentoo.org</who>
            <bug_when>2006-08-16 09:36:35 0000</bug_when>
            <thetext>(In reply to comment #23)
&gt; Hmmm on second thought, while removing preempt_scan does seem to fix the gentoo
&gt; issue in this bug

If someone else can confirm that then I&apos;ll look at patching the ebuild</thetext>
          </long_desc>
          <long_desc isprivate="0">
            <who>uberlord@gentoo.org</who>
            <bug_when>2006-08-22 23:55:21 0000</bug_when>
            <thetext>*** Bug 144811 has been marked as a duplicate of this bug. ***</thetext>
          </long_desc>
      
          <attachment
              isobsolete="0"
              ispatch="0"
              isprivate="0"
          >
            <attachid>94078</attachid>
            <date>2006-08-12 10:57 0000</date>
            <desc>emerge --info</desc>
            <filename>emerge-info.txt</filename>
            <type>text/plain</type>
            <data encoding="base64">R2VudG9vIEJhc2UgU3lzdGVtIHZlcnNpb24gMS4xMi40ClBvcnRhZ2UgMi4xLXIyIChkZWZhdWx0
LWxpbnV4L3g4Ni8yMDA2LjAsIGdjYy0zLjQuNiwgZ2xpYmMtMi4zLjYtcjQsIDIuNi4xOC1yYzQg
aTY4NikKPT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT0KU3lzdGVtIHVuYW1lOiAyLjYuMTgtcmM0IGk2ODYgSW50ZWwoUikgUGVu
dGl1bShSKSBNIHByb2Nlc3NvciAxNzAwTUh6CmNjYWNoZSB2ZXJzaW9uIDIuMyBbZW5hYmxlZF0K
YXBwLWFkbWluL2VzZWxlY3QtY29tcGlsZXI6IFtOb3QgUHJlc2VudF0KZGV2LWxhbmcvcHl0aG9u
OiAgICAgMi40LjMtcjEKZGV2LXB5dGhvbi9weWNyeXB0bzogMi4wLjEtcjUKZGV2LXV0aWwvY2Nh
Y2hlOiAgICAgMi4zCmRldi11dGlsL2NvbmZjYWNoZTogIFtOb3QgUHJlc2VudF0Kc3lzLWFwcHMv
c2FuZGJveDogICAgMS4yLjE3CnN5cy1kZXZlbC9hdXRvY29uZjogIDIuMTMsIDIuNTktcjcKc3lz
LWRldmVsL2F1dG9tYWtlOiAgMS40X3A2LCAxLjUsIDEuNi4zLCAxLjcuOS1yMSwgMS44LjUtcjMs
IDEuOS42LXIyCnN5cy1kZXZlbC9iaW51dGlsczogIDIuMTYuMS1yMwpzeXMtZGV2ZWwvZ2NjLWNv
bmZpZzogMS4zLjEzLXIzCnN5cy1kZXZlbC9saWJ0b29sOiAgIDEuNS4yMgp2aXJ0dWFsL29zLWhl
YWRlcnM6ICAyLjYuMTEtcjIKQUNDRVBUX0tFWVdPUkRTPSJ4ODYiCkFVVE9DTEVBTj0ieWVzIgpD
QlVJTEQ9Imk2ODYtcGMtbGludXgtZ251IgpDRkxBR1M9Ii1tYXJjaD1wZW50aXVtLW0gLU8yIC1w
aXBlIC1mb21pdC1mcmFtZS1wb2ludGVyIC1mZm9yY2UtYWRkciAtZnJlbmFtZS1yZWdpc3RlcnMi
CkNIT1NUPSJpNjg2LXBjLWxpbnV4LWdudSIKQ09ORklHX1BST1RFQ1Q9Ii9ldGMgL3Vzci9rZGUv
My41L2VudiAvdXNyL2tkZS8zLjUvc2hhcmUvY29uZmlnIC91c3Iva2RlLzMuNS9zaHV0ZG93biAv
dXNyL2xpYi9tb3ppbGxhL2RlZmF1bHRzL3ByZWYgL3Vzci9zaGFyZS9YMTEveGtiIC91c3Ivc2hh
cmUvY29uZmlnIC91c3Ivc2hhcmUvdGV4bWYvZHZpcGRmbS9jb25maWcvIC91c3Ivc2hhcmUvdGV4
bWYvZHZpcHMvY29uZmlnLyAvdXNyL3NoYXJlL3RleG1mL3RleC9nZW5lcmljL2NvbmZpZy8gL3Vz
ci9zaGFyZS90ZXhtZi90ZXgvcGxhdGV4L2NvbmZpZy8gL3Vzci9zaGFyZS90ZXhtZi94ZHZpLyIK
Q09ORklHX1BST1RFQ1RfTUFTSz0iL2V0Yy9lbnYuZCAvZXRjL2Vudi5kL2phdmEvIC9ldGMvZ2Nv
bmYgL2V0Yy9qYXZhLWNvbmZpZy92bXMvIC9ldGMvcmV2ZGVwLXJlYnVpbGQgL2V0Yy90ZXJtaW5m
byIKQ1hYRkxBR1M9Ii1tYXJjaD1wZW50aXVtLW0gLU8yIC1waXBlIC1mb21pdC1mcmFtZS1wb2lu
dGVyIC1mZm9yY2UtYWRkciAtZnJlbmFtZS1yZWdpc3RlcnMiCkRJU1RESVI9Ii91c3IvcG9ydGFn
ZS9kaXN0ZmlsZXMiCkZFQVRVUkVTPSJhdXRvY29uZmlnIGNjYWNoZSBkaXN0bG9ja3MgbWV0YWRh
dGEtdHJhbnNmZXIgc2FuZGJveCBzZnBlcm1zIHN0cmljdCIKR0VOVE9PX01JUlJPUlM9Imh0dHA6
Ly9wYW5kZW1vbml1bS50aXNjYWxpLmRlL3B1Yi9nZW50b28vIGh0dHA6Ly9taXJyb3JzLnNlYy5p
bmZvcm1hdGlrLnR1LWRhcm1zdGFkdC5kZS9nZW50b28vIGh0dHA6Ly9mdHAtc3R1ZC5maHQtZXNz
bGluZ2VuLmRlL3B1Yi9NaXJyb3JzL2dlbnRvby8iCkxBTkc9ImVuX1VTLnV0ZjgiCkxDX0FMTD0i
ZW5fVVMudXRmOCIKTElOR1VBUz0iZGUiCk1BS0VPUFRTPSItajMiClBLR0RJUj0iL3Vzci9wb3J0
YWdlL3BhY2thZ2VzIgpQT1JUQUdFX1JTWU5DX09QVFM9Ii0tcmVjdXJzaXZlIC0tbGlua3MgLS1z
YWZlLWxpbmtzIC0tcGVybXMgLS10aW1lcyAtLWNvbXByZXNzIC0tZm9yY2UgLS13aG9sZS1maWxl
IC0tZGVsZXRlIC0tZGVsZXRlLWFmdGVyIC0tc3RhdHMgLS10aW1lb3V0PTE4MCAtLWV4Y2x1ZGU9
Jy9kaXN0ZmlsZXMnIC0tZXhjbHVkZT0nL2xvY2FsJyAtLWV4Y2x1ZGU9Jy9wYWNrYWdlcyciClBP
UlRBR0VfVE1QRElSPSIvdmFyL3RtcCIKUE9SVERJUj0iL3Vzci9wb3J0YWdlIgpQT1JURElSX09W
RVJMQVk9Ii91c3IvbG9jYWwvcG9ydGFnZSIKU1lOQz0icnN5bmM6Ly9vZXJuaWUubmV0NHUuZGUv
Z2VudG9vLXBvcnRhZ2UiClVTRT0ieDg2IFggYWNwaSBhbHNhIGFwYWNoZTIgYXBtIGFydHMgYXJ0
c3dyYXBwZXJzdWlkIGF2aSBiYXNoLWNvbXBsZXRpb24gYmVya2RiIGJpdG1hcC1mb250cyBibHVl
dG9vdGggYnppcDIgY2RkYiBjZHBhcmFub2lhIGNkciBjbGkgY3J5cHQgY3NzIGN1cHMgZGJ1cyBk
Z2EgZGxsb2FkZXIgZG1pIGRvYyBkcmkgZHZiIGR2ZCBkdmRyIGR2ZHJlYWQgZW1hY3MgZW1ib3Nz
IGVuY29kZSBlc2QgZXhwYXQgZmlyZWZveCBmb29tYXRpY2RiIGZvcnRyYW4gZ2RibSBnaWYgZ2lt
cCBnbm9raWkgZ25vbWUgZ3BtIGdzdHJlYW1lciBndGsgZ3RrMiBoYWwgaGRhcHMgaW1saWIgaXJk
YSBpc2RubG9nIGphdmEganBlZyBrZGUga2RlZW5hYmxlZmluYWwgbGliZysrIGxpYnd3dyBtYWQg
bWlrbW9kIG1teCBtbXhleHQgbW90aWYgbXAzIG1wZWcgbmN1cnNlcyBubHMgbnB0bCBucHRsb25s
eSBuc3BsdWdpbiBvZ2cgb3BlbmdsIHBhbSBwY21jaWEgcGNyZSBwZGEgcGRmbGliIHBlcmwgcG5n
IHBvc3RncmVzIHBwcGQgcHl0aG9uIHF0MyBxdDQgcXVpY2t0aW1lIHJlYWRsaW5lIHJlYWwgcmVm
bGVjdGlvbiBzZGwgc2Vzc2lvbiBzbHAgc3BlbGwgc3BsIHNzZSBzc2UyIHNzbCBzdWJ2ZXJzaW9u
IHRjcGQgdGhlb3JhIHRpZmYgdHJ1ZXR5cGUgdHJ1ZXR5cGUtZm9udHMgdHlwZTEtZm9udHMgdWRl
diB1bmljb2RlIHVzYiB2NGwgdjRsMiB2b3JiaXMgd2lmaSB4aW5lIHhpbmVyYW1hIHhtbCB4bW1z
IHhvcmcgeG9zZCB4diB6bGliIGVsaWJjX2dsaWJjIGlucHV0X2RldmljZXNfZXZkZXYgaW5wdXRf
ZGV2aWNlc19qb3lzdGljayBpbnB1dF9kZXZpY2VzX3N5bmFwdGljcyBpbnB1dF9kZXZpY2VzX2tl
eWJvYXJkIGlucHV0X2RldmljZXNfbW91c2Uga2VybmVsX2xpbnV4IGxpbmd1YXNfZGUgdXNlcmxh
bmRfR05VIHZpZGVvX2NhcmRzX2ZiZGV2IHZpZGVvX2NhcmRzX3JhZGVvbiB2aWRlb19jYXJkc192
ZXNhIHZpZGVvX2NhcmRzX3ZnYSIKVW5zZXQ6ICBDVEFSR0VULCBFTUVSR0VfREVGQVVMVF9PUFRT
LCBJTlNUQUxMX01BU0ssIExERkxBR1MsIFBPUlRBR0VfUlNZTkNfRVhUUkFfT1BUUwoK
</data>        

          </attachment>
          <attachment
              isobsolete="0"
              ispatch="1"
              isprivate="0"
          >
            <attachid>94150</attachid>
            <date>2006-08-13 07:48 0000</date>
            <desc>Fix frequency detection</desc>
            <filename>madwifi.patch</filename>
            <type>text/plain</type>
            <data encoding="base64">SW5kZXg6IGl3Y29uZmlnLnNoCj09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09PT09
PT09PT09PT09PT09PT09PT09PT09PT09PT09PT0KLS0tIGl3Y29uZmlnLnNoCShyZXZpc2lvbiAy
MTgyKQorKysgaXdjb25maWcuc2gJKHdvcmtpbmcgY29weSkKQEAgLTM0Nyw3ICszNDcsNyBAQAog
IyBzbyB3ZSBjYW4gZmFpbCBncmFjZWZ1bGx5IHdpdGhvdXQgZXZlbiB0cnlpbmcgdG8gY29ubmVj
dAogaXdjb25maWdfYXNzb2NpYXRlKCkgewogCWxvY2FsIGlmYWNlPSIkMSIgbW9kZT0iJHsyOi1t
YW5hZ2VkfSIKLQlsb2NhbCBtYWM9IiQzIiB3ZXBfcmVxdWlyZWQ9IiQ0IiBmcmVxPSIkNSIgdz0i
KFdFUCBEaXNhYmxlZCkiCisJbG9jYWwgbWFjPSIkMyIgd2VwX3JlcXVpcmVkPSIkNCIgZnJlcT0i
JDUiIGNoYW49IiQ2IiB3PSIoV0VQIERpc2FibGVkKSIKIAlsb2NhbCBkZXNzaWQ9IiR7RVNTSUQv
L1xcXFwvXFxcXH0iIGtleT0KIAogCWl3Y29uZmlnX3NldF9tb2RlICIke2lmYWNlfSIgIiR7bW9k
ZX0iCkBAIC0zNzgsNyArMzc4LDEyIEBACiAJCVtbICR7a2V5fSAhPSAib2ZmIiBdXSAmJiB3PSQo
aXdjb25maWdfZ2V0X3dlcF9zdGF0dXMgIiR7aWZhY2V9IikKIAlmaQogCi0JW1sgLW4gJHtmcmVx
fSBdXSAmJiBpd2NvbmZpZyAiJHtpZmFjZX0iIGZyZXEgIiR7ZnJlcX0iCisJIyBPbmx5IHVzZSBj
aGFubmVsIG9yIGZyZXF1ZW5jeQorCWlmIFtbIC1uICR7Y2hhbn0gXV0gOyB0aGVuCisJCWl3Y29u
ZmlnICIke2lmYWNlfSIgY2hhbm5lbCAiJHtjaGFufSIKKwllbGlmIFtbIC1uICR7ZnJlcX0gXV0g
OyB0aGVuCisJCWl3Y29uZmlnICIke2lmYWNlfSIgZnJlcSAiJHtmcmVxfSIKKwlmaQogCVtbIC1u
ICR7bWFjfSBdXSAmJiBpd2NvbmZpZyAiJHtpZmFjZX0iIGFwICIke21hY30iCiAKIAlpZiAhIGl3
Y29uZmlnICIke2lmYWNlfSIgZXNzaWQgIiR7RVNTSUR9IiA7IHRoZW4KQEAgLTQ1Myw3ICs0NTgs
NyBAQAogCVtbIC16ICR7IXh9IHx8ICR7IXh9IC1ndCAwIF1dICYmIHNsZWVwICIkeyF4Oi0xfSIK
IAogCWxvY2FsIGVycm9yPXRydWUgaT0tMSBsaW5lPQotCWxvY2FsIC1hIG1hYz0oKSBlc3NpZD0o
KSBlbmM9KCkgcXVhbD0oKSBtb2RlPSgpCisJbG9jYWwgLWEgbWFjPSgpIGVzc2lkPSgpIGVuYz0o
KSBxdWFsPSgpIG1vZGU9KCkgZnJlcT0oKSBjaGFuPSgpCiAKIAl3aGlsZSByZWFkIGxpbmU7IGRv
CiAJCWVycm9yPWZhbHNlCkBAIC00NzYsNyArNDgxLDEyIEBACiAJCQkJOzsKIAkJCSpGcmVxdWVu
Y3k6KikKIAkJCQlmcmVxW2ldPSIke2xpbmUjKjp9IgorCQkJCWZyZXFbaV09IiR7ZnJlcVtpXSUl
ICp9IgogCQkJCTs7CisJCQkqQ2hhbm5lbDoqKQorCQkJCWNoYW5baV09IiR7bGluZSMqOn0iCisJ
CQkJY2hhbltpXT0iJHtjaGFuW2ldJSUgKn0iCisJCQkJOzsKIAkJCSpRdWFsaXR5KikKIAkJCQlx
dWFsW2ldPSIke2xpbmUjKjp9IgogCQkJCXF1YWxbaV09IiR7cXVhbFtpXSUvKn0iCkBAIC01MzMs
NiArNTQzLDcgQEAKIAkJCQl1bnNldCBtb2RlW3ldCiAJCQkJdW5zZXQgZW5jW3ldCiAJCQkJdW5z
ZXQgZnJlcVt5XQorCQkJCXVuc2V0IGNoYW5beV0KIAkJCWZpCiAJCWRvbmUKIAlkb25lCkBAIC01
NDIsNiArNTUzLDcgQEAKIAltb2RlPSggIiR7bW9kZVtAXX0iICkKIAllbmM9KCAiJHtlbmNbQF19
IiApCiAJZnJlcT0oICIke2ZyZXFbQF19IiApCisJY2hhbj0oICIke2NoYW5bQF19IiApCiAKIAlm
b3IgKCggaT0wOyBpPCR7I21hY1tAXX07IGkrKyApKTsgZG8KIAkJIyBEb24ndCBsaWtlIGFkLWhv
YyBub2RlcyBieSBkZWZhdWx0CkBAIC01NTcsNiArNTY5LDcgQEAKIAkJbW9kZV9BUHNbaV09IiR7
bW9kZVske3NvcnRsaW5lW3hdfV19IgogCQllbmNfQVBzW2ldPSIke2VuY1ske3NvcnRsaW5lW3hd
fV19IgogCQlmcmVxX0FQc1tpXT0iJHtmcmVxWyR7c29ydGxpbmVbeF19XX0iCisJCWNoYW5fQVBz
W2ldPSIke2NoYW5bJHtzb3J0bGluZVt4XX1dfSIKIAlkb25lCiAKIAlyZXR1cm4gMApAQCAtNjI5
LDYgKzY0Miw3IEBACiAJCXVuc2V0IG1hY19BUHNbaV0KIAkJdW5zZXQgZW5jX0FQc1tpXQogCQl1
bnNldCBmcmVxX0FQc1tpXQorCQl1bnNldCBjaGFuX0FQc1tpXQogCWRvbmUKIAogCSMgV2UgbmVl
ZCB0byBzcXVhc2ggb3VyIGFycmF5cyBzbyBpbmRleGVzIHdvcmsgYWdhaW4KQEAgLTYzNyw2ICs2
NTEsNyBAQAogCW1hY19BUHM9KCAiJHttYWNfQVBzW0BdfSIgKQogCWVuY19BUHM9KCAiJHtlbmNf
QVBzW0BdfSIgKQogCWZyZXFfQVBzPSggIiR7ZnJlcV9BUHNbQF19IiApCisJY2hhbl9BUHM9KCAi
JHtjaGFuX0FQc1tAXX0iICkKIH0KIAogIyBib29sIGl3Y29uZmlnX2ZvcmNlX3ByZWZlcnJlZChj
aGFyICppZmFjZSkKQEAgLTY3OSw3ICs2OTQsNyBAQAogCQkJaWYgW1sgJHtlc3NpZH0gPT0gIiR7
ZXNzaWRfQVBzW2ldfSIgXV07IHRoZW4KIAkJCQlFU1NJRD0iJHtlc3NpZH0iCiAJCQkJaXdjb25m
aWdfYXNzb2NpYXRlICIke2lmYWNlfSIgIiR7bW9kZV9BUHNbaV19IiAiJHttYWNfQVBzW2ldfSIg
XAotCQkJCQkiJHtlbmNfQVBzW2ldfSIgIiR7ZnJlcV9BUHNbaV19IiAmJiByZXR1cm4gMAorCQkJ
CQkiJHtlbmNfQVBzW2ldfSIgIiR7ZnJlcV9BUHNbaV19IiAiJHtjaGFuX0FQc1tpXX0iICYmIHJl
dHVybiAwCiAJCQkJYnJlYWsKIAkJCWZpCiAJCWRvbmUKQEAgLTcwNiw3ICs3MjEsNyBAQAogCQlp
ZiAhICR7aGFzX3ByZWZlcnJlZH0gOyB0aGVuCiAJCQlFU1NJRD0iJHtlc3NpZF9BUHNbaV19Igog
CQkJaXdjb25maWdfYXNzb2NpYXRlICIke2lmYWNlfSIgIiR7bW9kZV9BUHNbaV19IiAiJHttYWNf
QVBzW2ldfSIgXAotCQkJCSIke2VuY19BUHNbaV19IiAiJHtmcmVxX0FQc1tpXX0iICYmIHJldHVy
biAwCisJCQkJIiR7ZW5jX0FQc1tpXX0iICIke2ZyZXFfQVBzW2ldfSIgIiR7Y2hhbl9BUHNbaV19
IiAmJiByZXR1cm4gMAogCQlmaQogCWRvbmUKIApAQCAtNzUxLDEyICs3NjYsMTQgQEAKIAkJCQl1
bnNldCBtYWNfQVBzW2pdCiAJCQkJdW5zZXQgZW5jX0FQc1tqXQogCQkJCXVuc2V0IGZyZXFfQVBz
W2pdCisJCQkJdW5zZXQgY2hhbl9BUHNbal0KIAkJCQkjIFdlIG5lZWQgdG8gc3F1YXNoIG91ciBh
cnJheXMgc28gdGhhdCBpbmRleGVzIHdvcmsKIAkJCQllc3NpZF9BUHM9KCAiJHtlc3NpZF9BUHNb
QF19IiApCiAJCQkJbW9kZV9BUHM9KCAiJHttb2RlX0FQc1tAXX0iICkKIAkJCQltYWNfQVBzPSgg
IiR7bWFjX0FQc1tAXX0iICkKIAkJCQllbmNfQVBzPSggIiR7ZW5jX0FQc1tAXX0iICkKIAkJCQlm
cmVxX0FQcz0oICIke2ZyZXFfQVBzW0BdfSIgKQorCQkJCWNoYW5fQVBzPSggIiR7Y2hhbl9BUHNb
QF19IiApCiAJCQkJYnJlYWsKIAkJCWZpCiAJCWRvbmUKQEAgLTc4MCw3ICs3OTcsOCBAQAogIyB2
YXJpYWJsZXMgZm9yIHRoZSBFU1NJRAogaXdjb25maWdfY29uZmlndXJlKCkgewogCWxvY2FsIGlm
YWNlPSIkMSIgZT0geD0gaWZ2YXI9JChiYXNoX3ZhcmlhYmxlICIkMSIpCi0JbG9jYWwgLWEgZXNz
aWRfQVBzPSgpIG1hY19BUHM9KCkgbW9kZV9BUHM9KCkgZW5jX0FQcz0oKSBmcmVxX0FQcz0oKQor
CWxvY2FsIC1hIGVzc2lkX0FQcz0oKSBtYWNfQVBzPSgpIG1vZGVfQVBzPSgpCisJbG9jYWwgLWEg
ZW5jX0FQcz0oKSBmcmVxX0FQcz0oKSBjaGFuX0FQcz0oKQogCiAJRVNTSUQ9ImVzc2lkXyR7aWZ2
YXJ9IgogCUVTU0lEPSIkeyFFU1NJRH0iCg==
</data>        

          </attachment>
          <attachment
              isobsolete="1"
              ispatch="1"
              isprivate="0"
          >
            <attachid>94182</attachid>
            <date>2006-08-13 15:40 0000</date>
            <desc>if_down_up_hack.patch</desc>
            <filename>iwconfig.sh.ifdownup.patch</filename>
            <type>text/plain</type>
            <data encoding="base64">LS0tIGl3Y29uZmlnLnNoLm9yaWcJMjAwNi0wOC0xMyAyMzoyOTowMy4wMDAwMDAwMDAgKzAyMDAK
KysrIGl3Y29uZmlnLnNoCTIwMDYtMDgtMTMgMjM6NDc6MzEuMDAwMDAwMDAwICswMjAwCkBAIC0z
NDcsNyArMzQ3LDcgQEAKICMgc28gd2UgY2FuIGZhaWwgZ3JhY2VmdWxseSB3aXRob3V0IGV2ZW4g
dHJ5aW5nIHRvIGNvbm5lY3QKIGl3Y29uZmlnX2Fzc29jaWF0ZSgpIHsKIAlsb2NhbCBpZmFjZT0i
JDEiIG1vZGU9IiR7MjotbWFuYWdlZH0iCi0JbG9jYWwgbWFjPSIkMyIgd2VwX3JlcXVpcmVkPSIk
NCIgZnJlcT0iJDUiIHc9IihXRVAgRGlzYWJsZWQpIgorCWxvY2FsIG1hYz0iJDMiIHdlcF9yZXF1
aXJlZD0iJDQiIGZyZXE9IiQ1IiBjaGFuPSIkNiIgdz0iKFdFUCBEaXNhYmxlZCkiCiAJbG9jYWwg
ZGVzc2lkPSIke0VTU0lELy9cXFxcL1xcXFx9IiBrZXk9CiAKIAlpd2NvbmZpZ19zZXRfbW9kZSAi
JHtpZmFjZX0iICIke21vZGV9IgpAQCAtMzc4LDcgKzM3OCwxMiBAQAogCQlbWyAke2tleX0gIT0g
Im9mZiIgXV0gJiYgdz0kKGl3Y29uZmlnX2dldF93ZXBfc3RhdHVzICIke2lmYWNlfSIpCiAJZmkK
IAotCVtbIC1uICR7ZnJlcX0gXV0gJiYgaXdjb25maWcgIiR7aWZhY2V9IiBmcmVxICIke2ZyZXF9
IgorCSMgT25seSB1c2UgY2hhbm5lbCBvciBmcmVxdWVuY3kKKwlpZiBbWyAtbiAke2NoYW59IF1d
IDsgdGhlbgorCQlpd2NvbmZpZyAiJHtpZmFjZX0iIGNoYW5uZWwgIiR7Y2hhbn0iCisJZWxpZiBb
WyAtbiAke2ZyZXF9IF1dIDsgdGhlbgorCQlpd2NvbmZpZyAiJHtpZmFjZX0iIGZyZXEgIiR7ZnJl
cX0iCisJZmkKIAlbWyAtbiAke21hY30gXV0gJiYgaXdjb25maWcgIiR7aWZhY2V9IiBhcCAiJHtt
YWN9IgogCiAJaWYgISBpd2NvbmZpZyAiJHtpZmFjZX0iIGVzc2lkICIke0VTU0lEfSIgOyB0aGVu
CkBAIC00NTMsNyArNDU4LDcgQEAKIAlbWyAteiAkeyF4fSB8fCAkeyF4fSAtZ3QgMCBdXSAmJiBz
bGVlcCAiJHsheDotMX0iCiAKIAlsb2NhbCBlcnJvcj10cnVlIGk9LTEgbGluZT0KLQlsb2NhbCAt
YSBtYWM9KCkgZXNzaWQ9KCkgZW5jPSgpIHF1YWw9KCkgbW9kZT0oKQorCWxvY2FsIC1hIG1hYz0o
KSBlc3NpZD0oKSBlbmM9KCkgcXVhbD0oKSBtb2RlPSgpIGZyZXE9KCkgY2hhbj0oKQogCiAJd2hp
bGUgcmVhZCBsaW5lOyBkbwogCQllcnJvcj1mYWxzZQpAQCAtNDc2LDYgKzQ4MSwxMSBAQAogCQkJ
CTs7CiAJCQkqRnJlcXVlbmN5OiopCiAJCQkJZnJlcVtpXT0iJHtsaW5lIyo6fSIKKwkJCQlmcmVx
W2ldPSIke2ZyZXFbaV0lJSAqfSIKKwkJCQk7OworCQkJKkNoYW5uZWw6KikKKwkJCQljaGFuW2ld
PSIke2xpbmUjKjp9IgorCQkJCWNoYW5baV09IiR7Y2hhbltpXSUlICp9IgogCQkJCTs7CiAJCQkq
UXVhbGl0eSopCiAJCQkJcXVhbFtpXT0iJHtsaW5lIyo6fSIKQEAgLTQ4Niw2ICs0OTYsMTAgQEAK
IAkJZXNhYwogCWRvbmUgPCA8KGl3bGlzdCAiJHtpZmFjZX0iIHNjYW4gMj4vZGV2L251bGwpCiAK
KwkjIEhVUCB0aGUgaW50ZXJmYWNlIGFzIHNvbWUgZHJpdmVycy9jYXJkcyBuZWVkIGl0CisJaW50
ZXJmYWNlX2Rvd24gJHtpZmFjZX0KKwlpbnRlcmZhY2VfdXAgJHtpZmFjZX0KKwogCWlmICR7ZXJy
b3J9OyB0aGVuCiAJCWV3YXJuICIke2lmYWNlfSBkb2VzIG5vdCBzdXBwb3J0IHNjYW5uaW5nIgog
CQl4PSJhZGhvY19lc3NpZF8ke2lmdmFyfSIKQEAgLTUzMyw2ICs1NDcsNyBAQAogCQkJCXVuc2V0
IG1vZGVbeV0KIAkJCQl1bnNldCBlbmNbeV0KIAkJCQl1bnNldCBmcmVxW3ldCisJCQkJdW5zZXQg
Y2hhblt5XQogCQkJZmkKIAkJZG9uZQogCWRvbmUKQEAgLTU0Miw2ICs1NTcsNyBAQAogCW1vZGU9
KCAiJHttb2RlW0BdfSIgKQogCWVuYz0oICIke2VuY1tAXX0iICkKIAlmcmVxPSggIiR7ZnJlcVtA
XX0iICkKKwljaGFuPSggIiR7Y2hhbltAXX0iICkKIAogCWZvciAoKCBpPTA7IGk8JHsjbWFjW0Bd
fTsgaSsrICkpOyBkbwogCQkjIERvbid0IGxpa2UgYWQtaG9jIG5vZGVzIGJ5IGRlZmF1bHQKQEAg
LTU1Nyw2ICs1NzMsNyBAQAogCQltb2RlX0FQc1tpXT0iJHttb2RlWyR7c29ydGxpbmVbeF19XX0i
CiAJCWVuY19BUHNbaV09IiR7ZW5jWyR7c29ydGxpbmVbeF19XX0iCiAJCWZyZXFfQVBzW2ldPSIk
e2ZyZXFbJHtzb3J0bGluZVt4XX1dfSIKKwkJY2hhbl9BUHNbaV09IiR7Y2hhblske3NvcnRsaW5l
W3hdfV19IgogCWRvbmUKIAogCXJldHVybiAwCkBAIC02MjksNiArNjQ2LDcgQEAKIAkJdW5zZXQg
bWFjX0FQc1tpXQogCQl1bnNldCBlbmNfQVBzW2ldCiAJCXVuc2V0IGZyZXFfQVBzW2ldCisJCXVu
c2V0IGNoYW5fQVBzW2ldCiAJZG9uZQogCiAJIyBXZSBuZWVkIHRvIHNxdWFzaCBvdXIgYXJyYXlz
IHNvIGluZGV4ZXMgd29yayBhZ2FpbgpAQCAtNjM3LDYgKzY1NSw3IEBACiAJbWFjX0FQcz0oICIk
e21hY19BUHNbQF19IiApCiAJZW5jX0FQcz0oICIke2VuY19BUHNbQF19IiApCiAJZnJlcV9BUHM9
KCAiJHtmcmVxX0FQc1tAXX0iICkKKwljaGFuX0FQcz0oICIke2NoYW5fQVBzW0BdfSIgKQogfQog
CiAjIGJvb2wgaXdjb25maWdfZm9yY2VfcHJlZmVycmVkKGNoYXIgKmlmYWNlKQpAQCAtNjc5LDcg
KzY5OCw3IEBACiAJCQlpZiBbWyAke2Vzc2lkfSA9PSAiJHtlc3NpZF9BUHNbaV19IiBdXTsgdGhl
bgogCQkJCUVTU0lEPSIke2Vzc2lkfSIKIAkJCQlpd2NvbmZpZ19hc3NvY2lhdGUgIiR7aWZhY2V9
IiAiJHttb2RlX0FQc1tpXX0iICIke21hY19BUHNbaV19IiBcCi0JCQkJCSIke2VuY19BUHNbaV19
IiAiJHtmcmVxX0FQc1tpXX0iICYmIHJldHVybiAwCisJCQkJCSIke2VuY19BUHNbaV19IiAiJHtm
cmVxX0FQc1tpXX0iICIke2NoYW5fQVBzW2ldfSIgJiYgcmV0dXJuIDAKIAkJCQlicmVhawogCQkJ
ZmkKIAkJZG9uZQpAQCAtNzA2LDcgKzcyNSw3IEBACiAJCWlmICEgJHtoYXNfcHJlZmVycmVkfSA7
IHRoZW4KIAkJCUVTU0lEPSIke2Vzc2lkX0FQc1tpXX0iCiAJCQlpd2NvbmZpZ19hc3NvY2lhdGUg
IiR7aWZhY2V9IiAiJHttb2RlX0FQc1tpXX0iICIke21hY19BUHNbaV19IiBcCi0JCQkJIiR7ZW5j
X0FQc1tpXX0iICIke2ZyZXFfQVBzW2ldfSIgJiYgcmV0dXJuIDAKKwkJCQkiJHtlbmNfQVBzW2ld
fSIgIiR7ZnJlcV9BUHNbaV19IiAiJHtjaGFuX0FQc1tpXX0iICYmIHJldHVybiAwCiAJCWZpCiAJ
ZG9uZQogCkBAIC03NTEsMTIgKzc3MCwxNCBAQAogCQkJCXVuc2V0IG1hY19BUHNbal0KIAkJCQl1
bnNldCBlbmNfQVBzW2pdCiAJCQkJdW5zZXQgZnJlcV9BUHNbal0KKwkJCQl1bnNldCBjaGFuX0FQ
c1tqXQogCQkJCSMgV2UgbmVlZCB0byBzcXVhc2ggb3VyIGFycmF5cyBzbyB0aGF0IGluZGV4ZXMg
d29yawogCQkJCWVzc2lkX0FQcz0oICIke2Vzc2lkX0FQc1tAXX0iICkKIAkJCQltb2RlX0FQcz0o
ICIke21vZGVfQVBzW0BdfSIgKQogCQkJCW1hY19BUHM9KCAiJHttYWNfQVBzW0BdfSIgKQogCQkJ
CWVuY19BUHM9KCAiJHtlbmNfQVBzW0BdfSIgKQogCQkJCWZyZXFfQVBzPSggIiR7ZnJlcV9BUHNb
QF19IiApCisJCQkJY2hhbl9BUHM9KCAiJHtjaGFuX0FQc1tAXX0iICkKIAkJCQlicmVhawogCQkJ
ZmkKIAkJZG9uZQpAQCAtNzgwLDcgKzgwMSw4IEBACiAjIHZhcmlhYmxlcyBmb3IgdGhlIEVTU0lE
CiBpd2NvbmZpZ19jb25maWd1cmUoKSB7CiAJbG9jYWwgaWZhY2U9IiQxIiBlPSB4PSBpZnZhcj0k
KGJhc2hfdmFyaWFibGUgIiQxIikKLQlsb2NhbCAtYSBlc3NpZF9BUHM9KCkgbWFjX0FQcz0oKSBt
b2RlX0FQcz0oKSBlbmNfQVBzPSgpIGZyZXFfQVBzPSgpCisJbG9jYWwgLWEgZXNzaWRfQVBzPSgp
IG1hY19BUHM9KCkgbW9kZV9BUHM9KCkKKwlsb2NhbCAtYSBlbmNfQVBzPSgpIGZyZXFfQVBzPSgp
IGNoYW5fQVBzPSgpCiAKIAlFU1NJRD0iZXNzaWRfJHtpZnZhcn0iCiAJRVNTSUQ9IiR7IUVTU0lE
fSIK
</data>        

          </attachment>
          <attachment
              isobsolete="0"
              ispatch="1"
              isprivate="0"
          >
            <attachid>94330</attachid>
            <date>2006-08-15 09:07 0000</date>
            <desc>madwifi_preempt_scan_remove.patch</desc>
            <filename>madwifi_preempt_scan_remove.patch</filename>
            <type>text/plain</type>
            <data encoding="base64">LS0tIG5ldDgwMjExL2llZWU4MDIxMV93aXJlbGVzcy5jLm9yaWcJMjAwNi0wOC0xNSAxNzo1Nzoy
MS4wMDAwMDAwMDAgKzAyMDAKKysrIG5ldDgwMjExL2llZWU4MDIxMV93aXJlbGVzcy5jCTIwMDYt
MDgtMTUgMTg6MDA6NTcuMDAwMDAwMDAwICswMjAwCkBAIC0xMjEsNiArMTIxLDcgQEAKIAlpcS0+
dXBkYXRlZCA9IElXX1FVQUxfQUxMX1VQREFURUQ7CiB9CiAKKyNpZiAwCiBzdGF0aWMgdm9pZAog
cHJlZW1wdF9zY2FuKHN0cnVjdCBuZXRfZGV2aWNlICpkZXYsIGludCBtYXhfZ3JhY2UsIGludCBt
YXhfd2FpdCkKIHsKQEAgLTE1Myw3ICsxNTQsNyBAQAogCQkJICAgIF9fZnVuY19fKTsgCiAJfQog
fQotCQorI2VuZGlmCiBzdGF0aWMgc3RydWN0IGl3X3N0YXRpc3RpY3MgKgogaWVlZTgwMjExX2l3
X2dldHN0YXRzKHN0cnVjdCBuZXRfZGV2aWNlICpkZXYpCiB7CkBAIC0xNTE1LDcgKzE1MTYsNyBA
QAogCS8qIFhYWCBhbHdheXMgbWFudWFsLi4uICovCiAJSUVFRTgwMjExX0RQUklOVEYodmFwLCBJ
RUVFODAyMTFfTVNHX1NDQU4sCiAJCSIlczogYWN0aXZlIHNjYW4gcmVxdWVzdFxuIiwgX19mdW5j
X18pOwotCXByZWVtcHRfc2NhbihkZXYsIDEwMCwgMTAwKTsKKwkvLyBwcmVlbXB0X3NjYW4oZGV2
LCAxMDAsIDEwMCk7CiAjaWYgV0lSRUxFU1NfRVhUID4gMTcKIAlpZiAoZGF0YSAmJiAoZGF0YS0+
ZmxhZ3MgJiBJV19TQ0FOX1RISVNfRVNTSUQpKSB7CiAJCXN0cnVjdCBpd19zY2FuX3JlcSByZXE7
Cg==
</data>        

          </attachment>
    </bug>

</bugzilla>