Re: [Dnsmasq-discuss] Single-port mode for TFTP

[kvaps]

Simon,

You're amazing, thank you so much!

- kvaps


On Mon, Jan 6, 2020 at 12:06 AM Simon Kelley 
wrote:

> On 30/12/2019 11:51, kvaps wrote:
> > Hi Simon,
> >
> > We're happy to use dnsmasq for organize network booting in Kubernetes,
> > it have everything need: DNS-, DHCP- and TFTP-servers.
> >
> > The only problem is that TFTP protocol in its reference implementation
> > is not working behind the NAT, because always sends reply packets from
> > random port.
> >
> > Note that Kubernetes uses NAT for external services, so it's not
> > possible to run TFTP-server for external clients there. There is one
> > proposed solution for that, it suggests moving away from the RFC and
> > implement --single-port option for always reply from the same port which
> > was requested by the client.
> >
> > In this way, the TFTP-packets can be simple NAT'ed back to the client
> side.
> >
> > Take a look on unique features for go-tftp implementation:
> > https://github.com/vcabbage/go-tftp#unique-features
> >
> > And its command line client:
> > https://github.com/kvaps/trivialt/
> >
> > Best regards
> > - kvaps
> >
> > ___
> > Dnsmasq-discuss mailing list
> > Dnsmasq-discuss@lists.thekelleys.org.uk
> > http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
> >
>
>
> Patch done. --tftp-single-port is an option. I tested with all the
> tftp-clients easily available and it worked fine.
>
>
>
>
> http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=66f62650c353e901264a4cf0729d35dbc0ae284d
>
>
> Simon.
>
>
> ___
> Dnsmasq-discuss mailing list
> Dnsmasq-discuss@lists.thekelleys.org.uk
> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
>
___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

Re: [Dnsmasq-discuss] Single-port mode for TFTP

[Simon Kelley]

On 30/12/2019 11:51, kvaps wrote:
> Hi Simon,
> 
> We're happy to use dnsmasq for organize network booting in Kubernetes,
> it have everything need: DNS-, DHCP- and TFTP-servers.
> 
> The only problem is that TFTP protocol in its reference implementation
> is not working behind the NAT, because always sends reply packets from
> random port.
> 
> Note that Kubernetes uses NAT for external services, so it's not
> possible to run TFTP-server for external clients there. There is one
> proposed solution for that, it suggests moving away from the RFC and
> implement --single-port option for always reply from the same port which
> was requested by the client.
> 
> In this way, the TFTP-packets can be simple NAT'ed back to the client side.
> 
> Take a look on unique features for go-tftp implementation:
> https://github.com/vcabbage/go-tftp#unique-features
> 
> And its command line client:
> https://github.com/kvaps/trivialt/
> 
> Best regards
> - kvaps
> 
> ___
> Dnsmasq-discuss mailing list
> Dnsmasq-discuss@lists.thekelleys.org.uk
> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
> 


Patch done. --tftp-single-port is an option. I tested with all the
tftp-clients easily available and it worked fine.



http://thekelleys.org.uk/gitweb/?p=dnsmasq.git;a=commit;h=66f62650c353e901264a4cf0729d35dbc0ae284d


Simon.


___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

Re: [Dnsmasq-discuss] Single-port mode for TFTP

[Simon Kelley]

