• Status: Solved
  • Priority: Medium
  • Security: Public
  • Views: 692
  • Last Modified:

Increasing maximum # of IP addresses handed out by proxy server

I'm having trouble with a Ubuntu-based proxy server that's running Squid and DansGuardian.  The server is used for content-filtering a guest wireless network.

The system was set up by a consultant who is no longer available, and I'm trying to troubleshoot an issue.  My Linux skills and my networking skills are fairly basic, to say the least.

Here is the problem: After the server runs for three or four days, new devices are no longer able to connect to the wireless network.  The devices seem unable to get an IP address.  My suspicion is that there is a limit to the number of addresses (maybe 50?) that the server gives out.  

Based on the very sparse documentation that was provided by the networking consultant, I know that routing is turned on by executing this command at boot time:

echo 1 > /proc/sys/net/ipv4/ip_forward

Is there a config file somewhere that I can edit to determine (and then change) the maximum number of IP addresses that the server can hand out?  As I said, I don't have much experience in this area, and I wasn't able to answer the question via running Google searches.

Thanks in advance for any guidance.
0
chernavsky
Asked:
chernavsky
  • 5
  • 5
3 Solutions
 
chernavskyAuthor Commented:
@southpau1 -- the page you referenced talks about setting a limit for simultaneous web connections from a single client.  I don't think that that's the issue in my case.
0
 
savoneCommented:
Traditionally a proxy server does not hand out IP addresses.  That is the job of a DHCP server.  Unless of course the consultant put the DHCP service on the same machine as the proxy server.

Do you know if you also have a DHCP server?  When a machine is not able to connect have you checked to see if it has a valid IP address?
0
Get quick recovery of individual SharePoint items

Free tool – Veeam Explorer for Microsoft SharePoint, enables fast, easy restores of SharePoint sites, documents, libraries and lists — all with no agents to manage and no additional licenses to buy.

 
chernavskyAuthor Commented:
@Savone, I think you may have given me the clue I needed.  I did some more poking around, and I think that the server is running udhcpd.  There is a promising-looking config file at /etc/udhcpd.conf.

Unfortunately, it's the end of the day right now, and I have to go home.  I will take a closer look at it tomorrow.
0
 
savoneCommented:
Yes, that is the configuration file for DHCP.  Just MAKE SURE you back it up first.  This way if you make a change that it doesn't like, or that breaks something else you can always copy it back over.

Here is the man page with all the information you will need:
http://manpages.ubuntu.com/manpages/dapper/man5/udhcpd.conf.5.html
0
 
chernavskyAuthor Commented:
Savone, I've attached the udhcpd.conf file.  Can I ask you a few questions about it?

I assume that the block of dynamic IPs starts at .100 so that you can create 98 static IP addresses, if necessary.  Is that correct?  If so, then I can probably start the block at .20 or something like that.  I don't anticipate needing to create so many static IPs (or any, actually).

The lease time seems to be set for 10 days.  That seems long to me.  What would be a reasonable lease time, given that the wireless network is used both by true guests (visitors to our facility) as well as by staff (for their smart phones, iPads, etc.)?

Offhand, do you see any other parameters that should be changed in the config file?

Thanks so much for your help.
0
 
chernavskyAuthor Commented:
OK, I'm having trouble attaching the config file.  Let me copy-and-paste it below.


# Sample udhcpd configuration file (/etc/udhcpd.conf)

# The start and end of the IP lease block

start            192.168.100.100      #default: 192.168.0.20
end            192.168.100.199      #default: 192.168.0.254


# The interface that udhcpd will use

interface      eth0            #default: eth0


# The maximim number of leases (includes addressesd reserved
# by OFFER's, DECLINE's, and ARP conficts

max_leases      99            #default: 254


# If remaining is true (default), udhcpd will store the time
# remaining for each lease in the udhcpd leases file. This is
# for embedded systems that cannot keep time between reboots.
# If you set remaining to no, the absolute time that the lease
# expires at will be stored in the dhcpd.leases file.

#remaining      yes            #default: yes


