4

This will be kind of a long post, but I want to give complete information.

I have a home/business LAN with isc-dhcp-server running an ipv4 dhcp server and bind as a DNS server running on an ubuntu server box. I have comcast business, and the gateway has all dhcp functions disabled. To kill off ipv6 until I'm ready to deal with it, on all my linux boxes, I've disabled ipv6 both with a grub command and sysctl parameter:

surfrock66@sr66-hp2:~/.scripts$ cat /etc/default/grub | grep -v "#"

GRUB_DEFAULT=0
GRUB_TIMEOUT=5
GRUB_DISTRIBUTOR=`lsb_release -i -s 2> /dev/null || echo Debian`
GRUB_CMDLINE_LINUX_DEFAULT="quiet ipv6.disable=1 acpi_backlight=vendor"
GRUB_CMDLINE_LINUX=""

surfrock66@sr66-hp2:~/.scripts$ cat /etc/sysctl.conf | grep -v "#"

net.ipv6.conf.all.disable_ipv6 = 1
net.ipv6.conf.default.disable_ipv6 = 1
net.ipv6.conf.lo.disable_ipv6 = 1
net.ipv6.conf.eth0.disable_ipv6 = 1
net.ipv6.conf.wlo0.disable_ipv6 = 1
surfrock66@sr66-hp2:~/.scripts$ 

There's no ipv6 on these systems. So, on what I thought was an unrelated note, my android and chromecast devices have had wifi issues. The main thing I see is excessively slow connections which can result in timeout and failure. Well, I was doing some troubleshooting and performed an iperf...the iperf app listed an ipv6 address as well as an ipv4 one. Sure enough, some further looking...every device with slowness issues has an ipv6 address from somewhere!

The ipv6 disable app resolves my connection issues, but reverts any time the connection breaks and is remade. The real solution here is to kill off the rogue DHCP server, or to set up my own ipv6 dhcp solution. The latter is my eventual plan, but for now I want to stop the current devices from getting an ipv6 address.

The gateway has all DHCP services off (both ipv4 and ipv6, which are on different screens). The DHCP server is a member of the LAN, and it points to the gateway as the default route.

The comcast business class gateway isn't a Wifi AP; I have 3 Netis AP's with all routing functionality disabled. They're dumb devices.

I was able to run a network scan from an android device and found a list of clients with ipv6 addresses...3 of them have MAC addresses I didn't recognize and couldn't resolve using a MAC lookup. I'm going to re-enable ipv6 on one of my laptops, but am pretty sure that when I do that device won't have a network connection immediately. I want to go into this with a plan for figuring out how these clients are getting their ipv6 address.

https://goo.gl/photos/Z7yuXnL7C38tBA2z8

https://goo.gl/photos/urwY6rXUYs5d9mjP8

I'm not sure how to tell which is the DHCP server though from Android; on ipv4 it's 192.168.1.22. I can identify all the MAC addresses as devices I know, except 3:

  • 61:AD:F8:15:56:CC
  • 16:0A:EB:A3:10:A4
  • 61:AD:F8:51:15:25

No idea what those 3 are; I did an ipv4 scan of the entire LAN and no corresponding ipv4 devices show up. No MAC lookup gives me a result as to who the manufacturer might be.

My DHCP server issues addresses based on the MAC; so I know every mac on the LAN. Guests (aka unknown MAC) get a 192.168.1.197-254 addresses, so they'd be easy to identify.

I re-enabled ipv6 on my laptop, and now my wifi adapter gets an ipv6 address:

