Bug 148058

Summary: pppd looses first - triggering - packet when ISP changes local IP (dial on demand)
Product: [openSUSE] SUSE LINUX 10.0 Reporter: B. Semtner <cc-tec>
Component: NetworkAssignee: Hendrik Vogelsang <hvogel>
Status: RESOLVED WONTFIX QA Contact: E-mail List <qa-bugs>
Severity: Minor    
Priority: P5 - None CC: bugz57
Version: Final   
Target Milestone: ---   
Hardware: i586   
OS: SuSE Linux 10.0   
Whiteboard:
Found By: Customer Services Priority:
Business Priority: Blocker: ---
Marketing QA Status: --- IT Deployment: ---

Description B. Semtner 2006-02-03 17:09:09 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
Comment 1 B. Semtner 2006-02-04 16:09:20 UTC 
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
Comment 2 Hendrik Vogelsang 2006-02-06 13:50:19 UTC 
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"...
Comment 3 B. Semtner 2006-02-06 15:58:40 UTC 
thks, 

do you know where to contact them? couldn't find them on the web, neither a recent howto, 

B.
Comment 4 Hendrik Vogelsang 2006-04-24 16:12:25 UTC 
*** Bug 116376 has been marked as a duplicate of this bug. ***
Comment 5 Hendrik Vogelsang 2006-04-24 16:12:54 UTC 
http://samba.org/ppp/