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

Joakim Tjernlund/Transmode wrote on 23/03/2009 13:59:15:

Patrick McHardy [off-list ref] wrote on 23/03/2009 13:29:33:

quoted

Joakim Tjernlund wrote:

quoted

Patrick McHardy [off-list ref] wrote on 23/03/2009 13:15:45:

quoted

Joakim Tjernlund wrote:

quoted

doing a "ping -f -l 3" on my host towards my board on linus tree 

as of 

quoted

quoted

quoted

quoted

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

quoted

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