[Q]: Static DHCP Lease with the WRT54GL...

Hello,
I have replaced my old D-LINK router with a WRT54GL wireless router.
On the old router I could configure static DHCP entries, providing the same IP address to specific MAC addresses (from my different devices at home), and still continue to receive all other settings via DHCP (Like DNS servers that my ISP changes from time to time).
Using static IP addresses is not an option due that the ISP I'm connected changes the DNS settings frequently and my computers can't connect to the internet. Setting the WRT54GL router as DNS server on my computers is also not practical.
On the WRT54GL I could not find how to create static (or permanent) DHCP leases. Is this possible?.. is this in the wish list for future releases of the firmware?
Thanks in advance.

Thanks for the quick response.
I was surprised that this (and maybe other) Linksys routers does not provide this simple feature.
All DHCP servers I know provide this feature and most of the unmanaged routers that provide DHCP services have this feature.
--- Ricky.

Similar Messages

DHCP Server with the Static IP fill out DNS information

When filling out the DHCP Server with the Static IP from ipconfig.exe in the "Preferred DNS server IPv4 address:
192.168.1.199
The same as in the static IP. The IPv6 DNS one validates IPv4 does not.
I tried using the IPv4 Address and that validated but gave an error at the end: 1059 and 1046.
Gives an error:
"The DNS Server at the specified IP address does not support the required TCP protocol."

Hi,
Firstly, would you please post the result of running “ipconfig/all” on the DHCP server and domain controller?
It seems that the DHCP server cannot be authorized in AD DS. Please make sure that the DHCP server is a domain member and try to ping the domain controller on the DHCP server.
Best regards,
Susie

WRT320N static DHCP leases

hi,
i have a wrt320n. it runs fine, but i'm in need of static DHCP leases.
the reason is simple: if one uses static port forwards for applications that doesn't support upnp, and the client gets a different ip than what's specified for the port forwards, it all gets messed up.
i couldn't find any reference for this feature neither in the manual nor in the router web interface, so i guess it's not possible ATM.
could you please add support for this (quite basic) feature?
thanks in advance.
Solved!
Go to Solution.

Well i think the feature which you are trying to look under the linksys router its not possible. I think you need to wait until linksys release the new firmware along with the DHCP Leases.

How do I revoke a DHCP lease in the 10.8.4 server app?

Hello Everyone,
I have some devices (security cameras) that have successfully requested a DHCP lease. Since then I went ahead and manually created a static reservation for them with a MAC hardware address in the DHCP. For whatever reason they are not switching over to the reserved address. The leases were originally for 1 day. It has been 5 days now. After the first day I switched my lease time to 1 hour. I have done everything short of leaving the devices off for 24 hours.
In Lion server, I could revoke the lease via the gui. No such luck now. My call to Applecare resulted in a "there is no way in 10.8.4 to do this". They said it would switch to the new reserved address after the initial lease period timed out, so I'm hoping the representative was wrong twice. They mentioned a complete lease wipe, but couldn't say if this would cause me to lose my list of reserved static addresses, which isn't an option.
It seems crazy that such a basic feature wouldn't make it into this release of the DHCP service. Any help would be greatly appreciated!

