Proxmox VM & Ethernet frames

[nosuch]

Hi,

I'm trying to use EtherDFS with a ProxMox VM running Debian and so far have had no luck. EtherDFS communicates directly to the MAC of the VM using ethernet frames and does not use IP level communication (sorry for my rough network terminology). Is this possible using ProxMox with a bridged network adapter? More information on EtherDFS can be found here: https://github.com/BrianHoldsworth/etherdfs-client

Description of EtherDFS Protocol​

The ethernet communication between the client and the server is very simple: for every INT 2F query, the client (EtherDFS) sends a single ethernet frame to the server (ethersrv), using the following format:

DOEEpppVSDLxxx

where:

offs|field| description
----+-----+-------------------------------------------------------------------
0 | D | destination MAC address
6 | O | origin (source) MAC address
12 | EE | EtherType value (0xEDF5)
14 | ppp | padding: 38 bytes of garbage space. used to make sure every frame
| | respects the minimum ethernet payload length of 46 bytes. could
| | also be used in the future to fill in fake IP/UDP headers for
| | router traversal and such.
52 | ss | size, in bytes, of the entire frame (optional, can be zero)
54 | cc | 16-bit BSD checksum, covers payload that follows (if CKS flag set)
56 | V | the etherdfs protocol version (7 bits) and CKS flag (highest bit)
57 | S | a single byte with a "sequence" value. Each query is supposed to
| | use a different sequence, to avoid the client getting confused if
| | it receives an answer relating to a different query than it
| | expects.
58 | D | a single byte representing the numeric value of the destination
| | (server-side) drive (A=0, B=1, C=2, etc) in its 5 lowest bits,
| | and flags in its highest 3 bits (flags are undefined yet).
59 | L | the AL value of the original INT 2F query, used by the server to
| | identify the exact "subfunction" that is being called.
60 | xxx | a variable-length payload of the request, it highly depends on the
| | type subfunction being called.
For each request sent, the client expects to receive exactly one answer. The client might (and is encouraged to) repeat the query if no valid answer comes back within a reasonable period of time (several milliseconds at least).

 

[Stoiko Ivanov]

Sadly I have no experience with etherDFS at all - so not sure if this can work - but then again - on a rough view PVE uses tap-devices on a bridge - so most things work on layer 2 /ethernet

* make sure you don't have any firewall rules defined - as I'd assume that most sane rulesets would discard ethernet-frames without a well-known ethertype

afterwards I'd suggest to use `tcpdump` (see `man tcpdump` for documentation, there's also tons of howtos on the internet) - e.g. `tcpdump -envi <iface>` on multiple points (the tap-device, the vmbr, the outbound NIC port, inside the VM....) - to see if the packets leave the VM at all and where they get lost

I hope this helps!

 

[nosuch]

This does help, ty! I've tried running tcpdump on the host OS as well as the VM and neither have seen incoming frames when I believe they are generated. I don't know the difference between TAP device and the others you mentioned, I'm just doing tcpdump on the ethXX devices that I see with a connection. Maybe the Ubiquiti dream machine is filtering it? This is a good start, thanks!

 

[Stoiko Ivanov]

don't know the difference between TAP device and the others you mentioned

basically it's just different devices where the packets go through:
vm-nic -> tap<vmid>i<interfacenumber> (on PVE)-> vmbrX -> physical nic to the network -> switch
(vmbr is a bridge, which acts like a virtual switch, the tap device is just 'plugged into' this bridge)

I hope this explains it!
good luck!