Share

VDE: Virtual Distributed Ethernet

The forum address has changed, you have been automatically redirected. Please update any bookmarks to use the new URL.

Subscribe

Multi-Platform support

You are viewing a single message from this topic. View all messages.

  1. 2009-06-02 21:52:06 UTC
    Hello,

    for having a virtual network for virtual machines (hobby).
    I wanted to setup a VDE_SWITCH between my server
    (it is a small ARM-based NAS server running fill-blown
    Debian Etch (and Lenny in chroot)) and my working
    station (notebook, 4GB RAM, Core 2 Duo).

    On my ARM machine I encountered my problem. If
    I try to connect with vde_plug, the magic check fails.
    Instrumenting the source shows the problem. On the
    ARM CPU (little endian, too), the access to the reqbuf
    "magic" field fails. On non-x86 machines the 32bit accesses
    have to be 32bit aligned. But the reqbuf is a byte stream,
    and type-casted to the request structure.

    A simple change solved this problem:

    In 'src/vde_switch/datasock.c':

    static void handle_input(unsigned char type,int fd,int revents,int *arg)
    {
    :
    :
    else if (type == wd_type) {
    char ___reqbuf[REQBUFLEN+1+3];
    char * reqbuf;
    union request *req;
    int len;

    reqbuf = (char *) (((unsigned int) ___reqbuf + 3) & ~0x3);
    req=(union request *)reqbuf;

    len = read(fd, reqbuf, REQBUFLEN);
    :
    }

    Here I tried to pad the "reqbuf" to a 32bit aligned position.
    The vde_plug works, packets could be transferred, but no stable network
    operation was possible.

    Further, if I would use a big endian machine, is the use of vde_switch
    possible ? Ok, the vde_plug is always called on the same machine
    as vde_switch, so there should not be any problem.

    But in general, the padding stuff should be investigated. On some machines,
    a TRAP or EXCEPTION is rised, on ARM only the wrong bytes are used:

    Example, seen here:

    Here is the 0xfeedface magic + some bytes before:

    0xTT 0xXX 0xYY 0xZZ 0xce 0xfa 0xed 0xfe
    BYTE POS:
    Result in my case: 0xZZYYXXce

    Why: ARM takes the bytes fix on B0 B1 B2 B3 without rotating or swapping
    any bytes. If the magic starts on offest +3, then bytes at offset 0..2 are taken,
    not of pos +4..+6 !

    Bye
    Chrisly
< Previous | 1 | Next >

Add a Reply

This forum does not allow anonymous participation.

Log in to add a reply. Not registered? Create an account to participate and receive email updates when replies are posted to this topic.