All of lore.kernel.org
 help / color / mirror / Atom feed
From: Ben Greear <greearb@candelatech.com>
To: Rask Ingemann Lambertsen <rask@sygehus.dk>
Cc: netdev@oss.sgi.com, "David S. Miller" <davem@redhat.com>
Subject: Re: [PATCH]  e100: Enable receiving bogus packets, and transmitting bad/custom CRC
Date: Sat, 13 Dec 2003 11:12:49 -0800	[thread overview]
Message-ID: <3FDB64B1.5050700@candelatech.com> (raw)
In-Reply-To: <20031213200044.B1791@sygehus.dk>

Rask Ingemann Lambertsen wrote:
> On Mon, Nov 24, 2003 at 03:24:11PM -0800, Ben Greear wrote:
> 
>>Thanks to those who pointed me in the right direction, here is a patch
>>to the e100 (2.4.23-pre9) that allows it to capture all frames, bogons included.
>>It also coppies the FCS to the skb so ethereal et al can read it.
>>
>>It utilizes ethtool commands to get/set the rx-all feature, and uses
>>a new flag in the skbuff (and socket struct) structure to determine when to disable generating
>>the FCS on transmit.  I have the entire patch that adds the management
>>bits and flags, but as usual, it's mixed in with various other things...
> 
> 
> Reading the tulip manual (see below) triggered a question: When transmitting
> a custom CRC, who is responsible for padding the frame to the minimum length?
> If frame padding is left to the driver, what should be used for padding?

Hrm, I have not tested this, as my sending app itself enforces the minimum
size.  I am guessing that padding is up to the driver/OS in this case,
but I'd have to re-read the e100 docs to be sure...

> I (or rather, Google) found the tulip documentation at
> <URL:http://www.intel.com/design/network/manuals/278074.htm>. The tulip
> chips are capable of all these tricks too.

Cool, I'll check out this doc soon.  If you happen to write up a tulip driver
patch for this feature, please let me know.  I have lots of 4-port tulip nics to
test on here...

DaveM:  Are you interested in getting these patches into 2.4.24-preX?  (It would
be helpful to get the infrastructure and ethtool portions in, even if the driver
parts remain outside the tree for a bit longer.)


Thanks,
Ben

> 


-- 
Ben Greear <greearb@candelatech.com>
Candela Technologies Inc  http://www.candelatech.com

      reply	other threads:[~2003-12-13 19:12 UTC|newest]

Thread overview: 10+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2003-11-24 23:24 [PATCH] e100: Enable receiving bogus packets, and transmitting bad/custom CRC Ben Greear
2003-11-24 23:29 ` David S. Miller
2003-11-24 23:48   ` Ben Greear
2003-11-25  1:33     ` David S. Miller
2003-11-25  7:53       ` [PATCH 0/3] e100: Enable receiving bogus packets and saving FCS Ben Greear
2003-11-25 14:42       ` [PATCH] e100: Enable receiving bogus packets, and transmitting bad/custom CRC Rask Ingemann Lambertsen
2003-11-25 14:45         ` David S. Miller
2003-11-25 14:56     ` Rask Ingemann Lambertsen
2003-12-13 19:00 ` Rask Ingemann Lambertsen
2003-12-13 19:12   ` Ben Greear [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=3FDB64B1.5050700@candelatech.com \
    --to=greearb@candelatech.com \
    --cc=davem@redhat.com \
    --cc=netdev@oss.sgi.com \
    --cc=rask@sygehus.dk \
    /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 an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.