This is an archived copy of the Xen.org mailing list, which we have preserved to ensure that existing links to archives are not broken. The live archive, which contains the latest emails, can be found at http://lists.xen.org/
Home Products Support Community News


[Xen-devel] Re: VIF Interfaces not transparent to all ethernet protocols

To: xen-devel@xxxxxxxxxxxxxxxxxxxxx
Subject: [Xen-devel] Re: VIF Interfaces not transparent to all ethernet protocols?
From: Armin Kemper <Armin.Kemper@xxxxxxx>
Date: Fri, 12 Nov 2004 15:28:28 +0000 (UTC)
Delivery-date: Fri, 12 Nov 2004 17:36:35 +0000
Envelope-to: steven.hand@xxxxxxxxxxxx
List-archive: <http://sourceforge.net/mailarchive/forum.php?forum=xen-devel>
List-help: <mailto:xen-devel-request@lists.sourceforge.net?subject=help>
List-id: List for Xen developers <xen-devel.lists.sourceforge.net>
List-post: <mailto:xen-devel@lists.sourceforge.net>
List-subscribe: <https://lists.sourceforge.net/lists/listinfo/xen-devel>, <mailto:xen-devel-request@lists.sourceforge.net?subject=subscribe>
List-unsubscribe: <https://lists.sourceforge.net/lists/listinfo/xen-devel>, <mailto:xen-devel-request@lists.sourceforge.net?subject=unsubscribe>
References: <A95E2296287EAD4EB592B5DEEFCE0E9D122DC8@xxxxxxxxxxxxxxxxxxxxxxxxxxx>
Sender: xen-devel-admin@xxxxxxxxxxxxxxxxxxxxx
User-agent: Loom/3.14 (http://gmane.org/)
I got it working now!

> Perhaps the easiest way of tracking this down would be to add some
> tracing to the receive interrupt of netback. printk a "*" whenever a
> packet is received and see if it gets that far. If not, add something to
> the start_xmit function in netfront.

I traced the netfrontend / netbackend drivers, the packets were arriving at the
backend, but then were dropped.

So I added many printk s to the driver, to see the way of the packet through the
driver, I added one to every block entered on a condition and watched the output
in domain 0 while sending PPPoE packets to the interface. (My first time
debugging kernel drivers .... ;) )

I saw my packets ending up with an error in the following block in 

        if ( unlikely(txreq.size <= PKT_MIN_LEN) ||
             unlikely(txreq.size > ETH_FRAME_LEN) )
                  DPRINTK("Bad packet size: %d\n", txreq.size);
added by me--->   printk(KERN_ALERT "Bad packet size: %d\n", txreq.size);
                  make_tx_response(netif, txreq.id, NETIF_RSP_ERROR);

So I got messages:
"Bad packet size: 32"

I think I would have seen that, if I had turned debugging on, while compiling
xen...  ;)

# tcpdump -nei vif1.1
tcpdump: WARNING: vif1.1: no IPv4 address assigned
tcpdump: listening on vif1.1
15:48:19.620043 aa:fd:0:0:2:2 ff:ff:ff:ff:ff:ff 8863 32: PPPoE PADI
[Service-Name] [Host-Uniq UTF8]

the packet size is 32 bytes if you take a look at the dump above.

So I changed 
#define PKT_MIN_LEN (ETH_HLEN + 20)
which seems to IP specific

and ... now it is working!

Maybe that should be changed in future releases?
But the strange thing is, that the error / drop counters aren't increased,
which should happen, if I understand the above code correctly.

No problem for me now, but that is rather unexpected behaviour.

THX for your support!


This SF.Net email is sponsored by:
Sybase ASE Linux Express Edition - download now for FREE
LinuxWorld Reader's Choice Award Winner for best database on Linux.
Xen-devel mailing list

<Prev in Thread] Current Thread [Next in Thread>