pppoe, geen subnet en dns

[Attilla]

Goedemorgen,


Ik heb hier thuis een pppoe server draaien (gewoon een linux machine) voor authentication op mijn wireless netwerk. Dit werkt perfect, mits het een windows client is (zelfs xp onder parallels doet het goed), maar direct onder os x werkt het niet.

Het probleem is dat de ppp sessie netjes tot stand komt, chap authentication werkt gewoon, maar om 1 of andere reden gebruikt os x de dns server niet die door de pppoe server wordt meegegeven. Je kan je nogal voorstellen dat het dan lastig browsen is.




Het vreemde is ook dat in de shell wel het correcte subnet wordt aangegeven, maar bij de system properties niet. Dus dat werkt ook verder wel, ik kan alleen niks resolven dus.

Heeft iemand enig idee waar dit probleem aan kan liggen ?

[edit]

Ik heb nog even in de logs gekeken en het ziet er naar uit dat OS X wel gewoon netjes mijn dns settings krijgt, maar ze niet gebruikt.

code:

Sun Sep  3 12:41:37 2006 : PPPoE connecting to service 'stofzuiger' [access concentrator '']...
Sun Sep  3 12:41:37 2006 : PPPoE connection established.
Sun Sep  3 12:41:37 2006 : using link 0
Sun Sep  3 12:41:37 2006 : Using interface ppp0
Sun Sep  3 12:41:37 2006 : Connect: ppp0 <--> socket[34:16]
Sun Sep  3 12:41:37 2006 : sent [LCP ConfReq id=0x1 <mru 1492> <magic 0xe78ec950>]
Sun Sep  3 12:41:40 2006 : sent [LCP ConfReq id=0x1 <mru 1492> <magic 0xe78ec950>]
Sun Sep  3 12:41:40 2006 : rcvd [LCP ConfReq id=0x1 <mru 1492> <auth chap MD5> <magic 0x1ddcbc0>]
Sun Sep  3 12:41:40 2006 : lcp_reqci: returning CONFACK.
Sun Sep  3 12:41:40 2006 : sent [LCP ConfAck id=0x1 <mru 1492> <auth chap MD5> <magic 0x1ddcbc0>]
Sun Sep  3 12:41:40 2006 : rcvd [LCP ConfAck id=0x1 <mru 1492> <magic 0xe78ec950>]
Sun Sep  3 12:41:40 2006 : sent [LCP EchoReq id=0x0 magic=0xe78ec950]
Sun Sep  3 12:41:40 2006 : rcvd [LCP EchoReq id=0x0 magic=0x1ddcbc0]
Sun Sep  3 12:41:40 2006 : sent [LCP EchoRep id=0x0 magic=0xe78ec950]
Sun Sep  3 12:41:40 2006 : rcvd [CHAP Challenge id=0xae <9ace48e9e73e976f6662c7ad5033fe8d57>, name
 = "stofzuiger"]
Sun Sep  3 12:41:40 2006 : sent [CHAP Response id=0xae <ef6a85a579976c58be8ec632fcdc84c8>, name = 
"airwolf"]
Sun Sep  3 12:41:40 2006 : rcvd [LCP EchoRep id=0x0 magic=0x1ddcbc0]
Sun Sep  3 12:41:40 2006 : rcvd [CHAP Success id=0xae "Access granted"]
Sun Sep  3 12:41:40 2006 : CHAP authentication succeeded: Access granted
Sun Sep  3 12:41:40 2006 : sent [IPCP ConfReq id=0x1 <addr 0.0.0.0> <ms-dns1 0.0.0.0> <ms-dns3 0.0
.0.0>]
Sun Sep  3 12:41:40 2006 : sent [IPV6CP ConfReq id=0x1 <addr fe80::0216:cbff:fecc:4e41>]
Sun Sep  3 12:41:40 2006 : rcvd [IPCP ConfReq id=0x1 <addr 10.0.1.100>]
Sun Sep  3 12:41:40 2006 : ipcp: returning Configure-ACK
Sun Sep  3 12:41:40 2006 : sent [IPCP ConfAck id=0x1 <addr 10.0.1.100>]
Sun Sep  3 12:41:40 2006 : rcvd [IPCP ConfNak id=0x1 <addr 10.0.1.112> <ms-dns1 83.98.255.11> <ms-
dns3 83.98.255.20>]
Sun Sep  3 12:41:40 2006 : sent [IPCP ConfReq id=0x2 <addr 10.0.1.112> <ms-dns1 83.98.255.11> <ms-
dns3 83.98.255.20>]
Sun Sep  3 12:41:40 2006 : rcvd [LCP ProtRej id=0x2 80 57 01 01 00 0e 01 0a 02 16 cb ff fe cc 4e 4
1]
Sun Sep  3 12:41:40 2006 : rcvd [IPCP ConfAck id=0x2 <addr 10.0.1.112> <ms-dns1 83.98.255.11> <ms-
dns3 83.98.255.20>]
Sun Sep  3 12:41:40 2006 : ipcp: up
Sun Sep  3 12:41:40 2006 : local  IP address 10.0.1.112
Sun Sep  3 12:41:40 2006 : remote IP address 10.0.1.100
Sun Sep  3 12:41:40 2006 : primary   DNS address 83.98.255.11
Sun Sep  3 12:41:40 2006 : secondary DNS address 83.98.255.20

[edit2]

Nou, het probleem heeft zich uitzichzelf opgelost.

code:

airwolf-laptop:~ airwolf$ cat /etc/resolv.conf 
nameserver 83.98.255.11
nameserver 83.98.255.20

[ Voor 67% gewijzigd door Attilla op 03-09-2006 12:52 ]

[Uberprutser]

SpeedXS DNS lag er ook uit bij mij vanmorgen dat kan het ook geweest zijn.

[Attilla]

Ballebek schreef op zondag 03 september 2006 @ 13:02:
SpeedXS DNS lag er ook uit bij mij vanmorgen dat kan het ook geweest zijn.

Ik ben er al langer meebezig, maar ik ontdekte vandaag pas het verschil tussen windows en os x. Overigens heb ik vanochtend niks gemerkt van een dns outage.