Xen devel - Nov 2004 - VIF Interfaces not transparent to all ethernet protocols?

Hi, 

I''m new to XEN and trying to migrate from UserMode Linux, because its
much
faster!!!

After having some trouble messing around with devfs (I''m using
gentoo...)
the VMs are booting fine.


My current UML Setup looks like this:

Main Machine:
linux-2.4.22-gentoo   (using SKAS patch)
2 ethernet interfaces
eth0 connected to LAN
eth1 connected to DSL-Modem

The UML-VM has 2 virtual Interfaces 
eth0 and eth1
apperaing as tap0 and tap1 on the main machine

the vm is connected to the lan via proxy-arp/routing (uml-stadard),
the tap1 Interface ist bridged to eth1 on the main machine.

The UML-VM is running the rp-pppoe driver on eth1 (tap1)




My XEN 2.0 setup:
what I tried to do is creating 2 bridges (one for each physical interface)
on the host, bridging the first VIF to the LAN and the second to the DSL-Modem.

when I start the rp-pppoe inside the vm, I can see the PPPoE packets appearing
on the eth1 Interface (using tcpdump -nei eth1 inside the vm), but they never 
arrive at the corresponding vif on the main machine (using tcpdump -nei vif1.1).

The other way, sending PPPoE packets, to the vif1.1 from the main machine works.
I can see them inside the VM, but the other direction seems to be blocked.

If I set an IP-address on the eth1 interface inside the vm, I can see IP/ARP 
packets to, but no PPPoE.

After searching the XEN Mailing lists and XEN Changlogs, I found that there has 
been a change in one of 1.x releases making changes to the handling of ethernet 
packets, but I can''t find any similar code in the current release.
This was in ChangeSet@1.497.

Sowhere in the XEN-docs I read that vif Interfaces are transparent, but in this 
case they aren''t.


So my Question is:
I this a bug? Otherwise I cannot find anything in the docs about this.
If this is the right behaviour, where can I change it?
I havent''t found any filtering code neither in the backend nor the
frontend
driver.


Best regards,

Armin Kemper



-------------------------------------------------------
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.
http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xen-devel

> So my Question is:
> I this a bug? Otherwise I cannot find anything in the docs about this.
> If this is the right behaviour, where can I change it?
> I havent''t found any filtering code neither in the backend nor the
frontend
> driver.
This is unexpected behaviour at least. We really do expect the virtual
networking to ''just work''. Maybe there''s an
unfortunate interaction
with the ether bridge... If you find out more please let us know; we''d
like to fix the problem and/or add a solution to the FAQ.

 -- Keir


-------------------------------------------------------
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.
http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xen-devel

Perhaps something''s gone wrong due to your bridging setup.  Have you
adjusted
the Xend network and vif-bridge scripts to do the right thing for your setup?  
If not, Xend will be trying its own bridge setup and possibly confusing thins 
as a result...

If not, you might want to a) try starting Xend without any preconfigured 
bridges to see if that works and then b) adapt the scripts to suit your setup 
properly.

HTH,
Mark

