First Last Prev Next    No search results available      Search page      Enter new bug
Bug#: 143698
Alias:
Product:
Component:
Status: RESOLVED
Resolution: UPSTREAM
Assigned To: Roy Marples (RETIRED) <uberlord@gentoo.org>
Hardware:
OS:
Version:
Priority:
Severity:
Reporter: Ernst Herzberg <earny@net4u.de>
Add CC:
CC:
Remove selected CCs
URL:
Summary:
Status Whiteboard:
Keywords:

Filename Description Type Creator Created Size Actions
emerge-info.txt emerge --info text/plain Ernst Herzberg 2006-08-12 10:57 0000 3.11 KB Details
madwifi.patch Fix frequency detection patch Roy Marples (RETIRED) 2006-08-13 07:48 0000 3.59 KB Details | Diff
iwconfig.sh.ifdownup.patch if_down_up_hack.patch patch Ernst Herzberg 2006-08-13 15:40 0000 3.79 KB Details | Diff
madwifi_preempt_scan_remove.patch madwifi_preempt_scan_remove.patch patch Ernst Herzberg 2006-08-15 09:07 0000 742 bytes Details | Diff
Create a New Attachment (proposed patch, testcase, etc.) View All

Bug 143698 depends on: Show dependency tree
Show dependency graph
Bug 143698 blocks:
Votes: 0    Show votes for this bug    Vote for this bug

Additional Comments: (this is where you put emerge --info)







View Bug Activity   |   Format For Printing   |   XML   |   Clone This Bug


Description:   Opened: 2006-08-12 10:52 0000
First of all: 
No problems with sys-apps/baselayout-1.11.15-r3.
At any time i can do an

halso:~ # ifconfig ath0 up && sleep 1 && iwconfig ath0 essid net4u2 && sleep 5
&& 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=( "dhcp" )
dhcpcd_ath0="-t 30 -h halsowa"
sleep_scan_ath0="10"
sleep_associate_ath0="20"
preferred_aps=( "net4u2" "mocisoft" )
associate_order="preferedonly"

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 "net4u2" at 00:0F:3D:09:CF:27 (managed)
 *     Found "WLAN" at 00:12:BF:57:76:91 (managed, encrypted)
 *   Connecting to "net4u2" in managed mode (WEP Disabled) ...  [ !! ]
 *   Couldn'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 "iwconfig $@"
        LC_ALL=C /sbin/iwconfig "$@"
 }
 iwgetid() {
+       logger -t iwsh "iwgetid $@"
        LC_ALL=C /sbin/iwgetid "$@"
 }
 iwlist() {
+       logger -t iwsh "iwlist $@"
        LC_ALL=C /sbin/iwlist "$@"
 }
 iwpriv() {
+       logger -t iwsh "iwpriv $@"
        LC_ALL=C /sbin/iwpriv "$@"
 }


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'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: "iwconfig ath0 freq 2.412 GHz (Channel 1)" 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 "1" if association succeeds.

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

A "watch --interval 1 iwconfig ath0" 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'm lost. Some ideas?

------- Comment #1 From Ernst Herzberg 2006-08-12 10:57:01 0000 -------
Created an attachment (id=94078) [edit]
emerge --info

------- Comment #2 From Toralf Förster 2006-08-12 13:05:14 0000 -------
What'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

------- Comment #3 From Colin Macdonald 2006-08-12 19:59:45 0000 -------
I think I'm seeing this too.  I'm using madwifi-ng-0.9.2 and
baselayout-1.12.4-r2.

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

results in:
aconite conf.d # /etc/init.d/net.ath0 restart
 * Starting ath0
 *   Configuring wireless network for ath0
 *   Couldn'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 "dhcpcd
ath0" and it connects (in other words, essid, WEP key etc are setup correctly
by the baselayout script).  Its just the baselayout script that won't connect
to an AP, everything works if I do it manually.

