0

I'm trying to setup a poorly designed Wi-Fi device and I've connected to its wifi network and set my IP and routes manually as DHCP does not appear to be working.

# ip route show
default via 192.168.10.100 dev wlp2s0b1 src 192.168.10.3
192.168.10.0/24 dev wlp2s0b1 scope link

When I try to ping 192.168.10.100 (the alleged default IP), the ping utility shows no output. tcpdump also shows nothing, though there is activity on the network, and ARP happens occasionally:

17:12:43.147305 ARP, Request who-has gateway tell localhost.localdomain, length 28
17:12:43.148516 ARP, Reply gateway is-at d8:eb:97:a2:3b:fc (oui Unknown), length 28


17:14:15.914295 IP localhost.localdomain.50800 > 239.255.255.250.ssdp: UDP, length 171
17:14:15.921169 IP gateway.ssdp > localhost.localdomain.50800: UDP, length 279
17:14:17.750750 ARP, Request who-has localhost.localdomain tell gateway, length 28
17:14:17.750799 ARP, Reply localhost.localdomain is-at 70:18:8b:06:ba:57 (oui Unknown), length 28

Additionally, if I send pings to a host outside of the subnet, tcpdump -i wlp2s0b1 shows the following (not in this order, just that it shows the request and response):

17:13:16.989280 IP gateway > localhost.localdomain: ICMP net 192.168.1.1 unreachable, length 92
17:13:17.989237 IP localhost.localdomain > 192.168.1.1: ICMP echo request, id 27888, seq 12, length 64

even though ping shows no output. (?)

How is this behavior possible? What's happening?

Here's my firewall:

# iptables-save
# Generated by iptables-save v1.6.0 on Tue Dec 19 17:19:43 2017
*nat
:PREROUTING ACCEPT [29:6414]
:INPUT ACCEPT [23:5137]
:OUTPUT ACCEPT [10380:773373]
:POSTROUTING ACCEPT [9239:678321]
-A POSTROUTING -p udp -m udp --sport 1500 -j SNAT --to-source :30000
-A POSTROUTING -p udp -m udp --sport 1504 -j SNAT --to-source :30001
COMMIT
# Completed on Tue Dec 19 17:19:43 2017
# Generated by iptables-save v1.6.0 on Tue Dec 19 17:19:43 2017
*filter
:INPUT ACCEPT [52617:8798972]
:FORWARD ACCEPT [0:0]
:OUTPUT ACCEPT [54107:7942732]
COMMIT
# Completed on Tue Dec 19 17:19:43 2017

Also, tcpdump -i lo does not show any of the packets I'm looking for

EDIT Some updates:

# ip route get 192.168.10.100
192.168.10.100 dev wlp2s0b1 src 192.168.10.3 uid 0 
    cache 

# ip addr show wlp2s0b1
3: wlp2s0b1:  mtu 1500 qdisc fq_codel state UP group default qlen 1000
    link/ether 70:18:8b:--:--:-- brd ff:ff:ff:ff:ff:ff
    inet 192.168.10.3/24 brd 192.168.10.255 scope global wlp2s0b1
       valid_lft forever preferred_lft forever
    inet6 fe80::ff1e:167e:8d67:797d/64 scope link 
       valid_lft forever preferred_lft forever

Also, looking at tcpdump -n, 192.168.10.100 is indeed 'gateway', not sure how that name is getting in there.

UPDATE sorry guys, it is because I was running an IPsec client with local selector containing 192.168.10.0/24. I did not see evidence of this using the ip utility, including with ip route show table all but stopping the client released this 'blackhole'. Thanks

  • Aren't you missing the -i option before the interface name? Man doesn't show that syntax as valid... – Zip Dec 19 '17 at 22:32
  • Check ip addr to make sure the addresses and netmasks are correct. Also, do a tcpdump -n -i wlp2s0b1 to see the numeric addresses, so you can check if they are correct (I assume gateway = 192.168.10.100, but who knows...). Try ip route get 192.168.10.100 to make sure you don't have funny policy routing rules for some reason. – dirkt Dec 19 '17 at 23:08
  • Are we looking at network configuration on the WiFi device, or on a client of that WiFi device? – roaima Dec 19 '17 at 23:29
  • 1
    What's your network topology, and which part is wired and which part wireless? What is the IP address for the host called "gateway"? – roaima Dec 19 '17 at 23:29
  • 1
    Your IPsec comment... Is that the solution? Because if so it belongs as an Answer. Or else you may want to delete this question – roaima Dec 20 '17 at 0:35

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy