UMTS
in [Linux Networking]
|
From: Moe Trin on 13 Mar 2010 14:23 On Sat, 13 Mar 2010, in the Usenet newsgroup comp.os.linux.networking, in article <slrnhpmq8t.nv4.whynot(a)orphan.zombinet>, Eric Pozharski wrote: >Then, I think that peers 'pppd' I'm talking to from my router is in >fact on the modem (in contrary with ole' cable ISP's). It's not really different from cable or dial-in - the other end of the link is a terminal server at the ISP. Try doing a traceroute >Mar 12 10:57:00 agentsmith pppd[5974]: sent [LCP ConfReq id=0xcc > <asyncmap 0x0> <magic 0x8d94ceb9> <pcomp> <accomp>] You propose pretty much standard options >Mar 12 10:57:00 agentsmith pppd[5974]: rcvd [LCP ConfReq id=0x1e > <asyncmap 0x0> <auth chap MD5> <magic 0x7b690ee> <pcomp> <accomp>] So does the peer, and wants you to authenticate using CHAP with an MD5 hash - no biggy >Mar 12 10:57:00 agentsmith pppd[5974]: No auth is possible Oh, but you don't have /etc/ppp/chap-secrets set up with the username and password needed. That probably kills everything from here on. >Mar 12 10:57:00 agentsmith pppd[5974]: sent [LCP ConfRej id=0x1e > <auth chap MD5>] You reject authentication using CHAP >Mar 12 10:57:00 agentsmith pppd[5974]: rcvd [LCP ConfAck id=0xcc ><asyncmap 0x0> <magic 0x8d94ceb9> <pcomp> <accomp>] The peer approves your choice of options >Mar 12 10:57:00 agentsmith pppd[5974]: rcvd [LCP ConfReq id=0x1f > <asyncmap 0x0> <magic 0x7b690ee> <pcomp> <accomp>] and suggests the original options but not including authentication. This _MAY_ be OK, but I think this is leading you down the garden path to no-where. >Mar 12 10:57:00 agentsmith pppd[5974]: sent [LCP ConfAck id=0x1f > <asyncmap 0x0> <magic 0x7b690ee> <pcomp> <accomp>] >Mar 12 10:57:00 agentsmith pppd[5974]: sent [LCP EchoReq id=0x0 > magic=0x8d94ceb9] You approve these options, and send a 'ping' to the peer >Mar 12 10:57:00 agentsmith pppd[5974]: sent [IPCP ConfReq id=0xa3 > <compress VJ 0f 01> <addr 178.92.14.159> <ms-dns1 0.0.0.0> > <ms-dns3 0.0.0.0>] You ask to talk IP, using address 178.92.14.159 with VJ header compression, and you want the peer to tell you the IPs of two name servers. >Mar 12 10:57:00 agentsmith pppd[5974]: rcvd [LCP DiscReq id=0x20 > magic=0x7b690ee] Now, what in the heck is this - haven't seen this before. OK, RFC1661 section 5.9, and it's meaningless. >Mar 12 10:57:00 agentsmith pppd[5974]: rcvd [LCP EchoRep id=0x0 > magic=0x7b690ee 8d 94 ce b9] Peer replies to your ping >Mar 12 10:57:01 agentsmith pppd[5974]: rcvd [IPCP ConfNak id=0xa3 > <ms-dns1 10.11.12.13> <ms-dns3 10.11.12.14> <ms-wins 10.11.12.13> > <ms-wins 10.11.12.14>] Peer is NotAcKnoleging your IP requests, and suggests two RFC1918 addresses for DNS and windoze name service. [...] >Mar 12 10:57:16 agentsmith pppd[5974]: rcvd [IPCP ConfReq id=0x17] FINALLY the peer comes back with an empty IP request >Mar 12 10:57:16 agentsmith pppd[5974]: sent [IPCP ConfNak id=0x17 > <addr 10.112.112.112>] You propose the peer use a default address >Mar 12 10:57:16 agentsmith pppd[5974]: rcvd [IPCP ConfRej id=0xb3 > <compress VJ 0f 01>] The peer rejects Van Jacobson Header compression (RFC1144) >Mar 12 10:57:16 agentsmith pppd[5974]: sent [IPCP ConfReq id=0xb4 > <addr 178.92.14.159>] >Mar 12 10:57:16 agentsmith pppd[5974]: rcvd [IPCP ConfNak id=0xb4 > <addr 178.92.53.84>] >Mar 12 10:57:16 agentsmith pppd[5974]: sent [IPCP ConfReq id=0xb5 > <addr 178.92.53.84>] >Mar 12 10:57:16 agentsmith pppd[5974]: rcvd [IPCP ConfAck id=0xb5 ><addr 178.92.53.84>] and ask again to use 178.92.14.159 as your address. The peer NAKs that, and suggests asking for 178.92.53.84 - when you do, the peer approves using that. >Mar 12 10:57:17 agentsmith pppd[5974]: rcvd [IPCP ConfReq id=0x18] >Mar 12 10:57:17 agentsmith pppd[5974]: sent [IPCP ConfAck id=0x18] The peer comes back with an empty request, and you approve that. >Mar 12 10:57:17 agentsmith pppd[5974]: Local IP address changed to > 178.92.53.84 and at this point, you've got an address but none for the peer (should not matter much, but it's usual to have _something_ there - see below). >As you can see, 'pppd' at my side finishes with no DNS assigned at all >(in fact, it logs those vulgar 10.11.12.13 and 10.11.12.14 what don't >have DNS running, obviously). Can't say - 10.11.12.xx is an RFC1918 address not to be seen on the Internet at large, but _WITHIN_ a network entity (such as within your ISP) this is perfectly legal. Have you tried to as those IPs to resolve names for you? If they don't, you might try NOT setting the 'usepeerdns' option, and manually setting /etc/resolv.conf with the name servers for the domain. From outside, this seems to be 82.207.67.6 and 195.5.6.10. >Now I would like to see community's opinion on -- is a problem (if >there is any) on modem part (blame vendor) or ISP side (blame operator)? Can't say from out here. Does the connection work when you try using IP addresses rather than hostnames? Suggestions: 1. Set up /etc/ppp/chap-secrets 2. Add option 'novj' to /etc/ppp/options 3. REMOVE 'usepeerdns' from /etc/ppp/options 4. Remove '178.92.14.159:' from /etc/ppp/options 5. Add ':10.112.112.112' in place of suggestion 4 Regarding use of an RFC1918 address for _internal_ use within an ISP, this is acceptable. Why should the ISP waste a perfectly good world reachable IP for a service that may only be accessed from within the ISP? As of last month, RIPE has only allocated 6714048 IPv4 addresses to the Ukraine, and I'm sure the ISP has better things to do with those addresses than waste them for internal use only. Old guy
From: Eric Pozharski on 14 Mar 2010 09:36 with <slrnhpnpgm.8pj.ibuprofin(a)compton.phx.az.us> Moe Trin wrote: > On Sat, 13 Mar 2010, in the Usenet newsgroup comp.os.linux.networking, in > article <slrnhpmq8t.nv4.whynot(a)orphan.zombinet>, Eric Pozharski wrote: > >>Then, I think that peers 'pppd' I'm talking to from my router is in >>fact on the modem (in contrary with ole' cable ISP's). > > It's not really different from cable or dial-in - the other end of the > link is a terminal server at the ISP. Try doing a traceroute Have you meant the one that has no IP (remote IP)? *SKIP* > Oh, but you don't have /etc/ppp/chap-secrets set up with the username > and password needed. That probably kills everything from here on. Sad but true -- I have no authentication tokens to put there. And none have. I"ve investigated linux connectivity issues with my probably next ISP before buying modem. I has found out that none instruction (for any modem) has any meaning of any '*-secrets' (for my present ISP). TBH, I'm not that motivated to call ISP's support. Because I know what solution they have for me. Although may be, if I would be in good enough mood, I could make that call -- for lulz. To your point -- that doesn't kill anything. whynot(a)carpet:~$ ( zcat /var/log/syslog.[1-6].gz ; cat /var/log/syslog /var/log/syslog.0 ) | grep 'ConfAck .\+ <addr [0-9.]\+>\]' | wc 39 429 3429 whynot(a)carpet:~$ ( zcat /var/log/syslog.[1-6].gz ; cat /var/log/syslog /var/log/syslog.0 ) | grep 'ConfAck .\+ <addr [0-9.]\+> <ms-dns' | wc 35 525 4833 That's possible, I might have to show the other (surprise, surprise -- I believed that (the other) is usual; me's wrong again) scenario: Mar 14 06:46:55 agentsmith pppd[5974]: Starting link Mar 14 06:46:59 agentsmith pppd[5974]: Serial connection established. Mar 14 06:46:59 agentsmith pppd[5974]: using channel 1298 Mar 14 06:46:59 agentsmith pppd[5974]: Connect: ppp0 <--> /dev/MC990D Mar 14 06:47:00 agentsmith /USR/SBIN/CRON[14348]: (root) CMD (test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.weekly )) Mar 14 06:47:00 agentsmith pppd[5974]: sent [LCP ConfReq id=0xe8 <asyncmap 0x0> <magic 0x46b50d01> <pcomp> <accomp>] Mar 14 06:47:00 agentsmith pppd[5974]: rcvd [LCP ConfReq id=0x48 <asyncmap 0x0> <auth chap MD5> <magic 0x111e6a80> <pcomp> <accomp>] Mar 14 06:47:00 agentsmith pppd[5974]: No auth is possible Mar 14 06:47:00 agentsmith pppd[5974]: sent [LCP ConfRej id=0x48 <auth chap MD5>] Mar 14 06:47:00 agentsmith pppd[5974]: rcvd [LCP ConfAck id=0xe8 <asyncmap 0x0> <magic 0x46b50d01> <pcomp> <accomp>] Mar 14 06:47:00 agentsmith pppd[5974]: rcvd [LCP ConfReq id=0x49 <asyncmap 0x0> <magic 0x111e6a80> <pcomp> <accomp>] Mar 14 06:47:00 agentsmith pppd[5974]: sent [LCP ConfAck id=0x49 <asyncmap 0x0> <magic 0x111e6a80> <pcomp> <accomp>] Mar 14 06:47:00 agentsmith pppd[5974]: sent [LCP EchoReq id=0x0 magic=0x46b50d01] Mar 14 06:47:00 agentsmith pppd[5974]: sent [IPCP ConfReq id=0x35 <compress VJ 0f 01> <addr 178.92.142.91> <ms-dns1 0.0.0.0> <ms-dns3 0.0.0.0>] Mar 14 06:47:00 agentsmith pppd[5974]: rcvd [LCP DiscReq id=0x4a magic=0x111e6a80] Mar 14 06:47:00 agentsmith pppd[5974]: rcvd [LCP EchoRep id=0x0 magic=0x111e6a80 46 b5 0d 01] Mar 14 06:47:01 agentsmith pppd[5974]: rcvd [IPCP ConfNak id=0x35 <ms-dns1 10.11.12.13> <ms-dns3 10.11.12.14> <ms-wins 10.11.12.13> <ms-wins 10.11.12.14>] Mar 14 06:47:01 agentsmith pppd[5974]: sent [IPCP ConfReq id=0x36 <compress VJ 0f 01> <addr 178.92.142.91> <ms-dns1 10.11.12.13> <ms-dns3 10.11.12.14>] Mar 14 06:47:02 carpet /USR/SBIN/CRON[511]: (root) CMD (test -x /usr/sbin/anacron || ( cd / && run-parts --report /etc/cron.weekly )) Mar 14 06:47:02 agentsmith pppd[5974]: rcvd [IPCP ConfNak id=0x36 <ms-dns1 10.11.12.13> <ms-dns3 10.11.12.14> <ms-wins 10.11.12.13> <ms-wins 10.11.12.14>] Mar 14 06:47:02 agentsmith pppd[5974]: sent [IPCP ConfReq id=0x37 <compress VJ 0f 01> <addr 178.92.142.91> <ms-dns1 10.11.12.13> <ms-dns3 10.11.12.14>] Mar 14 06:47:03 agentsmith pppd[5974]: rcvd [IPCP ConfNak id=0x37 <ms-dns1 10.11.12.13> <ms-dns3 10.11.12.14> <ms-wins 10.11.12.13> <ms-wins 10.11.12.14>] Mar 14 06:47:03 agentsmith pppd[5974]: sent [IPCP ConfReq id=0x38 <compress VJ 0f 01> <addr 178.92.142.91> <ms-dns1 10.11.12.13> <ms-dns3 10.11.12.14>] Mar 14 06:47:04 agentsmith pppd[5974]: rcvd [IPCP ConfNak id=0x38 <ms-dns1 10.11.12.13> <ms-dns3 10.11.12.14> <ms-wins 10.11.12.13> <ms-wins 10.11.12.14>] Mar 14 06:47:04 agentsmith pppd[5974]: sent [IPCP ConfReq id=0x39 <compress VJ 0f 01> <addr 178.92.142.91> <ms-dns1 10.11.12.13> <ms-dns3 10.11.12.14>] Mar 14 06:47:05 agentsmith pppd[5974]: rcvd [IPCP ConfReq id=0x33] Mar 14 06:47:05 agentsmith pppd[5974]: sent [IPCP ConfNak id=0x33 <addr 10.112.112.112>] Mar 14 06:47:05 agentsmith pppd[5974]: rcvd [IPCP ConfRej id=0x39 <compress VJ 0f 01>] Mar 14 06:47:05 agentsmith pppd[5974]: sent [IPCP ConfReq id=0x3a <addr 178.92.142.91> <ms-dns1 10.11.12.13> <ms-dns3 10.11.12.14>] Mar 14 06:47:05 agentsmith pppd[5974]: rcvd [IPCP ConfNak id=0x3a <addr 178.92.139.62> <ms-dns1 213.179.249.133> <ms-dns3 212.113.36.14>] Mar 14 06:47:05 agentsmith pppd[5974]: sent [IPCP ConfReq id=0x3b <addr 178.92.139.62> <ms-dns1 213.179.249.133> <ms-dns3 212.113.36.14>] Mar 14 06:47:05 agentsmith pppd[5974]: rcvd [IPCP ConfAck id=0x3b <addr 178.92.139.62> <ms-dns1 213.179.249.133> <ms-dns3 212.113.36.14>] Mar 14 06:47:06 carpet syslogd 1.5.0#5: restart (remote reception). Mar 14 06:47:06 agentsmith pppd[5974]: rcvd [IPCP ConfReq id=0x34] Mar 14 06:47:06 agentsmith pppd[5974]: sent [IPCP ConfAck id=0x34] Mar 14 06:47:06 agentsmith pppd[5974]: Local IP address changed to 178.92.139.62 Mar 14 06:47:07 agentsmith pppd[5974]: Open UDP 178.92.139.62:25489 -> 198.41.0.4:53 Mar 14 06:47:07 agentsmith pppd[5974]: sent [IP data] 45 00 00 4a 5c 21 40 00 ... Mar 14 06:47:07 agentsmith pppd[5974]: Script /etc/ppp/ip-up started (pid 14398) Mar 14 06:47:08 agentsmith pppd[5974]: Script /etc/ppp/ip-up finished (pid 14398), status = 0x0 As you can see -- 'No auth is possible'! *SKIP* >>As you can see, 'pppd' at my side finishes with no DNS assigned at all >>(in fact, it logs those vulgar 10.11.12.13 and 10.11.12.14 what don't >>have DNS running, obviously). > > Can't say - 10.11.12.xx is an RFC1918 address not to be seen on the > Internet at large, but _WITHIN_ a network entity (such as within your > ISP) this is perfectly legal. Have you tried to as those IPs to > resolve names for you? If they don't, you might try NOT setting the > 'usepeerdns' option, and manually setting /etc/resolv.conf with the > name servers for the domain. From outside, this seems to be 82.207.67.6 > and 195.5.6.10. Look, I've said above (in skipped): I have no no-DNS issue -- I've gone for roots (once I've found out that I had no DNS for a whole day; then suddenly nothing resloves (even google!); may be I'm too hysteric?) >>Now I would like to see community's opinion on -- is a problem (if >>there is any) on modem part (blame vendor) or ISP side (blame operator)? > > Can't say from out here. Does the connection work when you try using > IP addresses rather than hostnames? That doesn't compile. > Suggestions: > > 1. Set up /etc/ppp/chap-secrets I can do nothing with this. I can't even request personal page (that's translated from local IT-speek; the page where you can enable/disable services, probably see statistics etc). To achieve such I must be on cable. And I'm not > 2. Add option 'novj' to /etc/ppp/options Fixed. And BTW disabled 'noauth' -- let's see how it will end. > 3. REMOVE 'usepeerdns' from /etc/ppp/options Fixed. It haven't any sense anyway. > 4. Remove '178.92.14.159:' from /etc/ppp/options And it have no such in first place. 'pppd' runs persist+ondemand. That's left after a previous session. > 5. Add ':10.112.112.112' in place of suggestion 4 Why exactly this one? > Regarding use of an RFC1918 address for _internal_ use within an ISP, > this is acceptable. Why should the ISP waste a perfectly good world > reachable IP for a service that may only be accessed from within the > ISP? As of last month, RIPE has only allocated 6714048 IPv4 addresses > to the Ukraine, and I'm sure the ISP has better things to do with > those addresses than waste them for internal use only. But they do! See above. p.s. The things they do aren't, in fact, 'better'. My ISP is believed (probably urban legend (or better FIDO legend)) to be a cash cow of current criminal group what happens to be on the wheel (whatever 'current' means). p.p.s. And I still insist on comunity's opinion. -- Torvalds' goal for Linux is very simple: World Domination Stallman's goal for GNU is even simpler: Freedom
From: Günther Schwarz on 15 Mar 2010 13:35 Moe Trin wrote: > Suggestions: > > 1. Set up /etc/ppp/chap-secrets > 2. Add option 'novj' to /etc/ppp/options 3. REMOVE 'usepeerdns' from > /etc/ppp/options 4. Remove '178.92.14.159:' from /etc/ppp/options 5. > Add ':10.112.112.112' in place of suggestion 4 > > Regarding use of an RFC1918 address for _internal_ use within an ISP, > this is acceptable. Why should the ISP waste a perfectly good world > reachable IP for a service that may only be accessed from within the > ISP? IME and without really deep into analyzing the issue it takes a bit of good luck to get a correct DNS address within a ppp connection over a G3/ UMTS modem. With my provider (Telefonica) I might get 193.189.244.2, but sometimes also just 10.11.12.13 like the OP. The latter can not be resolved within the internal network of the terminal server. This might or might not be a timing issue at the service provider's side. The proper solution is not to use the DNS server as provided by the ISP but to use a static address within or outside the providers network. Thanks for the suggestion regarding /etc/ppp/options. Günther
From: Moe Trin on 15 Mar 2010 21:40 On Sun, 14 Mar 2010, in the Usenet newsgroup comp.os.linux.networking, in article <slrnhpppip.620.whynot(a)orphan.zombinet>, Eric Pozharski wrote: >Moe Trin wrote: >> It's not really different from cable or dial-in - the other end of the >> link is a terminal server at the ISP. Try doing a traceroute >Have you meant the one that has no IP (remote IP)? Which version of pppd are you using? It should show up in the log a bit before the 'Starting link' line. The reason I ask is that there is a 2.4.5 version (released in mid-November) that has some improvements for wireless setups. That's normally a brain-dead ISP, but for the most part there is no problem. Look at the output of /sbin/route and you will see something like [conover ~]$ /sbin/route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 192.168.195.11 0.0.0.0 255.255.255.255 UH 0 0 1 ppp0 192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 4198 eth0 127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 20 lo 0.0.0.0 192.168.195.11 0.0.0.0 UG 0 0 5 ppp0 [conover ~]$ for a normal setup. The 'UH' route says there is a host at the other end of the ppp0 route. The 'UG' route at the bottom says that all of the world (other than the local net and loopback) can be reached by sending packets to 192.168.195.11 (who will then forward them). HOWEVER, the same function can be had with [conover ~]$ /sbin/route -n Kernel IP routing table Destination Gateway Genmask Flags Metric Ref Use Iface 192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 4198 eth0 127.0.0.0 0.0.0.0 255.0.0.0 U 0 0 20 lo 0.0.0.0 0.0.0.0 0.0.0.0 U 0 0 5 ppp0 [conover ~]$ What this says is that the entire world is _directly_ reachable at the other end of the ppp0 link. If you look at the packets going over the link, there is no difference between the two. Compare to Ethernet, (RFC 894) where the packet has the link level 'source' and destination address (so your system needs to know the MAC address on "this" wire to send the packet), a ppp packet (RFC 1662) has a five byte header: 7E FF 03 protocol data.................. where 7E is a flag, FF is an "address", 03 is a control byte, and the protocol is "0021" for an IPv4 datagram. The data is the IP datagram per RFC 791. The "FF" address is the only one used, but is meaningless as this is a point-to-point link, and the only two hosts on the link are you and the peer - so if you send a packet, it _must_ be going to the peer. That peer will look at the protocol and data, see that it is an IP datagram, and send it on in the direction of the destination. If the peer sends a packet over this link, it _must_ be going to you (why else would the peer send the packet over the link?). Lacking an IP address of the peer merely means that if you want to speak to that peer (not using it as a forwarder), you'll have to figure out the address by some other means. But then, maybe the ISP doesn't want you to connect to the peer. >As you can see -- 'No auth is possible'! That is pppd telling you that the peer asked for an authentication function, but there is no secrets file that is usable. >Look, I've said above (in skipped): I have no no-DNS issue Then what is the problem? >>> is a problem (if there is any) on modem part (blame vendor) or ISP >>> side (blame operator)? >> Can't say from out here. Does the connection work when you try using >> IP addresses rather than hostnames? >That doesn't compile. Can you reach http://152.46.7.80/pub/linux/ as opposed to http://ibiblio.org/pub/linux/ which is the same page. If the numeric address works, and the name doesn't, you have a DNS problem, but NOT a ppp problem. If neither address works, what is the error message? >> 2. Add option 'novj' to /etc/ppp/options >Fixed. And BTW disabled 'noauth' -- let's see how it will end. 'noauth' tells pppd not to ask the peer to authenticate to you. It doesn't stop the peer from asking you to authenticate to it. >> 5. Add ':10.112.112.112' in place of suggestion 4 >Why exactly this one? This would tell pppd to suggest the peer uses that address for itself. You could use almost any RFC5735 or RFC1918 address. This _may_ cause the peer to have an IP address for it's end of the link - something like the first routing table I show above. The newer version of ppp is supposed to be more tolerant of a peer that refuses to negotiate an IP address for itself. >> Regarding use of an RFC1918 address for _internal_ use within an ISP, >> this is acceptable. Why should the ISP waste a perfectly good world >> reachable IP for a service that may only be accessed from within the >> ISP? As of last month, RIPE has only allocated 6714048 IPv4 addresses >> to the Ukraine, and I'm sure the ISP has better things to do with >> those addresses than waste them for internal use only. >But they do! See above. It may be "who answers the phone" - one of the ISPs I use has many connections using the same telephone number. This means I may reach one of several different terminal servers even though I dial the same number. Two of them use RFC1918 addresses both for their own address and the address of the DNS servers they suggest. Three of them use ``regular'' IP addresses for their address, and two of them use RFC1918 addresses for the DNS, while the last uses ``regular'' addresses for the DNS. The admins must be very st00pid, but things work, so I have no reason to complain. But I've also seen reports that wireless connections may come up with strange addresses if the connection to the ISP is slow to set up. I'm not using this type of service, so I can't say. Old guy
From: Moe Trin on 15 Mar 2010 21:41 On 15 Mar 2010, in the Usenet newsgroup comp.os.linux.networking, in article <8079ebFhhvU1(a)mid.individual.net>, G�nther Schwarz wrote: >Moe Trin wrote: >> Regarding use of an RFC1918 address for _internal_ use within an ISP, >> this is acceptable. Why should the ISP waste a perfectly good world >> reachable IP for a service that may only be accessed from within the >> ISP? >IME and without really deep into analyzing the issue it takes a bit of >good luck to get a correct DNS address within a ppp connection over a >G3/ UMTS modem. With my provider (Telefonica) I might get 193.189.244.2, >but sometimes also just 10.11.12.13 like the OP. The latter can not be >resolved within the internal network of the terminal server. Which version of ppp are you using? I've seen some reports that wireless setups getting strange values for both DNS and WINS addresses (10.11.12.13 and 10.11.12.14 is mentioned, but doing a search for these addresses always turns up people using the addresses as examples (instead of using the address range specifically reserved for such examples) but not much in the case of ppp actually getting those values.. >This might or might not be a timing issue at the service provider's >side. I've seen some reports of this, but with no reported solutions. >The proper solution is not to use the DNS server as provided by the >ISP but to use a static address within or outside the providers >network. I agree that using static addresses is preferred. The reason the dynamic setup is used is that windoze determined that the average user can't understand complex things like editing the resolver configuration file, and made this an "automatic - you're to stupid to be doing this, I'll do it for you" type of task - RFC1877 documents this. In reality, most admins don't change the IP address of the name server without very good reason - our nameservers at work are on the same address they used for the last 25 years. Setting up a caching name server on a local system is relatively easy, and fixes a LOT of problems. Many distributions provide a simple setup to do just this. Old guy
|
Next
|
Last
Pages: 1 2 3 4 5 6 7 Prev: Madwifi doesn't work with my Atheros card Next: Logging dropped packets via netfilter/iptables |