# The time period at which udhcpd will write out a dhcpd.leases
# file. If this is 0, udhcpd will never automatically write a
# lease file. (specified in seconds)

#auto_time      7200            #default: 7200 (2 hours)


# The amount of time that an IP will be reserved (leased) for if a
# DHCP decline message is received (seconds).

#decline_time      3600            #default: 3600 (1 hour)


# The amount of time that an IP will be reserved (leased) for if an
# ARP conflct occurs. (seconds

#conflict_time      3600            #default: 3600 (1 hour)


# How long an offered address is reserved (leased) in seconds

#offer_time      60            #default: 60 (1 minute)

# If a lease to be given is below this value, the full lease time is
# instead used (seconds).

#min_lease      60            #defult: 60


# The location of the leases file

#lease_file      /var/lib/misc/udhcpd.leases      #defualt: /var/lib/misc/udhcpd.leases

# The location of the pid file
#pidfile      /var/run/udhcpd.pid      #default: /var/run/udhcpd.pid

# Everytime udhcpd writes a leases file, the below script will be called.
# Useful for writing the lease file to flash every few hours.

#notify_file                        #default: (no script)

#notify_file      dumpleases      # <--- useful for debugging

# The following are bootp specific options, setable by udhcpd.

#siaddr            192.168.0.22            #default: 0.0.0.0

#sname            zorak                  #default: (none)

#boot_file      /var/nfs_root            #default: (none)

# The remainer of options are DHCP options and can be specifed with the
# keyword 'opt' or 'option'. If an option can take multiple items, such
# as the dns option, they can be listed on the same line, or multiple
# lines. The only option with a default is 'lease'.

#Examles
opt      dns      172.16.200.254
option      subnet      255.255.255.0
opt      router      192.168.100.1
#opt      wins      192.168.10.10
option      dns      8.8.8.8      # appened to above DNS servers for a total of 3
option      domain      lollypop.org
option      lease      864000            # 10 days of seconds


# Currently supported options, for more info, see options.c
#opt subnet
#opt timezone
#opt router
#opt timesrv
#opt namesrv
#opt dns
#opt logsrv
#opt cookiesrv
#opt lprsrv
#opt bootsize
#opt domain
#opt swapsrv
#opt rootpath
#opt ipttl
#opt mtu
#opt broadcast
#opt wins
#opt lease
#opt ntpsrv
#opt tftp
#opt bootfile
#opt wpad

# Static leases map
#static_lease 00:60:08:11:CE:4E 192.168.0.54
#static_lease 00:60:08:11:CE:3E 192.168.0.44
0
 
savoneCommented:
Ok so you are right on the money.  

First off 10 day leases are way too long.  In your situation I think setting them to 4-8 hours would be safe.

Also it looks like the start and end IP addresses can be increased. I don't see a need to stop it at 199 either, so maybe:

start            192.168.100.20      #default: 192.168.0.20
end            192.168.100.254      #default: 192.168.0.254

Also your max leases is set to 99, probably because of the old start and end ip range, so maybe:

max_leases      234            #default: 254

And of course you want to change your lease time, for example 4 hours:

option      lease      14400            # 4 hours of seconds

These changes should fix your issues.
0
 
savoneCommented:
Remember to back up your original file first before making changes:

cp /etc/udhcpd.conf ~/

Also remember to start the dhcp service for the changes to take effect.
I do not use ubuntu, but I imagine this would work to restart it:

/etc/init.d/udhcpd restart
0
 
chernavskyAuthor Commented:
Excellent.  Everything worked as expected.  Thanks so much, Savone.  I think this solves a very vexing problem that I've had for several months now, ever since I installed the wireless network.
0
 
savoneCommented:
Glad I can help
0

Featured Post

Industry Leaders: We Want Your Opinion!

We value your feedback.

Take our survey and automatically be enter to win anyone of the following:
Yeti Cooler, Amazon eGift Card, and Movie eGift Card!

  • 5
  • 5
Tackle projects and never again get stuck behind a technical roadblock.
Join Now