Ffdon - keine IPv4 für Client in VirtualBox

Hallo,
ich betreibe hier an einem Laptop unter Windows 7 VirtualBox.
Den Guest-Betriebssystemen stelle ich eine Bridge zum WLAN-Device zur Verfügung.

In meinem LAN gibt es ohne Probleme IPv4 und IPv6-Adressen.

Jedoch im Freifunk-Netz bekomme ich von dem Node die IPv6-Konfiguration. Allerings laufen zum DHCP-Server nur Timeouts auf.
Das Phänomen tritt unter allen getesteten Guest-Systemen auf:

  • Win7
  • Linux, Elementary OS
  • Linux, Debian
  • FreeBSD /PCOS

Ich denke, dass hier eine TTL zu niedrig ist.

Ich habe noch keine Pakete gesnifft, und auch noch nicht ins syslog des DHCP geschaut.

Konntet Ihr schon so etwas beobachten?
Habt Ihr hierzu etwas korrigiert?

Auszug aus dem syslog:

Oct 20 22:21:01 gw02 dhcpd: DHCPDISCOVER from nn:nn:nn:nn:nn:nn (Win7-Client) via bat03
Oct 20 22:21:02 gw02 dhcpd: DHCPOFFER on 10.86.16.226 to nn:nn:nn:nn:nn:nn (Win7-Client) via bat03
Oct 20 22:21:04 gw02 dhcpd: DHCPDISCOVER from nn:nn:nn:nn:nn:nn (Win7-Client) via bat03
Oct 20 22:21:04 gw02 dhcpd: DHCPOFFER on 10.86.16.226 to nn:nn:nn:nn:nn:nn (Win7-Client) via bat03
Oct 20 22:21:12 gw02 dhcpd: DHCPDISCOVER from nn:nn:nn:nn:nn:nn (Win7-Client) via bat03
Oct 20 22:21:12 gw02 dhcpd: DHCPOFFER on 10.86.16.226 to nn:nn:nn:nn:nn:nn (Win7-Client) via bat03

hier noch unser repo:

Leider finde ich auf die Schnelle mit den Suchbegriffen “TTL” und “DHCP” nur Angaben zur Gültigkeit der Leases und nicht der Pakete.

http://de.linwiki.org/wiki/DHCP

hier steht für den Counter / TTL:
8 Bit Hops

Auszug aus: https://www.daemon-systems.org/man/dhcp-options.5.html
bin ich hier richtig?

   option default-ip-ttl uint8;

     This option specifies the default time-to-live that the client should
     use on outgoing datagrams.

   option default-tcp-ttl uint8;

     This option specifies the default TTL that the client should use when
     sending TCP segments.  The minimum value is 1.

Kann das an der ttl liegen?

tracert vom Host-System:

>tracert 10.86.16.2

Routenverfolgung zu 10.86.16.2 über maximal 30 Abschnitte

  1    32 ms    29 ms    26 ms  10.86.16.2

Ablaufverfolgung beendet.

und tracert vom Guest-System:

>tracert 10.86.16.2

Routenverfolgung zu 10.86.16.2 über maximal 30 Abschnitte

  1    25 ms    26 ms    65 ms  10.86.16.2

Ablaufverfolgung beendet.

Mit der TTL bist du IMHO auf dem Holzweg.
Bei VirtualBox Bridge Networking ist der Hop Count vom Guest == Host.
Ausserdem wäre TTL eh Long Shot aka geraten.

Wenns auf dem Host geht und dem Guest nicht liegt es IMHO an der Virtualisierungsmimik und nicht am externen Netz.
Was verwendetst du für eine MAC für das Guest Interface?

Im VirtualBox-Guest-System ist die IP angeblich gewürfelt: 08-00-27-nn-nn-nn - es läuft derzeit nur eine Maschine
ImHost-System ist es die native Intel A4-34-D9-nn-nn-nn .

Ich schrieb aber bereits, dass im heimischen W-LAN IPv4-Adressen per DHCP vom selben Guest-System bezogen werden.

Vom Guest aus im Freifunk gibt ein

nmap -sU -p 67 --script=dhcp-discover
https://nmap.org/nsedoc/scripts/dhcp-discover.html

