All of lore.kernel.org
 help / color / mirror / Atom feed
From: Bill Leckey <bleckey@tpg.com.au>
To: netdev@oss.sgi.com
Subject: Net device queries.
Date: Wed, 06 Nov 2002 21:11:45 +1100	[thread overview]
Message-ID: <3DC8EAE1.80001@tpg.com.au> (raw)

I've been coding an ethernet driver for some new hardware we're 
developing and while it's working, there are a few issues I'm still 
unsure of.  I couldn't find any archives for this list, so I'm 
suspecting I'm going to cover a lot of 'old ground'.

Firstly some background.  With these cards I can have up to 25 point to 
point connections (to the same destination machine, or 25 destination 
machines).  I have almost total control of what goes out on the wire, so 
I've chosen a minimal header that contains the type (passed in to 
hard_header) and a 16 bit field that contains misc other information. 
So, 32 bits, plus the data.  The hardware provides things like length, 
and CRC checking.

Currently I'm setting dev->hard_header_len to 4.

The part that concerns me is what I set dev->type, dev->addr_len and 
dev->flags to.

We don't technically have a hardware address so I set dev->addr_len to 0.

I set dev->type to ARPHRD_VOID, simply because I'm not sure what the 
consequences of setting it to anything else are.

I set dev->flags to IFF_POINTOPOINT | IFF_NOARP

This appears to all work correctly, however both ifconfig and tcpdump 
aren't really happy.

TCPDUMP doesn't know what to do with the ARPHRD_VOID and drops to 'raw' 
mode, so it still does what I need, even if it prints an annoying 
message for each packet.

ifconfig isn't sure what to do about the HWaddr.  For instance, this is 
the ifconfig for one of the links:


hssl0     Link encap:UNSPEC  HWaddr 
00-00-00-00-00-00-00-00-00-00-00-00-00-00-00-00
           inet addr:192.168.2.1  P-t-P:192.168.2.2  Mask:255.255.255.255
           UP POINTOPOINT RUNNING NOARP  MTU:1500  Metric:1
           RX packets:3509748 errors:459 dropped:0 overruns:0 frame:363
           TX packets:3013210 errors:0 dropped:0 overruns:0 carrier:0
           collisions:0 txqueuelen:100
           RX bytes:368907445 (351.8 Mb)  TX bytes:266074976 (253.7 Mb)

Any thoughts, comments or otherwise on what I've done, or what I 
/should/ be doing would be appreciated as I'm still not fully across how 
the networking stuff works.

Bill

-- 
Bill Leckey - Senior Software Design Engineer
TPG Research and Development
Ph: +61 2 62851711
Fax: +61 2 62853939

             reply	other threads:[~2002-11-06 10:11 UTC|newest]

Thread overview: 3+ messages / expand[flat|nested]  mbox.gz  Atom feed  top
2002-11-06 10:11 Bill Leckey [this message]
  -- strict thread matches above, loose matches on Subject: below --
2002-11-10 15:30 Net device queries Bill Leckey
2002-11-11  3:47 ` Ben Greear

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=3DC8EAE1.80001@tpg.com.au \
    --to=bleckey@tpg.com.au \
    --cc=netdev@oss.sgi.com \
    /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.