Ffdon - keine IPv4 für Client in VirtualBox

ffdon-mgk · 20. Oktober 2016 um 20:19

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?

ffdon-mgk · 20. Oktober 2016 um 20:30

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

ffdon-mgk · 20. Oktober 2016 um 20:49

hier noch unser repo:

github.com

ffdon/ansible-ffdon/blob/ffdon/roles/dhcp/templates/dhcpd.conf.j2

# This file is managed by ansible, don't make changes here - they will be overwritten.
default-lease-time {{dhcp_global.lease_default}};
max-lease-time {{dhcp_global.lease_max}};

authoritative;

log-facility local7;

subnet {{ff_network.v4_network | ipaddr('network')}} netmask {{ff_network.v4_network | ipaddr('netmask')}} {
    range {{dhcp.range_start}} {{dhcp.range_end}};

    option routers {{ff_network.v4_network | ipaddr(server_id) | ipaddr('address') }};
    option domain-name-servers {{ff_network.v4_network | ipaddr(server_id) | ipaddr('address') }};
    option interface-mtu {{dhcp_global.mtu}};
}
{% if "static_hosts" in hostvars[inventory_hostname] %}

{% for host in static_hosts %}

host {{host.name}} {

This file has been truncated. show original

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

ffdon-mgk · 20. Oktober 2016 um 20:53

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.

ffdon-mgk · 20. Oktober 2016 um 21:22

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.

kgbvax · 20. Oktober 2016 um 21:23

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?

ffdon-mgk · 20. Oktober 2016 um 23:44

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

MPW · 21. Oktober 2016 um 09:10

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.

ffdon-mgk · 21. Oktober 2016 um 11:47

syslog:

Ja, TCPdumps kommen als nächstes.

MPW · 21. Oktober 2016 um 17:57

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

ffdon-mgk · 21. Oktober 2016 um 17:58

ich bin dran …

ffdon-mgk · 22. Oktober 2016 um 05:38

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

MPW · 22. Oktober 2016 um 08:10

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

Probier doch mal KVM.

ffdon-mgk · 22. Oktober 2016 um 09:38

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

Powermanagement
spezielle Hardware
sind nur Zwei Punkte…

kgbvax · 22. Oktober 2016 um 10:57

VMWare Workstation?

MPW · 22. Oktober 2016 um 12:51

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.