On 31/12/2019 08:36, kvaps wrote:
> On Tue, Dec 31, 2019 at 8:45 AM Kurt H Maier  > wrote:
> 
> If you need this kind of functionality in Kubernetes you're much better
> off using a different CNI plugin to manage your networking.  There's no
> inherent NAT requirement imposed by Kubernetes itself.
> 
> 
> This is not about CNI networking, inside cluster tftp is working pretty
> fine.
> This is more about service networking (kube-proxy) and accessing
> services from outside.
> Example: when you need to boot some node, on the early booting stage it
> can't be member of cluster.
> 
> Of course you can use hostNetwork=true, but it is less secure and not
> redundant.
> 
> That approach is dangerously broken.  The transfer IDs and the ports are
> supposed to match; ramming everything over a single port is going to   
> break down when you have a lot of transfers happening simultaneously.
> 
> 
> The packets are always sending to the client specific port. There is no
> put requests.
> What is actually broken? Example tcpdump:
> 
> This is standard mode:
> IP 172.17.0.2.42447 > 172.17.0.1.69:  22 RRQ "/some_file" netascii
> IP 172.17.0.1.56457 > 172.17.0.2.42447: UDP, length 15
> IP 172.17.0.2.42447 > 172.17.0.1.56457: UDP, length 4
> 
> This is single port mode:
> IP 172.17.0.2.56296 > 172.17.0.1.69:  22 RRQ "/some_file" netascii
> IP 172.17.0.1.69 > 172.17.0.2.56296:  15 DATA block 1
> IP 172.17.0.2.56296 > 172.17.0.1.69:  4 ACK block 1
> 
> - kvaps
> 

I think this will work, AS LONG AS the client uses a unique port for
each transfer, which seems likely, since the RFC says it should. Note
that NAT chosing a  unique port ain't enough, the client has to use a
new port for each transfer when it does more that one, to avoid the
possibility of packets getting mixed up. Making the changes to the TFTP
code looks like a bit of a pain, however. It should have a specific
option to enable it, with a big NOT STANDARDS COMPLIANT warning, as you
suggest.

Do you have a patch to try, or do you want me to look at this?


Simon.



> 
> On Tue, Dec 31, 2019 at 8:45 AM Kurt H Maier  > wrote:
> 
> On Mon, Dec 30, 2019 at 12:51:30PM +0100, kvaps wrote:
> >
> > Note that Kubernetes uses NAT for external services, so it's not
> possible
> > to run TFTP-server for external clients there. There is one proposed
> > solution for that, it suggests moving away from the RFC and implement
> > --single-port option for always reply from the same port which was   
> > requested by the client.
> 
> That approach is dangerously broken.  The transfer IDs and the ports are
> supposed to match; ramming everything over a single port is going to   
> break down when you have a lot of transfers happening simultaneously.
> 
> If you need this kind of functionality in Kubernetes you're much better
> off using a different CNI plugin to manage your networking.  There's no
> inherent NAT requirement imposed by Kubernetes itself.
> 
> khm
> 
> 
> ___
> Dnsmasq-discuss mailing list
> Dnsmasq-discuss@lists.thekelleys.org.uk
> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
> 


___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

Re: [Dnsmasq-discuss] Single-port mode for TFTP

[Kurt H Maier]

On Tue, Dec 31, 2019 at 09:36:58AM +0100, kvaps wrote:
> 
> Of course you can use hostNetwork=true, but it is less secure and not
> redundant.

You can also use pipework or just correctly configure your firewall
rules.  Either load the conntrack modules for tftp and nat, or use
additional software to mark the traffic and configure the host system to
permit the marked packets through.

Not sure what you mean about less secure, but redundancy is easy to
achieve with tftp, since it's all udp and you can have more than one
service on hand.  IP migration doesn't do you much good in this case
anywaqy.


> The packets are always sending to the client specific port. There is no put
> requests.
> What is actually broken? Example tcpdump:

The TID in the tftp packets is supposed to match the port it's sending
on.  This is how well-behaving tftp software can verify it's receiving
the correct packets.  The single-port stuff breaks down when, e.g.,
you're booting 1500 computers from a given tftpd.

It's always easier to write new code than to learn the existing tools.
It's just not a sustainable practice, especially when you're violating
standards in the process.

khm

___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

Re: [Dnsmasq-discuss] Single-port mode for TFTP

[kvaps]

On Tue, Dec 31, 2019 at 8:45 AM Kurt H Maier  wrote:

> If you need this kind of functionality in Kubernetes you're much better
> off using a different CNI plugin to manage your networking.  There's no
> inherent NAT requirement imposed by Kubernetes itself.


This is not about CNI networking, inside cluster tftp is working pretty
fine.
This is more about service networking (kube-proxy) and accessing services
from outside.
Example: when you need to boot some node, on the early booting stage it
can't be member of cluster.

