Received: with ECARTIS (v1.0.0; list netdev); Fri, 01 Jul 2005 09:34:35 -0700 (PDT) Received: from mail.tpack.net (ip18.tpack.net [213.173.228.18]) by oss.sgi.com (8.12.10/8.12.10/SuSE Linux 0.7) with SMTP id j61GYUH9015022 for ; Fri, 1 Jul 2005 09:34:31 -0700 Received: (qmail 5899 invoked from network); 1 Jul 2005 16:32:59 -0000 Received: from unknown (HELO ?172.17.159.11?) (192.168.111.1) by 0 with SMTP; 1 Jul 2005 16:32:59 -0000 Message-ID: <42C57058.70806@tpack.net> Date: Fri, 01 Jul 2005 18:33:28 +0200 From: Tommy Christensen User-Agent: Mozilla/5.0 (X11; U; Linux i686; en-US; rv:1.7.2) Gecko/20040803 X-Accept-Language: en-us, en MIME-Version: 1.0 To: Eric Lammerts CC: madwifi-devel@lists.sourceforge.net, herbert@gondor.apana.org.au, davem@davemloft.net, netdev@oss.sgi.com Subject: Re: problems with 2.6.12 References: <42C562A4.9070501@lammerts.org> In-Reply-To: <42C562A4.9070501@lammerts.org> Content-Type: text/plain; charset=us-ascii; format=flowed Content-Transfer-Encoding: 7bit X-archive-position: 2586 X-ecartis-version: Ecartis v1.0.0 Sender: netdev-bounce@oss.sgi.com Errors-to: netdev-bounce@oss.sgi.com X-original-sender: tommy.christensen@tpack.net Precedence: bulk X-list: netdev Eric Lammerts wrote: > Hello all, > I was having problems with 2.6.12 + madwifi in master mode. No packets > were going out. With tcpdump I see DHCP requests coming in, with strace > I see the dhcp daemon sending replies out, but they don't show up in > tcpdump. > > It's caused by this change: > http://oss.sgi.com/projects/netdev/archive/2005-05/msg00109.html > > which btw also causes problems for other people: > http://marc.theaimsgroup.com/?l=linux-kernel&m=111853727810345&w=2 Auch. And vlan interfaces are having trouble as well. > Madwifi doesn't call netif_carrier_on() in master mode, so Linux drops > all packets. When I remove the dev_deactivate() line, it works fine again. Netdevices are "born" with carrier on, so if your code don't call netif_carrier_off() or set dev->state directly, I don't see how you can end up in this state. Could you investigate this? > Should we fix madwifi or the kernel? The code is there for a reason, so hopefully we can work this out. -Tommy