Skip site navigation (1)Skip section navigation (2)
Date:      Wed, 21 Feb 2001 09:50:58 Gmt +0200
From:      idobarnea@NewMail.Net
To:        Ruslan Ermilov <ru@FreeBSD.ORG>, mouss <usebsd@free.fr>, hackers@FreeBSD.ORG
Subject:   Re: Bug in creating ICMP error messages in FreeBSD4.2
Message-ID:  <3a938f82.19b.0@NewMail.Net>

next in thread | raw e-mail | index | archive | help
>On Mon, Feb 19, 2001 at 08:26:56PM +0100, mouss wrote:
>> At 14:25 19/02/01 +0200, idobarnea@NewMail.Net wrote:
>> >Hi,
>> >   I encountered the following problem in the 4.2 version.
>> >In ip_forward, the following lines intend to save the mbuf in case we want
to
>> >send ICMP error later:
>> >  mcopy = m_copy(m, 0, imin((int)ip->ip_len, 64));
>> >  if (mcopy && (mcopy->m_flags & M_EXT))
>> >      m_copydata(mcopy, 0, sizeof(struct ip), mtod(mcopy, caddr_t));
>> >
>> >Later on, before sending the ICMP packet we do:
>> >  if (mcopy->m_flags & M_EXT)
>> >      m_copyback(mcopy, 0, sizeof(struct ip), mtod(mcopy, caddr_t));
>> >
>> >The problem as I understand it is that the m_copydata and m_copyback, actually

>> >do nothing (It just
>> >copies from mcopy to itself).
>> 
>> I'm speaking from memory, so don't take this for more than it is:)
>> 
>> As far as I understand:
>> m_copym copies the mbuf, but if there is external storage, only pointers

>> are copied. so you get two mbuf chains with a common external storage.
>> m_copydata will copy the external storage.
>> that's why there are both m_copym and m_copydata. so while
>>    m_copydata(mcopy, .... (mcopy...))
>> is surprising, it's not nothing. it copies the data pointed to in mcopy.

>> 
>I wrote this code, and the above said is right.
>-- 
>Ruslan Ermilov  Oracle Developer/DBA,

I understand that this is what you meant it to be. But look again at m_copydata.
This is the relevant line:
   bcopy(mtod(m, caddr_t) + off, cp, count);
If cp is mtod(m, caddr_t) and off is 0, this command has no effect.

Anyway, even if I am wrong about this, the facts are that if you take FreeBSD
4.2-RELEASE machine,
put net.inet.ip.forwarding to 1,and then blast the kernel with ip packets with
len 256 and with destination
to which it has a direct network route (on its local lan), but it can't resolve
the arp entry the kernel crashes
after a while. You can try this yourself. I can explain some more, and give
exact conf' if anybody wants it.

Now if you stop with a debugger in icmp_error you see that oip->ip_len equals
1, then you see the other
stuff I talked about, and then you get a kernel panic.

After you make the correction I suggested, and do the same thing, you see that
oip->ip_len equals 256 (the
right value), and you never get a kernel panic.

I'll be glad to here other explanations to this kernel crash.

Yours, Ido Barnea



_________________________________________
Get Your Free Virus Protection Tool at http://www.VCatch.com

To Unsubscribe: send mail to majordomo@FreeBSD.org
with "unsubscribe freebsd-hackers" in the body of the message




Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?3a938f82.19b.0>