Of course you can use hostNetwork=true, but it is less secure and not
redundant.

That approach is dangerously broken.  The transfer IDs and the ports are
> supposed to match; ramming everything over a single port is going to
> break down when you have a lot of transfers happening simultaneously.
>

The packets are always sending to the client specific port. There is no put
requests.
What is actually broken? Example tcpdump:

This is standard mode:
IP 172.17.0.2.42447 > 172.17.0.1.69:  22 RRQ "/some_file" netascii
IP 172.17.0.1.56457 > 172.17.0.2.42447: UDP, length 15
IP 172.17.0.2.42447 > 172.17.0.1.56457: UDP, length 4

This is single port mode:
IP 172.17.0.2.56296 > 172.17.0.1.69:  22 RRQ "/some_file" netascii
IP 172.17.0.1.69 > 172.17.0.2.56296:  15 DATA block 1
IP 172.17.0.2.56296 > 172.17.0.1.69:  4 ACK block 1

- kvaps


On Tue, Dec 31, 2019 at 8:45 AM Kurt H Maier  wrote:

> On Mon, Dec 30, 2019 at 12:51:30PM +0100, kvaps wrote:
> >
> > Note that Kubernetes uses NAT for external services, so it's not possible
> > to run TFTP-server for external clients there. There is one proposed
> > solution for that, it suggests moving away from the RFC and implement
> > --single-port option for always reply from the same port which was
> > requested by the client.
>
> That approach is dangerously broken.  The transfer IDs and the ports are
> supposed to match; ramming everything over a single port is going to
> break down when you have a lot of transfers happening simultaneously.
>
> If you need this kind of functionality in Kubernetes you're much better
> off using a different CNI plugin to manage your networking.  There's no
> inherent NAT requirement imposed by Kubernetes itself.
>
> khm
>
___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

Re: [Dnsmasq-discuss] Single-port mode for TFTP

[Kurt H Maier]

On Mon, Dec 30, 2019 at 12:51:30PM +0100, kvaps wrote:
>
> Note that Kubernetes uses NAT for external services, so it's not possible
> to run TFTP-server for external clients there. There is one proposed
> solution for that, it suggests moving away from the RFC and implement
> --single-port option for always reply from the same port which was   
> requested by the client.
  
That approach is dangerously broken.  The transfer IDs and the ports are
supposed to match; ramming everything over a single port is going to
break down when you have a lot of transfers happening simultaneously.

If you need this kind of functionality in Kubernetes you're much better
off using a different CNI plugin to manage your networking.  There's no
inherent NAT requirement imposed by Kubernetes itself.

khm

___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

Re: [Dnsmasq-discuss] Single-port mode for TFTP

[kvaps]

No, there is need to respond exact from the same port which get an request.
There is no way to configure firewall and use tftp-helper in Kubernetes,
it's environments is very dynamic and might use different backends, eg ipvs
and iptables.

Please read this issue for more information:
https://github.com/kubernetes/kubernetes/issues/26718

On Tue, Dec 31, 2019, 07:20 john doe  wrote:

> On 12/30/2019 6:34 PM, kvaps wrote:
> > On Mon, Dec 30, 2019 at 2:42 PM john doe  wrote:
> >
> >> Isn't the below flag what you want from (1):
> >>
> >> "--tftp-port-range=,
> >> A TFTP server listens on a well-known port (69) for connection
> >> initiation, but it also uses a dynamically-allocated port for each
> >> connection. Normally these are allocated by the OS, but this option
> >> specifies a range of ports for use by TFTP transfers. This can be useful
> >> when TFTP has to traverse a firewall. The start of the range cannot be
> >> lower than 1025 unless dnsmasq is running as root. The number of
> >> concurrent TFTP connections is limited by the size of the port range."
> >>
> >>
> >> 1)  http://www.thekelleys.org.uk/dnsmasq/docs/dnsmasq-man.html
> >>
> >> --
> >> John Doe
> >>
> >
> > Hi John,
> >
> > Unfrtunately it isn't working correctly:
> >
> > if I run dnsmasq with static port range:
> >
> > dnsmasq -d --enable-tftp --tftp-port-range=69,69
> >
> > It reports an error:
> >
> > dnsmasq-tftp: unable to get free port for TFTP
> >
> > when I tries to download any file
> >
>
> You can not specify 69 here, with the current implimentation, you need
> to open an other port for TFTP transfer.
>
> Can't you open two ports?
>
> Have you considered using a TFTP helper in your Firewall?
>
> --
> John Doe
>
> ___
> Dnsmasq-discuss mailing list
> Dnsmasq-discuss@lists.thekelleys.org.uk
> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
>
___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

