Error: linux/config.h: No such file or directory 錯誤

According to this guy,

http://allanh.pixnet.net/blog/post/36588057-%5Bubuntu%5D--error%3A-linux-config.h%3A-no-such-file-or-directory

 linux have remove linux/config.h since version 2.6.19, replace with linux/autoconf.h.

In order to solve this problem, we just need to replace linux/config.h to linux/autoconf.h

Done! easy.

Installing PPPOE server on linux system with VM. 利用VM在linux系統上安裝 PPPOE server

1. install

apt-get install ppp
apt-get install pppoe

or

yum install ppp
yum install pppoe

2. config

#if there is no /etc/ppp/pppoe-server-options
cp /etc/ppp/options /etc/ppp/pppoe-server-options

you can see detail configs in http://wayne0225.blogspot.tw/2012/07/pppoe-server-on-ubuntu.html

3. Execute

#*** need to execute every time when you reboot
# config distributed address, # eth0 is the nic which client will dial in.
pppoe-server -I eth0 -L 192.168.1.1 -R 192.168.1.10-200
# -L IP : interface's ip (gateway)
# -R IP: distributed ip range

# enable the fordwarding function on your linux system
echo "1">/proc/sys/net/ipv4/ip_forward

porting packet to internet accessable nics
# eth0 is your outgoing interface
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE

4.with VM

Sometimes you want to test your cpe's pppoe function but with the ISP's corporation, and VM is easy accessible, portable and easy recovery tool. Below, I use vmware as my virtualization tool.

first topology (not working)

My purpose is start two vm, vm1 as pppoe server with nat, vm2 as client, vm1 has two nics, first nic for internet access throught the vm's nat, the second nic used to connected with vm2.

But I found that the packet from vm2 can't go throught the VM NAT, it will be blocked, and I don't know why.

Using real nic as nat server despite vm's nat function (working)

So, I use my physical nic's nat function, and bridge VM1 NIC1 to host pc's NIC2, and it works, the packet can go through now, it's weird, but it works.

5. Trouble shooting:

if your packet is blocking by firewall, clear iptables first
iptables -F
iptables -X
iptables -Z

Interesting DHCP offer packet. 有趣的 DHCP offer 封包

當我在研究DHCP協定時，我參考了wikipedia的DHCP頁面:
http://en.wikipedia.org/wiki/Dynamic_Host_Configuration_Protocol
其中我發現一件奇怪的事，DHCP Offer 封包的 Destination 竟然是 255.255.255.255 (Broadcast)
這一點Sense都沒有，因為在 Discover 的時候 Server 就知道 Client 的 MAC Address了，沒理由要Broadcast。

When I was studying dchp protocol, I look wikipedia's dhcp page for reference:
http://en.wikipedia.org/wiki/Dynamic_Host_Configuration_Protocol
And i found something weired, on wiki's description, the destination field in dhcp offer is 255.255.255.255. It makes no sence. Because on the first step DHCP discover, the server already knew client's MAC address, there is no reason to broadcast the packet.

wiki 中 dhcp offer 的描述 (2014/02/14)
the dhcp offer description on wiki page

根據wiki中的描述我們可以確定的是，在 offer 的封包中底層的欄位有填入 client 的 MAC，這表示在 Ethernet 是 unicast，ip 是 broadcast，那實際上他到底會跑 broadcast or unicast ? 這是一個很有趣的問題，我們來做實驗看看：

According to wiki's description, we can be sure, the lower layer's field filled by client's MAC, it means it's unicast on Ethernet layer, and broadcast on ip layer. So, which one will happened in reality? broadcast or unicast? Let's take a experiment.

實際用wireshark觀察的dhcp封包 (圖有點小 sorry)
actual dhcp packet captured by wireshark

在實際的實驗中，我們可以看到 destination 欄位並不是填255，而是填 server 分配的ip位置，這表示wiki寫錯了嗎？經過網路上的搜尋以及詢問專家之後，得到的答案是：

destination填255 or 分配的 ip 位置都是可行的，因為在實作上，會先看Ethernet的封包，所以說ip位置並不會影響(可不可以亂填我就不知道了)，但是目前的做法很少會採用wiki那種填255的作法。

On the experiment, we can see the destination field is not 255.255.255.255, it's the ip address whcih server distributed to client. Dose it mean wiki is wrong? After I search through the internet and asking to experts, I got the answer: No matter the destination field is 255.255.255.255 or the distributed ip address by server is correct, because in the implementation, the Ethernet packet will be read first, so the ipaddress doesn't affect the packet's type.