Darren,
I realized that 64 bytes can not allocate all needed dumpings
(It shall be 52+20(ipheader size)=72). Here is 72 bytes long dumpings:
1, When situation is good.
# ping 10.2.2.1
10.2.2.1 is alive
# tail -f /var/adm/messages
Jun 18 10:26:37 unknown pfil: [ID 937897 kern.info] pfil_precheck():
ip:d42e5e3c,off:34,rptr:d42e5e08,dump: 00 00 00 00 00 7F 10 20 33 03 00
00 16 ED 75 46 4C 00 00 00 06 00 00 00 FE CA DD BA FE CA DD BA 45 00 00
00 00 00 40 00 3C 04 00 00 87 FC 3A A1 87 FC 3A AE 45 00 00 54 37 87 40
00 FF 01 2D 1D 0A 01 01 01 0A 02 02 01
......
# ifconfig ip.tun.pfil5
ip.tun.pfil5: flags=10008d1<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST,IPv4>
mtu 1480 index 4
inet tunnel src 135.252.58.161 tunnel dst 135.252.58.174
tunnel security settings ah (hmac-md5) esp
(3des-cbc/<any-none>)
tunnel hop limit 60
inet 10.1.1.1 --> 10.2.2.1 netmask ffffff00
# ping -s 10.2.2.1
PING 10.2.2.1: 56 data bytes
^C
----10.2.2.1 PING Statistics----
2 packets transmitted, 0 packets received, 100% packet loss
# tail -f /var/adm/messages
......
Jun 18 10:29:48 unknown pfil: [ID 937897 kern.info] pfil_precheck():
ip:d49eb4c8,off:0,rptr:d49eb4c8,dump: 00 00 00 00 00 7F 10 20 33 03 00
00 16 ED 75 46 4C 00 00 00 06 00 00 00 FE CA DD BA FE CA DD BA 45 00 00
00 00 00 40 00 3C 04 00 00 87 FC 3A A1 87 FC 3A AE 45 00 00 54 37 88 40
00 FF 01 2D 1C 0A 01 01 01 0A 02 02 01
......
Jun 18 10:29:49 unknown pfil: [ID 937897 kern.info] pfil_precheck():
ip:d49eb4c8,off:0,rptr:d49eb4c8,dump: 00 00 00 00 00 7F 10 20 33 03 00
00 16 ED 75 46 4C 00 00 00 06 00 00 00 FE CA DD BA FE CA DD BA 45 00 00
00 00 00 40 00 3C 04 00 00 87 FC 3A A1 87 FC 3A AE 45 00 00 54 37 89 40
00 FF 01 2D 1B 0A 01 01 01 0A 02 02 01
......
Here we can see that when ipsec tunnel goes wrong, the dumpings
are the same as it is in good situation. Then only change is off changed
from 52(0x34) to 0.
Regards,
Sander
----Original Message-----
From: Zang, Lan (Sander)
Sent: Monday, June 18, 2007 10:13 AM
To: '[EMAIL PROTECTED]'
Cc: [email protected]
Subject: RE: IPsec Tunnel problem seek confirm from author or anyone
knows
Darren,
Thanks for your quick response. Here are some codes in function
pfil_precheck() (File SunOS/pfildrv.c):
qpi->qpi_hl = qif->qf_hl;
......
out = (flags & PFIL_OUT) ? 1 : 0;
off = (out) ? qpi->qpi_hl : 0;
.......
Here off is equal to qpi->qpi_hl if the packets are outgoing.
And in general case, IP header ip=m->b_rptr+off. I add some codes below
to print what these variables are and dump some memory pointed by
m->b_rptr;
char pbuf[64*3+1];
int pi;
for (pi=0;pi<64;pi++)
{
sprintf(pbuf+pi*3,"%02X ",*(((unsigned
char*)m->b_rptr)+pi));
}
PRINT(0, (CE_CONT, "!pfil_precheck():
ip:%lx,off:%lx,rptr:%lx,dump: %s",ip,off,mt->b_rptr, pbuf));
After system rebooted, everything seems OK:
# ping -s 10.2.2.1
10.2.2.1 is alive
# tail -f /var/adm/messages (Note here I only take messages related to
outgoing packets over ip.tun.pfil5. "unknown" is hostname) Jun 18
09:44:52 unknown pfil: [ID 937897 kern.info] pfil_precheck():
ip:d4ebfbbc,off:34,rptr:d4ebfb88,dump: 00 00 00 00 00 CA 10 20 0F 08 00
00 44 E2 75 46 90 00 00 00 06 00 00 00 FE CA DD BA FE CA DD BA 45 00 00
00 00 00 40 00 3C 04 00 00 87 FC 3A A1 87 FC 3A AE 45 00 00 54 6F 05 40
00 FF 01 F5 9E
(Note: the 0x45, which is beginning of IP header started at
m->b_rptr+off(52) )
After check network interface status(ifconfig -a or ifconfig
ip.tun.pfil5), the IPsec tunnel goes wrong.
# ifconfig ip.tun.pfil5
ip.tun.pfil5: flags=10008d1<UP,POINTOPOINT,RUNNING,NOARP,MULTICAST,IPv4>
mtu 1480 index 4
inet tunnel src 135.252.58.161 tunnel dst 135.252.58.174
tunnel security settings ah (hmac-md5) esp
(3des-cbc/<any-none>)
tunnel hop limit 60
inet 10.1.1.1 --> 10.2.2.1 netmask ffffff00 # ping -s 10.2.2.1
PING 10.2.2.1: 56 data bytes ^C
----10.2.2.1 PING Statistics----
4 packets transmitted, 0 packets received, 100% packet loss
Here is the output of syslog then
# tail -f /var/adm/messages
Jun 18 09:52:43 unknown pfil: [ID 937897 kern.info] pfil_precheck():
ip:d4ebddc8,off:0,rptr:d4ebddc8,dump: 00 00 00 00 00 CA 10 20 0F 08 00
00 44 E2 75 46 90 00 00 00 06 00 00 00 FE CA DD BA FE CA DD BA 45 00 00
00 00 00 40 00 3C 04 00 00 87 FC 3A A1 87 FC 3A AE 45 00 00 54 6F 08 40
00 FF 01 F5 9B Jun 18 09:52:44 unknown pfil: [ID 937897 kern.info]
pfil_precheck(): ip:d4ebddc8,off:0,rptr:d4ebddc8,dump: 00 00 00 00 00 CA
10 20 0F 08 00 00 44 E2 75 46 90 00 00 00 06 00 00 00 FE CA DD BA FE CA
DD BA 45 00 00 00 00 00 40 00 3C 04 00 00 87 FC 3A A1 87 FC 3A AE 45 00
00 54 6F 09 40 00 FF 01 F5 9A ......
(Note: the 0x45 is still in the same place as m->b_rptr+52, while off
is set to improper value (0) now, So the outgoing packets are not
interpreted correctly)
My conclusion: 1, it got same result when use "ip.tun.pfil5" as
IPsec tunnel name.
2, This is because qif->qf_hl set to 0 while
handling outgoing ipsec packets. And this must because of 'ifconfig
ip.tun.pfil5'.
After I modify codes in SunOS/qif.c of function qif_attach(),
this problem can be solved:
if (qif->qf_hl == 0 ) { // This line is added by me.
#if SOLARIS2 < 8
qif->qf_hl = ill->ill_hdr_length;
#else
if ((ill->ill_type > 0) && (ill->ill_type < 0x37) &&
(hdrsizes[ill->ill_type][0] == ill->ill_type))
qif->qf_hl = hdrsizes[ill->ill_type][1];
if (qif->qf_hl == 0 && ill->ill_type != IFT_OTHER) {
cmn_err(CE_WARN,
"!Unknown layer 2 header size for %s type %d sap
%x\n",
qif->qf_name, ill->ill_type, ill->ill_sap);
}
#endif
}
So, my concern is that will this solution be alright? Need your
help on that.
Regards, & thanks
Sander
-----Original Message-----
From: Darren Reed [mailto:[EMAIL PROTECTED]
Sent: Friday, June 15, 2007 17:42 PM
To: Zang, Lan (Sander)
Cc: [email protected]
Subject: Re: IPsec Tunnel problem seek confirm from author or anyone
knows
Zang, Lan (Sander) wrote:
> All,
..
>
> When using 'ifconfig -a' or 'ifconfig ip.tun5', qif_attach()
> will be called and qif->qf_hl
> will be set to 0. The problem is when it is an outgoing packet, in
> function pfil_precheck(),
> it shall be 52 to set 'off' appropriately. Otherwise, 'off' is
> also set to zero, which is not
> correct, and causing the packet is not well interpreted. So the
> outgoing packet won't be sent out.
>
What are the 52 bytes that you are skipping over?
Can you send a hex dummp of them?
But really, you should be using "ip.tun.pfil5"
Darren