surfrock66@sr66-hp2:~$ sudo ifconfig -a
eth0: flags=4099<UP,BROADCAST,MULTICAST>  mtu 1500
        ether 10:1f:74:1b:ec:cb  txqueuelen 1000  (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 1  (Local Loopback)
        RX packets 3581  bytes 464169 (453.2 KiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 3581  bytes 464169 (453.2 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

wlo1: flags=4163<UP,BROADCAST,RUNNING,MULTICAST>  mtu 1500
        inet 192.168.1.46  netmask 255.255.255.0  broadcast 192.168.1.255
        inet6 2601:204:cd00:e200:1c5d:6970:a767:9c9e  prefixlen 64  scopeid 0x0<global>
        inet6 fe80::c1b6:f422:a87d:4f49  prefixlen 64  scopeid 0x20<link>
        ether 74:e5:0b:1d:62:90  txqueuelen 1000  (Ethernet)
        RX packets 4151  bytes 2333517 (2.2 MiB)
        RX errors 0  dropped 0  overruns 0  frame 0
        TX packets 3531  bytes 651073 (635.8 KiB)
        TX errors 0  dropped 0 overruns 0  carrier 0  collisions 0

surfrock66@sr66-hp2:/var/lib/dhcp$ for i in `\ls /var/lib/dhcp`; do echo $i; cat $i; done
dhclient.eth0.leases
lease {
  interface "eth0";
  fixed-address 192.168.1.227;
  filename "pxelinux.0";
  option subnet-mask 255.255.255.0;
  option time-offset -25200;
  option routers 192.168.1.1;
  option dhcp-lease-time 3600;
  option dhcp-message-type 5;
  option domain-name-servers 8.8.8.8,8.8.4.4;
  option dhcp-server-identifier 192.168.1.22;
  option domain-name "hda.surfrock66.com";
  renew 3 2016/06/01 04:01:58;
  rebind 3 2016/06/01 04:01:58;
  expire 3 2016/06/01 04:01:58;
}
dhclient.leases

surfrock66@sr66-hp2:/var/lib/dhcp$ sudo grep -R "DHCPOFFER" /var/log/*
/var/log/auth.log:Jul  9 14:32:23 sr66-hp2 sudo: surfrock66 : TTY=pts/1 ; PWD=/var/lib/dhcp ; USER=root ; COMMAND=/bin/grep -R DHCPOFFER /var/log/alternatives.log /var/log/alternatives.log.1 /var/log/alternatives.log.2.gz /var/log/apt /var/log/auth.log /var/log/auth.log.1 /var/log/auth.log.2.gz /var/log/auth.log.3.gz /var/log/auth.log.4.gz /var/log/btmp /var/log/btmp.1 /var/log/cups /var/log/daemon.log /var/log/daemon.log.1 /var/log/daemon.log.2.gz /var/log/daemon.log.3.gz /var/log/daemon.log.4.gz /var/log/debug /var/log/debug.1 /var/log/debug.2.gz /var/log/debug.3.gz /var/log/debug.4.gz /var/log/dmesg /var/log/dpkg.log /var/log/dpkg.log.1 /var/log/dpkg.log.2.gz /var/log/exim4 /var/log/faillog /var/log/firebird /var/log/fontconfig.log /var/log/fsck /var/log/hp /var/log/installer /var/log/kern.log /var/log/kern.log.1 /var/log/kern.log.2.gz /var/log/kern.log.3.gz /var/log/kern.log.4.gz /var/log/lastlog /var/log/lightdm /var/log/mail.err /var/log/mail.err.1 /var/log/mail.err.2.gz
/var/log/daemon.log:Jul  5 09:18:22 sr66-hp2 dhclient[6017]: DHCPOFFER of 192.168.110.50 from 192.168.108.2

I don't have a dhcp lease for ipv6, and the only DHCP offer was from when I was using the guest wifi in a hospital this week.

I can no longer resolve anything that didn't have a cached DNS entry. I've re-disabled ipv6 on the laptop for more troubleshooting research.

Where should I start?

  • 3
    It's not a DHCPv6 service that's doing this. DHCP is not the only way addresses can get assigned in v6. What's happening here (likely) is v6 SLAAC, where your router sends RA packets to the network periodically, advertising itself as a valid v6 router, and telling its clients which subnet to use. Then the clients assign themselves an address in that subnet. – EEAA Jul 10 '16 at 4:16
  • 3
    Honest question: why are you avoiding IPv6? It appears that your network and provider already support it, and all modern OSes are quite well-behaved with IPv6 (I recently enabled it at work and no one but me noticed). v6 isn't going away, so you might as well dig in now. – EEAA Jul 10 '16 at 4:21
  • The MAC addresses 61:AD:F8:15:56:CC and 61:AD:F8:51:15:25 are group addresses, and 16:0A:EB:A3:10:A4 is a locally administered address. – Ron Maupin Jul 10 '16 at 4:24
  • 2
    Congrats! To disable SLAAC, all you need to do is turn off RA functionality on your router. On Linux, OSX, and Windows, you can likely tell them to ignore RAs, but with mobile OSes, you're stuck. You'll need to either sort out how to disable this on your router or replace the router altogether. – EEAA Jul 10 '16 at 4:36
  • 2
    1) they are public addresses, but behind a firewall. Nothing to worry about. 2) yes 3) they will use whatever is available 4) yes – EEAA Jul 10 '16 at 5:09

Your Answer

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

Browse other questions tagged or ask your own question.