LARTC - May 2003 - u32 hashing bug?

I''m hashing on a non-octet boundary, and it doesn''t seem to be
working.

I''ve got this set of filters, that does work: 

# root
tc filter add dev eth1  \
       parent 1: protocol ip prio 2 \
       u32 

# ht
tc filter add dev eth1  \
       parent 1: protocol ip prio 2   \
       handle 2:       \
       u32 divisor 256 

# flow
tc filter replace dev eth1  \
       parent 1: protocol ip prio 2   \
	 \
       u32     \
               ht 2:65:        \
               match ip src 192.168.1.100      \
               flowid 1:20 

# link
tc filter add dev eth1  \
       protocol ip parent 1: prio 2   \
	handle 800::2 \
       u32     \
               ht 800::        \
               match ip src 192.168.0.0/16     \
               hashkey mask 0x000000ff at 12 \
               link 2: 

I changed just the hashkey mask on the "link" filter to:
               hashkey mask 0x000ff000 at 12 \
and the hashtable on the "flow" filter to:
               ht 2:80:        \ 

Checking it in tc -r filter list dev eth1, I see that nothing but the 
hashkey and bucket changed. 

I''d expect that it''d hash on the fourth and fifth bytes.  But
it doesn''t
match, and my traffic goes to the default bucket.  I tried it with a hashkey 
mask of 0xff00 0000, 0x00ff 0000, 0x0000 ff00, and 0x0000 00ff (and
ht''s of
c0, a8, 01, and 69, respectively); they all worked.  I tried 0x0ff0 0000 and 
0x000f f000 (ht''s 0a and 80) without success. 

Does this appear to be a bug?  I don''t have a patch, but I''ll
post one if I
get one (or I''ll recant my "bug" :) ).
_______________________________________________
LARTC mailing list / LARTC@mailman.ds9a.nl
http://mailman.ds9a.nl/mailman/listinfo/lartc HOWTO: http://lartc.org/