19. [reported by Jason Haar <jason@lazerjem.demon.co.uk>]
    MTU settings on the proxy may not match the MTU settings on the
    PPP link. Mismatches can result in frame errors when sending
    large IP packets. The MTU on the proxy should be adjusted
    every time the PPP link comes up. On the other hand, I don't
    see that this can always be done, because the kernel may not
    support it. I must check the kernel code and perhaps ask
    Alan Cox if he sees a way around this problem. (Question:
    how can I forward packets from one IP interface to another
    so that they are fragmented by the second interface if needed.)
    [Ok, some general observations about this.
     I can't just adjust the MTU on the proxy to match,
     because changing the MTU on the fly on an up interface
     is not supported in the current series of kernels.
     Furthermore, even once it is supported, if I move to
     a single proxy interface monitoring for multiple outgoing
     connections this isn't an option because the actual
     connections may all have different MTU settings.
     So, I have two choices here. (1) I can write a packet
     fragmenter myself, or (2) I can try to use the SOCK_RAW
     protocol to forward the packets (instead of SOCK_PACKET).
     Now, if I use SOCK_RAW, then I'm sending the packets
     through the routing code. This means that I must change
     the routes to point to the real connection. This opens
     up the minor possiblity of locking up TCP sessions
     that are retransmitting when the link goes dead.]

27. [reported by paulo@tranbics.worldlink.ca (Paulo Alves Lima Neto)]

    --------------------------------------------------------------------------
    I am having a strange problem with diald since 0.6, it does
    not happen always but I still don't know what exactly causes it to
    hang. 

    Configuration setup:
    -------------------
    Linux 1.1.85 -> 1.2.6  (it happens for all kernel version in the range)
    386DX 40 8M 16M swap
    diald 0.6/0.7 (both diald version behaved similarly)
    ppp2.1.2b

    Problem descrition:
	    Diald does not run my connect (sometimes disconnect)
    script. Although it log a pid in the syslog file my scripts don't
    get called.
	    I had diald working without a problem for 10 days in roll, but
    sometimes ... it hangs in a few hours.
	    Trying to activate the link gives me this:
    diald.log ->
    ---------
    Tue Apr 25 18:00:36 1995 EDT: Calling site xxx.yyy.zz.k.
    Tue Apr 25 18:00:38 1995 EDT: Disconnected. Call duration 2 seconds.
	  IP transmited 0 bytes and received 0 bytes.
    syslog ->
    ------
    Apr 25 18:00:37 tranbics diald[2629]: Running connect (pid = 2686).
    Apr 25 18:00:38 tranbics diald[2629]: Connect script failed.
    Apr 25 18:00:40 tranbics diald[2629]: Delaying 30 seconds before clear
    to dial.

	    Trying to send a TERM signal gives this on syslog :
    Apr 25 20:35:01 tranbics diald[2629]: SIGTERM. Termination request
    received.
    Apr 25 21:08:32 tranbics diald[2629]: SIGTERM. Termination request
    received.
    --------------------------------------------------------------------------

    The same problem was also reported by Jason Venner <jason@idiom.com>:

    --------------------------------------------------------------------------
    I have 2 diald links that I use on my machine.

    I have noticed that sometimes the dialds get into a state where
    the message sequence in the log file is a series of

    Apr 17 23:28:31 anami diald[113]: Running connect (pid = 946).
    Apr 17 23:28:31 anami diald[113]: Connect script failed.
    Apr 17 23:28:32 anami diald[113]: Delaying 30 seconds before clear to dial.

    I am using chat -vf ... as my connect script and I never see any chat
    messages.
    There are no lock files for the lines present either.

    If I kill and restart the diald, everything immediately works
    correctly.

    Diald 0.7 linux 1.2.6
    --------------------------------------------------------------------------

28. As written there is a built in bug of sorts in the timer code.
    In particular, if your machine is up for more than about
    248 days (2^31/CLK_TCK) seconds, then the code will hiccup.
    as time rolls over. I'm not yet certain of the correct way to
    fix this, since the kernel measures clock ticks in unsigned longs,
    but clib returns them in signed longs. Also, I'm not at all sure
    how well the kernel itself would deal with the clock ticks counter
    rolling over.

31. (Several reports) kerneld starting of SLIP protocol fails, and diald
    just won't start.

32. When using the UNSAFE_ROUTING option, diald cannot reliably
    separate the number of bytes transmitted from the number of
    bytes received on a line. Fixing this efficiently would
    require support from the kernel. Currently I check if the
    source address is the local address, if it is I count
    the bytes as transmitted, otherwise as received.
    This counts ALL forwarded packets as received.

33.