Are there any DHCP queries from the cameras? Check the DHCP server log via Console.app or Server.app (or Terminal.app) for details. (I don't know the 10.8 path to the DHCP logs offhand.)
According to a FAQ over at the Vivotek site, the following is the setup sequence for various recent cameras; the boxes start up in the "I don't have an IP address" self-allocated address block oddly enough, and apparently don't ask for a DHCP address? (You may well be aware of all of this, but this is the block that DHCP clients use when they first communicate with DHCP servers.)
If you are using our new product such as IP7138 / IP7139 / FD7131 / VS7100… etc, no matter your network environment is what, you can always find the camera by Installation Wizard II with the IP address 169.254.x.y.
And then, please double click the camera found by Installation Wizard II or directly type the IP address to your Internet Explorer URL box to access your camera (you do not need to change your PC's IP address). After access your camera, please go to "Network" page to configure proper network settings.
See if the devices are available via mDNS, as well; download the Bonjour Browser and have a look around your LAN. (If you're very lucky, the cameras might be visible and chatting on mDNS.)
Might also try resetting one of the cameras back to factory defaults, and seeing if you can get them to re-ask the DHCP server.
(I've had issues with some HP printers and DHCP clients and IP address assignment, but that's fodder for another discussion. And I also wouldn't rule out a rogue DHCP server, either. I've seen all sorts of unexpected stuff connected to networks over the years...)

Clients timeout on DHCP lease with Aironet 1141

Hello
I have an interesting problem that I can't find a solution for.
Backround info:
I'm setting up a Cisco Aironet 1141 (standalone mode, AP) to handle wireless traffic in the office. It gives out 2 mbssids, one of which authenticates domain users through a RADIUS server and places them in an appropriate VLAN (RADIUS options 64, 65, and 81). The other is a guest ssid that uses WPA-PSK and places users in the restricted guest VLAN. Physically, the AP is connected to a 3750 PoE Catalyst, to which RADIUS and DHCP servers are also connected. AP, SSIDs, RADIUS and EAP authentication all work. The configuration given below is a working configuration. People do get authenticated and do get placed in the appropriate vlan.
The problem is that, once authenticated, the "Obtaining IP Address" phase on the client hangs and most clients timeout without getting an IP address. Given that the DHCP server is on the same switch and a test simple ASUS Wi-Fi IP gives out the same scenario (except the multiple VLAN) at the speed of light, I don't think that it's a problem with the network connections between clients and the DHCP server.
After reading some topics here, I realized that probably other communication will be extremely slow, as well, but haven't tested that for sure.
Clients are all non-Cisco - smartphones, notebooks, etc. Most of them are 802.11G, not N.
Configuration is attached below.
Does anyone have any ideas?

Sure, possibly relevant parts:
errdisable recovery cause udld
errdisable recovery cause bpduguard
errdisable recovery cause security-violation
errdisable recovery cause channel-misconfig (STP)
errdisable recovery cause pagp-flap
errdisable recovery cause dtp-flap
errdisable recovery cause link-flap
errdisable recovery cause gbic-invalid
errdisable recovery cause l2ptguard
errdisable recovery cause psecure-violation
errdisable recovery cause dhcp-rate-limit
errdisable recovery cause vmps
errdisable recovery cause storm-control
errdisable recovery cause arp-inspection
spanning-tree mode rapid-pvst
spanning-tree loopguard default
spanning-tree portfast bpduguard default
spanning-tree extend system-id
vlan internal allocation policy ascending
ip ssh time-out 60
ip ssh authentication-retries 5
ip ssh logging events
ip ssh version 2
interface GigabitEthernet1/0/1
description Gi1/0/1 to CAT-CORE
switchport trunk encapsulation dot1q
switchport mode trunk
interface GigabitEthernet1/0/4
description Gi1/0/4 to RADIUS_serv
switchport access vlan 240
switchport mode access
spanning-tree portfast
spanning-tree bpdufilter enable
spanning-tree bpduguard enable
interface GigabitEthernet1/0/8
description Gi1/0/8 to DHCP_serv
switchport access vlan 240
switchport mode access
spanning-tree portfast
spanning-tree bpdufilter enable
spanning-tree bpduguard enable
interface GigabitEthernet1/0/11
description Aironet 1141 AIRONET-MO-1
switchport trunk encapsulation dot1q
switchport trunk native vlan 240
switchport trunk allowed vlan 240-246,248,249
switchport mode trunk
interface Vlan240
description Admin_Vlan
ip address 192.168.240.244 255.255.255.0
ip default-gateway 192.168.240.1
ip classless
no ip http server
ip http secure-server

DHCP Server with the strange MAC address at the same time. This MAC address is HEX IP address!

Server version: Windows server 2008 R2 Ent.
Structure of DHCP scopes: Two DHCP server 50% to 50% all allocation for per scopes.
Question: Sometimes the DHCP server
allocate the IP address at the same time to the a strange MAC address per IP address, the type is "DHCP/BOOT", it cause DHCP scopes out of space at some time point. We need clear up them manually.
I found strange MAC address in HEX is the IP address which the server allocated.
Someone meet the issues before, any solution for this ?
Thanks !
Client IP Address
Name
Lease Expiration
Type
Unique ID
10.199.190.0
10.199.190.0
2014/8/5 10:07
DHCP/BOOTP
31302e3139392e3139302e3000
10.199.190.46
10.199.190.46
2014/8/5 10:07
DHCP/BOOTP
31302e3139392e3139302e343600
10.199.190.59
10.199.190.59
2014/8/5 10:07
DHCP/BOOTP
31302e3139392e3139302e353900
10.199.190.69
10.199.190.69
2014/8/5 10:07
DHCP/BOOTP
31302e3139392e3139302e363900
10.199.190.74
10.199.190.74
2014/8/5 10:07
DHCP/BOOTP
31302e3139392e3139302e373400
10.199.190.90
10.199.190.90
2014/8/5 10:07
DHCP/BOOTP
31302e3139392e3139302e393000
10.199.190.101
10.199.190.101
2014/8/5 10:07
DHCP/BOOTP
31302e3139392e3139302e31303100
10.199.190.104
10.199.190.104
2014/8/5 10:07
DHCP/BOOTP
31302e3139392e3139302e31303400
10.199.190.110
10.199.190.110
2014/8/5 10:07
DHCP/BOOTP
31302e3139392e3139302e31313000
10.199.190.114
10.199.190.114
2014/8/5 10:07
DHCP/BOOTP
31302e3139392e3139302e31313400
10.199.190.117
10.199.190.117
2014/8/5 10:07
DHCP/BOOTP
31302e3139392e3139302e31313700
10.199.190.121
10.199.190.121
2014/8/5 10:07
DHCP/BOOTP
31302e3139392e3139302e31323100
10.199.190.138
10.199.190.138
2014/8/5 10:07
DHCP/BOOTP
31302e3139392e3139302e31333800
10.199.190.144
10.199.190.144
2014/8/5 10:07
DHCP/BOOTP
31302e3139392e3139302e31343400
10.199.190.153
10.199.190.153
2014/8/5 10:07
DHCP/BOOTP
31302e3139392e3139302e31353300
10.199.190.156
10.199.190.156
2014/8/5 10:07
DHCP/BOOTP
31302e3139392e3139302e31353600
10.199.190.157
10.199.190.157
2014/8/5 10:07
DHCP/BOOTP
31302e3139392e3139302e31353700
10.199.190.163
10.199.190.163
2014/8/5 10:07
DHCP/BOOTP
31302e3139392e3139302e31363300
10.199.190.165
10.199.190.165
2014/8/5 10:07
DHCP/BOOTP
31302e3139392e3139302e31363500
10.199.190.168
10.199.190.168
2014/8/5 10:07
DHCP/BOOTP
31302e3139392e3139302e31363800
10.199.190.169
10.199.190.169
2014/8/5 10:07
DHCP/BOOTP
31302e3139392e3139302e31363900
10.199.190.174
10.199.190.174
2014/8/5 10:07
DHCP/BOOTP
31302e3139392e3139302e31373400
10.199.190.177
10.199.190.177
2014/8/5 10:07
DHCP/BOOTP
31302e3139392e3139302e31373700
10.199.190.184
10.199.190.184
2014/8/5 10:07
DHCP/BOOTP
31302e3139392e3139302e31383400
10.199.190.188
10.199.190.188
2014/8/5 10:07
DHCP/BOOTP
31302e3139392e3139302e31383800
10.199.190.189
10.199.190.189
2014/8/5 10:07
DHCP/BOOTP
31302e3139392e3139302e31383900
10.199.190.192
10.199.190.192
2014/8/5 10:07
DHCP/BOOTP
31302e3139392e3139302e31393200
10.199.190.197
10.199.190.197
2014/8/5 10:07
DHCP/BOOTP
31302e3139392e3139302e31393700
10.199.190.201
10.199.190.201
2014/8/5 10:07
DHCP/BOOTP
31302e3139392e3139302e32303100
10.199.190.202
10.199.190.202
2014/8/5 10:07
DHCP/BOOTP
31302e3139392e3139302e32303200
10.199.190.209
10.199.190.209
2014/8/5 10:07
DHCP/BOOTP
31302e3139392e3139302e32303900
10.199.190.210
10.199.190.210
2014/8/5 10:07
DHCP/BOOTP
31302e3139392e3139302e32313000
10.199.190.211
10.199.190.211
2014/8/5 10:07
DHCP/BOOTP
31302e3139392e3139302e32313100
10.199.190.212
10.199.190.212
2014/8/5 10:07
DHCP/BOOTP
31302e3139392e3139302e32313200
10.199.190.213
10.199.190.213
2014/8/5 10:07
DHCP/BOOTP
31302e3139392e3139302e32313300
10.199.190.216
10.199.190.216
2014/8/5 10:07
DHCP/BOOTP
31302e3139392e3139302e32313600
10.199.190.219
10.199.190.219
2014/8/5 10:07
DHCP/BOOTP
31302e3139392e3139302e32313900
10.199.190.222
10.199.190.222
2014/8/5 10:07
DHCP/BOOTP
31302e3139392e3139302e32323200
10.199.190.225
10.199.190.225
2014/8/5 10:07
DHCP/BOOTP
31302e3139392e3139302e32323500
10.199.190.226
10.199.190.226
2014/8/5 10:07
DHCP/BOOTP
31302e3139392e3139302e32323600
10.199.190.229
10.199.190.229
2014/8/5 10:07
DHCP/BOOTP
31302e3139392e3139302e32323900
10.199.190.233
10.199.190.233
2014/8/5 10:07
DHCP/BOOTP
31302e3139392e3139302e32333300
10.199.190.235
10.199.190.235
2014/8/5 10:07
DHCP/BOOTP
31302e3139392e3139302e32333500
10.199.190.238
10.199.190.238
2014/8/5 10:07
DHCP/BOOTP
31302e3139392e3139302e32333800
10.199.190.240
10.199.190.240
2014/8/5 10:07
DHCP/BOOTP
31302e3139392e3139302e32343000
10.199.190.242
10.199.190.242
2014/8/5 10:07
DHCP/BOOTP
31302e3139392e3139302e32343200
10.199.190.243
10.199.190.243
2014/8/5 10:07
DHCP/BOOTP
31302e3139392e3139302e32343300
10.199.190.246
10.199.190.246
2014/8/5 10:07
DHCP/BOOTP
31302e3139392e3139302e32343600
10.199.190.249
10.199.190.249
2014/8/5 10:07
DHCP/BOOTP
31302e3139392e3139302e32343900
10.199.190.251
10.199.190.251
2014/8/5 10:07
DHCP/BOOTP
31302e3139392e3139302e32353100
10.199.190.252
10.199.190.252
2014/8/5 10:07
DHCP/BOOTP
31302e3139392e3139302e32353200
10.199.190.255
10.199.190.255
2014/8/5 10:07
DHCP/BOOTP
31302e3139392e3139302e32353500
10.199.191.1
10.199.191.1
2014/8/5 10:07
DHCP/BOOTP
31302e3139392e3139312e3100
10.199.191.2
10.199.191.2
2014/8/5 10:07
DHCP/BOOTP
31302e3139392e3139312e3200
10.199.191.5
10.199.191.5
2014/8/5 10:07
DHCP/BOOTP
31302e3139392e3139312e3500
10.199.191.6
10.199.191.6
2014/8/5 10:07
DHCP/BOOTP
31302e3139392e3139312e3600
10.199.191.8
10.199.191.8
2014/8/5 10:07
DHCP/BOOTP
31302e3139392e3139312e3800
10.199.191.13
10.199.191.13
2014/8/5 10:07
DHCP/BOOTP
31302e3139392e3139312e313300
10.199.191.14
10.199.191.14
2014/8/5 10:07
DHCP/BOOTP
31302e3139392e3139312e313400
10.199.191.15
10.199.191.15
2014/8/5 10:07
DHCP/BOOTP
31302e3139392e3139312e313500
10.199.191.16
10.199.191.16
2014/8/5 10:07
DHCP/BOOTP
31302e3139392e3139312e313600
10.199.191.17
10.199.191.17
2014/8/5 10:07
DHCP/BOOTP
31302e3139392e3139312e313700
10.199.191.18
10.199.191.18
2014/8/5 10:07
DHCP/BOOTP
31302e3139392e3139312e313800
10.199.191.19
10.199.191.19
2014/8/5 10:07
DHCP/BOOTP
31302e3139392e3139312e313900
10.199.191.20
10.199.191.20
2014/8/5 10:07
DHCP/BOOTP
31302e3139392e3139312e323000
10.199.191.21
10.199.191.21
2014/8/5 10:07
DHCP/BOOTP
31302e3139392e3139312e323100
10.199.191.22
10.199.191.22
2014/8/5 10:07
DHCP/BOOTP
31302e3139392e3139312e323200
10.199.191.23
10.199.191.23
2014/8/5 10:07
DHCP/BOOTP
31302e3139392e3139312e323300
10.199.191.24
10.199.191.24
2014/8/5 10:07
DHCP/BOOTP
31302e3139392e3139312e323400
10.199.191.27
10.199.191.27
2014/8/5 10:07
DHCP/BOOTP
31302e3139392e3139312e323700
10.199.191.29
10.199.191.29
2014/8/5 10:07
DHCP/BOOTP
31302e3139392e3139312e323900
10.199.191.30
10.199.191.30
2014/8/5 10:07
DHCP/BOOTP
31302e3139392e3139312e333000
10.199.191.31
10.199.191.31
2014/8/5 10:07
DHCP/BOOTP
31302e3139392e3139312e333100
10.199.191.32
10.199.191.32
2014/8/5 10:07
DHCP/BOOTP
31302e3139392e3139312e333200
10.199.191.33
10.199.191.33
2014/8/5 10:07
DHCP/BOOTP
31302e3139392e3139312e333300
10.199.191.34
10.199.191.34
2014/8/5 10:07
DHCP/BOOTP
31302e3139392e3139312e333400
10.199.191.37
10.199.191.37
2014/8/5 10:07
DHCP/BOOTP
31302e3139392e3139312e333700
10.199.191.38
10.199.191.38
2014/8/5 10:07
DHCP/BOOTP
31302e3139392e3139312e333800
10.199.191.39
10.199.191.39
2014/8/5 10:07
DHCP/BOOTP
31302e3139392e3139312e333900
10.199.191.42
10.199.191.42
2014/8/5 10:07
DHCP/BOOTP
31302e3139392e3139312e343200
10.199.191.44
10.199.191.44
2014/8/5 10:07
DHCP/BOOTP
31302e3139392e3139312e343400
10.199.191.49
10.199.191.49
2014/8/5 10:07
DHCP/BOOTP
31302e3139392e3139312e343900
10.199.191.52
10.199.191.52
2014/8/5 10:07
DHCP/BOOTP
31302e3139392e3139312e353200
10.199.191.54
10.199.191.54
2014/8/5 10:07
DHCP/BOOTP
31302e3139392e3139312e353400
10.199.191.56
10.199.191.56
2014/8/5 10:07
DHCP/BOOTP
31302e3139392e3139312e353600
10.199.191.61
10.199.191.61
2014/8/5 10:07
DHCP/BOOTP
31302e3139392e3139312e363100
10.199.191.62
10.199.191.62
2014/8/5 10:07
DHCP/BOOTP
31302e3139392e3139312e363200
10.199.191.64
10.199.191.64
2014/8/5 10:07
DHCP/BOOTP
31302e3139392e3139312e363400
10.199.191.65
10.199.191.65
2014/8/5 10:07
DHCP/BOOTP
31302e3139392e3139312e363500
10.199.191.66
10.199.191.66
2014/8/5 10:07
DHCP/BOOTP
31302e3139392e3139312e363600
10.199.191.70
10.199.191.70
2014/8/5 10:07
DHCP/BOOTP
31302e3139392e3139312e373000
10.199.191.72
10.199.191.72
2014/8/5 10:07
DHCP/BOOTP
31302e3139392e3139312e373200
10.199.191.73
10.199.191.73
2014/8/5 10:07
DHCP/BOOTP
31302e3139392e3139312e373300
10.199.191.79
10.199.191.79
2014/8/5 10:07
DHCP/BOOTP
31302e3139392e3139312e373900
10.199.191.80
10.199.191.80
2014/8/5 10:07
DHCP/BOOTP
31302e3139392e3139312e383000
10.199.191.81
10.199.191.81
2014/8/5 10:07
DHCP/BOOTP
31302e3139392e3139312e383100
10.199.191.82
10.199.191.82
2014/8/5 10:07
DHCP/BOOTP
31302e3139392e3139312e383200
10.199.191.83
10.199.191.83
2014/8/5 10:07
DHCP/BOOTP
31302e3139392e3139312e383300
10.199.191.84
10.199.191.84
2014/8/5 10:07
DHCP/BOOTP
31302e3139392e3139312e383400
10.199.191.86
10.199.191.86
2014/8/5 10:07
DHCP/BOOTP
31302e3139392e3139312e383600
10.199.191.90
10.199.191.90
2014/8/5 10:07
DHCP/BOOTP
31302e3139392e3139312e393000
10.199.191.91
10.199.191.91
2014/8/5 10:07
DHCP/BOOTP
31302e3139392e3139312e393100
10.199.191.92
10.199.191.92
2014/8/5 10:07
DHCP/BOOTP
31302e3139392e3139312e393200
10.199.191.93
10.199.191.93
2014/8/5 10:07
DHCP/BOOTP
31302e3139392e3139312e393300
10.199.191.97
10.199.191.97
2014/8/5 10:07
DHCP/BOOTP
31302e3139392e3139312e393700
10.199.191.98
10.199.191.98
2014/8/5 10:07
DHCP/BOOTP
31302e3139392e3139312e393800
10.199.191.99
10.199.191.99
2014/8/5 10:07
DHCP/BOOTP
31302e3139392e3139312e393900
10.199.191.101
10.199.191.101
2014/8/5 10:07
DHCP/BOOTP
31302e3139392e3139312e31303100
10.199.191.102
10.199.191.102
2014/8/5 10:07
DHCP/BOOTP
31302e3139392e3139312e31303200
10.199.191.105
10.199.191.105
2014/8/5 10:07
DHCP/BOOTP
31302e3139392e3139312e31303500
10.199.191.106
10.199.191.106
2014/8/5 10:07
DHCP/BOOTP
31302e3139392e3139312e31303600
10.199.191.108
10.199.191.108
2014/8/5 10:07
DHCP/BOOTP
31302e3139392e3139312e31303800
10.199.191.112
10.199.191.112
2014/8/5 10:07
DHCP/BOOTP
31302e3139392e3139312e31313200
10.199.191.115
10.199.191.115
2014/8/5 10:07
DHCP/BOOTP
31302e3139392e3139312e31313500
10.199.191.116
10.199.191.116
2014/8/5 10:07
DHCP/BOOTP
31302e3139392e3139312e31313600
10.199.191.117
10.199.191.117
2014/8/5 10:07
DHCP/BOOTP
31302e3139392e3139312e31313700
10.199.191.119
10.199.191.119
2014/8/5 10:07
DHCP/BOOTP
31302e3139392e3139312e31313900
10.199.191.120
10.199.191.120
2014/8/5 10:07
DHCP/BOOTP
31302e3139392e3139312e31323000
10.199.191.121
10.199.191.121
2014/8/5 10:07
DHCP/BOOTP
31302e3139392e3139312e31323100
10.199.191.125
10.199.191.125
2014/8/5 10:07
DHCP/BOOTP
31302e3139392e3139312e31323500
10.199.191.133
10.199.191.133
2014/8/5 10:07
DHCP/BOOTP
31302e3139392e3139312e31333300
10.199.191.146
10.199.191.146
2014/8/5 10:07
DHCP/BOOTP
31302e3139392e3139312e31343600
10.199.191.158
10.199.191.158
2014/8/5 10:07
DHCP/BOOTP
31302e3139392e3139312e31353800
10.199.191.162
10.199.191.162
2014/8/5 10:07
DHCP/BOOTP
31302e3139392e3139312e31363200

Hi,
According your description, this may be caused by virus or malicious client.
Please try to perform a network capture on your DHCP server. Then find the device which send these malicious discover messages.
To download Network Monitor, please click the link below,
http://www.microsoft.com/en-hk/download/details.aspx?id=4865
To prevent this issue, you may implement NAP Enforcement for DHCP.
Here is a checklist of configuring NAP Enforcement for DHCP,
Checklist: Configure NAP Enforcement for DHCP
http://technet.microsoft.com/en-us/library/cc772356(v=WS.10).aspx
Hope this helps.
Steven Lee
TechNet Community Support

Monitoring DHCP leases with SNMP

Hi,
is there a way to monitor the number of DHCP leases (show ip dhcp binding) of a DHCP pool created on a 2960 switch?
Regards, Leonardo

Once I got my SNMP host to accept the correct attribute and configure the event trap all I had to do was add the trap command to the router. I then bounced one of my low usage PRI's (which had 0 calls on it ) and got the following event traps on the SNMP host:
Minor
May 19, 2010 2:21:00 PM EDT
A demandNbrLayer2Change notification has been received indicating that a D-channel on Rtr_Cisco device, named has layer 1 active but layer 2 not established. Interface Index = 83 Link Status = ISDNLinkInTransition
System
May 19, 2010 2:21:01 PM EDT
System
Major
May 19, 2010 2:20:59 PM EDT
A demandNbrLayer2Change notification has been received indicating that a D-channel on Rtr_Cisco device, named has both layers 1 and 2 inactive. Interface Index = 83 Link Status = ISDNLinkDown
System
May 19, 2010 2:21:00 PM EDT
System
It doesn't tell you specifically which interface is down but at least it narrows it down to the gateway/router. Most of our gateways have only one PRI anyway.
We use Spectrum One Click for network monitoring.
Here is L2 back on line:
May 19, 2010 2:21:01 PM EDT
A demandNbrLayer2Change notification has been received indicating that a D-channel on Rtr_Cisco device, named has layer 1 active and layer 2 established. Interface Index = 83 Link Status = ISDNLinkUp
System

N82 does not correctly process DHCP leases

I have no problem attaching my new N82 to my, and friends, home wireless networks. However, it fails to connect to the Univeristy Campus network giving the error: "Web: No gateway reply!"
This is because the phone doesn't correctly process DHCP leases with the 'network of one'' (2545.255.255.255) subnet mask.
Campus network details:
HP WAP 530 enterprise access point. The DHCP server is an ISC dhcp server giving out ip address in the standard private class C address range (192.168.1.0) with a subnet mask of (255.255.255.255), and a default route of 192.168.1.1.
This works on Windows 2000/XP/Vista and MAC OSX, but many embedded devices will not add the default route as they see it as outside their subnet. Many institutions use 255.255.255.255 to mitigate inter host communication.
This means I cannot use my N82 at work and I'm not happy. Beware, don't assume you can use your Nokia device at work.

If task manager says it's still running, then obviously it hasn't completed, contrary to what you said. Maybe this .exe process isn't written correctly. For example, maybe it is dependent on the current directory it is launched from, and so double-clicking it causes it to be launched from the directory it lives in, but when run from this java app, the working directory is somewhere else.

RV180W with 1.0.2.6 Firmware - Static DHCP problem

Today I installed the 1.0.2.6 Firmware on a RV180W. I only have now two problems regarding the Static DHCP support in the GUI.
1. Via the Networking > LAN (Local Network) > Static DHCP I have no buttons to Add a new static Lease.
2. Via the Networking > LAN (Local Network) > DHCP Lease Clients I can thick a Lease and click on Make Static IP. The result is an error: Operation failed.
Is this a bug or am I doing something wrong?

RV180 f/w 1.0.4.14
Static DHCP page – missing buttons Add, Edit, Delete since some f/w update.
Apparently Cisco has changed syntax since some f/w version I don't remember.
Fix:
1. Backup unit's settings. Use some editor to check that the syntax for the section DhcpfixedIpAddress is correct in the configuration file. The main clue is a new variable "Name". An example bellow displays 2 lines in Static DHCP page. If necessary make changes most likely including upper/lower case conversion for MacAddr and the lines order.
2. Change checksum to 0.
systemConfig[1]["checksum"]="0"
3. Restore unit's settings from the edited configuration file. I have got missing buttons back only after the above procedure. Any other suggested solutions didn't work for me.
Correct syntax for newer firmware:
ifStatic[4]["SecondaryDns"] = ""
DhcpfixedIpAddress = {}
DhcpfixedIpAddress[1] = {}
DhcpfixedIpAddress[1]["MacAddr"] = "bc:ee:7b:e3:3b:0a"
DhcpfixedIpAddress[1]["Name"] = "Computer01"
DhcpfixedIpAddress[1]["IpAddr"] = "192.168.1.100"
DhcpfixedIpAddress[1]["LogicalIfName"] = "LAN"
DhcpfixedIpAddress[1]["_ROWID_"] = "1"
DhcpfixedIpAddress[2] = {}
DhcpfixedIpAddress[2]["MacAddr"] = "00:15:e9:6a:0f:15"
DhcpfixedIpAddress[2]["Name"] = "Unknown"
DhcpfixedIpAddress[2]["IpAddr"] = "192.168.1.101"
DhcpfixedIpAddress[2]["LogicalIfName"] = "LAN"
DhcpfixedIpAddress[2]["_ROWID_"] = "2"
DhcpLdapServerInfo = {}
Old syntax incompatible with newer firmware:
ifStatic[4]["SecondaryDns"] = ""
DhcpfixedIpAddress = {}
DhcpfixedIpAddress[1] = {}
DhcpfixedIpAddress[1]["IpAddr"] = "192.168.1.100"
DhcpfixedIpAddress[1]["LogicalIfName"] = "LAN"
DhcpfixedIpAddress[1]["_ROWID_"] = "1"
DhcpfixedIpAddress[1]["MacAddr"] = "BC:EE:7B:E3:3B:0A"
DhcpfixedIpAddress[2] = {}
DhcpfixedIpAddress[2]["IpAddr"] = "192.168.1.101"
DhcpfixedIpAddress[2]["LogicalIfName"] = "LAN"
DhcpfixedIpAddress[2]["_ROWID_"] = "2"
DhcpfixedIpAddress[2]["MacAddr"] = "00:15:E9:6A:0F:15"
DhcpLdapServerInfo = {}

Why available Lan Host not showing up in the DHCP Leased Client table for RV180

I just purchased the RV180 and am puzzled as to why lan host with ip address of 192.168.1.102 not showing up in the DHCP leased clients list.
I have 4 static ip addresses with the last 3 digits ending in 101, 102,103 and 200 listed in the static DHCP and available local network list, but 102 is not in the DHCP leased clients list. The other 3: 101,103 and 200 are.
Should it not be there also?

Thanks Marty,
There is nothing different about 102 than the other hosts.
I did talk to tech support at Cisco this morning and I was told that I should not use the static DHCP under Networking LAN. Instead, I should set the static IP at the device level.
So under Static DHCP, the list is blank, but the IP address will show up under Available LAN Hosts and listed as Static as Type.
I thought this is a bit strange since it is Static DHCP and should be under Static DHCP (?)
George

Does anyone else have to renew their DHCP Lease every 30 seconds when using the internet?

Everytime I want to use the internet for surfing the web or browsing iTunes etc I have to go into System Preferences and navigate through to a button that says "Renew DHCP Lease". If watching catch-up TV online I have to click this button every 30 seconds or so because the programme freezes, and if I'm surfing the web or browsing iTunes I have to click it every time I want to update the content of the page. Does anybody know what my problem might be?

This Fix has got things working for me.
I have reprinted this response from another thread I have made (Repost) A number of people were asking me about my fix, so I have expanded my response to hopefully offer a little more clarity.
I was having this problem the other night after I finished doing a massive upgrade to our Home Network (New Router, Modem, Cabling, Etc)
I had to reset my DHCP lease every few minutes, in the end I found Mac Mini's IP Address kept setting itself to other items on the Network, I have some items connected on wired (ethernet) and some were connected on WiFi (Airport Extreme) after clicking the DHCP Lease Renew the Mac Mini would grab an IP address that it thought was available but then another item on my network would "check in" then we would have a clash, The Mac Mini was grabbing what it thought was an available IP address, the DHCP Renew button was not setting the Mac Mini's IP number far enough away to stop the clash.
I was watching the items on my Routers Attached devices screen, The Mac Mini would show up on the page with its new address (after hitting the DHCP Renewal button) then something else would check in with that exisiting IP Address, clash and the Mac Mini would need it's DHCP lease renewed again.
My Network consists of:
- Mac Mini (Wired)
- Acer Laptop (Wired)
- PS3 (1) (wired)
- Apple TV (wired)
- Airport Extreme (wired and looking ater WiFi duties throughout the house)
- PS3 (2) (WiFi)
- TV (WiFi)
- iPad (WiFi)
- Nexus 7 (WiFi)
- Printer (WiFi)
I'll be the first to admit my Networking knowledge is limited (and I'm learning more all the Time) but I simply went into the preferences panel and set the IP address manually.
1. I went into Preferences and selected Network
2. Set Configure IPV4 to: using DHCP with manual address
Now it helped I had my NetGear Routers "Attached devices" Page open here so I could see the address of everything else on my network (I went and switched everything on that was web connected so it would be logged in and running on the network) I looked at the last digit or 2 of every item on my network and then set my new IP address.
3. To ensure I wouldn't have any more clashes I set my new IP address far away from the the others* your only changing the last digit or 2 of the IP address, so in the case of my Mac Mini it went from
xxx.xxx.02 to xxx.xxx.0.52 (note the x's are normally your IP address numbers)
*I originally set it to xxx.xxx.09 but I since found the TV had that IP address (The one thing I forgot to check the previous night) so I this is when I decided to set it far away from the rest of the bunch by setting it to .52 (No specific reason for 52, that was just the 1st number to pop into my head)
Now that was over a week ago and since then I have had no more issues on my Network, so far everything is running smooth and fast. (It has now been over 3 weeks since I posted this, and everything is still working perfectly, I suggested this solution to 2 friends having the same issue and it also fixed there problems as well)
I'm not saying this is the be all and end all to the problem, there must be a more permanent solution out there, but this is working for me so far.

DHCP Problem with ASA 5505

Hi. I have an ASA 5505 configured for Transparent Mode. The Outside interface connects to a router (RV042). The router manages DHCP. With the 5505 in the system, all computers can connect to the internet and to each other, except for a few. The problem computers can be made to work if they are set to a specific address, rather than automatically assigned by the router. Some of the iPads work correctly, some do not. At least one Apple Notebook cannot connect even if I enter a static address.
Consulting the documentation, I found that DHCP traffic (UPD Port 67 and 68) needed to be enabled via rules for the Inside and Outside interfaces. I did that in ASDM but now nothing works.
I have pulled the 5505 out of the system and restored it to the configuration that worked for most of the computers.
Any suggestions would be appreciated. I can pull a "show" run from CLI if it is useful.
Thanks...

Understood. I tried adding the "inside_out extended permit ip any any" command, but it made no difference. Because the implicit rule (permit ip traffic to any less secure interface) is still in the access list table, it would seem the additional extended rule is not needed.
When I first received the 5505, it had an older version of firmware. At the time, when I entered any rule in ASDM it deleted the "less secure" implicit rule, which then broke the system since there was no path for internet traffic from inside to outside, as you have stated. With the newest firmware release, however, when I enter a rule, the "less secure" implicit rule does not go away.
So, with help from the folks here I have made progress. Right now the issue is that when the 5505 in Transparent Mode is between the router and user computers, the computers cannot reliably get addresses that are auto-assigned by the router.
Looking through the logs displayed on ASDM, I noticed the following curious statement:
"6 Mar 31 2014 07:16:42 fe80::1131:41c2:3627:8339 63575 ff02::1:3 5355 No management IP address configured for transparent firewall. Dropping protocol UDP packet from outside:fe80::1131:41c2:3627:8339/63575 to inside:ff02::1:3/5355"
However, I have configured a management IP address, and it is listed in the "show" document that I posted yesterday:
interface BVI1
ip address 192.168.1.10 255.255.255.0
So, I am confused.
I appreciate the help. I am new to the 5505, although I participated as a "friendly" in the ASA program some years ago. I recall a similar problem with that setup. Regrettably, I can't remember how we fixed it...
Regards...

Wake on Demand and DHCP Lease

I have a Mac Pro running Snow Leopard and an Airport Extreme. Wake on Demand works as advertised and I am able to access any sharing service running on the Mac Pro, even if the computer is asleep . . . but only for about 24 hours.
My only problem is that it seemed every night the Mac Pro would no longer be available to my Macbook. Troubleshooting it tonight, I think the problem is that the Airport Extreme base station is not renewing the Mac Pro's DHCP lease.
The Mac Pro's lease had been visible in the Airport Extreme's list of leases all day. When the Mac Pro no longer appeared in my Macbook's Finder, I opened Airport Utility and noticed that the Mac Pro had dropped off in the list of DHCP lease holders. After walking down to my basement and waking the Mac Pro with the mouse, the Mac Pro is back in the list of lease holders and Wake on Demand works once again.
While in the basement, I often hear the Mac Pro waking up momentarily, which I understand is to update the Bonjour Sleep Proxy. Shouldn't it also do something to renew the DHCP lease? Is there a way to make this system work for more than 24 hours without extended the DHCP lease length on the Airport Extreme?
Thanks for the help.

Hi mcewen. The Wake on Demand feature works with any service being advertised with Bonjour. The caveat with Web Sharing is that it only advertises itself with Bonjour if you've modified one of the default web pages. So all you have to do is go into the Sites folder in your Home directory, and make a change to the index.html file, and then turn off Web Sharing and turn it back on. That should get it to be advertised with Bonjour (you can verify this by going to the Bonjour bookmarks section in Safari to make sure your web page shows up). After that it will support Wake on Demand using Web Sharing.

Self-assigned IP after trying to renew DHCP lease for former network

Hi all,
MacBook Pro 15" purchased in Februrary 2008, currently running 10.5.5, up-to-date with patches as of yesterday, 10/20/2008.
For a few weeks now, I've been consistently unable to connect to wireless networks (secured or unsecured, public or private) after changing networks (i.e. going from home to a coffee shop).
I have control over my home network router, and its logs show that upon connecting to the network, OS X tries to renew a DHCP lease for the previous network it was on. Upon receiving the "bad network" DHCP reply, instead of releasing the lease and obtaining a new one, the AirPort interface is immediately assigned an IPV4LL address (from 169.254.0.0/16) and no combination of changing network settings, changing AirPort settings, or rebooting will eliminate the old DHCP lease.
The end result is that my MBP is entirely nonfunctional on some wireless networks that other clients (both Windows and Mac) seem to have no trouble accessing. The problem is quite annoying because I can't connect to access points that (previously) worked fine and whose configurations haven't changed.
In any case where this problem occurs, an old DHCP lease for a different network (10.0.0.0/8 when trying to get on 192.168.0.0/24 or vice versa) is present, so I strongly suspect a DHCP problem. In all cases, I have perfect connectivity to the access point itself, so problems with the wireless connection parameters (including encryption), or those troublesome problems with 802.11b/g/n interoperation seem highly unlikely.
One of two things would help me:
1) Please tell me how to clear the DHCP lease cache. Deleting files from /var/db/dhcpclient/leases does nothing (they appear again upon reboot, identical save for timestamps even after changing network environments, so the cache must be read at boot time and written at shutdown). Selecting "Renew DHCP lease" from the "TCP/IP" tab in the advanced network settings merely attempts to renew the existing lease (for an invalid IP address); it does not appear to release invalid leases.
2) If this is really how the DHCP client is behaving, change the DHCP client so that upon receiving the "Bad network" response, it releases (or simply abandons) the lease and obtains a new one, rather than immediately assigning an IPV4LL address to the AirPort interface.
Additionally, is there any documentation on the Apple DHCP client? Under Linux, I could alter dhcpcd parameters to diagnose things like this. I could find no documentation about the Apple DHCP client outside of Mac Help, which wasn't really any help in this case.
Finally, I do not suspect that this is an instance of the problem discussed in http://discussions.apple.com/thread.jspa?threadID=1352518&tstart=0 as my connection is rock-solid if it can get an IP address when it connects. I've never even seen it hiccup.
Thanks,
Matt Z.

I have had wireless problems intermittently for a year, and seriously for 6 weeks. Apple denied the issue and was no help in spite of many tens of thousands of people on their own discussions complaining. I found a post suggesting a couple of things which fixed the problem. I don't know if both are necessary, but the first by itself does not solve the problem.
Lock the channel of your router to channel 1, apparently Apple and 802.11n don't play well together on higher channels. When this becomes a standard this will be resolved I hope.
Open your network preferences, select 'airport' and advanced. Delete unused networks. Select your network.
Open TCP/IP and write down all the settings, configure iPv4 manually. Enter the settings manually. Turn off IpV6.
Open DNS and write down your DNS server. Delete it and re-enter it manually.
This has worked on 2 macbooks and an iMac for the last 3 weeks with no network drops.
Joe Shea
Philadelphia

Cisco 867VAE drops connection on DHCP lease timeout

Hey!
We have a very annoying problem on our hands. I'm no IOS expert, but I make do.
We've got a Telia DSL connection that has a 20 minute DHCP lease timer. Every 20 minutes when it shakes hand again, the connection drops for about 5 seconds. This because the Cisco thinks that administratively shutting down the interface is a good idea....
How do I stop this behavior? I've tried manually setting <ip dhcp client lease 1 0 0> (for 1 day lease) but it completely disregards that.
Best would obviously be to stop it shutting down the interface every time, but worst case scenario I'll take a solution with a longer DHCP lease since the address rarely changes.
<snip from log>
*Aug 1 01:44:43.514 PCTime: %DHCP-6-ADDRESS_ASSIGN: Interface ATM0.1 assigned DHCP address 81.230.xxx.xx, mask 255.255.255.0, hostname elsa
*Aug 1 02:04:48.498 PCTime: %DHCP-5-RESTART: Interface ATM0.1 is being restarted by DHCP
*Aug 1 02:04:56.106 PCTime: %DHCP-6-ADDRESS_ASSIGN: Interface ATM0.1 assigned DHCP address 81.230.xxx.xx, mask 255.255.255.0, hostname elsa
*Aug 1 02:25:01.050 PCTime: %DHCP-5-RESTART: Interface ATM0.1 is being restarted by DHCP
</snip>
It's running firmware c860vae-ipbasek9-mz.153-2
I'm attaching the current running-config as well.
Thank you in advance!
Best Regards
Daniel

I'm sorry for not reporting in. The case is closed at Cisco and they simply couldn't do anything. The router does, according to the debug logs, send dhcp renew requests, but the ISP doesn't reply to them. If they get lost on the way, or if there's an incompatability with the ISP, I dunno. I heavily doubt it, since Telia (Swedish ISP) used Cisco gear for pretty much everything.
Also, Telia will not reply to anything like this, since they don't support equipment they don't supply.
So I'm completely at a loss, and will remain there until I stumble across something.
I've received an 887M router though, which I'm gonna test. But I'm currently stuck with the fact that it's not supported anymore, and therefor I can't seem to download new IOS software (it uses a very old one).
This is the last reply I got before they closed my case:
*Aug 27 14:56:15.751 PCTime: DHCP Ack Message
*Aug 27 14:56:15.751 PCTime: DHCP: Lease Seconds: 1200
*Aug 27 14:56:15.751 PCTime: DHCP: Server ID Option: 213.66.241.86
*Aug 27 14:56:18.751 PCTime: DHCPD: IP address change on interface ATM0.1
*Aug 27 14:56:18.751 PCTime: DHCPD: IP address change on interface ATM0.1
*Aug 27 14:56:18.751 PCTime: DHCP: Releasing ipl options:
*Aug 27 14:56:18.751 PCTime: DHCP: Applying DHCP options:
*Aug 27 14:56:18.751 PCTime:   Setting default_gateway to 81.230.121.65
*Aug 27 14:56:18.751 PCTime:   Adding default route 81.230.121.65
*Aug 27 14:56:19.751 PCTime:   Adding route to DHCP server 213.66.241.86 via ATM0.1 81.230.121.65
*Aug 27 14:56:19.751 PCTime:   Adding DNS server address 195.67.199.39
*Aug 27 14:56:19.751 PCTime:   Adding DNS server address 195.67.199.40
*Aug 27 14:56:19.751 PCTime: DHCP: Sending notification of ASSIGNMENT:
*Aug 27 14:56:19.751 PCTime:   Address 81.230.121.83 mask 255.255.255.192
*Aug 27 14:56:19.751 PCTime: DHCP Client Pooling: ***Allocated IP address: 81.230.121.83
*Aug 27 14:56:19.803 PCTime: Allocated IP address = 81.230.121.83 255.255.255.192
*Aug 27 14:56:19.803 PCTime: %DHCP-6-ADDRESS_ASSIGN: Interface ATM0.1 assigned DHCP address 81.230.121.83, mask 255.255.255.192, hostname elsa
*Aug 27 14:56:25.751 PCTime: DHCP: Client socket is closed
*Aug 27 15:06:18.759 PCTime: DHCP: Client socket is opened
*Aug 27 15:06:19.759 PCTime: DHCP: QScan: Bound..T1 fired..Renewing
*Aug 27 15:06:19.759 PCTime: DHCP: SRequest attempt # 1 for entry:
*Aug 27 15:06:19.759 PCTime: Temp IP addr: 81.230.121.83 for peer on Interface: ATM0.1
*Aug 27 15:06:19.759 PCTime: Temp sub net mask: 255.255.255.192
*Aug 27 15:06:19.759 PCTime:    DHCP Lease server: 213.66.241.86, state: 7 Renewing
*Aug 27 15:06:19.759 PCTime:    DHCP transaction id: 914
*Aug 27 15:06:19.759 PCTime:    Lease: 1200 secs, Renewal: 600 secs, Rebind: 1050 secs
*Aug 27 15:06:19.759 PCTime: Temp default-gateway addr: 81.230.121.65
*Aug 27 15:06:19.759 PCTime:    Next timer fires after: 00:03:46
*Aug 27 15:06:19.759 PCTime:    Retry count: 1   Client-ID: cisco-d48c.b524.7b17-AT0.1
*Aug 27 15:06:19.759 PCTime:    Client-ID hex dump: 636973636F2D643438632E623532342E
*Aug 27 15:06:19.759 PCTime:                        376231372D4154302E31
*Aug 27 15:06:19.759 PCTime:    Hostname: elsa
*Aug 27 15:06:19.759 PCTime: DHCP: SRequest - ciaddr: 81.230.121.83
*Aug 27 15:06:19.759 PCTime: DHCP: SRequest: 293 bytes
*Aug 27 15:06:19.759 PCTime: DHCP: SRequest: 293 bytes
*Aug 27 15:06:30.759 PCTime: DHCP: Client socket is closed
*Aug 27 15:10:04.759 PCTime: DHCP: Client socket is opened
*Aug 27 15:10:05.759 PCTime: DHCP: QScan: Renewal..Retrying
*Aug 27 15:10:05.759 PCTime: DHCP: SRequest attempt # 2 for entry:
*Aug 27 15:10:05.759 PCTime: Temp IP addr: 81.230.121.83 for peer on Interface: ATM0.1
*Aug 27 15:10:05.759 PCTime: Temp sub net mask: 255.255.255.192
*Aug 27 15:10:05.759 PCTime:    DHCP Lease server: 213.66.241.86, state: 7 Renewing
*Aug 27 15:10:05.759 PCTime:    DHCP transaction id: 914
*Aug 27 15:10:05.759 PCTime:    Lease: 1200 secs, Renewal: 600 secs, Rebind: 1050 secs
*Aug 27 15:10:05.759 PCTime: Temp default-gateway addr: 81.230.121.65
*Aug 27 15:10:05.759 PCTime:    Next timer fires after: 00:01:53
*Aug 27 15:10:05.759 PCTime:    Retry count: 2   Client-ID: cisco-d48c.b524.7b17-AT0.1
*Aug 27 15:10:05.759 PCTime:    Client-ID hex dump: 636973636F2D643438632E623532342E
*Aug 27 15:10:05.759 PCTime:                        376231372D4154302E31
*Aug 27 15:10:05.759 PCTime:    Hostname: elsa
*Aug 27 15:10:05.759 PCTime: DHCP: SRequest - ciaddr: 81.230.121.83
*Aug 27 15:10:05.759 PCTime: DHCP: SRequest: 293 bytes
*Aug 27 15:10:05.759 PCTime: DHCP: SRequest: 293 bytes
*Aug 27 15:10:16.759 PCTime: DHCP: Client socket is closed
*Aug 27 15:11:57.759 PCTime: DHCP: Client socket is opened
*Aug 27 15:11:58.759 PCTime: DHCP: QScan: Renewal..Retrying
*Aug 27 15:11:58.759 PCTime: DHCP: SRequest attempt # 3 for entry:
As pointed to you in my previous mails renews/packets are being sent and as router is not getting back any reply, lease is timing out and that’s the reason why the interface is getting flapped. You need to find with ISP why the renews and rebind packets are not responded to by Providers DHCP server.
Hope this clarifies your query.
Thanks and regards,
Lijesh

[Q]: Static DHCP Lease with the WRT54GL...

Similar Messages

Maybe you are looking for