Finisterre
Professional
I noticed that nearly every tutorial for Netbooting demands that you use a static IP, I could never figure out why. I assumed after my first attempt failed to obtain an IP address somewhere along the line someone had a similar experience, and it was just solidified into the community Gospel on how things are done. Additionally the PiForceTools pretty well say it has to be done this way as well. Given that the bulk of the community uses this tool, the "use a static IP" meme seems to have obvious roots.
https://github.com/travistyoj/pifor...6328#diff-04c6e90faac2675aa89e2176d2eec7d8R24
"The netdimm will need to be configured in static mode with an IP address of 192.168.1.2, netmask of 255.255.255.0, and gateway of 192.168.1.1"
My brain really wanted to know why my Naomi was refusing to take a DHCP address from my router. The solution was for me to break out a sniffer to figure out what was up. I basically noticed the RFC1048 (BOOTP) support on my router sucked! My ATT uverse router is simply unable to provide BOOTP responses in RFC 1048 format.
This is what a *successful* DHCP reply bound for a Naomi looks like in tcpdump, you can clearly see the Vendor-rfc1048 Extensions are enabled in the packet request. Additionally you can see the "Option 3" and "Option 6" settings are provided to enable a working DNS server, and Gateway address.
21:15:01.264514 IP (tos 0xc0, ttl 64, id 64036, offset 0, flags [none], proto UDP (17), length 32
10.0.0.254.bootps > 10.0.0.5.bootpc: BOOTP/DHCP, Reply, length 300, xid 0xc3b330d7, Flags [none]
Your-IP 10.0.0.5
Server-IP 10.0.0.254
Client-Ethernet-Address 00:d0:f1:01:de:56 (oui Unknown)
Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message Option 53, length 1: ACK
Server-ID Option 54, length 4: 10.0.0.254
Lease-Time Option 51, length 4: 3600
RN Option 58, length 4: 1800
RB Option 59, length 4: 3150
Subnet-Mask Option 1, length 4: 255.255.255.0
BR Option 28, length 4: 10.0.0.255
Default-Gateway Option 3, length 4: 10.0.0.254
Domain-Name-Server Option 6, length 4: 10.0.0.254
If you want your Naomi to be on the network after making a "REMOTE" DHCP/BOOTP request, your router will need to support it, or you will need to add an alternate DHCP server on your LAN like I have. In order to replicate a good response in an environment where your normal router refuses to play along, you can simply make use of the dnsmasq tool. http://www.thekelleys.org.uk/dnsmasq/doc.html
Keep in mind that you can only have one DHCP server present on your network, so this setup will replace your current one, or you'll need to keep this semi isolated.
To follow these steps it is assumed that you are working with a *clean* system. Make sure /etc/dnsmasq.conf is empty, or it will be merged with your command line options
(alternately you could use a config file with the options that are worked out below, this is an exercise for the reader however)
The first thing you need to do is add an entry to your hosts file so that the NaomiNet address in Japan can be resolved by the Network Test utility. You can also add hostnames for your DHCP pool if you wish.
# cat /etc/hosts
127.0.0.1 localhost
127.0.1.1 dev0
192.168.1.54 naomi1
192.168.1.55 naomi2
192.168.1.253 naominet.jp
It is also desirable to make sure that your own /etc/resolv.conf isn't pointing to your own machine for resolutions. If it is, you may find that dnsmasq is overloaded by internal network services like ntpd looking for their address. You'll also want dnsmask to have a proper resolve.conf to access so it can forward DNS requests for the rest of your network.
In my /etc/rc.local I add the following line to start dnsmasq.
dnsmasq --interface=enp3s0 --except-interface=lo --bind-interfaces --dhcp-range=192.168.1.1,192.168.1.200,255.255.255.0,1h --dhcp-option=6,192.168.1.252,209.143.0.10 --dhcp-option=3,192.168.1.254 --log-dhcp -q --dns-forward-max=9000 -d &
Once the service has started (in this case you'd need to reboot so rc.local will kick in) If you watch the log file (/var/log/syslog) you can see your Naomi's make DHCP requests, and confirm that they were indeed issued addresses. You will need to Power cycle Naomi, go into Network Settings, set it to "Remote", and then reboot.
the logs are shown below:
dnsmasq: started, version 2.75 cachesize 150
dnsmasq: compile time options: IPv6 GNU-getopt DBus i18n IDN DHCP DHCPv6 no-Lua TFTP conntrack ipset auth DNSSEC loop-detect inotify
dnsmasq-dhcp: DHCP, IP range 192.168.1.9 -- 192.168.1.10, lease time 1h
dnsmasq: reading /etc/resolv.conf
dnsmasq: using nameserver 127.0.1.1#53
dnsmasq: read /etc/hosts - 12 addresses
dnsmasq-dhcp: 3451072727 available DHCP range: 192.168.1.9 -- 192.168.1.10
dnsmasq-dhcp: 3283300567 DHCPREQUEST(eno1) 192.168.1.9 00:d0:f1:01:de:56
dnsmasq-dhcp: 3283300567 tags: eno1
dnsmasq-dhcp: 3283300567 DHCPACK(eno1) 192.168.1.9 00:d0:f1:01:de:56
dnsmasq-dhcp: 3283300567 requested options: 1:netmask, 28:broadcast, 3:router, 6:dns-server
dnsmasq-dhcp: 3283300567 next server: 192.168.1.253
dnsmasq-dhcp: 3283300567 sent size: 1 option: 53 message-type 5
dnsmasq-dhcp: 3283300567 sent size: 4 option: 54 server-identifier 192.168.1.253
dnsmasq-dhcp: 3283300567 sent size: 4 option: 51 lease-time 1h
dnsmasq-dhcp: 3283300567 sent size: 4 option: 58 T1 30m
dnsmasq-dhcp: 3283300567 sent size: 4 option: 59 T2 52m30s
dnsmasq-dhcp: 3283300567 sent size: 4 option: 1 netmask 255.255.255.0
dnsmasq-dhcp: 3283300567 sent size: 4 option: 28 broadcast 192.168.1.255
dnsmasq-dhcp: 3283300567 sent size: 4 option: 3 router 192.168.1.253
dnsmasq-dhcp: 3283300567 sent size: 4 option: 6 dns-server 192.168.1.253
The Network Test utility will attempt to resolve a specific web domain, and subsequently make an HTTP get request looking for the words "naomi ok". You can easily spoof this response locally so that no real internet connectivity is required.
dnsmasq: query[A] naominet.jp from 192.168.1.9
dnsmasq: /etc/hosts naominet.jp is 192.168.1.253
dnsmasq: query[PTR] 253.1.168.192.in-addr.arpa from 192.168.1.9
dnsmasq: /etc/hosts 192.168.1.253 is naominet.jp
The dnsmasq tool will respond with the IP that you provide, so if you wish to spoof this locally you can use something like Python, and a simple html file.
# cat > naomitest.html
naomi ok
^C
# python -m SimpleHTTPServer 80
Serving HTTP on 0.0.0.0 port 80 ...
192.168.1.9 - - [18/Jun/2018 01:26:01] "GET /naomitest.html HTTP/1.0" 200 -
Power the cycle Naomi again, go into Network Settings, choose Network Test
You will get back a "GOOD" report.
If you were to sniff the session as it occurred, it would look something like this:
To script this response I add the following to my /etc/rc.local file
cd /tmp; echo "naomi ok" > naomitest.html;python -m SimpleHTTPServer 80&
At this point after one more reboot you can use Netboot utilities as you would expect, but in this case with DHCP based machines.
If you need to know the addresses that the Naomi's have obtained you can check the leases file at /var/lib/misc/dnsmasq.leases
# cat /var/lib/misc/dnsmasq.leases
1532201849 00:d0:f1:01:de:56 192.168.1.96 * 01:00:d0:f1:01:de:56
After my DHCP requests are successful, my Naomi's now have the proper IP and gateway, and I am able to push a ROM out from a remote internet based server with the help of some port forwarding on my router:
root@debian:/var/www/RomBINS# time ./naomi_netboot_upload/netboot_upload_tool 1.2.3.4 MarvelVsCapcom2_unlocked.bin
Received: '0x04 0x00 0xffffff81 0x07 0x01 0x00 0x00 0x00 '
Uploading...
Address at: 0889b600
closing netboot tool
real 2m41.261s
user 0m2.876s
sys 0m0.304s
I needed to sort this out for my attempts to work with Netbooting across the internet as it is not desirable to manage a pool of static addresses at potentially remote locations. I hope it is useful info for some of you.
https://github.com/travistyoj/pifor...6328#diff-04c6e90faac2675aa89e2176d2eec7d8R24
"The netdimm will need to be configured in static mode with an IP address of 192.168.1.2, netmask of 255.255.255.0, and gateway of 192.168.1.1"
My brain really wanted to know why my Naomi was refusing to take a DHCP address from my router. The solution was for me to break out a sniffer to figure out what was up. I basically noticed the RFC1048 (BOOTP) support on my router sucked! My ATT uverse router is simply unable to provide BOOTP responses in RFC 1048 format.
This is what a *successful* DHCP reply bound for a Naomi looks like in tcpdump, you can clearly see the Vendor-rfc1048 Extensions are enabled in the packet request. Additionally you can see the "Option 3" and "Option 6" settings are provided to enable a working DNS server, and Gateway address.
21:15:01.264514 IP (tos 0xc0, ttl 64, id 64036, offset 0, flags [none], proto UDP (17), length 32
10.0.0.254.bootps > 10.0.0.5.bootpc: BOOTP/DHCP, Reply, length 300, xid 0xc3b330d7, Flags [none]
Your-IP 10.0.0.5
Server-IP 10.0.0.254
Client-Ethernet-Address 00:d0:f1:01:de:56 (oui Unknown)
Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message Option 53, length 1: ACK
Server-ID Option 54, length 4: 10.0.0.254
Lease-Time Option 51, length 4: 3600
RN Option 58, length 4: 1800
RB Option 59, length 4: 3150
Subnet-Mask Option 1, length 4: 255.255.255.0
BR Option 28, length 4: 10.0.0.255
Default-Gateway Option 3, length 4: 10.0.0.254
Domain-Name-Server Option 6, length 4: 10.0.0.254
If you want your Naomi to be on the network after making a "REMOTE" DHCP/BOOTP request, your router will need to support it, or you will need to add an alternate DHCP server on your LAN like I have. In order to replicate a good response in an environment where your normal router refuses to play along, you can simply make use of the dnsmasq tool. http://www.thekelleys.org.uk/dnsmasq/doc.html
Keep in mind that you can only have one DHCP server present on your network, so this setup will replace your current one, or you'll need to keep this semi isolated.
To follow these steps it is assumed that you are working with a *clean* system. Make sure /etc/dnsmasq.conf is empty, or it will be merged with your command line options
(alternately you could use a config file with the options that are worked out below, this is an exercise for the reader however)
The first thing you need to do is add an entry to your hosts file so that the NaomiNet address in Japan can be resolved by the Network Test utility. You can also add hostnames for your DHCP pool if you wish.
# cat /etc/hosts
127.0.0.1 localhost
127.0.1.1 dev0
192.168.1.54 naomi1
192.168.1.55 naomi2
192.168.1.253 naominet.jp
It is also desirable to make sure that your own /etc/resolv.conf isn't pointing to your own machine for resolutions. If it is, you may find that dnsmasq is overloaded by internal network services like ntpd looking for their address. You'll also want dnsmask to have a proper resolve.conf to access so it can forward DNS requests for the rest of your network.
In my /etc/rc.local I add the following line to start dnsmasq.
dnsmasq --interface=enp3s0 --except-interface=lo --bind-interfaces --dhcp-range=192.168.1.1,192.168.1.200,255.255.255.0,1h --dhcp-option=6,192.168.1.252,209.143.0.10 --dhcp-option=3,192.168.1.254 --log-dhcp -q --dns-forward-max=9000 -d &
Once the service has started (in this case you'd need to reboot so rc.local will kick in) If you watch the log file (/var/log/syslog) you can see your Naomi's make DHCP requests, and confirm that they were indeed issued addresses. You will need to Power cycle Naomi, go into Network Settings, set it to "Remote", and then reboot.
the logs are shown below:
dnsmasq: started, version 2.75 cachesize 150
dnsmasq: compile time options: IPv6 GNU-getopt DBus i18n IDN DHCP DHCPv6 no-Lua TFTP conntrack ipset auth DNSSEC loop-detect inotify
dnsmasq-dhcp: DHCP, IP range 192.168.1.9 -- 192.168.1.10, lease time 1h
dnsmasq: reading /etc/resolv.conf
dnsmasq: using nameserver 127.0.1.1#53
dnsmasq: read /etc/hosts - 12 addresses
dnsmasq-dhcp: 3451072727 available DHCP range: 192.168.1.9 -- 192.168.1.10
dnsmasq-dhcp: 3283300567 DHCPREQUEST(eno1) 192.168.1.9 00:d0:f1:01:de:56
dnsmasq-dhcp: 3283300567 tags: eno1
dnsmasq-dhcp: 3283300567 DHCPACK(eno1) 192.168.1.9 00:d0:f1:01:de:56
dnsmasq-dhcp: 3283300567 requested options: 1:netmask, 28:broadcast, 3:router, 6:dns-server
dnsmasq-dhcp: 3283300567 next server: 192.168.1.253
dnsmasq-dhcp: 3283300567 sent size: 1 option: 53 message-type 5
dnsmasq-dhcp: 3283300567 sent size: 4 option: 54 server-identifier 192.168.1.253
dnsmasq-dhcp: 3283300567 sent size: 4 option: 51 lease-time 1h
dnsmasq-dhcp: 3283300567 sent size: 4 option: 58 T1 30m
dnsmasq-dhcp: 3283300567 sent size: 4 option: 59 T2 52m30s
dnsmasq-dhcp: 3283300567 sent size: 4 option: 1 netmask 255.255.255.0
dnsmasq-dhcp: 3283300567 sent size: 4 option: 28 broadcast 192.168.1.255
dnsmasq-dhcp: 3283300567 sent size: 4 option: 3 router 192.168.1.253
dnsmasq-dhcp: 3283300567 sent size: 4 option: 6 dns-server 192.168.1.253
The Network Test utility will attempt to resolve a specific web domain, and subsequently make an HTTP get request looking for the words "naomi ok". You can easily spoof this response locally so that no real internet connectivity is required.
dnsmasq: query[A] naominet.jp from 192.168.1.9
dnsmasq: /etc/hosts naominet.jp is 192.168.1.253
dnsmasq: query[PTR] 253.1.168.192.in-addr.arpa from 192.168.1.9
dnsmasq: /etc/hosts 192.168.1.253 is naominet.jp
The dnsmasq tool will respond with the IP that you provide, so if you wish to spoof this locally you can use something like Python, and a simple html file.
# cat > naomitest.html
naomi ok
^C
# python -m SimpleHTTPServer 80
Serving HTTP on 0.0.0.0 port 80 ...
192.168.1.9 - - [18/Jun/2018 01:26:01] "GET /naomitest.html HTTP/1.0" 200 -
Power the cycle Naomi again, go into Network Settings, choose Network Test
You will get back a "GOOD" report.
If you were to sniff the session as it occurred, it would look something like this:
Code:
# tcpdump -vvnni eno1 ether host 00:d0:f1:01:de:56 or ether host 00:d0:f1:01:44:65
01:26:00.941899 IP (tos 0x0, ttl 64, id 64, offset 0, flags [none], proto ICMP (1), length 84)
192.168.1.9 > 192.168.1.253: ICMP echo request, id 38982, seq 0, length 64
01:26:00.941942 IP (tos 0x0, ttl 64, id 17816, offset 0, flags [none], proto ICMP (1), length 84)
192.168.1.253 > 192.168.1.9: ICMP echo reply, id 38982, seq 0, length 64
01:26:00.942532 IP (tos 0x0, ttl 64, id 66, offset 0, flags [none], proto UDP (17), length 72)
192.168.1.9.1028 > 192.168.1.253.53: [udp sum ok] 4+ PTR? 253.1.168.192.in-addr.arpa. (44)
01:26:00.942827 IP (tos 0x0, ttl 64, id 442, offset 0, flags [DF], proto UDP (17), length 97)
192.168.1.253.53 > 192.168.1.9.1028: [bad udp cksum 0x84b5 -> 0x4a49!] 4* q: PTR? 253.1.168.192.in-addr.arpa. 1/0/0 253.1.168.192.in-addr.arpa. PTR naominet.jp. (69)
01:26:00.944371 IP (tos 0x0, ttl 64, id 68, offset 0, flags [none], proto UDP (17), length 57)
192.168.1.9.1029 > 192.168.1.253.53: [udp sum ok] 5+ A? naominet.jp. (29)
01:26:00.944694 IP (tos 0x0, ttl 64, id 443, offset 0, flags [DF], proto UDP (17), length 73)
192.168.1.253.53 > 192.168.1.9.1029: [bad udp cksum 0x849d -> 0x12ca!] 5* q: A? naominet.jp. 1/0/0 naominet.jp. A 192.168.1.253 (45)
01:26:01.943603 IP (tos 0x0, ttl 64, id 70, offset 0, flags [none], proto TCP (6), length 60)
192.168.1.9.1028 > 192.168.1.253.80: Flags [S], cksum 0xd00d (correct), seq 2219461053, win 8192, options [mss 1460,nop,wscale 0,nop,nop,TS val 1096 ecr 0], length 0
01:26:01.943657 IP (tos 0x0, ttl 64, id 0, offset 0, flags [DF], proto TCP (6), length 60)
192.168.1.253.80 > 192.168.1.9.1028: Flags [S.], cksum 0x8485 (incorrect -> 0xc83c), seq 4286681853, ack 2219461054, win 28960, options [mss 1460,nop,nop,TS val 275977126 ecr 1096,nop,wscale 7], length 0
01:26:01.944072 IP (tos 0x0, ttl 64, id 72, offset 0, flags [none], proto TCP (6), length 40)
192.168.1.9.1028 > 192.168.1.253.80: Flags [.], cksum 0xa6a0 (correct), seq 1, ack 1, win 8192, length 0
01:26:01.944383 IP (tos 0x0, ttl 64, id 74, offset 0, flags [none], proto TCP (6), length 72)
192.168.1.9.1028 > 192.168.1.253.80: Flags [P.], cksum 0x01e2 (correct), seq 1:33, ack 1, win 8192, length 32: HTTP, length: 32
GET /naomitest.html HTTP/1.0
01:26:01.944411 IP (tos 0x0, ttl 64, id 51658, offset 0, flags [DF], proto TCP (6), length 52)
192.168.1.253.80 > 192.168.1.9.1028: Flags [.], cksum 0x847d (incorrect -> 0x6425), seq 1, ack 33, win 227, options [nop,nop,TS val 275977126 ecr 1096], length 0
01:26:01.944965 IP (tos 0x0, ttl 64, id 51659, offset 0, flags [DF], proto TCP (6), length 69)
192.168.1.253.80 > 192.168.1.9.1028: Flags [P.], cksum 0x848e (incorrect -> 0xa447), seq 1:18, ack 33, win 227, options [nop,nop,TS val 275977126 ecr 1096], length 17: HTTP, length: 17
HTTP/1.0 200 OK
01:26:01.945337 IP (tos 0x0, ttl 64, id 51660, offset 0, flags [DF], proto TCP (6), length 228)
192.168.1.253.80 > 192.168.1.9.1028: Flags [FP.], cksum 0x852d (incorrect -> 0xce3a), seq 18:194, ack 33, win 227, options [nop,nop,TS val 275977126 ecr 1096], length 176: HTTP
01:26:01.945368 IP (tos 0x0, ttl 64, id 76, offset 0, flags [none], proto TCP (6), length 40)
192.168.1.9.1028 > 192.168.1.253.80: Flags [.], cksum 0xa66f (correct), seq 33, ack 18, win 8192, length 0
01:26:01.946003 IP (tos 0x0, ttl 64, id 78, offset 0, flags [none], proto TCP (6), length 40)
192.168.1.9.1028 > 192.168.1.253.80: Flags [.], cksum 0xa66e (correct), seq 33, ack 195, win 8016, length 0
01:26:02.944110 IP (tos 0x0, ttl 64, id 80, offset 0, flags [none], proto TCP (6), length 40)
192.168.1.9.1028 > 192.168.1.253.80: Flags [F.], cksum 0xa5bd (correct), seq 33, ack 195, win 8192, length 0
01:26:02.944153 IP (tos 0x0, ttl 64, id 10413, offset 0, flags [DF], proto TCP (6), length 52)
192.168.1.253.80 > 192.168.1.9.1028: Flags [.], cksum 0x6268 (correct), seq 195, ack 34, win 227, options [nop,nop,TS val 275977376 ecr 1096], length 0cd /tmp; echo "naomi ok" > naomitest.html;python -m SimpleHTTPServer 80&
At this point after one more reboot you can use Netboot utilities as you would expect, but in this case with DHCP based machines.
If you need to know the addresses that the Naomi's have obtained you can check the leases file at /var/lib/misc/dnsmasq.leases
# cat /var/lib/misc/dnsmasq.leases
1532201849 00:d0:f1:01:de:56 192.168.1.96 * 01:00:d0:f1:01:de:56
After my DHCP requests are successful, my Naomi's now have the proper IP and gateway, and I am able to push a ROM out from a remote internet based server with the help of some port forwarding on my router:
root@debian:/var/www/RomBINS# time ./naomi_netboot_upload/netboot_upload_tool 1.2.3.4 MarvelVsCapcom2_unlocked.bin
Received: '0x04 0x00 0xffffff81 0x07 0x01 0x00 0x00 0x00 '
Uploading...
Address at: 0889b600
closing netboot tool
real 2m41.261s
user 0m2.876s
sys 0m0.304s
I needed to sort this out for my attempts to work with Netbooting across the internet as it is not desirable to manage a pool of static addresses at potentially remote locations. I hope it is useful info for some of you.
Last edited:
