Linux Netfilter discussions
 help / color / mirror / Atom feed
From: Scott MacKay <scottmackay@yahoo.com>
To: netfilter@vger.kernel.org
Subject: Re: RHEL 4.5 + brigde + sample QUEUE app=panic
Date: Tue, 11 Mar 2008 21:45:34 -0700 (PDT)	[thread overview]
Message-ID: <429463.14929.qm@web52408.mail.re2.yahoo.com> (raw)
In-Reply-To: <671872.8600.qm@web52403.mail.re2.yahoo.com>

More details....

The culprit seems to be the memcpy(), transferring the
payload back into the skb.
memcpy(e->skb->data, v->payload, v->data_len); 

I commented that out, and put a "return 0;"after:
 e->skb->nfcache |= NFC_ALTERED;

(basically skip the memcop and extra routing).  Worked
fine.

I now put in a for loop to run several different
tests.  It basically was:
        for (index=0;index<v->data_len;index++)  {
          /* insert test */
        }
First was:
    c=v->payload[index];  /* read the payload */
No crashes.
Second was:
    c=e->skb->data[index]; /* read the skb payload */
No crashes.
Next was:
    c=e->skb->data[index];  /* read sky payload */
    e->skb->data[index]=c;  /* write value back */
No crashes.
Now
    c=v->payload[index];
    e->skb->data[index]=c;
No crashes.
Finally:
    e->skb->data[index]=v->payload[index];
Crashes.

My test was with wget-ting a kernel and I would
actually see read errors appear before it finally
died.

I wil be retesting the final couple, but any idea why
in the world the memcpy and memcpy-ish loop would
crash everything?

-Scott


--- Scott MacKay <scottmackay@yahoo.com> wrote:

> Related to this:
> I got and rebuilt the ip_queue.c code and it seems
> to
> be within the ipq_mangle_ipv4 code.  The top part
> does
> not affect us since that is only for when size
> changes.  I commented out the mangle call (so I was
> still passing data down) and the system seemed to
> run
> ok, just like data_len=0.
> 
> When I reenabled the memcpy and the ALTER flag
> change
> it worked for a while but then locked up, the
> keyboard
> lights flashing.
> 
> Note that this did not always/immediately cause a
> crash but pretty close.  The last thing I could try
> is
> a simple for loop on the incoming data to see if
> accessing the data (like char c=payload[i] kind of
> throwaway) is the issue.  If there are any thoughts
> on
> the stuff sendmsg() sends to the ip_queue I would
> love
> to know.  
> 
> -Scott



      ____________________________________________________________________________________
Looking for last minute shopping deals?  
Find them fast with Yahoo! Search.  http://tools.search.yahoo.com/newsearch/category.php?category=shopping

      reply	other threads:[~2008-03-12  4:45 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2008-03-11 14:52 RHEL 4.5 + brigde + sample QUEUE app=panic Scott MacKay
2008-03-11 19:18 ` Scott MacKay
2008-03-12  4:45   ` Scott MacKay [this message]

Reply instructions:

You may reply publicly to this message via plain-text email
using any one of the following methods:

* Save the following mbox file, import it into your mail client,
  and reply-to-all from there: mbox

  Avoid top-posting and favor interleaved quoting:
  https://en.wikipedia.org/wiki/Posting_style#Interleaved_style

* Reply using the --to, --cc, and --in-reply-to
  switches of git-send-email(1):

  git send-email \
    --in-reply-to=429463.14929.qm@web52408.mail.re2.yahoo.com \
    --to=scottmackay@yahoo.com \
    --cc=netfilter@vger.kernel.org \
    /path/to/YOUR_REPLY

  https://kernel.org/pub/software/scm/git/docs/git-send-email.html

* If your mail client supports setting the In-Reply-To header
  via mailto: links, try the mailto: link
Be sure your reply has a Subject: header at the top and a blank line before the message body.
This is a public inbox, see mirroring instructions
for how to clone and mirror all data and code used for this inbox