[SLOF] [PATCH 0/6] net-snk: More IPv6 fixes and improvements

[Alexey Kardashevskiy]

On 01/14/2016 06:25 PM, Thomas Huth wrote:
> On 14.01.2016 04:42, Alexey Kardashevskiy wrote:
>> On 01/14/2016 10:10 AM, Thomas Huth wrote:
>>> Here are some more bug fixes and improvements for the IPv6 code
>>> in SLOF:
>>> First patch takes care of getting rid of some junk bytes at the
>>> end of IPv6 TFTP packets (similar to the problem I recently fixed
>>> with DHCPv6 packets).
>>> The next two patches are required that SLOF properly sends IPv6
>>> with non-link-local unicast addresses (if available), which is
>>> needed for example if the TFTP server is not on the same link
>>> as the client.
>>> The following patches are minor cleanup and finally a patch that
>>> allows to use stateless address autoconfiguration also when the
>>> TFTP server address and bootfile name have been specified manually.
>>>
>>>    Cheers,
>>>     Thomas
>>>
>>>
>>> Thomas Huth (6):
>>>     net-snk: Remove junk at the end of IPv6 TFTP ACK and error packets
>>>     net-snk: Fix the check for link-local addresses when receiving RAs
>>>     net-snk: Prefer non-link-local unicast IPv6 addresses if possible
>>>     net-snk: Move global variable definition out of the header file
>>>     net-snk: Simplify the ip6_is_multicast() function
>>>     net-snk: Allow stateless autoconfig IPv6 addresses with
>>> IP_INIT_IPV6_MANUAL
>>
>>
>> Thanks, applied.
>>
>> How did you test the 6/6?
>
> So far, it was only possible to do something like this (fec0::2 is the
> TFTP server address):
>
> 0 > load net:ipv6,fec0::2,test.txt,fec0::23
> Trying to load:  from:
> /pci at 800000020000000/ethernet at 0:ipv6,fec0::2,test.txt,fec0::23 ...
>   Initializing NIC
>    Reading MAC address from device: 52:54:00:12:34:56
>    Using IPv6 address: fec0::23
>    Requesting file "test.txt" via TFTP from fec0::2
>    Receiving data:  4 KBytes
>    TFTP: Received test.txt (4 KBytes)
>
> With patch 6, you now can omit the client IPv6 address so that it gets
> created automatically:
>
> 0 > load net:ipv6,fec0::2,test.txt
> Trying to load:  from:
> /pci at 800000020000000/ethernet at 0:ipv6,fec0::2,test.txt ...
>   Initializing NIC
>    Reading MAC address from device: 52:54:00:12:34:56
>    Using IPv6 address: fec0::5254:ff:fe12:3456
>    Requesting file "test.txt" via TFTP from fec0::2
>    Receiving data:  4 KBytes
>    TFTP: Received test.txt (4 KBytes)
>
>> And as I understand, SLOF still cannot get through the default route,
>> only loads an image over tftp if the server is in the same network.
>
> I do not have a network setup to test this, so I don't know ... but in
> case we ever want to get that running, we need non-link-local IPv6
> addresses, too, for sure, so it certainly does not hurt to already
> introduce them now already.


You can create any network setup using virtual bridges and tap networking 
actually.

For my tests I have a virtual bridge which is not connected anywhere, and 3 
guests:

1. "dhcpv6" guest, fc23, one interface, attached to bridge#1, static IP 
(fd00:4149:4b00::1), running dmasq with DHCP on and TFTP off, with RA and 
everything.

2. "tftp" guest, fc23, two interfaces - one is attached to bridge#1 and 
received IPv6 via DHCP (fd00:4149:4b00::bc), another interface is not 
attached anywhere and has a static IP (d00:4149:4b01::1); this guest is 
also running dnsmasq but DHCP is off there and TFTP is on.

3. test guest to boot via IPv6 (so - only SLOF, no disk image or 
initramdisk), one interface, attached to the same bridge, it gets IP over 
DHCP (fd00:4149:4b00:0:c041:49ff:fe4b:5 - which is quite weird but ok) and 
it receives TFTP image name via dhcp6 and tries downloading it but fails.
dnsmasq.conf:
dhcp-option=option6:59,tftp://[fd00:4149:4b01::1]/image.aiktest0


If I move TFTP from 2 to 1 (i.e. from fd00:4149:4b01::1 to 
fd00:4149:4b00::1), then SLOF can download the image and boot.

I tried pinging fd00:4149:4b01::1 from guest#3 (booted it from a disk 
image, received fd00:4149:4b00::bd from dhcp), it worked so routing works 
fine (I added a route and enabled forwarding on guest#1).

It seems that SLOF just fails to use the default route. The code is there, 
just needs some debugging...


-- 
Alexey