Starting Nmap 7.01 ( https://nmap.org ) at 2016-10-21 01:33 Mitteleuropäische Sommerzeit
Nmap scan report for 10.86.16.2
Host is up (0.00s latency).
PORT   STATE SERVICE
67/udp open  dhcps
| dhcp-discover: 
|   DHCP Message Type: DHCPACK
|   Server Identifier: 10.86.16.2
|   Subnet Mask: 255.255.252.0
|   Router: 10.86.16.2
|   Domain Name Server: 10.86.16.2
|_  Interface MTU: 1280
MAC Address: 56:53:F2:27:C6:6E (Unknown)
Nmap done: 1 IP address (1 host up) scanned in 1.41 seconds

im heimischen W-LAN

Starting Nmap 7.01 ( https://nmap.org ) at 2016-10-21 01:47 Mitteleuropäische Sommerzeit
Nmap scan report for pfSense163.localdomain (172.27.163.0)
Host is up (0.00s latency).
PORT   STATE SERVICE
67/udp open  dhcps
| dhcp-discover: 
|   DHCP Message Type: DHCPACK
|   Server Identifier: 172.27.163.0
|   Subnet Mask: 255.255.0.0
|   Router: 172.27.163.0
|   Domain Name Server: 172.27.163.0
|_  Domain Name: localdomain
MAC Address: 00:0D:B9:40:EA:6E (PC Engines GmbH)
Nmap done: 1 IP address (1 host up) scanned in 1.36 seconds

Nach erneutem “Würfeln” ist eine neue MAC gesetzt, welche auch im syslog auf dem GW auftaucht und wie oben beschrieben mit einem DHCPOFFER beantwortet wird.

Im Freifunk ergab ein windump während einem ipconfig /renew LAN-Verbindung:

C:\service>WinDump.exe -e -n -i 1 port 67 or port 68
WinDump.exe: listening on \Device\NPF_{C0AC20ED-07CD-420E-9EBE-0B7C4C7B1086} 
02:17:56.367499 08:00:27:eb:59:c2 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 343: 0.0.0.0.68 > 255.255.255.255 .67: BOOTP/DHCP, Request from 08:00:27:eb:59:c2, length 301
02:17:59.364070 08:00:27:eb:59:c2 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 343: 0.0.0.0.68 > 255.255.255.255 .67: BOOTP/DHCP, Request from 08:00:27:eb:59:c2, length 301
02:18:07.360514 08:00:27:eb:59:c2 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 343: 0.0.0.0.68 > 255.255.255.255 .67: BOOTP/DHCP, Request from 08:00:27:eb:59:c2, length 301
02:18:22.360122 08:00:27:eb:59:c2 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 343: 0.0.0.0.68 > 255.255.255.255 .67: BOOTP/DHCP, Request from 08:00:27:eb:59:c2, length 301
02:18:55.357106 08:00:27:eb:59:c2 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 343: 0.0.0.0.68 > 255.255.255.255 .67: BOOTP/DHCP, Request from 08:00:27:eb:59:c2, length 301
02:18:59.355435 08:00:27:eb:59:c2 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 343: 0.0.0.0.68 > 255.255.255.255 .67: BOOTP/DHCP, Request from 08:00:27:eb:59:c2, length 301
02:19:07.356843 08:00:27:eb:59:c2 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 343: 0.0.0.0.68 > 255.255.255.255 .67: BOOTP/DHCP, Request from 08:00:27:eb:59:c2, length 301
02:19:23.355575 08:00:27:eb:59:c2 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 343: 0.0.0.0.68 > 255.255.255.255 .67: BOOTP/DHCP, Request from 08:00:27:eb:59:c2, length 301

8 packets captured
1099 packets received by filter
0 packets dropped by kernel

Zur Info bezüglich der Netzmaske
255.255.252.0 = 22
Unser Netzsegment der Domäne 03 lautet 10.86.16.0/22 --> von .16.0-.19.255
Die DHCP-Range des (ersten) GW02 10.86.16.25-10.86.17.254

Guck mal im Log des Servers, ob für die virtuelle Mac Anfragen kommen und ob die bearbeitet werden. DHCP ist ein Vier-Wege-Hanschlag.

Und dann musst du mal schauen, wo die Pakete hängen bleiben.

syslog:

Ja, TCPdumps kommen als nächstes.

Da sind nur Dicsovers und Offers. Keine Requests und keine ACKs zu sehen.

ich bin dran …

Hallo beisammen,

mein Setup wird so nicht mit VirtualBox funktionieren.

Zum einen gibt es in VirtualBox unter NAT kein IPv6 - hier für ist ein Adapter im Bridged-Modus zu verwenden.

Im Bridged-Modus funktioniert vor allem in Verbindung mit WLAN die DHCP-Aushandlung nicht zuverlässig.
https://forums.virtualbox.org/viewtopic.php?f=1&t=50335

Im Allgemeinen wird empfohlen hier zwei separate Adapter zu verwenden.

Über den neuen Adapter-Typ NAT-Services, bzw. NAT-Netzwerk habe ich noch zu wenig gelesen.

Das Thema stellt nur insofern ein Freifunk-Problem dar, dass die ein oder andere Ansible-Maschine in einer VirtualBox läuft.

PS: ulkig war bei meinen Win7 Guest + Win7 Host zu beobachten, dass sobald der Host seinen Adapter mit WinPCap und Wireshark im promiscous-Mode hatte, dieser alle DHCP-DISCOVER-Broadcasts zeitnah dupliziert und mit seiner MAC versandt hat. Daraufhin kam vom Server nur ein DHCP-OFFER-Broadcast vom Server zurück.

Grüße, Martin

VirtualBox ist auch nicht für sowas gedacht. Die konzentrieren sich auf eine gute Bedienbarkeit.

Probier doch mal KVM.

Auf Desktop, oder der Serverhardware macht das wohl Sinn.
Aber auf einem Laptop

  • Powermanagement
  • spezielle Hardware
    sind nur Zwei Punkte…

VMWare Workstation?

1 Like

Wir haben auch schon mal mit VirtualBox auf einem Gateway experimentiert. Das war Performance technisch halt auch ein Totalausfall. Daher würde ich da an deiner Stelle nicht zu viel Zeit investieren.

Hast du den Promiscen-Modus für die virtuelle und oder echte Netzwerkkarte aktiviert? Wenn du bridget, ist das nötig, sonst kann die virtuelle Karte keine Pakete empfangen, weil die physikalische nur die Pakete für ihre eigene Mac-Adresse annimmt.

Ich hatte mal bei mir unter VirtualBox probiert ein Gluon virtuell aufzusetzen und dann ein internes Netzwerk zu einer VM zu schalten, die dann im Freifunknetz hängen sollte. So zu Testzwecken. Das hatte ich auch nicht hinbekommen, mit KVM lief es auf Anhieb.