[Avila] Gateworks and the Intel NPEs

[devel]

Tim,

    I don't have anything really formal to show the list as far as what is 
happening when a wifi client loses connection (or appears to). We are using 
madwifi, bridging, and hostapd. This occurs with no encryption as well as 
over the bridge (ath0 & eth0 is promiscuous) so hostapd wouldn't be running 
at that point of course. What I have seen using ethereal is, the client 
can't get receive traffic back across the AP. Ethereal sees the request AND 
the reply for a ping on a wired PC on the other side of the AP, but this 
never gets back to the client. I put tcpdump on the AP and it never sees the 
reply from the wired PC.

    Currently, I have gone back and stripped out any work I've done in the 
NPE driver (which really wasn't much) and I do have this monitored as I let 
this AP run with a console to a PC. So for over a week now, no problems. But 
I will let this go awhile yet before I say things seem relsolved. And yes I 
am using the npe_learing=0.

Dave....I too would like to know when the next release of the BSP would be. 
We are seeing the interrupt problem that many on the list have noted. Also 
I've heard madwifi bark about the improvements to the kernel build in the 
2.6.16+ kernels and they seem to like it.

Thanks guys.

Travis

----- Original Message ----- 
From: "Tim Harvey" <tim_harvey at yahoo.com>
To: "Avila" <avila at lists.unixstudios.net>
Sent: Sunday, January 07, 2007 1:35 PM
Subject: Re: [Avila] Gateworks and the Intel NPEs
Subject: [Avila] >I would have to agree with Dave here as to where the problem is.  I have 
>been using the IAL (with npe_learning=0) for quite some time and I've never 
>run into this problem (at least that I know of).  Travis, do you have a 
>simple test case that shows this problem?  What other components are you 
>using in your setup (madwifi/hostap/bridge?).
>
> Dave, any target date for your next BSP?
>
> I've been working on updating my kernel, however I use snapgear for 
> userland with glibc.  I've found that the glibc-2.25 that snapgear uses is 
> very outdated and has issues building with newer toolchains which are 
> required to build the latest kernels.  Therefore, if your using 
> snapgear+glibc+linux-2.6.18+ you have to use a different toolchain for 
> building the kernel as you do for snapgear userland (glibc specifically). 
> I'm not sure how easy it is to update glibc in snapgear (I notice that 
> snapgear 3.4.0 does not even include glibc).
>
> So, what are you people using with your newer kernels with regards to 
> userland?  buildroot?
>
> Thanks,
>
> Tim
>
> ----- Original Message ----
> From: Dave G <daveg at unixstudios.net>
> To: Avila <avila at lists.unixstudios.net>
> Sent: Friday, January 5, 2007 12:00:00 PM
> Subject: Re: [Avila] Gateworks and the Intel NPEs
>
> Hi Travis/List,
>
>
> I can comment on the roadmap question. Our plans are to include latest IAL
> as well as the GPL driver in our next BSP release so you can choose either
> to use.
> We currently don't have plans to dig into the IAL code to do repair work,
> however if the next IAL release exhibits the same issues previous releases
> have we likely would dig into it to see what we can find. As you all know
> the IAL code is developed and provided by Intel and not by Gateworks.
>
>
> My own thoughts on the reported IAL/NPE issues are probably not shared by
> most. Because it seems that the reported IAL issues persist over different
> versions of the IAL and also since Intel has failed to acknowledge and/or
> repair the reported issues, I suspect that there may not be any issues
> whatsoever in the IAL or if there are they may be very minor. I find it 
> hard
> to believe that Intel would continue to release IAL versions which exhibit
> the same reported issues without Intel doing anything about it if such
> issues indeed existed and were validated by Intel. I realize that many of
> the IAL releases are just feature/cpu upgrades and not always fixes.
>
> IMHO I think that the reported issues could very well be related to the
> environment or manner in which many of us use the NPEs.
>
> For example, the npe_learning=0 argument passed to the ixp400_eth module
> turns off MAC learning in the IAL/driver. This argument MUST be used if 
> the
> NPE is to be a part of a bridge where MAC learning is already being done
> (Linux ethernet bridging). Without turning off npe_learning in the IAL 
> some
> funky things happen.
> Looking at the various available microcode (the microcode loaded into the
> NPE) and the different features that each of them employ causes me to
> suspect that I might have a problem down the road because the IAL is doing
> something like:
>
> NPEA_ETH_SPAN_MASK_FIREWALL_VLAN_QOS_HDR_CONV_EXTMIB
> NPEA_ETH_SPAN_VLAN_QOS_HDR_CONV_EXTMIB
> NPEA_ETH_LEARN_FILTER_SPAN_MASK_FIREWALL_VLAN_QOS_EXTMIB
> NPEB_ETH_LEARN_FILTER_SPAN_FIREWALL_VLAN_QOS
> NPEB_ETH_SPAN_FIREWALL_VLAN_QOS_HDR_CONV
>
> yet I am planning on doing some of the same in the kernel via iprout2,
> iptables, etc, etc.
>
> I haven't looked deeply into even if the above features are actually being
> performed in the NPE or how to control them, except that I know using
> npe_learning=0 absolutely cleans up the bridging issues I was experiencing
> when ixp0/ixp1 was part of a bridge group. Additionally I haven't looked
> specifically at the ramifications of the NPE microcode doing something 
> like
> HDR_CONV while I am doing iptables -t mangle stuff.
>
> Anyway, if we end up experiencing IAL/NPE issues after this next BSP 
> release
> I would suspect that we would begin looking in the above described areas.
>
>
> Thanks!
>
>
> -Dave G
>
>
>
>
>
>
>
> Hey list,
>
>    I am just wondering where Gateworks stands with the Intel NPEs. We've
> all seen the posts about the receive buffer problems (in promiscuous mode)
> some of us have had with the Intel driver currently released with the 
> BSPs.
> Currently, we still have this issue and it remains a big problem for us.
> This of course doesn't allow a confident Wi-fi access point.
>
>    I have seen that a lot of you are switching over to the open source NPE
> driver, NSLU2 correct? Is this the direction that everyone is going and 
> does
> Gateworks have a roadmap to possibly solve the issue with the BSP released
> NPE driver? Or are they recommending everyone just use the open source
> version?
>
>    Hopefully this ends up being an easy answer. I know a few of us have
> looked at this ourselves, in particular David Acker. Some of the things
> David had found ended up not working for both of us. However, I have tried
> what was last stated by David and Dave G on regards to the modprobe line:
>
>    modprobe ixp400
>    cat /etc/IxNpeMicrocode.dat > /dev/ixNpe
>    modprobe ixp400_eth npe_learning=0
>
>    Even with adding the npe_learning=0 option for the modprobe of
> ixp400_eth, we have still seen periods of dropped packets just as before.
> Any thoughts would be greatly appreciated. Thanks.
>
>
> Travis
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: avila-unsubscribe at lists.unixstudios.net
> For additional commands, e-mail: avila-help at lists.unixstudios.net
>
>
>
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail: avila-unsubscribe at lists.unixstudios.net
> For additional commands, e-mail: avila-help at lists.unixstudios.net
>
>
>