sit tunnel on Linux 2.6.32 not seeing inbound IPv6 packets

[dkg]

until recently, IPv6 was working from my LAN via a tunnel from HE's
tunnelbroker.net service.

But as of a couple days ago, IPv6 connectivity is no longer
working. In particular, IPv6 packets aren't accepted by the router,
even though valid IPv6 packets are emitted by it.

My tunnel is supposed to be using a sit tunnel to an
HE/tunnelbroker.net endpoint.

From the router itself (running Linux 2.6.32), I can ping the remote
IPv4 endpoint of the tunnel and get a response.

If i ping6 the remote IPv6 endpoint of the tunnel, ping6 sees nothing
in response.

However, using tcpdump on the outbound physical interface, i can see
the appropriate IPv4-encapsulated ICMP6 response packets coming in
immediately ater the IPv4-encapsulated ICMP6 request packets go out.

Using tcpdump on the tunnel interface itself, i can only see the ICMP6
echo request packets.  i don't see ICMP6 echo response packets there.

i've verified that none of my iptables DROP rules are getting
triggered by the response.  Indeed, i've even seen that an ACCEPT
rule's packet counter is getting incremented on the IPv4 address from
the IPv4-encapsulated ICMP6 response packets.

However, looking at ip6tables, only the *outbound* packet counter is
getting incremented during a ping6 -- it's as though the inbound
packet hits the IPv4 stack, but never gets translated (via the
tunnel?) to the IPv6 stack.  I see *no* DROP target rule packet
counters incrementing at all in ip6tables.

Looking at another router on a different LAN with a similar
arrangement, i see ip6tables packet counters increasing for both input
and output from an icmpv6 echo request and response.

So what is the difference?  What should i be looking for?  What have i
overlooked?  How should i debug this?

[broquea]

Have you made certain that your IPv4 endpoint is up to date in the broker?

[dkg]

Have you made certain that your IPv4 endpoint is up to date in the broker?

yes, i have.  As i noted, a packet capture on the raw network interface actually shows the IPv4-encapsulated ICMP6 response packets coming from the other side of the endpoint.  So i'm pretty sure that the problem is not an external configuration problem :(

Any other suggestions of what to check?

[dkg]

It is now fixed!

It appears that the problem was that the IPv4 address of my local endpoint of the tunnel was marked as a secondary address on the local interface, and a different IPv4 address (not associated with the tunnel) was marked as primary.  When i tore it down and set it back up with the tunnel endpoint's IP address as the primary, then the tunnel interface was willing to accept the encapsulated packets from the peer.