Re: Concealing short disconnects

From: Andrew P. (infofarmer_at_mail.ru)
Date: 02/13/05

  • Next message: Dave Horsfall: "Re: Freebsd vs. linux"
    Date: Sun, 13 Feb 2005 08:53:20 +0300
    To: Dan Nelson <dnelson@allantgroup.com>
    
    

    Dan Nelson wrote:
    > In the last episode (Feb 12), Andrew P. said:
    >
    >>Dan Nelson wrote:
    >>
    >>>In the last episode (Feb 12), Andrew P. said:
    >>>
    >>>>I have a few machines behind my FreeBSD box. The box connects to
    >>>>ISP via ppp (PPPoE protocol). It's all working very nicely, but the
    >>>>ISP is a pain - it disconnects every 24 hours. I can reconnect in
    >>>>just a moment - so the diconnect is usually less than a second
    >>>>long, but many applications, like ICQ/MSN and games "feel" the
    >>>>disconnect. The matter is that these applications can handle fairly
    >>>>large packet loss (e.g. Counter-Strike can cope with at least
    >>>>15-second long 100% packet loss), but AFAIK it's in the nature of
    >>>>the TCP/UDP that a disconnect is a disconnect.
    >>>>
    >>>>As I know that FreeBSD is full of magic, is there any way to
    >>>>conceal these reconnects as short moments of 100% packet loss? I am
    >>>>ashamed to know very little about protocols' technicalities, but
    >>>>I'll look into any sources you advise.
    >>>
    >>>Check to see if your IP number changes when you reconnect. If it
    >>>does, there's nothing you really can do; the remote system you were
    >>>talking to knew you only by your old IP, and those packets coming to
    >>>them from this other IP are unrelated.
    >>
    >>It changes only once in about a week. Let's say it doesn't change
    >>at all. What then?
    >
    >
    > I'm still suspicious :) The two most common causes for connection
    > resets are IP address changes and NAT resets. /usr/sbin/ppp keeps its
    > NAT table across disconnects as long as the process itself stays
    > running, so I don't think that's the cause. If you have root access to
    > a remote system, try running tcpdump on it and your local machine while
    > running something like top over ssh, and watch what happens when your
    > connection drops and reconnects.
    >

    No, there's really nothing to be suspicious about :) The IP doesn't
    change (well, in the process of IPCP it virtually does, first to
    10.0.0.1/0 and then back to the assigned one - but that doesn't
    count, does it), the ppp process stays, but TCP/UDP streams are
    somehow interrupted. Don't worry anyway. Disconnects happen in
    5-6 in the morning, when all the users are sleeping and the only
    one sleepless surfer is unlucky me, trying to seamlessly upgrade
    self-made internet connection sharing box from 4.10 to 5.3.

    BTW, if only anyone happens to know: I asked list before, but got
    no reply. When ISP actually assigns new IP address, I occasionally
    get double IPs on the tun0 interface (the old one and the new one
    simultaneously). Everything's working fine, but the dyndns updater
    can't recognize the IP change. Is there a way to fix this glitch/
    feature? I've really manned and googled for it - without succes.

    Best wishes,
    Andrew P.
    _______________________________________________
    freebsd-questions@freebsd.org mailing list
    http://lists.freebsd.org/mailman/listinfo/freebsd-questions
    To unsubscribe, send any mail to "freebsd-questions-unsubscribe@freebsd.org"


  • Next message: Dave Horsfall: "Re: Freebsd vs. linux"