Re: [Dnsmasq-discuss] Single-port mode for TFTP

[john doe]

On 12/30/2019 6:34 PM, kvaps wrote:
> On Mon, Dec 30, 2019 at 2:42 PM john doe  wrote:
>
>> Isn't the below flag what you want from (1):
>>
>> "--tftp-port-range=,
>> A TFTP server listens on a well-known port (69) for connection
>> initiation, but it also uses a dynamically-allocated port for each
>> connection. Normally these are allocated by the OS, but this option
>> specifies a range of ports for use by TFTP transfers. This can be useful
>> when TFTP has to traverse a firewall. The start of the range cannot be
>> lower than 1025 unless dnsmasq is running as root. The number of
>> concurrent TFTP connections is limited by the size of the port range."
>>
>>
>> 1)  http://www.thekelleys.org.uk/dnsmasq/docs/dnsmasq-man.html
>>
>> --
>> John Doe
>>
>
> Hi John,
>
> Unfrtunately it isn't working correctly:
>
> if I run dnsmasq with static port range:
>
> dnsmasq -d --enable-tftp --tftp-port-range=69,69
>
> It reports an error:
>
> dnsmasq-tftp: unable to get free port for TFTP
>
> when I tries to download any file
>

You can not specify 69 here, with the current implimentation, you need
to open an other port for TFTP transfer.

Can't you open two ports?

Have you considered using a TFTP helper in your Firewall?

--
John Doe

___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

Re: [Dnsmasq-discuss] Single-port mode for TFTP

[kvaps]

> dnsmasq -d --enable-tftp --tftp-port-range=1069,1069

No way, because in this case it should also listen on 1069 port.

- kvaps


On Mon, Dec 30, 2019 at 9:11 PM Geert Stappers  wrote:

> On Mon, Dec 30, 2019 at 06:36:49PM +0100, kvaps wrote:
> > On Mon, Dec 30, 2019 at 2:42 PM john doe  wrote:
> > > Dec 30 2019, kvaps wrote:
> > > >   ...
> > > Isn't the below flag what you want from (1):
> > >
> > > "--tftp-port-range=,
> > > A TFTP server listens on a well-known port (69) for connection
> > > initiation, but it also uses a dynamically-allocated port for each
> > > connection. Normally these are allocated by the OS, but this option
> > > specifies a range of ports for use by TFTP transfers. This can be
> useful
> > > when TFTP has to traverse a firewall. The start of the range cannot be
> > > lower than 1025 unless dnsmasq is running as root. The number of
> > > concurrent TFTP connections is limited by the size of the port range."
> > >
> > >
> > > 1)  http://www.thekelleys.org.uk/dnsmasq/docs/dnsmasq-man.html
> > >
> >
> > Unfortunately it isn't working correctly, if I run dnsmasq with static
> port
> > range:
> >
> > dnsmasq -d --enable-tftp --tftp-port-range=69,69
> >
> > It reports an error:
> >
> > dnsmasq-tftp: unable to get free port for TFTP
> >
> > when I try to download any file from it
> > - kvaps
>
>
> dnsmasq -d --enable-tftp --tftp-port-range=1069,1069
>
> ___
> Dnsmasq-discuss mailing list
> Dnsmasq-discuss@lists.thekelleys.org.uk
> http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss
>
___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

Re: [Dnsmasq-discuss] Single-port mode for TFTP

[Geert Stappers]

