bios   1   2   3   4   5   6   7   8   9   10   11   12

Dial-on-demand users should know:

From Richard Greaney

More Answers by Mike Orr, Jim Dennis, Willy Tareau, David Forrest, Juanjo and Erik Corry

If you are on a dial-up connection and are tired of not getting reliable starts to your connection (often having to click "refresh" after starting a browser to prevent it from timing out) you may benefit from this piece of advice.

There are two ways Linux looks up a host before connecting. One uses the traditional gethostbyname() function (which uses DNS and hence UDP) while the other uses a straight lookup on the IP address. Either way, if you use a demand dial setup, these will run into problems. If you type ifconfig before you get connected, you will notice your ppp0 adapter has the address 10.64.64.64. Once you are connected, it becomes a little more beleivable. However, those first lookup SYN packets are sent from 10.64.64.64, but since the ppp interface has changed it's IP address, the packets will not reach it. Refreshing the connection attempt will work, but it's less than elegant.

How to fix: cat /proc/sys/net/ipv4/ip_dynaddr should return the value '1'. If this is not the case, type (as root) echo 1 > /proc/sys/net/ipv4/ip_dynaddr

What you are doing is telling your machine that it has a dynamic IP address. Any packets which are originally sent from 10.64.64.64 will be redirected to the new IP address as soon as you get connected to your ISP.

Richard Greaney

[Mike] Thanks for the advice. Why do people need to do this now? When I used to have a dynamic IP address three years ago, I never needed to do this.

That one I can't answer. I've built a few Linux boxes in my time and not one of them has had anything other than 0 set for the ip_dynaddr field. Having said that, they were very seldom used to connect to the net. My present machine (which connects to the net several times a day) was also set to 0 by default (as is standard) but I decided one day I was going to iron out why I was having to refresh the connection on startup before any data came across. I was looking to rewrite some source code but stumbled across this one instead. I've read that Linux is widely known for not being great with demand-dial setups. Perhaps this is why? I thought the people could benefit from knowing this.

The text from the kernel docs explains it pretty clearly.

[JimD] The result is a failure of existing connections. As new connections are established over the newly raised link, those work. So the ip_dynaddr solution is for a problem that many Linux users never knew they were having.

Paul Mackerras (author/maintainer of the Linux pppd) was trying to explain this whole thing to me one time. I'm afraid I just wasn't "getting it." (We'd probably already had too much sake by then, I think we were eating sushi that evening).

[Mike] I did a google search for "ip_dynaddr" and came up with:

(Willy Tareau)

https://web.gnu.walfield.org/mail-archive/linux-kernel/2000-March/0179.html

What exactly does setting ip_dynaddr to 1 or 2 do? it allows to change your local addresses to the one of an interface which is changing (typically ppp*) when up.

(David Forrest)

https://web.gnu.walfield.org/mail-archive/linux-kernel/2000-March/0184.html

drf5n@mug:/usr/src/linux$ grep -r ip_dynaddr *

(Juanjo, with RST-provoking mode by Erik Corry )

https://www.linuxhq.com/kernel/v2.0/doc/networking/ip_dynaddr.txt.html

IP dynamic address hack-port v0.03-rst
This stuff allows diald ONESHOT connections to get established by dynamically changing packet source address (and socket's if local procs). It is implemented for TCP diald-box connections(1) and IP_MASQuerading(2).
 
If enabled[*] and forwarding interface address has changed:
 

• Socket (and packet) source address is rewritten ON RETRANSMISSIONS while in SYN_SENT state (diald-box processes).
• Out-bounded MASQueraded source address changes ON OUTPUT (when internal host does retransmission) until a packet from outside is received by the tunnel.
  This is specially helpful for auto dialup links (diald), where the "actual" outgoing address is unknown at the moment the link is going up. So, the same (local AND masqueraded) connections requests that bring the link up will be able to get established.
   
  If you enable the RST-provoking mode, then the source address will be changed, even if the socket is established. This means we send an incorrect packet out, which causes the remote host to kill our socket. This is the desired behaviour, because such a socket is doomed anyway, and the earlier it dies, the better. This prevents the dial-on-demand connection from being kept up by a dead connection, and tells the application that the connection was lost.
   
  [*] At boot, by default no address rewriting is attempted.
   
  The values for the ip_dynaddr sysctl are:
   
  
1: To enable:
2: To enable verbosity:
4: To enable RST-provoking:
   
  Flags can be combined by adding them. Common settings would be:

  To switch off special handling of dynamic addresses (default)

  # echo 0 > /proc/sys/net/ipv4/ip_dynaddr

  To enable rewriting in quiet mode:

  # echo 1 > /proc/sys/net/ipv4/ip_dynaddr

  To enable rewriting in verbose mode:

  # echo 3 > /proc/sys/net/ipv4/ip_dynaddr

  (for backwards compatibility you can also use)

  # echo 2 > /proc/sys/net/ipv4/ip_dynaddr

  To enable quiet RST-provoking mode:

  # echo 5 > /proc/sys/net/ipv4/ip_dynaddr

  To enable verbose RST-provoking mode:

  # echo 7 > /proc/sys/net/ipv4/ip_dynaddr

This page edited and maintained by the Editors of Linux Gazette Copyright © 2001
Published in issue 68 of Linux Gazette July 2001

HTML script maintained by Heather Stern of Starshine Technical Services, https://www.starshine.org/

bios   1   2   3   4   5   6   7   8   9   10   11   12