On Monday 08 Nov 2004 20:28, Armin Kemper wrote:
> Hi,
>
> I''m new to XEN and trying to migrate from UserMode Linux, because
its much
> faster!!!
>
> After having some trouble messing around with devfs (I''m using
gentoo...)
> the VMs are booting fine.
>
>
> My current UML Setup looks like this:
>
> Main Machine:
> linux-2.4.22-gentoo   (using SKAS patch)
> 2 ethernet interfaces
> eth0 connected to LAN
> eth1 connected to DSL-Modem
>
> The UML-VM has 2 virtual Interfaces
> eth0 and eth1
> apperaing as tap0 and tap1 on the main machine
>
> the vm is connected to the lan via proxy-arp/routing (uml-stadard),
> the tap1 Interface ist bridged to eth1 on the main machine.
>
> The UML-VM is running the rp-pppoe driver on eth1 (tap1)
>
>
>
>
> My XEN 2.0 setup:
> what I tried to do is creating 2 bridges (one for each physical interface)
> on the host, bridging the first VIF to the LAN and the second to the
> DSL-Modem.
>
> when I start the rp-pppoe inside the vm, I can see the PPPoE packets
> appearing on the eth1 Interface (using tcpdump -nei eth1 inside the vm),
> but they never arrive at the corresponding vif on the main machine (using
> tcpdump -nei vif1.1).
>
> The other way, sending PPPoE packets, to the vif1.1 from the main machine
> works. I can see them inside the VM, but the other direction seems to be
> blocked.
>
> If I set an IP-address on the eth1 interface inside the vm, I can see
> IP/ARP packets to, but no PPPoE.
>
> After searching the XEN Mailing lists and XEN Changlogs, I found that there
> has been a change in one of 1.x releases making changes to the handling of
> ethernet packets, but I can''t find any similar code in the current
release.
> This was in ChangeSet@1.497.
>
> Sowhere in the XEN-docs I read that vif Interfaces are transparent, but in
> this case they aren''t.
>
>
> So my Question is:
> I this a bug? Otherwise I cannot find anything in the docs about this.
> If this is the right behaviour, where can I change it?
> I havent''t found any filtering code neither in the backend nor the
frontend
> driver.
>
>
> Best regards,
>
> Armin Kemper
>
>
>
> -------------------------------------------------------
> 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.
> http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/xen-devel

-------------------------------------------------------
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.
http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xen-devel

> If not, you might want to a) try starting Xend without any preconfigured 
> bridges to see if that works and then b) adapt the scripts to suit your
setup
> properly.
I tried both of that, without any success.

My first attempt was adjusting the xend bridging script to create 2 bridges,
one for each physical interface on the host.

Then I tried the VIF <-> eth (vm) transfer without any bridging setup,
so that the VIF Interface did not have any routes/ips or bridges attached.
Same behaviour.

PPPoE Packets from Domain1 eth1   to Domain0 vif1.1    never arrive,
PPPoE Packets from Domain0 vif1.1 to Domain1 eth1      work fine.

Maybe I''ll give the pppoed instead of rp-pppoe a try.
But the above has been tested with rp-pppoed on both sides.

So I cannot really understand whats going on, as I see it vif-Interfaces and 
the corresponding ethx-Interfaces in the vm should be like an ethernet
"tunnel",
everything send to the ethx inside the vm should appear on the vif interface and
vice versa.


Is there any possibility to trace the network front- or backend drivers?
Some kind of tcpdump in "between"? 

 -- Armin




-------------------------------------------------------
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.
http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xen-devel

I had some really annoying things happen with the tlan driver where a
change in link status (eg cable unplugged then re-plugged in) would
cause the card to drop out of promiscuous mode.

ifconfig eth3 promisc

or
ifconfig eth3 -promisc
ifconfig eth3 promisc

would set things right again.

Nobody on lkml seemed interested in my patch to fix it.