I don't really understand Comment #2's reference to bug #143666 because this
doesn'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="no"
RC_COLDPLUG="no"
RC_PLUG_SERVICES=""

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="x86 ~x86"
AUTOCLEAN="yes"
CBUILD="i686-pc-linux-gnu"
CFLAGS="-march=i686 -O2 -pipe"
CHOST="i686-pc-linux-gnu"
CONFIG_PROTECT="/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"
CONFIG_PROTECT_MASK="/etc/env.d /etc/env.d/java/ /etc/eselect/compiler
/etc/gconf /etc/java-config/vms/ /etc/revdep-rebuild /etc/terminfo
/etc/texmf/web2c"
CXXFLAGS="-march=i686 -O2 -pipe"
DISTDIR="/usr/portage/distfiles"
FEATURES="autoconfig collision-protection distcc distlocks metadata-transfer
sandbox sfperms strict userpriv usersandbox"
GENTOO_MIRRORS="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"
LINGUAS=""
MAKEOPTS="-j1"
PKGDIR="/usr/portage/packages"
PORTAGE_RSYNC_OPTS="--recursive --links --safe-links --perms --times --compress
--force --whole-file --delete --delete-after --stats --timeout=180
--exclude='/distfiles' --exclude='/local' --exclude='/packages'"
PORTAGE_TMPDIR="/var/tmp"
PORTDIR="/usr/portage"
PORTDIR_OVERLAY="/usr/local/portage /usr/local/ag-portage"
SYNC="rsync://rsync.gentoo.org/gentoo-portage"
USE="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"
Unset:  CTARGET, EMERGE_DEFAULT_OPTS, INSTALL_MASK, LANG, LC_ALL, LDFLAGS,
PORTAGE_RSYNC_EXTRA_OPTS

------- Comment #4 From Roy Marples (RETIRED) 2006-08-13 03:04:53 0000 -------
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 "iwlist ath0 scan" please

------- Comment #5 From Roy Marples (RETIRED) 2006-08-13 07:48:17 0000 -------
Created an attachment (id=94150) [edit]
Fix frequency detection

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

I have a madwifi card, but it powers my AP. I'll see if I can replicate it in
the week when I can get a keyboard and screen to it, otherwise I'll happily
review any patches that come in.

------- Comment #6 From Ernst Herzberg 2006-08-13 15:40:19 0000 -------
Created an attachment (id=94182) [edit]
if_down_up_hack.patch

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

@@ -486,6 +496,10 @@
                esac
        done < <(iwlist "${iface}" scan 2>/dev/null)

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


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 "${iface}" essid any

        veinfo "Scanning for access points"

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 "${iface}" essid "${ESSID}"
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)

------- Comment #7 From Roy Marples (RETIRED) 2006-08-13 15:55:15 0000 -------
(In reply to comment #6)
> Created an attachment (id=94182) [edit]
> if_down_up_hack.patch
> 
> Ok, found it. The new baselayout misses two lines of code:
> 
> @@ -486,6 +496,10 @@
>                 esac
>         done < <(iwlist "${iface}" scan 2>/dev/null)
> 
> +       # HUP the interface as some drivers/cards need it
> +       interface_down ${iface}
> +       interface_up ${iface}
> +
>         if ${error}; then
>                 ewarn "${iface} does not support scanning"
>                 x="adhoc_essid_${ifvar}"
> 
> 
> 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's not going to fly right now - it's going to have
to be fixed upstream.

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

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

> 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 "${iface}" essid any
> 
>         veinfo "Scanning for access points"
> 
> 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;)

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.

