Bug 116376

Arvin?

IIRC this may be caused by a wrong static DNS entry.  For the first DNS
query the DNS server in /etc/sysconfig/network/provider/xxx is used. If
that is wrong the lookup fails.  When the connection is established the
dynamic DNS server provided by the ISP is used and thus new ping calls
work.

Can you provide the file /etc/resolv.conf before and after the connection
is established?

/etc/sysconfig/network/providers/Ihug : 
DNS1='203.109.252.7' 
Note this name server sends only empty replies unless one is dialled up with 
this ISP. I guess this could be the problem... 
I believe this is the IP the dialup DHCP returns, although 
 
Ihug's publicly accessible is 203.109.252.42. 
http://www.ihug.co.nz/help/access/settings.html 
 
/etc/resolv.conf contains a name server for the wrong ISP (Xtra): 
nameserver 202.27.184.3 
This should be irrelevant. 
 
I'll run a test again on another machine. 

Tested on my own 10RC1 text machine with external modem and my own ISP (though 
all irrelevant). I made sure /etc/resolv.conf 
and /etc/sysconfig/network/provider/xxx have the same and correctly functional 
IP number for my ISP's DNS. Modem was on "user control", "demand dialling". 
/etc/sysconfig/sysctrl IP_DYNIP="yes", and I even rebooted to make sure. 
 
With the interface on standby, a ping google.com correctly triggers the 
dialup, and consistently returns "unknown host". Running the same command 
again then works. Therefore, the bug is still in RC1 (as well as in 9.3 and 
probably most other SuSE releases). 

So far I cannot reproduce the problem.  I have configured a modem to use
Arcor with dial on demand.  On the first click in kinternet the pppd is
started and resolv.conf is changed to contain the nameserver from the
provider file.  A ping triggers the connection and the same ping also
works as soon as the connection is up.  I didn't even touch IP_DYNIP.

Maybe Karsten has an idea.  I remember there were problems like this
for ISDN.

Do you have any other network interfaces?  What kind of modem do you use?
Please provide the logs from kinternet.

Machine 1 (testing now): Duron 600, external dialup modem connected via serial 
port + autodetected by yast, SiS900 PCI Fast Ethernet configured for LAN 
access. Routing table when status lurking (looks fine): 
 
Destination     Gateway         Genmask         Flags Metric Ref    Use Iface 
203.97.141.70   0.0.0.0         255.255.255.255 UH    0      0        0 modem0 
10.x.x.0        0.0.0.0         255.255.255.0   U     0      0        0 eth0 
169.254.0.0     0.0.0.0         255.255.0.0     U     0      0        0 eth0 
127.0.0.0       0.0.0.0         255.0.0.0       U     0      0        0 lo 
0.0.0.0         203.97.141.70   0.0.0.0         UG    0      0        0 modem0 
 
Old-style telephone line, no ISDN in New Zealand! 
Attached log is for this machine. 
 
 
Machine 2: Celeron 800, Ethernet controller: Accton Technology Corporation 
SMC2-1211TX (configured static IP, unused, unconnected), RaLink Ralink RT2500 
802.11 PCI, Conexant dial-modem with driver hcfpcimodem-1.06full-1. Problem 
existed before the Ralink card was installed. Problem exists with SuLi 9.3, no 
better with 10.0RC1. 
 
In all cases: 
# ping google.com 
ping: unknown host google.com 
# ping google.com 
PING google.com (216.239.37.99) 56(84) bytes of data. 
64 bytes from 216.239.37.99: icmp_seq=1 ttl=237 time=375 ms 
 

Created attachment 49887 [details]
machine 1 kinternet log

Looks very normal to me.

This behavior is normal with Dynamic IP dialups and cannot solved completly 
without violating TCP/IP layering rules. 
Here are several workarounds: 
Enter the nameserver address multiple times (2-3) into /etc/resolv.conf. 
This work very well, if the connections is established quickly enough, but I 
doubt on analog modem connections. 
The other thing you can try is ip_resend (is part of SL). 
Read /usr/share/doc/packages/ip_resend/README after installing it. 
 

Thanks for the tips! 
 
Multiple entries in resolv.conf make no difference. 
 
ip_resend looks like just the ticket, but it doesn't work. The default -w 10 
is insufficient, actual time is about -w 28 so I set -w 40 (and -r 40). The 
first ping google.com still gives unknown host. To check whether iptables 
interferes, I changed SuSEfirewall2 to true and cleared the rules. First thing 
it needs is a sleep 1 before ip_resend called by ifup, or it exits not finding 
the modem0 device. Still no go though, and I can't say why, looking at the -d2 
output. 
 
I'll attach the log and the 3 short scripts, should anyone be interested. 

Created attachment 50225 [details]
log and scripts

Is there a reason why SuSE is at 0.3, when 
http://www.baty.hanse.de/ip_resend/ip_resend-0.4.tar.gz has been out for 4 
years now? 

ip_resend 0.4 with the ip_resend-fhs.diff from SuSE's 0.3 doesn't work any 
better. Same scripts as before. 

hi, just my two cent, 

i'd submit bug 148058 on the problem that 

'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.'

maybe - just check out -, that in your case the first packet is NATed wrong, the link takes some time to come up, the resolver - or who ever does this - tries the second nameserver - i have seen retries after about 3 seconds - the link is still not ready, this packet is also translated to the wrong address, and the resolver ends in 'unknown host'. 

depending how long this information is cached on the local machine, it may take some time to be able to reconnect to this particular host, while others work fine. 

maybe Karsten Keil can tell some more details why it's not possible to correct this behaviour. ??? 

despite the fact that it is dealing with another OS 

'http://www.freebsd.org/doc/en_US.ISO8859-1/books/faq/ppp.html#PPP-AUTODIALPROCESS-NOCONNECT'

looks to announce a solution for this - or a very similar - problem, just i'm too few expert to guess the date of this document, neither wich version of ppp(d) was the 'latest' at that time. 

hope this helps, ... 

nice work over here, 

Bernd

*** This bug has been marked as a duplicate of 148058 ***