Bugzilla – Bug 148058
pppd looses first - triggering - packet when ISP changes local IP (dial on demand)
Last modified: 2006-04-24 16:12:54 UTC
pppd or Susefirewall2 or iptables or who ever does masquerading, NATting or translating the packets from the internal net, doesn't do this for the first packet that triggers the connection. this packet is translated, but with the wrong ip-address which the interface had on the last dialin. the same behaviour affects packets from the gateway machine itself, the first packet for a new connection gets the old ip-number, the answer cannot come back, and so a second try is neccessary, which, depending on peer and protocol, is attemted within few seconds. sample: pppd (dsl0) is the default route, had been 'up' and got IP 1.2.3.4 from the ISP, goes 'down' for idle timeout, is triggered by a packet that needs to go to 5.6.7.8, composes this packet as 'from 1.2.3.4 to 5.6.7.8', activates the link, gets the new! local IP 9.10.11.12 from the ISP and tries to send 'from 1.2.3.4 to 5.6.7.8' over the link. i don't know whether the ISP drops the packet or just the answer from 5.6.7.8 is misleaded to 1.2.3.4, but 8.9.10.11 does not! get any answer. i found some information on a similar behaviour under 'http://www.freebsd.org/doc/en_US.ISO8859-1/books/faq/ppp.html#PPP-AUTODIALPROCESS-NOCONNECT' you can reproduce the behavior on any dial on demand (pppd - adsl) machine by watching packets on the ppp (dslx) or underlying ethernet (ethx) interface while triggering the link with any application. the bug doesn't harm a lot, it's just a little annoying to wait for the timeout of the browser / DNS / ssh till the timeout and then making the next attempt. AFAIK this problem had been the same in all previous SuSE versions. best regards, Bernd
i have just seen another bug, 116376 - demand dialling loses first packets, dealing with a similar problem, they are discussing a detail of the problem that the nameservers don't answer on the first try, i think they may suffer from wrong local IP on the first packet too. there is one comment from Karsten Keil that something cannot be resolved without violating TCP/IP layering rules, maybe he can give a more detailed explanation. for me it's looks no problem to either detect the need do dial from the destination address, store the packet till the link is up and pppd knows the correct local IP, or change the IP twice, once when it is received from the application program, and second when the link is up and its really being sent. nice time to all, Bernd
The first package always gets lost. That is the implementation of dial on demand in pppd. You can use several workarounds as stated in the other bug. For instance more then one nameserver (one that does not send you bogus empty replies). Sorry but you have to talk to the pppd developers if you want to get his changed/"fixed"...
thks, do you know where to contact them? couldn't find them on the web, neither a recent howto, B.
*** Bug 116376 has been marked as a duplicate of this bug. ***
http://samba.org/ppp/