[prev in list] [next in list] [prev in thread] [next in thread] 

List:       ipfilter
Subject:    More info on ipv6 issues, with ipf 4.1.8/Solaris 9
From:       "Laxman, Amruth \(Com US\)" <amruth.laxman () siemens ! com>
Date:       2006-02-17 2:06:56
Message-ID: 3D80B10873C01D47BEC71C8DE311CF119781FF () USNWK100MSX ! ww017 ! siemens ! net
[Download RAW message or body]

Hello,

After some more investigation, here's what we have found regarding ipv6
on Solaris 9, with ipf v4.1.8/pfil 2.1.7 (similar results are expected
with ipf 4.1.10, since the relevant code is the same in both versions).

Pullup failures:
As pointed out earlier, ipfstat shows pullup failures in both inbound &
outbound directions. By placing some debug prints in ipf, we found that
one reason for the pullup failures is that the value of 'ip_off' passed
into function fr_pullup is '14' for inbound ipv6 packets. This causes
the following check on ip_off to fail in module ip_fil_solaris.c:

1396       if (((ipoff & 3) != 0) || (pullupmsg(m, len + ipoff) ==0)) {

We also found that ipv4 packets never make it in to this function - they
always match the earlier check in module fil.c, function frpr_pullup()
where the amount of data in the current m_block is checked against the
total packet length. In the case of ipv4, this check always passes,
indicating that the whole message is contained within one m_block. 

824        if (M_LEN(fin->fin_m) < plen) {    <-- This is never true for
ipv4

It appears that the m_block data sent up by pfil for ipv6 packets does
not consist of complete messages as it does for ipv4 packets.

As a further step, we enabled pfil debugging (level 11) and got this
message when ipv6 packets are processed:

IP Filter[ce2]: out 0 len 56/56 sap 34525 ip 30007702f10 b_rptr
30007702f10 off 0 m 300228bd400/0/56/0 mt 300296ea580/1/44/300228bd400

In the above output, it appears that the 'm' structure is the right
packet block - this is an icmpv6 packet, with a length of 56 bytes.
However, the 'mt' structure is what is passed to ipf - this only has a
size of 44 bytes. If the 14 byte Ethernet header is subtracted, this
leaves 30 bytes - which is what is printed by ipf, when a printout is
placed in fr_pullup. 

Finally, we attempted to remove the check of ipoff in ip_fil_solaris (it
appears that this should be checking the global ip pointer anyway...),
but the call to 'pullup' still fails. 

Summary:
- Pullups for ipv6 are failing in ip_fil_solaris.c
- This is caused by the check for ip_off, but removing this check
doesn't seem to help
- The real 'pullup' should probably be done by pfil, but this is not
working correctly for some reason. Or perhaps the right block is not
being passed in to ipf.

Not being familiar with Solaris streams programming, we are not sure how
to proceed. 

Darren - could you give us some hints as to how to go further with this?
Any information would be appreciated.

If anyone else has had success with ipf + ipv6 on solaris 9, please let
us know...

-Amruth & Pradeep

[prev in list] [next in list] [prev in thread] [next in thread]