DHCP Offer on vlan1 (WAN) not correctly handled with WRT54-GL and build 54 http://tomatousb.org/forum/t-295069/dhcp-offer-on-vlan1-wan-not-correctly-handled-with-wrt54-gl Posts in the discussion thread "DHCP Offer on vlan1 (WAN) not correctly handled with WRT54-GL and build 54" Sat, 25 May 2013 05:58:03 +0000 http://tomatousb.org/forum/t-295069#post-1530528 Re: DHCP Offer on vlan1 (WAN) not correctly handled with WRT54-GL and build 54 http://tomatousb.org/forum/t-295069/dhcp-offer-on-vlan1-wan-not-correctly-handled-with-wrt54-gl#post-1530528 Tue, 07 Aug 2012 21:35:09 +0000 hgratp 1415284 I am having a similar problem, more specifically with setting my router as DMZ on a att uverse gateway. The router is assigned an ip address but the lease time is limited to 10 minutes. I added the iptable rule but that did not change the results. I also noticed that my router accepts input from any source to port 68 on the default setting so I do not think adding the rule has an effect anyways.

I do not know if this is an issue with iptables or dnsmasq, etc. From what I read in different forums people have similar problems with ddwrt, some resolved the issue with the iptables rule mentioned above.

I am running 1.28.8754 ND vpn3.6 on a Linksys WRT54GL.

]]> http://tomatousb.org/forum/t-295069#post-962514 DHCP Offer on vlan1 (WAN) not correctly handled with WRT54-GL and build 54 http://tomatousb.org/forum/t-295069/dhcp-offer-on-vlan1-wan-not-correctly-handled-with-wrt54-gl#post-962514 Sun, 02 Jan 2011 04:19:31 +0000 Aliona 663906 When comparing the output of tcpdump on the router with vanilla Tomato Firmware v1.28.1816 and Tomato Firmware v1.28.8754 ND vpn3.6 (Linux kernel 2.4.37.10) it becomes evident that the DHCP Offer on vlan1 (WAN) is not correctly handled by build 54 of TomatoUSB since the router continues to send DHCP Requests to the identified DHCP-server with the offered IP-address.

Reference: Output of tcpdump

The problem does not exist in Tomato Firmware v1.28.1816 or dd-wrt v24 preSP2 VPN Generic build 14896 and is not resolved by erasing NVRAM or selecting/deselecting “Reduce packet size” for “DHCP Client (WAN)” or using a different hostname or entering the following rule for iptables:
iptables -I INPUT -p UDP -i vlan1 —dport 68 —sport 67 -j ACCEPT

No dropped packets are logged, however the problem described above, as seen in the packet dump, can also be observed in the output of the loggfile:
Dec 31 16:17:26 unknown daemon.info udhcpc[771]: Sending discover…
Dec 31 16:17:26 unknown daemon.info udhcpc[771]: Sending select for 213.103.xxx.xxx…
Dec 31 16:17:29 unknown daemon.info udhcpc[771]: Sending select for 213.103.xxx.xxx…
Dec 31 16:17:32 unknown daemon.info udhcpc[771]: Sending select for 213.103.xxx.xxx…
Dec 31 16:17:35 unknown daemon.info udhcpc[771]: Sending select for 213.103.xxx.xxx…
Dec 31 16:17:38 unknown daemon.info udhcpc[771]: Sending select for 213.103.xxx.xxx…
Dec 31 16:17:41 unknown daemon.info udhcpc[771]: No lease, forking to background
Dec 31 16:18:01 unknown daemon.info udhcpc[876]: Sending discover…
Dec 31 16:18:01 unknown daemon.info udhcpc[876]: Sending select for 213.103.xxx.xxx…
Dec 31 16:18:04 unknown daemon.info udhcpc[876]: Sending select for 213.103.xxx.xxx…
Dec 31 16:18:07 unknown daemon.info udhcpc[876]: Sending select for 213.103.xxx.xxx…
Dec 31 16:18:10 unknown daemon.info udhcpc[876]: Sending select for 213.103.xxx.xxx…
Dec 31 16:18:13 unknown daemon.info udhcpc[876]: Sending select for 213.103.xxx.xxx…

Any help to resolve this issue would be greatly appreciated.

]]>