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