search

intel / kernel-fuzzer-for-xen-project

Kernel Fuzzer for Xen Project (KF/x) - Hypervisor-based fuzzing using Xen VM forking, VMI & AFL
MIT License
466 stars 79 forks source link

When installing debian every time I am unable to connect to a network mirror and access wifi from within the vm #49

Closed docfate111 closed 2 years ago

docfate111 commented 3 years ago

I did everything through step 7 but I can't connect to the internet from within the vm at all. I tried adding nameserver 1.1.1.1 as suggestedhttps://github.com/intel/kernel-fuzzer-for-xen-project/issues/31 but still no internet. Please help

docfate111 commented 3 years ago

ifconfig within the vm(whether or not I'm connected to the one wifi option in the menu)

eth0: Link encap:Ethernet
inet addr:10.0.0.2
lo: Link encap:Local loopback
inet addr:127.0.0.1

running these commands locally within dom0

$ ifconfig
docker0: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
        inet 172.17.0.1  netmask 255.255.0.0  broadcast 172.17.255.255
        ether 02:42:d8:1e:e5:68  txqueuelen 0  (Ethernet)
        RX packets 0  bytes 0 (0.0 B)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 0  bytes 0 (0.0 B)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

lo: flags=73<UP,LOOPBACK,RUNNING>  mtu 65536
        inet 127.0.0.1  netmask 255.0.0.0
        inet6 ::1  prefixlen 128  scopeid 0x10<host>
        loop  txqueuelen 1000  (Local Loopback)
        RX packets 143397  bytes 153610463 (153.6 MB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 143397  bytes 153610463 (153.6 MB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

vif24.0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet6 fe80::fcff:ffff:feff:ffff  prefixlen 64  scopeid 0x20<link>
        ether fe:ff:ff:ff:ff:ff  txqueuelen 32  (Ethernet)
        RX packets 135  bytes 17934 (17.9 KB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 39  bytes 4202 (4.2 KB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

wlp2s0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.1.165  netmask 255.255.255.0  broadcast 192.168.1.255
        inet6 2600:1700:4b80:20d0::11  prefixlen 128  scopeid 0x0<global>
        inet6 fe80::12d:cc93:862e:628  prefixlen 64  scopeid 0x20<link>
        inet6 2600:1700:4b80:20d0:735d:78e8:9294:5aca  prefixlen 64  scopeid 0x0<global>
        ether 10:5b:ad:89:b8:fd  txqueuelen 1000  (Ethernet)
        RX packets 3637650  bytes 5229666233 (5.2 GB)
        RX errors 0  dropped 15736  overruns 0  frame 0
        TX packets 534205  bytes 63903329 (63.9 MB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

xenbr0: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 10.0.0.1  netmask 255.255.255.0  broadcast 10.0.0.255
        inet6 fe80::3410:7ff:fe34:1b6c  prefixlen 64  scopeid 0x20<link>
        ether fe:ff:ff:ff:ff:ff  txqueuelen 1000  (Ethernet)
        RX packets 3565  bytes 358969 (358.9 KB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 1665  bytes 171684 (171.6 KB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0
$ brctl show
bridge name     bridge id               STP enabled     interfaces
docker0         8000.0242d81ee568       no
xenbr0          8000.feffffffffff       no              vif24.0 <- this number somehow keeps getting bigger
tklengyel commented 3 years ago

Make sure in step 5 you use the network interface name that's your egress. For you that would be iptables -t nat -A POSTROUTING -o wlp2s0 -j MASQUERADE, not eth0.

docfate111 commented 3 years ago

oh i missed that thanks. im still running into the error even though i made the change and restarted from step 4

tklengyel commented 3 years ago

These are the steps I usually do to troubleshoot network connectivity: 1) Try pinging an IP on the outside, starting with 10.0.0.1, then 192.168.1.1 and then 1.1.1.1. 2) If you can ping IPs on the internet then you just need to set the DNS nameserver manually. 3) If you can't ping outside the 10.0.0.0/24 subnet then you either don't have IP forwarding enabled or the iptables masquerade rule didn't take. 4) If you can't ping 10.0.0.1 then the interface is not configured in the VM.

docfate111 commented 3 years ago

Within the vm I am only able to ping 10.0.0.1. IPv4 forwarding is enabled in the host and I just enabled it in the guest but I still am only able to ping 10.0.0.1. What steps should I take next?

tklengyel commented 3 years ago

Fire up tcpdump and verify that the ICMP packets leave on your egress interface when pinging outside. If you don't see them leave, then its the host not forwarding them. If they leave on your egress interface but with the src IP still of the VM its the iptables rule not being right.

docfate111 commented 3 years ago

locally

sudo tcpdump | grep 10.0.0.2
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on wlp2s0, link-type EN10MB (Ethernet), capture size 262144 bytes
(nothing)

inside the vm

$ ping 10.0.0.1
64 bytes from 10.0.0.1: icmp_seq...

both locally and not

$ cat /proc/sys/net/ipv4/ip_forward
1

so the host is not forwarding still?

tklengyel commented 3 years ago

Well, on wlp2s0 you should NOT be seeing any packets from 10.0.0.2, the iptables masquerade rule makes sure the packets leave with the IP of the host. So check for icmp packets.

tklengyel commented 3 years ago

Also, if you are pinging 10.0.0.1 from the VM those packets won't go out on your wifi, 10.0.0.1 is your dom0 so ping something external from your VM.

docfate111 commented 3 years ago

ok pings within the VM are not picked up(nm different ipv6 address was causing them)

sudo tcpdump| grep ICMP

in the vm for any address other than 10.0.0.1

ping www.google.com
Unable to reach host
tklengyel commented 3 years ago

Try pinging IPs, not domain names. And also, fyi https://www.ibm.com/support/pages/using-tcpdump-verify-icmp-polling

docfate111 commented 3 years ago

thanks ok i tried 

tcpdump icmp

like before

ping 192.168.0.1

is picked up if it is run locally but not if it run from within the vm.

tklengyel commented 3 years ago

Isn't your wifi subnet 192.168.1.165/24? So you should try pinging 192.168.1.1. If it's not picked up by tcpdump on the wifi interface then its not being forwarded.

docfate111 commented 3 years ago

Yes it is not being forwarded when i try that address How do I get it forwarded?

tklengyel commented 3 years ago

You already have IP forwarding enabled so I don't know what is stopping the forwarding. Check if you have a firewall or if your default route is perhaps set to something different.

docfate111 commented 3 years ago

How do I check default route? It wasn't set with iptables? I do not have any firewall.

tklengyel commented 3 years ago

ip route

docfate111 commented 3 years ago

local

$ ip route
default via 192.168.1.254 dev wlp2s0 proto dhcp metric 600 
10.0.0.0/24 dev xenbr0 proto kernel scope link src 10.0.0.1 
169.254.0.0/16 dev wlp2s0 scope link metric 1000 
172.17.0.0/16 dev docker0 proto kernel scope link src 172.17.0.1 linkdown 
192.168.1.0/24 dev wlp2s0 proto kernel scope link src 192.168.1.165 metric 600

vm

$ iproute
default via 10.0.0.1 dev eth0 proto static metric 1024
10.0.0.0/24 dev eth0 proto kernel scope link src 10.0.0.2
169.254.0.0/16 dev eth0 scope link metric 1000
tklengyel commented 3 years ago

Looks as expected. I don't know why your dom0 is not forwarding the packets out the default route. You probably want to start from scratch, reboot, delete all iptables rules and start over.

tklengyel commented 3 years ago

Oh, and I just noticed, your default route's IP is 192.168.1.254, not the usual 192.168.1.1, so try pinging that from the VM.

docfate111 commented 3 years ago

in the vm the pinging is not working. ok ill try on another computer. everyone ive tried on either fails to boot xen because not enough RAM and cpu and when it finally worked i cant get wifi to work.

tklengyel commented 2 years ago

You might also need to do iptables -A FORWARD -j ACCEPT