netdev - Re: ucc_geth: nf_conntrack: table full, dropping packet.

lists.openwall.net		lists / announce owl-users owl-dev john-users john-dev passwdqc-users yescrypt popa3d-users / oss-security kernel-hardening musl sabotage tlsify passwords / crypt-dev xvendor / Bugtraq Full-Disclosure linux-kernel linux-netdev linux-ext4 linux-hardening linux-cve-announce PHC
Open Source and information security mailing list archives

Hash Suite: Windows password security audit tool. GUI, reports in PDF.

[<prev] [next>] [day] [month] [year] [list]

Date:	Mon, 23 Mar 2009 14:09:42 +0100
From:	Joakim Tjernlund <Joakim.Tjernlund@...nsmode.se>
To:	leoli@...escale.com
Cc:	avorontsov@...mvista.com, Patrick McHardy <kaber@...sh.net>,
	netdev@...r.kernel.org
Subject: Re: ucc_geth: nf_conntrack: table full, dropping packet.

Joakim Tjernlund/Transmode wrote on 23/03/2009 13:59:15:
> 
> Patrick McHardy <kaber@...sh.net> wrote on 23/03/2009 13:29:33:
> > Joakim Tjernlund wrote:
> > > Patrick McHardy <kaber@...sh.net> wrote on 23/03/2009 13:15:45:
> > >> Joakim Tjernlund wrote:
> > >>> doing a "ping -f -l 3" on my host towards my board on linus tree 
as of 
> > > 
> > >>> Friday results in lots of:
> > >>> nf_conntrack: table full, dropping packet.
> > >>> nf_conntrack: table full, dropping packet.
> > >>> nf_conntrack: table full, dropping packet.
> > >>> __ratelimit: 11 callbacks suppressed
> > >>> nf_conntrack: table full, dropping packet.
> > >>> nf_conntrack: table full, dropping packet.
> > >>> nf_conntrack: table full, dropping packet.
> > >>> nf_conntrack: table full, dropping packet.
> > >>>
> > >>> for ucc_geth on a MPC832x.
> > >>> This really looks strange to me, ideas?
> > >> What does /proc/net/netfilter/nf_conntrack show?
> > > 
> > > There is no /proc/net/netfilter/nf_conntrack. There is a
> > > /proc/net/nf_conntrack though and it is empty. If I telnet
> > > to the board I see:
> > 
> > That means that something is leaking conntrack references, most likely
> > by leaking skbs. Since I haven't seen any other reports, my guess 
would
> > be the ucc_geth driver.

> hmm, I cannot see what in the ucc_geth driver is possibly "leaking". One 
thing
> I do notice is that the board becomes almost unresponsive during the 
ping flood.
> Perhaps it is building up a backlog of conntracks during the ping flood?
> 
>  Jocke

next hmm, ethtool -S eth0 shows:
...
 rx-mismatch-drop-frames: 13
...

13 matches the number of lost frames after I stop the ping flood.

The MPC832x manual says this(if i found the correct counter):

REBASE+2C MisMatchDrop 32 Counts number of frames dropped due to MAC 
filtering process, (e.g.
                          Address Mismatch, Type mismatch) and that would 
otherwise
                          considered good frame that would be transferred 
to upper layers

Why would a ping flood result in Address Mismatch or Type mismatch?

Leo?

  Jocke
--
To unsubscribe from this list: send the line "unsubscribe netdev" in
the body of a message to majordomo@...r.kernel.org
More majordomo info at  http://vger.kernel.org/majordomo-info.html