[Xen-devel] Re: VIF Interfaces not transparent to all ethernet protocols
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
# 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
#define PKT_MIN_LEN ETH_HLEN
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