none wrote:
> Hello,

> I am using pppd for dial-on-demand and i would like to know how can i avoid
> the packets, sent till the connection is etablished, to be discarded.
> Is any queueing done before the connection is up?
> Has any of you an idea about this situation?

Maybe. If you run Linux, you can use the pppd ktune option (or
otherwise set /proc/sys/net/ipv4/ip_dynaddr to 1) and configure
/etc/resolv.conf to extend the time that DNS lookups are generated
so that at most only some DNS lookups will be lost.

Setting ip_dynaddr to 1 will "Enable dynamic socket address rewriting
on interface address change."

In my resolv.conf there are 3 nameservers and

options attempts:5 rotate

which works out to 3*5*5=75 seconds for the default timeout of 5
seconds here, but you can also configure resolv.conf to extend the
timeout for DNS servers. man 5 resolver.

--
Clifford Kite Email: "echo xvgr_yvahk-ccc@ri1.arg|rot13"

Thank you for suggestion.
The thing is that i am not concerned about DNS lookups. I am looking to a
way not to lose any packets at all.
I think the solution would be in the code.

"Clifford Kite" wrote in message
news:bu4bcd.lj.ln@corncob.inetport.tld...
> none wrote:
> > Hello,
>
> > I am using pppd for dial-on-demand and i would like to know how can i
avoid
> > the packets, sent till the connection is etablished, to be discarded.
> > Is any queueing done before the connection is up?
> > Has any of you an idea about this situation?
>
> Maybe. If you run Linux, you can use the pppd ktune option (or
> otherwise set /proc/sys/net/ipv4/ip_dynaddr to 1) and configure
> /etc/resolv.conf to extend the time that DNS lookups are generated
> so that at most only some DNS lookups will be lost.
>
> Setting ip_dynaddr to 1 will "Enable dynamic socket address rewriting
> on interface address change."
>
> In my resolv.conf there are 3 nameservers and
>
> options attempts:5 rotate
>
> which works out to 3*5*5=75 seconds for the default timeout of 5
> seconds here, but you can also configure resolv.conf to extend the
> timeout for DNS servers. man 5 resolver.
>
> --
> Clifford Kite Email: "echo xvgr_yvahk-ccc@ri1.arg|rot13"

"bantonovici" writes:
> Thank you for suggestion.
> The thing is that i am not concerned about DNS lookups. I am looking to a
> way not to lose any packets at all.

Not any _at all_? I don't think that's really possible.

In the Solaris implementation (also using pppd; pppd is older than
Linux), we keep copies of a limited number of packets queued on a
demand interface so we can deliver them when the interface comes up,
but there's just no way to guarantee absolutely that no packets will
ever be lost.

That's not how IP works.

--
James Carlson, KISS Network
Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084
MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677

Maybe i didn't express it correctly. I wanted to say not to lose packets(of
course if you have an application which generates lots of traffic for a slow
interface you lose some packets). In my case the application doesn't
generate so much traffic but the packets are important being snmp-trap pdus.
I looked a little bit on the pppd code(2.4.1) and it seemed to me that the
packets should be queued and retransmited once the link is up. I am not
familiar at all with that code so my understanding is limited. Or maybe that
doesn't work as it should. I am not sure of that, so i need to find out more
about that.
Thank you
Bogdan

"James Carlson" wrote in message
news:xoavy87qep6g.fsf@sun.com...
> "bantonovici" writes:
> > Thank you for suggestion.
> > The thing is that i am not concerned about DNS lookups. I am looking to
a
> > way not to lose any packets at all.
>
> Not any _at all_? I don't think that's really possible.
>
> In the Solaris implementation (also using pppd; pppd is older than
> Linux), we keep copies of a limited number of packets queued on a
> demand interface so we can deliver them when the interface comes up,
> but there's just no way to guarantee absolutely that no packets will
> ever be lost.
>
> That's not how IP works.
>
> --
> James Carlson, KISS Network
> Sun Microsystems / 1 Network Drive 71.232W Vox +1 781 442 2084
> MS UBUR02-212 / Burlington MA 01803-2757 42.496N Fax +1 781 442 1677