On Mon, Dec 30, 2019 at 06:36:49PM +0100, kvaps wrote:
> On Mon, Dec 30, 2019 at 2:42 PM john doe  wrote:
> > Dec 30 2019, kvaps wrote:
> > >   ...
> > Isn't the below flag what you want from (1):
> >
> > "--tftp-port-range=,
> > A TFTP server listens on a well-known port (69) for connection
> > initiation, but it also uses a dynamically-allocated port for each
> > connection. Normally these are allocated by the OS, but this option
> > specifies a range of ports for use by TFTP transfers. This can be useful
> > when TFTP has to traverse a firewall. The start of the range cannot be
> > lower than 1025 unless dnsmasq is running as root. The number of
> > concurrent TFTP connections is limited by the size of the port range."
> >
> >
> > 1)  http://www.thekelleys.org.uk/dnsmasq/docs/dnsmasq-man.html
> >
> 
> Unfortunately it isn't working correctly, if I run dnsmasq with static port
> range:
> 
> dnsmasq -d --enable-tftp --tftp-port-range=69,69
> 
> It reports an error:
> 
> dnsmasq-tftp: unable to get free port for TFTP
> 
> when I try to download any file from it
> - kvaps


dnsmasq -d --enable-tftp --tftp-port-range=1069,1069

___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

Re: [Dnsmasq-discuss] Single-port mode for TFTP

[kvaps]

On Mon, Dec 30, 2019 at 2:42 PM john doe  wrote:

> Isn't the below flag what you want from (1):
>
> "--tftp-port-range=,
> A TFTP server listens on a well-known port (69) for connection
> initiation, but it also uses a dynamically-allocated port for each
> connection. Normally these are allocated by the OS, but this option
> specifies a range of ports for use by TFTP transfers. This can be useful
> when TFTP has to traverse a firewall. The start of the range cannot be
> lower than 1025 unless dnsmasq is running as root. The number of
> concurrent TFTP connections is limited by the size of the port range."
>
>
> 1)  http://www.thekelleys.org.uk/dnsmasq/docs/dnsmasq-man.html
>
> --
> John Doe
>

Hi John,
Unfrtunately it isn't working correctly, if I run dnsmasq with static port
range:

dnsmasq -d --enable-tftp --tftp-port-range=69,69

It reports an error:

dnsmasq-tftp: unable to get free port for TFTP

when I try to download any file from it
- kvaps
___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss

Re: [Dnsmasq-discuss] Single-port mode for TFTP

[john doe]

On 12/30/2019 12:51 PM, kvaps wrote:
> Hi Simon,
>
> We're happy to use dnsmasq for organize network booting in Kubernetes, it
> have everything need: DNS-, DHCP- and TFTP-servers.
>
> The only problem is that TFTP protocol in its reference implementation is
> not working behind the NAT, because always sends reply packets from random
> port.
>
> Note that Kubernetes uses NAT for external services, so it's not possible
> to run TFTP-server for external clients there. There is one proposed
> solution for that, it suggests moving away from the RFC and implement
> --single-port option for always reply from the same port which was
> requested by the client.
>
> In this way, the TFTP-packets can be simple NAT'ed back to the client side.
>
> Take a look on unique features for go-tftp implementation:
> https://github.com/vcabbage/go-tftp#unique-features
>
> And its command line client:
> https://github.com/kvaps/trivialt/
>

Isn't the below flag what you want from (1):

"--tftp-port-range=,
A TFTP server listens on a well-known port (69) for connection
initiation, but it also uses a dynamically-allocated port for each
connection. Normally these are allocated by the OS, but this option
specifies a range of ports for use by TFTP transfers. This can be useful
when TFTP has to traverse a firewall. The start of the range cannot be
lower than 1025 unless dnsmasq is running as root. The number of
concurrent TFTP connections is limited by the size of the port range."


1)  http://www.thekelleys.org.uk/dnsmasq/docs/dnsmasq-man.html

--
John Doe

___
Dnsmasq-discuss mailing list
Dnsmasq-discuss@lists.thekelleys.org.uk
http://lists.thekelleys.org.uk/mailman/listinfo/dnsmasq-discuss