In short words i want to present my private Project "Namiono". Namiono is an Service for Network booting (PXE and BSDP). It allows by using Relay Agent Methods to collect Bootservers on PXE requests, runs on Windows and Linux and is including an integrated TFTP Service which supports also Microsoft Features which are used in Windows Server... But Long words… short result…
So like a all in one quick solution for small boxes...
root@fb7360:/mnt/sda1/user-fs/namiono# ./namiono
Namiono-Server 0.5
[I] Starting...
[I] Current Directory is: /mnt/sda1/user-fs/namiono
[I] TFTP-Root Directory is: /mnt/sda1/user-fs/namiono/TFTP_Root
[E] File not found: /mnt/sda1/user-fs/namiono/TFTP_Root/Boot/x86/wdsnbp.com
(Put this file in the expected Directory).
[E] File not found: /mnt/sda1/user-fs/namiono/TFTP_Root/Boot/x64/wdsnbp.com
(Put this file in the expected Directory).
[E] File not found: /mnt/sda1/user-fs/namiono/TFTP_Root/Boot/x86/default.bcd
(Put this file in the expected Directory).
[E] File not found: /mnt/sda1/user-fs/namiono/TFTP_Root/Boot/x64/default.bcd
(Put this file in the expected Directory).
[I] Starting network...
[I] DHCP (Proxy) Listening on 127.0.0.1:67
[I] TFTP Listening on 127.0.0.1:69
[I] BINL Listening on 127.0.0.1:4011
[I] DHCP (Proxy) Listening on 10.20.1.1:67
[I] BINL Listening on 10.20.1.1:4011
[I] TFTP Listening on 10.20.1.1:69
[I] DHCP (Proxy) Listening on 10.20.3.1:67
[I] TFTP Listening on 10.20.2.1:69
[I] DHCP (Proxy) Listening on 10.20.2.1:67
[I] DHCP (Proxy) Listening on 10.20.4.1:67
[I] TFTP Listening on 10.20.3.1:69
[I] BINL Listening on 10.20.2.1:4011
[I] TFTP Listening on 10.20.4.1:69
[I] DHCP (Proxy) Listening on 10.20.5.1:67
[I] BINL Listening on 10.20.4.1:4011
[I] BINL Listening on 10.20.5.1:4011
[I] TFTP Listening on 10.20.5.1:69
[I] DHCP (Proxy) Listening on 10.20.6.1:67
[I] BINL Listening on 10.20.6.1:4011
[I] TFTP Listening on 10.20.6.1:69
[I] DHCP (Proxy) Listening on 90.186.152.237:67
[I] BINL Listening on 90.186.152.237:4011
[I] TFTP Listening on 90.186.152.237:69
[I] DHCP (Proxy) Listening on 10.20.0.12:67
[I] BINL Listening on 10.20.3.1:4011
[I] TFTP Listening on 10.20.0.12:69
[I] BINL Listening on 10.20.0.12:4011
I hope someone can use this and improve the Code or implement new stuff...
Yesterday i improved the support for relaying Packets across Interfaces. by using select() and implementig an ARP Cache. This enables fundermental support for downstream and upstream interfaces. See by our self...
A few days ago implemented select... which enables up and downstream interfaces. At a point on Linux i got the same problem with ISC Relay. The Bug is related to SO_BINDOTODEVICE and on Windows it gives a strange behaver because Winsock does not support BindOnDevice. Thats why we need Up and Downs stream interfaces.
In Namiono each interface with a gateway IP is marked as upstream. so each interface like BR-LAN is downstream. So the Relay component will send DHCP out on each interface to upstream servers. But WAN is also a upstream interface... so here comes routing in play.
While DHCP Clients gets happily its IP Adress from upstream servers... PXE clients will handled differently...
PXE Clients needs in the first phase an DHCP server and also a boot server... While we are also a boot server. the client will never see us. In this case Namiono will relay the PXE requests upstream... and looks in response packets for Option 60 ("PXEClient"). and replaces Option 54 and nextserver to redirect the clients to the box running namiono. This enables us to put settings like multicast configuration in response packets... THEN the RFC says we have to recreate the response packets on relaying ... not simply forwarding!
Additionaly the responding Upstream server with PXE configuration will dynamiclaly added to a list of upstream servers for PXE boot and handed out to the client via PXE boot. This enables us nicely things In this screen the upstream server 10.20.0.1 on remote site which is connected via VPN was dynamicly added to the list of boot servers and the client selected this server to boot...
When we select a server we have 3 methods to boot clients... Multicast, Broadcast and Unicast.
The PXE client is advised at the moment to probe multicast first. So 10.20.0.1 is the selected server and but we got the request and redirect the client to the selected server and relay the response back... and the client begins to boot via multicast... The Multicast (MTFTP Discovery) address was together with the client port injected in one of the offer responses from upstream servers.
Hi, since a few days, the work was going on researching how the WDS server selection works.
It is now fully implemented and together commited with the few other changes.
Clients can now select in WDS which server they want to use.
This WDS Server selection sounds odd because Namiono can also do this by default via RBCP.
A Nice Feature which is in my Mind to implement downstream-servers. This is mainly when we run more than one instances of Namiono in the network. Which affects mainly the bootserver discovery feature when collection all responses.
Also a few changes was made to the TFTP Service which is now more stable and a little bug was fixed when client gets connected to the TFTP service. So the response performance is now more faster. But this was mainly in Multicast.
In this screen the upstream server 10.20.0.1 on remote site which is connected via VPN was dynamicly added to the list of boot servers and the client selected this server to boot...
