DHCPNAK

The following is extracted from my system log file:

Nov 1 11:53:24 laptop dhclient: DHCPREQUEST on eth0 to 255.255.255.255 port 67
Nov 1 11:53:24 laptop dhclient: DHCPNAK from 192.168.1.1
Nov 1 11:53:25 laptop dhclient: DHCPDISCOVER on eth0 to 255.255.255.255 port 67 interval 8
Nov 1 11:53:25 laptop dhclient: DHCPOFFER from 192.168.1.1
Nov 1 11:53:25 laptop dhclient: DHCPREQUEST on eth0 to 255.255.255.255 port 67
Nov 1 11:53:25 laptop dhclient: DHCPACK from 192.168.1.1
Nov 1 11:53:25 laptop dhclient: bound to 192.168.1.3 — renewal in 39303 seconds.

Apparently, my computer tried to renew the IP address from the router, and was rejected. Then my computer started over a new DHCP request, and was offered the same IP.

I found all renewal requests were denied after checking the logs back a few days. I wonder if the router was designed to deny any DHCPREQUEST unless it immediately follows a DHCPOFFER. I can’t figure out any good reason for this. What I could think of is that the firmware programmers were just too lazy to implement a good DHCP server – after all, it was the cheapest wireless router I was able to find…

Tags: DHCP, network

tcpdump

I wanted to find out if remote X creates a lot of network flows, so I logged into a remote computer with “ssh -Y“, started xclock, and then typed tcpdump. Then screen began scrolling up crazily like this:

13:21:00.694367 IP xxx.xxx.xx.xx.45762 > 192.168.1.3.ssh: . ack 60640 win 2003 <nop,nop,timestamp 191668683 75287130>
13:21:00.694430 IP 192.168.1.3.ssh > xxx.xxx.xx.xx.45762: P 70416:70464(48) ack 113 win 501 <nop,nop,timestamp 191668683 75287200>

Was X sending/receiving lots of data even if it seems to be idling? It shouldn’t be so silly.. And… Finally I realized what a big mistake I had made… It was like putting a microphone against a loudspeaker…

---

This work is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License.

Tags: network, SSH, X11

SSH with X

Just successfully started FCITX and typed Chinese in OpenOffice remotely..

X11 forwarding should be first enabled both at the server and client ends.

At the server end, put “X11Forwarding yes” in /etc/ssh/sshd_config, restart SSH daemon and it should be able to forward X11 requests.

At the client end, connect with “ssh -X ” or “ssh -Y ” (if ssh -X fails..). Alternatively, SSH client can be configured to turn on X11 forwarding automatically. Put in /etc/ssh/ssh_config the following lines:

Host *
  ForwardX11 yes
  ForwardX11Trusted yes

The last line is not needed if “ssh -X” works. In some circumstances only “ssh -Y” does, then ForwardX11Trusted is necessary.

ps1. If network is slow, “-C” (compress) may help.
ps2. X must be running with “-nolisten” argument, which (I guess) is the default in most distributions.

---

This work is licensed under a Creative Commons Attribution-Noncommercial-Share Alike 3.0 Unported License.

Tags: network, SSH, X11