James
> -----Original Message-----
> From: xen-devel-admin@lists.sourceforge.net [mailto:xen-devel-
> admin@lists.sourceforge.net] On Behalf Of Armin Kemper
> Sent: Tuesday, 9 November 2004 07:29
> To: xen-devel@lists.sourceforge.net
> Subject: [Xen-devel] VIF Interfaces not transparent to all ethernet
> protocols?
> 
> Hi,
> 
> I''m new to XEN and trying to migrate from UserMode Linux, because
its
much
> faster!!!
> 
> After having some trouble messing around with devfs (I''m using
gentoo...)
> the VMs are booting fine.
> 
> 
> My current UML Setup looks like this:
> 
> Main Machine:
> linux-2.4.22-gentoo   (using SKAS patch)
> 2 ethernet interfaces
> eth0 connected to LAN
> eth1 connected to DSL-Modem
> 
> The UML-VM has 2 virtual Interfaces
> eth0 and eth1
> apperaing as tap0 and tap1 on the main machine
> 
> the vm is connected to the lan via proxy-arp/routing (uml-stadard),
> the tap1 Interface ist bridged to eth1 on the main machine.
> 
> The UML-VM is running the rp-pppoe driver on eth1 (tap1)
> 
> 
> 
> 
> My XEN 2.0 setup:
> what I tried to do is creating 2 bridges (one for each physical
interface)
> on the host, bridging the first VIF to the LAN and the second to the
DSL-
> Modem.
> 
> when I start the rp-pppoe inside the vm, I can see the PPPoE packets
> appearing
> on the eth1 Interface (using tcpdump -nei eth1 inside the vm), but
they
> never
> arrive at the corresponding vif on the main machine (using tcpdump
-nei
> vif1.1).
> 
> The other way, sending PPPoE packets, to the vif1.1 from the main
machine
> works.
> I can see them inside the VM, but the other direction seems to be
blocked.
> 
> If I set an IP-address on the eth1 interface inside the vm, I can see
> IP/ARP
> packets to, but no PPPoE.
> 
> After searching the XEN Mailing lists and XEN Changlogs, I found that
> there has
> been a change in one of 1.x releases making changes to the handling of
> ethernet
> packets, but I can''t find any similar code in the current release.
> This was in ChangeSet@1.497.
> 
> Sowhere in the XEN-docs I read that vif Interfaces are transparent,
but in
> this
> case they aren''t.
> 
> 
> So my Question is:
> I this a bug? Otherwise I cannot find anything in the docs about this.
> If this is the right behaviour, where can I change it?
> I havent''t found any filtering code neither in the backend nor the
> frontend
> driver.
> 
> 
> Best regards,
> 
> Armin Kemper
> 
> 
> 
> -------------------------------------------------------
> 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.
> http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click
> _______________________________________________
> Xen-devel mailing list
> Xen-devel@lists.sourceforge.net
> https://lists.sourceforge.net/lists/listinfo/xen-devel


-------------------------------------------------------
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.
http://ads.osdn.com/?ad_idU88&alloc_id065&op=click
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xen-devel

> PPPoE Packets from Domain1 eth1   to Domain0 vif1.1    never arrive,
> PPPoE Packets from Domain0 vif1.1 to Domain1 eth1      work fine.
Odd. I''ve never used PPPoE, but I can''t think why it
wouldn''t just work.

In domain 1, what happens if you do ''tcpdump -i eth0''. Do you
see the
packets? I presume you don''t see them if you do ''tcpdump -i
vif1.1'' in
domain 0.

Do you see any drops or errors in the ifconfig stats in either domain?

Ian


-------------------------------------------------------
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.
http://ads.osdn.com/?ad_idU88&alloc_id065&op=click
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xen-devel

> In domain 1, what happens if you do ''tcpdump -i eth0''. Do
you see the
> packets? I presume you don''t see them if you do ''tcpdump
-i vif1.1'' in
> domain 0.
eth0 is the interface I used for connecting to the lan, I can see packets 
passing, if I do that.
If I do ''tcpdump -i eth1'' I can see the PPPoE packets inside
domain 1, too.
If I put an IP address on that interface in domain 1 and ping something on that 
subnet, I see exactly the same output on
tcpdump -i eth1    in domain 1
and
tcpdump -i vif1.1  in domain 0
but not for PPPoE traffic FROM domain 1, the other direction works fine.

> Do you see any drops or errors in the ifconfig stats in either domain?
No, the ifconfig counters for drops or errors aren''t increasing in
either
domain.


Armin




-------------------------------------------------------
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.
http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xen-devel

> eth0 is the interface I used for connecting to the lan, I can 
> see packets passing, if I do that.
> If I do ''tcpdump -i eth1'' I can see the PPPoE packets
inside
> domain 1, too.
> If I put an IP address on that interface in domain 1 and ping 
> something on that subnet, I see exactly the same output on
> tcpdump -i eth1    in domain 1
> and
> tcpdump -i vif1.1  in domain 0
> but not for PPPoE traffic FROM domain 1, the other direction 
> works fine.
This does point toward either the netfront/back dropping the traffic,
but it''s rather unlikely that this would happen without one of the
error/drop counters being bumped. 

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.

Ian 


-------------------------------------------------------
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.
http://ads.osdn.com/?ad_idU88&alloc_id065&op=click
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xen-devel

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 

netbackend.c:
        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);
                  netif_put(netif);
                  continue;
        }

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
to
#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!

Armin



-------------------------------------------------------
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.
http://ads.osdn.com/?ad_id=5588&alloc_id=12065&op=click
_______________________________________________
Xen-devel mailing list
Xen-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/xen-devel