new networking features

new networking features

[Ben Greear]

I have a little collection of networking features that may be of
interest.  My patches are against 2.4.20...  If anyone thinks any of
these are of interest, I will break them out and send them to the list
for review/inclusion...

1)  send-to-self:  Add an IOCTL that allows an interface to be configured
     so that it will answer arps from other interfaces on the same machine.
     Also tweaks ip-v4 a bit.
     Allows:  can send traffic from one interface to another interface on same machine
      over an external network.  Tested with ipv4, may automatically work with ipv6
      too.

2)  802.1Q VLAN:  Add an ioctl that can be used to verify that a device is indeed
     an 802.1Q VLAN device (no more relying on name or luck).

3)  MAC-VLANs:  (Upgraded patch that someone else sent me.)  Allows one to specify
     VLAN-like devices based on source or destination MAC addresses (no extra padding
     in the ethernet frame.)
     This requires a hook in the skb-rx logic, near where the bridging logic has it's
     hook.

4)  Pktgen updates:  Allows receiving (and accounting) packets & threading changes.  Also requires
     a hook in the skb-rx logic.  (Dave already said he didn't like it before, and I
     assume he still doesn't, but including it here for completeness).


Thanks,
Ben

-- 
Ben Greear <greearb@candelatech.com>       <Ben_Greear AT excite.com>
President of Candela Technologies Inc      http://www.candelatech.com
ScryMUD:  http://scry.wanfear.com     http://scry.wanfear.com/~greear

Re: new networking features

[David S. Miller]

Independant of whether I'm interested in the changes, please use
ethtool in deference to ioctls.  If you absolutely must use
ioctls, I can't accept the changes without updates to the
compatability layer ioctl translation code of every platform.

Re: new networking features

[Ben Greear]

David S. Miller wrote:
> Independant of whether I'm interested in the changes, please use
> ethtool in deference to ioctls.  If you absolutely must use
> ioctls, I can't accept the changes without updates to the
> compatability layer ioctl translation code of every platform.
> 

Ok, so the general plan would be to add new structs as needed to ethtool.h
and then extend of the the ethtool enums?

Will ethtool ioctls work for generic/virtual interfaces/drivers?  I
need some way to get hooks into specific (ie dev.c, vlan, macvlan) code,
but I'm not too particular about how it gets there as long as it
isn't netlink :)

Also, for the VLAN code, it's not really adding a new ioctl, but adding a new
enum value to an existing ioctl payload...

Thanks,
Ben

-- 
Ben Greear <greearb@candelatech.com>       <Ben_Greear AT excite.com>
President of Candela Technologies Inc      http://www.candelatech.com
ScryMUD:  http://scry.wanfear.com     http://scry.wanfear.com/~greear

Re: new networking features

[David S. Miller]

   From: Ben Greear <greearb@candelatech.com>
   Date: Thu, 08 May 2003 11:00:29 -0700

   Ok, so the general plan would be to add new structs as needed to ethtool.h
   and then extend of the the ethtool enums?
   
There are no enumerations, ethtool commands are merely macro
defines to numbers.  But, otherwise yes.

   Will ethtool ioctls work for generic/virtual interfaces/drivers?

It's all via the devices netdev->do_ioctl(), what is the
problem?