On Thursday 23 November 2006 19:41, Fermín Galán Márquez wrote:
> Hello,
>
> I would like to report a strange behaviour when a virtual bridge is used to
> interconnect a external VLAN trunk to UML virtual machines, hopping some
> UML user or developer could bring some light into these shadows... :)
> Doing some experiments, I've discovered the problem seems due to tagged
> frames are 1518 bytes long, instead of the 1514 bytes of the conventional
> Ethernet frames, that is, 4 bytes more (this bytes are actually the VLAN
> tag). The solution is to increase the MTU in eth1 in virtual machines by 4,
> that is executing the following in vm0 and vm1 (before the vconfig commands
> shown before):
>
> ifconfig eth1 mtu 1504
>
> I think is a very amazing behaviour, and I don't know exactly what is the
> cause. However, I suspect an issue in the UML networking processing. It
> seems that it isn't "VLAN aware", so when it receives the frame (1518 byte)
> in eth1 it makes a calculation based on the total length of the frame less
> the header length (14 bytes), resulting is 1504 and, therefore bigger than
> 1500 bytes, so the frame is discarted. The right behaviour ("VLAN aware")
> should be to consider the header length *and* the VLAN tag length in the
> case it appears in the frame (some deconding function is needed to realice
> the frame has a VLAN tag).
>
> Anybody has observed a similar behaviour or can reproduce it? Any idea of
> what is the actual cause (I mean, if my hypothesis is right or wrong)? I've
> recently read in the list
> (http://sourceforge.net/mailarchive/forum.php?thread_id=31046766&forum_id=3
>6 47) that "The UML ethernet driver doesn't have VLAN support" and maybe
> what I observed is related...
Yes. arch/um/include/net_user.h has:
#define ETH_HEADER_OTHER (14)
#define ETH_MAX_PACKET (1500)
Most UML drivers do:
#define MAX_PACKET (ETH_MAX_PACKET + ETH_HEADER_OTHER)
In comparison, a card which surely supports VLAN frames (an Intel gigabit
card) has:
./drivers/net/e1000/e1000_hw.h
/* The sizes (in bytes) of a ethernet packet */
#define ENET_HEADER_SIZE 14
#define MAXIMUM_ETHERNET_FRAME_SIZE 1518 /* With FCS */
#define MINIMUM_ETHERNET_FRAME_SIZE 64 /* With FCS */
#define ETHERNET_FCS_SIZE 4
I've also discovered vlan_tx_tag_present to test whether a given sk_buff is a
VLAN packet - I doubt it can be useful until when we receive a packet, but
could be useful on sending.
However, this does not suffice to show what happens. Instead, this code in
tuntap_read (arch/um/os-Linux/drivers/tuntap_kern.c) does (if you are using
TUNTAP, as you seem to be doing):
static int tuntap_read(int fd, struct sk_buff **skb,
struct uml_net_private *lp)
{
*skb = ether_adjust_skb(*skb, ETH_HEADER_OTHER);
if(*skb == NULL) return(-ENOMEM);
return(net_read(fd, (*skb)->mac.raw,
(*skb)->dev->mtu + ETH_HEADER_OTHER));
}
The last line is a read for MTU + 14 bytes, and is surely buggy for a VLAN
setup. If you are a C programmer and can add + 4 to that size (obtaining
<....> + ETH_HEADER_OTHER + 4), can you test whether with this change the
described problem disappears?
Also, since I do not think we can properly handle the question, can you open a
bug in bugzilla.kernel.org about this? I'd like network kernel hackers to
take care of this; however, I think that the result of the above 'patch' will
be useful.
Inspection of other UML drivers (what I typed above only matters for TUN/TAP)
would also be needed; your help in testing at least the main ones will be
probably appreciated.
However, I probably can't follow actively this bug (especially do testing
myself), since I'm short on free time. I hope Jeff can help you on this.
Bye!
--
Inform me of my mistakes, so I can add them to my list!
Paolo Giarrusso, aka Blaisorblade
http://www.user-mode-linux.org/~blaisorblade
Chiacchiera con i tuoi amici in tempo reale!
http://it.yahoo.com/mail_it/foot/*http://it.messenger.yahoo.com
-------------------------------------------------------------------------
Take Surveys. Earn Cash. Influence the Future of IT
Join SourceForge.net's Techsay panel and you'll get the chance to share your
opinions on IT & business topics through brief surveys - and earn cash
http://www.techsay.com/default.php?page=join.php&p=sourceforge&CID=DEVDEV
_______________________________________________
User-mode-linux-user mailing list
User-mode-linux-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/user-mode-linux-user
