dummy ethernet driver

dummy ethernet driver

[Dave Airlie]

[-- Attachment #1: Type: TEXT/PLAIN, Size: 1036 bytes --]


Hi,
 I have a VAX simulator running on my PC which uses pcap to send/recv
packets, however these packets are never seen on the local machine when
using a real ethernet device (everyone else on the network sees them), now
I only really want the local machine to see them not the network so I
decided I might get away with using loopback, however the simulator
configures its own IP and loopback isn't useful for this as the sim starts
arping and we don't do any arp on loopback.

so I turned to the dummy device but it isn't really a dummy Ethernet
device but rather a useless one :-), so I patched the dummy so it had an
address (hardcoded) is broadcast and loops back packets to itself...

the patch is attached.. is there any reason why the dummy device doesn't
want to do this stuff? I'm just submitting the patch as a request for
comments on why this isn't done anyway in the dummy?

Dave.

-- 
David Airlie, Software Engineer
http://www.skynet.ie/~airlied / airlied@skynet.ie
pam_smb / Linux DecStation / Linux VAX / ILUG person


[-- Attachment #2: Type: TEXT/PLAIN, Size: 1772 bytes --]

--- /usr/src/linux/drivers/net/dummy.c	2001-10-01 05:26:06.000000000 +1000
+++ ./dummy.c	2003-01-06 17:06:44.000000000 +1100
@@ -35,6 +35,7 @@
 #include <linux/kernel.h>
 #include <linux/netdevice.h>
 #include <linux/init.h>
+#include <linux/etherdevice.h>
 
 static int dummy_xmit(struct sk_buff *skb, struct net_device *dev);
 static struct net_device_stats *dummy_get_stats(struct net_device *dev);
@@ -53,6 +54,7 @@
 
 static int __init dummy_init(struct net_device *dev)
 {
+	unsigned char myaddr[]="123456";
 	/* Initialize the device structure. */
 
 	dev->priv = kmalloc(sizeof(struct net_device_stats), GFP_KERNEL);
@@ -60,6 +62,7 @@
 		return -ENOMEM;
 	memset(dev->priv, 0, sizeof(struct net_device_stats));
 
+	memcpy(dev->dev_addr, myaddr, 6);
 	dev->get_stats = dummy_get_stats;
 	dev->hard_start_xmit = dummy_xmit;
 	dev->set_multicast_list = set_multicast_list;
@@ -70,7 +73,8 @@
 	/* Fill in device structure with ethernet-generic values. */
 	ether_setup(dev);
 	dev->tx_queue_len = 0;
-	dev->flags |= IFF_NOARP;
+/*	dev->flags |= IFF_NOARP; */
+	dev->flags |= IFF_BROADCAST;
 	dev->flags &= ~IFF_MULTICAST;
 
 	return 0;
@@ -82,8 +86,28 @@
 
 	stats->tx_packets++;
 	stats->tx_bytes+=skb->len;
+	
+	if(atomic_read(&skb->users) != 1)
+	  {
+	    struct sk_buff *skb2=skb;
+	    skb=skb_clone(skb, GFP_ATOMIC);         /* Clone the buffer */
+	    if(skb==NULL) {
+	      dev_kfree_skb(skb2);
+	      return 0;
+	    }
+	    dev_kfree_skb(skb2);
+	  }
+        else
+	  skb_orphan(skb);
+
+	skb->protocol=eth_type_trans(skb,dev);
+        skb->dev=dev;
+
+        skb->ip_summed = CHECKSUM_UNNECESSARY;
+	dev->last_rx = jiffies;
+
+	netif_rx(skb);
 
-	dev_kfree_skb(skb);
 	return 0;
 }
 

Re: dummy ethernet driver

[Nick Holloway]

airlied@linux.ie (Dave Airlie) writes:
> device but rather a useless one :-), so I patched the dummy so it had an
> address (hardcoded) is broadcast and loops back packets to itself...
> 
> the patch is attached.. is there any reason why the dummy device doesn't
> want to do this stuff? I'm just submitting the patch as a request for
> comments on why this isn't done anyway in the dummy?

[Some background on the dummy driver -- I don't know if there is another
way to configure devices for your purpose, or if your patch is the only
way, I'll leave that for others to answer]

With the way the dummy driver was used, it wasn't necessary to handle
packets.

I wanted my dial-up static IP address to be valid even when the ppp device
was not connected, so I wrote the dummy interface.  If the destination
IP of a packet matches the IP of a local interface, then the packet is
routed over the loopback interface.

So, for this use the dummy interface doesn't need to handle packets, it
just needs to hold an IP address.  In the case that someone configures
the routing tables so that packets are sent via the dummy device, it
just black-holes the packets.

-- 
 `O O'  | Nick.Holloway@pyrites.org.uk
// ^ \\ | http://www.pyrites.org.uk/

Re: dummy ethernet driver

[Alan Cox]

On Mon, 2003-01-06 at 05:57, Dave Airlie wrote:
> the patch is attached.. is there any reason why the dummy device doesn't
> want to do this stuff? I'm just submitting the patch as a request for
> comments on why this isn't done anyway in the dummy

If you want to talk to local systems why don't you use the netlink
interface/ethertap stuff ?

Re: dummy ethernet driver

[Dave Airlie]

> On Mon, 2003-01-06 at 05:57, Dave Airlie wrote:
> > the patch is attached.. is there any reason why the dummy device doesn't
> > want to do this stuff? I'm just submitting the patch as a request for
> > comments on why this isn't done anyway in the dummy
>
> If you want to talk to local systems why don't you use the netlink
> interface/ethertap stuff ?

because I'm unconscionably lazy, and the VAX simulator code is already
written to use pcap and I'd rather not rewrite it, why fix something when
a quick hack will suffice :-)

my long term plan is too ethertap the simulator alright.. but moving along
the Linux/VAX project is primary, fixing simulator isn't :-)

I'm just wondering why dummy just do that bit more.. design decision? or
nobodys ever bothered?

Dave.

-- 
David Airlie, Software Engineer
http://www.skynet.ie/~airlied / airlied@skynet.ie
pam_smb / Linux DecStation / Linux VAX / ILUG person

Re: dummy ethernet driver

[Peter Svensson]

On Mon, 6 Jan 2003, Dave Airlie wrote:

> > If you want to talk to local systems why don't you use the netlink
> > interface/ethertap stuff ?
> 
> because I'm unconscionably lazy, and the VAX simulator code is already
> written to use pcap and I'd rather not rewrite it, why fix something when
> a quick hack will suffice :-)

Just as an aside, the ts10 vax emulator uses the tap driver. Combined with
the kernel bridging code you can create all kinds of network
configurations.

The last time i looked at simh Bob Supnik mentioned that the ethernet 
simulation layer was to be targeted at tap/tun driver among others.

Peter
--
Peter Svensson      ! Pgp key available by finger, fingerprint:
<petersv@psv.nu>    ! 8A E9 20 98 C1 FF 43 E3  07 FD B9 0A 80 72 70 AF
------------------------------------------------------------------------
Remember, Luke, your source will be with you... always...