Posts tagged #dhcp

Apple iOS Personal Hotspot Annoyances

This week, I ran into an annoying feature regarding the Apple iOS Personal Hotspot function of my iPhone 5s. I had to do some software testing with various WiFi clients. This worked fine, up to the moment that new devices ran into connectivity problems.

The new devices could connect, but got a message that there was no/limited Internet connectivity. Checking the IP address of the devices showed that they had an 169 address assigned.
So the iPhone wouldn't give new IP addresses to the new devices. Earlier devices that connected correctly could reconnect without a problem though.

It turned out to be a 'normal' DHCP problem. The IP address scope on the iPhone was depleted.

The iPhone has a small DHCP address pool that can give out 16 addresses (172.20.10.0-172.20.10.15). Of these 16 addresses are 3 taken by the network, broadcast (172.20.10.0 and 172.20.10.15) and iPhone itself (172.20.10.1). Leaving 13 addresses for other devices.

In normal situations, this shouldn't be a problem, but when your testing stuff, you can run into a shortage of IP addresses. Besides the shortage of addresses there is another challenge; no way of altering the DHCP lease time, or even clearing the issued IP addresses.

The lease time for the DHCP address is approximately 1 day (85536 seconds), as shown by a little network traffic capturing below.

20:53:29.544291 56:e4:3a:38:4d:64 > 00:23:6c:8d:7f:8e, ethertype IPv4 (0x0800), length 342: (tos 0x0, ttl 255, id 45806, offset 0, flags [none], proto UDP (17), length 328)
    172.20.10.1.67 > 172.20.10.2.68: BOOTP/DHCP, Reply, length 300, xid 0xfd7e0982, Flags [none]
      Your-IP 172.20.10.2
      Server-IP 172.20.10.1
      Client-Ethernet-Address 00:23:6c:8d:7f:8e
      sname "Free-Public-WiFi"
      Vendor-rfc1048 Extensions
        Magic Cookie 0x63825363
        DHCP-Message Option 53, length 1: ACK
        Server-ID Option 54, length 4: 172.20.10.1
        Lease-Time Option 51, length 4: 85536
        Subnet-Mask Option 1, length 4: 255.255.255.240
        Default-Gateway Option 3, length 4: 172.20.10.1
        Domain-Name-Server Option 6, length 4: 172.20.10.1

There is a function to reset the network settings on the iPhone, but that just clears everything regarding (wireless) network settings, but it doesn't touch the DHCP service in the iPhone. A reboot of the iPhone doesn't do the trick either. So you just have to wait till it clears automagically.

So there is room for improvement......


Posted on July 30, 2015 and filed under Annoying, Apple, iPhone, Tips'n Tricks.

Ziggo Internet, Juniper Firewalls and DHCP

At the house I have currently two ISP delivering broadband. Well, broadband isn't the correct word, since the the one of them is only a mere 256kbps (I think). The other is a 'whopping' 20Mbps.
The 20Mb connection is provided by XS4ALL, and the 256kbps is for free (if you have a phone subscription with Ziggo). The 256kbp is the minimum they provide to transport the phone calls, but if you're a masochist you can also browse the internet over that connection.

So, two ISP @ home. Combine that with a Juniper SRX firewall, and a dual ISP setup is born. The theory of that setup is that I connect both ISP's to the firewall, and use the 20Mb line as a default internet connection, but when that one dies, I automatically get switched to the backup line (256kbps).

Posted on August 9, 2012 and filed under Annoying, Hardware, Internet, Security, Tips'n Tricks.

VMWare and Firewall / VPN Clients

Well, that was another morning well spent....

A couple off weeks ago I started experimenting with FreeRADIUS on Ubuntu server (v6.06.2 TLS). Mainly because I needed to test some things for work. So I used VMWare to experiment. The networking part was set-up as Bridged.

Today, I wanted to test with iperf (a tool for network performance testing). So I launched the virtual machine, but there was no network connectivity. ifconfig showed that eth1 didn't received an IP adres.
So I ran every possible test there was;

  • restarted the interfaces (/etc/init.d/networking restart)

This resulted in the following;

Listening on LPF/eth1/00:0c:29:68:e3:eb
Sending on LPF/eth1/00:0c:29:68:e3:eb
Sending on Socket/fallback
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 8
DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 12

The "DHCPDISCOVER" messages continue about 4 times, then the message:

No DHCPOFFERS received.
No working leases in persistent database - sleeping.

  • restarted the DHCP server
  • rebooted the virtual machine
  • changes the networking to NAT instead of Bridged (this way, connectivity was restored, but not the way I wanted. I needed Bridge-mode)
  • Tried to run the virtual machine on OSX (VMWare Fusion), which worked surprisingly.

After this I ran Wireshark on my server to see if DHCP request were coming in.... And you might have guessed; No DHCP request were reaching the DHCP server. So the problem was work PC related.... As a matter of fact, I had the Cisco VPN client running..... Which didn't allow the DHCP request broadcast.

Shutting the VPN client down solved the DHCP problem. After the virtual machine worked I could reinitiate the VPN.

Mental note to myself: do NOT boot/restart the virtual machines when the VPN is up.