------- Comment #8 From Ernst Herzberg 2006-08-13 16:29:59 0000 -------
(In reply to comment #7)

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

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.

> 
> 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.
> 

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

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

and the race is almost gone. (wait for at least 1sec)

------- Comment #9 From Colin Macdonald 2006-08-13 18:05:59 0000 -------
As per comment #4, commenting out the "# Use sysfs if we can" block of code had
no effect, still doesn't work.

aconite ~ # iwlist ath0 scan
ath0      Scan completed :
          Cell 01 - Address: 00:0C:41:1A:82:A0
                    ESSID:"REDSCAPE1"
                    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:"atropa"
                    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:"martin"
                    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't see the channel bug so I can'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 "fix" 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't fix
anything for me.

------- Comment #10 From Roy Marples (RETIRED) 2006-08-14 00:03:27 0000 -------
Does this help any? Place it in /etc/conf.d/net

preup() { 
    if [[ ${IFACE} == "ath0" ]] ; then 
       # Some atheros cards need an extra up 
       # NOTE: the card is upped a few times anyway, so this *should* be
redundant 
       interface_up "${IFACE}" 
       # Maybe give it time to settle 
       sleep 2 
    fi 
 }

------- Comment #11 From Horst Schirmeier 2006-08-14 03:36:02 0000 -------
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 'dhcpcd ath0' afterwards makes everything work.

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

/etc/conf.d/wireless:
essid_ath0="xxx"
channel_ath0="9"
sleep_scan_ath0="1"
associate_timeout_ath0="30"

------- Comment #12 From Roy Marples (RETIRED) 2006-08-14 06:36:33 0000 -------
(In reply to comment #11)
> 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    [ !! ]

Totatlly unrelated as this bug is about using iwconfig and your error is with
wpa_supplicant.

------- Comment #13 From Colin Macdonald 2006-08-14 10:24:09 0000 -------
Upgrade to baselayout-1.12.4-r3 didn'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 "atropa" 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 "/etc/dhcpc/dhcpcd.exe /var/lib/dhcpc/dhcpcd-ath0.info up"
                          [ ok ] *       ath0 received address 192.168.0.200/24

Is there still an issue here to report upstream?

------- Comment #14 From Roy Marples (RETIRED) 2006-08-14 10:42:47 0000 -------
(In reply to comment #13)
> 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'm guessing that it's a driver/hardware issue. FWIW it's a NetGear
WG311v1 - Atheros Communications, Inc. AR5212 802.11abg NIC (rev 01)

Someone should report this upstream and reference it here. I'd appreciate that
as my card is also my AP in a headless server making testing/debugging
difficult at best - also I don't seem to suffer from the bug.

------- Comment #15 From Colin Macdonald 2006-08-14 11:44:47 0000 -------
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.

------- Comment #16 From Roy Marples (RETIRED) 2006-08-14 12:23:33 0000 -------
(In reply to comment #15)
> Ok, I submitted this ticket to upstream madwifi:
> http://madwifi.org/ticket/823

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

BTW, don't emerge dhcpcd with the debug USE flag - it won't actually work as a
dhcp client ;)

------- Comment #17 From Ernst Herzberg 2006-08-14 12:35:55 0000 -------
Here in the office i can't reproduce it with the gentoo scripts, they just
work...
So maybe the problem depends on the ap's flying around in the air.

But then 'upstream bug' 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:"mocisoft"
                    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:"mocisoft"

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:"mocisoft"
                    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:"does_not_exists"
21:26:16.521428   ath0     Set ESSID:"mocisoft"
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....

------- Comment #18 From Colin Macdonald 2006-08-14 13:14:35 0000 -------
Re comment #16: I don't have debug USE flag on, I just pass -d to dhcpcd in
(dhcpcd_atropa="-d -t 16").  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't think its affects dhcpcd'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 < 1.9 or > 1.9

------- Comment #19 From Ernst Herzberg 2006-08-14 13:57:27 0000 -------
> 
> 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 < 1.9 or > 1.9
> 

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 "carrier: $(</sys/class/net/ath0/carrier)"; sleep 20; echo
"carrier: $(</sys/class/net/ath0/carrier)"
                    ESSID:"mocisoft"
carrier: 0
carrier: 0
halso:~ # iwlist ath0 scan | grep ESSID; sleep 11; iwconfig ath0 essid mocisoft
; sleep 1 ; echo "carrier: $(</sys/class/net/ath0/carrier)"; sleep 20; echo
"carrier: $(</sys/class/net/ath0/carrier)"
                    ESSID:"mocisoft"
carrier: 1
carrier: 1
halso:~ # iwconfig ath0 essid xyz; sleep 1 ; iwlist ath0 scan | grep ESSID;
iwconfig ath0 essid mocisoft ; sleep 1 ; echo "carrier:
$(</sys/class/net/ath0/carrier)"; sleep 20; echo "carrier:
$(</sys/class/net/ath0/carrier)"
                    ESSID:"mocisoft"
carrier: 0
carrier: 1

------- Comment #20 From Ernst Herzberg 2006-08-14 14:11:14 0000 -------
Ups:
It is a IBM Thinkpad R50p,
02:02.0 Ethernet controller: Atheros Communications, Inc. AR5212 802.11abg NIC
(rev 01)

------- Comment #21 From Ernst Herzberg 2006-08-15 09:07:55 0000 -------
Created an attachment (id=94330) [edit]
madwifi_preempt_scan_remove.patch

(In reply to comment #17)
> Here in the office i can't reproduce it with the gentoo scripts, they just
> work...
> So maybe the problem depends on the ap'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.

------- Comment #22 From Colin Macdonald 2006-08-16 09:22:33 0000 -------
Comment #21: removing preempt_scan does seem to avoid/fix the problem, will
report upstream.

------- Comment #23 From Colin Macdonald 2006-08-16 09:27:33 0000 -------
Hmmm on second thought, while removing preempt_scan does seem to fix the gentoo
issue in this bug, it doesn't seem to have any effect on my upstream but at
http://madwifi.org/ticket/823.  Maybe these are two seperate issues.

------- Comment #24 From Roy Marples (RETIRED) 2006-08-16 09:36:35 0000 -------
(In reply to comment #23)
> Hmmm on second thought, while removing preempt_scan does seem to fix the gentoo
> issue in this bug

If someone else can confirm that then I'll look at patching the ebuild

------- Comment #25 From Roy Marples (RETIRED) 2006-08-22 23:55:21 0000 -------
*** Bug 144811 has been marked as a duplicate of this bug. ***

First Last Prev Next    No search results available      Search page      Enter new bug