Debug DHCP troubles, see exactly what the DHCP server is sending me

Scenario: Trouble with DHCP on a client machine. User claims that the DHCP server is not sending the right information. Need to see exactly what DHCP server is sending.

System: openSUSE 13.1

Wide-open NAT firewall script using iptables

A couple years ago, I was trying to set up NAT on my home network's firewall/router using iptables, and I was desperate. It seemed that nothing I could do would convince "it" to work. (Hmm, maybe that's why they used to call it a "notwork" on alt.sysadmin.recovery . . . ) In desperation, I posted to a forum and good denizen Sum1 sent me this handy script, which I reproduce here in good will, but without his/her explicit permission:

#!/bin/sh
#
# Sum1's "wide-open, last-resort" NAT firewall
#
# Breathe, step away for a few, have a snack, and let the frustration level
# decline. You are not alone; I definitely know how you feel.
#
# I reserve the following rules for when I face utter frustration and meltdown:

IPTABLES="/usr/sbin/iptables"
LAN_INTERFACE="eth1"
INET_INTERFACE="eth0"
SUBNET1="192.168.0.0/24"

$IPTABLES -t filter -A INPUT -i $LAN_INTERFACE -j ACCEPT
$IPTABLES -t filter -A OUTPUT -o $LAN_INTERFACE -j ACCEPT
$IPTABLES -t filter -A OUTPUT -o $INET_INTERFACE -j ACCEPT
$IPTABLES -t filter -A FORWARD -i $LAN_INTERFACE -s $SUBNET1 -j ACCEPT
$IPTABLES -t filter -A FORWARD -i $LAN_INTERFACE -o $INET_INTERFACE -j ACCEPT
$IPTABLES -t filter -A FORWARD -i $INET_INTERFACE -o $LAN_INTERFACE -j ACCEPT
$IPTABLES -t nat -A POSTROUTING -o $INET_INTERFACE -s $SUBNET1 -j MASQUERADE
echo 1 > /proc/sys/net/ipv4/ip_forward

# Everything is now wide open and this is NOT SECURE, but it should allow
# any/every ethernet device on the subnet to access the internet.
#
# If it works, now add the following rule and see if it still does:

$IPTABLES -t filter -A INPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
$IPTABLES -t filter -A OUTPUT -m state --state ESTABLISHED,RELATED -j ACCEPT
$IPTABLES -t filter -A FORWARD -m state --state RELATED,ESTABLISHED -j ACCEPT

# If you still cannot ping eth1, eth0, and also your primary DNS address, then
# there's more issues to address like static ip's, dhcp servers, and icmp
# stuff.

By the way, the solution to my problem was hinted at in Sum1's last sentence - the problem with the NAT setup was not in the iptables script at all, it was in the DHCP server configuration. It's all inter-related, you see.

DHCP via dnsmasq: client machine not receiving nameserver

Last night I set up dnsmasq on the Western Digital My Book World Edition, a NAS that acts as a server at our home.

I ran up against a problem: one of the client machine (my laptop) was not changing its nameserver settings. It would get an IP address via DHCP just fine, but the nameserver settings were either not being transmitted or not being received properly.

If I had been in my right mind, I would have tried a different machine as client to find out if the problem was on the server side or on the client side. As it stood, I kept examining the server side, but found nothing wrong there.

Nevertheless, it eventually occurred to my clouded mind that I could look in the log on the client side. Eureka!

Nov 17 20:45:34 r400 dns-resolver: ATTENTION: You have modified 
/etc/resolv.conf. Leaving it untouched...
Nov 17 20:45:34 r400 dns-resolver: You can find my version in 
/etc/resolv.conf.netconfig

True, I had modified /etc/resolv.conf -- no argument there. And when I looked in /etc/resolv.conf.netconfig, I saw that the nameserver settings from dnsmasq were there, but of course ineffectual.

The problem went away when I deleted /etc/resolv.conf (my modified version) and then disconnected/reconnected the network cable to the laptop. This let NetworkManager did its thing. After that, a new /etc/resolv.conf appeared with the correct nameserver settings.