Tankakern Skrevet 6. desember 2006 Forfatter Del Skrevet 6. desember 2006 (endret) Jammen.. 510i støtter vel ikke ADSL2+ engang? NGT har vel kanskje oA på vanlig ADSL også... Men du har rett, disse kommandoene er beregnet på 5x6-serien, ikke 5x0-serien... Og husk, til dere som har vanlig ADSL med PPPoA (og en Speedtouch-boks i 5x6-serien), kommandoen "atm phonebook add name=BrPPPoE_ph addr=1.32" vil IKKE være rett! VPI/VCI vil være en annen en enn 1/32 på en vanlig ADSL-linje. Jeg vet ikke hva NGT opererer med, men en konfigurasjon a la 8/38 eller noe i det tallspekteret vil være det korrekte. Hvis du har et fungerende oppsett på din Speedtouch på forhånd, så kan du jo bare skrive opp verdiene den bruker, og så forandre addr= til det rette. Da skal det fungere. Endret 6. desember 2006 av h017ah Lenke til kommentar
kpolberg Skrevet 6. desember 2006 Del Skrevet 6. desember 2006 Og husk, til dere som har vanlig ADSL med PPPoA (og en Speedtouch-boks i 5x6-serien), kommandoen "atm phonebook add name=BrPPPoE_ph addr=1.32" vil IKKE være rett! VPI/VCI vil være en annen en enn 1/32 på en vanlig ADSL-linje. 7441835[/snapback] Hmm, dette er litt rart, men VPI/VCI 1.32 stemmte i hvertfall hos meg(Stavanger), men det jeg fikk problemer med var å dele nettet videre via en Linux maskin. Det vi fant ut var problemet var rett og slett MTU størrelsen, alt over 1400 feiler. i tillegg må det legges inn en linje i iptables som endrer mtu størrelsen på alt som skal ut mot ppp0 interfacet. Men takk skal du ha for å pense oss inn på riktig spor. Lenke til kommentar
Tankakern Skrevet 7. desember 2006 Forfatter Del Skrevet 7. desember 2006 Ja, jeg skal vel være forsiktig å utale meg om NGT-ADSL siden jeg aldri har hatt det selv... men Telenor bruker iallfall noe i det spekteret. Poenget er at hvis du har ADSL, så sjekk verdiene før du går igang med prosjektet Bra tips det med MTU, forresten! Mener at det ikke vil føre til noe nedsatt ytelse, fordi den MTUen gjelder så vidt jeg skjønner kun mellom Speedtouch-boksen og servern din... (Må gjerne arrestere meg på det hvis jeg tar feil) Lenke til kommentar
kpolberg Skrevet 7. desember 2006 Del Skrevet 7. desember 2006 Er faktisk litt usikker på det med MTU selv, ved standard MTU fikk jeg problemer mot sider som google f.eks var ett par andre og, men husker dem ikke nå i farten. Forøvrig sliter jeg med dårlig hastighet mot ubuntu sin norske repository, dette har jeg også en mistanke om at går på MTU problematikken. Om MTU størrelsen gjelder kun mellom SpeedTouchen og Serveren er jeg egentlig litt usikker på. Jeg lurer på om MTU størrelsen man setter på interfacet faktisk også gjelder for MTU størrelsen speedtouchen kobler seg opp mot ngt, men dette er jeg veldig usikker på. Lenke til kommentar
Tankakern Skrevet 7. desember 2006 Forfatter Del Skrevet 7. desember 2006 Tingen med over ATM (PPPoA) er at det har ikke noe som heter MTU, derfor jeg går ut i fra at den bare gjelder mellom Speedtouch og ruter... Men jeg vet ikke sikkert. På det jeg har satt opp fungerte alt nydelig rett out-of-the-box etter å ha lagd en enkel config med PPTPclient... Hvis du finner ut hva som er en faktor for stabilitet og slikt med PPTP, så er jo det interessant å vite Lenke til kommentar
kpolberg Skrevet 7. desember 2006 Del Skrevet 7. desember 2006 Tingen med over ATM (PPPoA) er at det har ikke noe som heter MTU, derfor jeg går ut i fra at den bare gjelder mellom Speedtouch og ruter... 7450205[/snapback] Jeg var faktisk klar over dette med ATM ikke har noen MTU problematikk, så da må det jo være mellom SpeedTouch og server, men dette virker så rart i og med at dette går over standard ethernet interface. Og det var som sagt kun mot google og noen få andre sider at vi så noe som helst til dette problemet. Hvis jeg koblet meg opp med en Windows maskin(VPN tilkobling), så vi ingenting som helst til dette problemet, riktignok glemte vi å sjekke hvilken MTU denne ble satt til. Forøvrig synes jeg det var litt rart i den guiden din at phonebook skulle settes til BrPPPoE når dette faktisk er en PPPoA oppkobling? Har du mulighet til å forklare hvorfor det er slik? Lenke til kommentar
Tankakern Skrevet 7. desember 2006 Forfatter Del Skrevet 7. desember 2006 Forøvrig synes jeg det var litt rart i den guiden din at phonebook skulle settes til BrPPPoE når dette faktisk er en PPPoA oppkobling? Har du mulighet til å forklare hvorfor det er slik? Det var dette som stod i manualen til Thomson. Vet faktisk ikke om navnet har noe å si i det hele tatt. Men du gjør jo i praksis om en oA-tilkobling om til en oE-tilkobling (i selve speedtouchen) ved å enable PPTP. Lenke til kommentar
kpolberg Skrevet 7. desember 2006 Del Skrevet 7. desember 2006 Men du gjør jo i praksis om en oA-tilkobling om til en oE-tilkobling (i selve speedtouchen) ved å enable PPTP. 7450641[/snapback] Er det mulig at det er her MTU problematikken kommer inn da? Lenke til kommentar
Tankakern Skrevet 8. desember 2006 Forfatter Del Skrevet 8. desember 2006 (endret) Hva kommer fram hvis du skriver: =>pptp list Har ikke den ADSL2+-linja foran meg for øyeblikket, ble litt nysgjerrig... http://www.speedtouchdsl.com/documentation...=cli&topic=init Se under PPTP commands. Endret 8. desember 2006 av h017ah Lenke til kommentar
kpolberg Skrevet 8. desember 2006 Del Skrevet 8. desember 2006 Hva kommer fram hvis du skriver:=>pptp list 7452665[/snapback] {Administrator}=>pptp list Dialstr Destination QoS Encaps AC State User BrPPPoE_ph default vcmux never CONNECTED (192.168.1.1) Lenke til kommentar
Tankakern Skrevet 8. desember 2006 Forfatter Del Skrevet 8. desember 2006 Vet ikke om du er keen på å prøve eller ikke, men det er jo en del verdier du kan leke med... pptp flush før hver forandring iallfall. =>pptp flush =>pptp ifadd dest=BrPPPoE_ph encaps=nlpid for eksempel... Den forandrer fra VC-MUX til NLPID-encapsulation. Bare å prøve.. eller f.eks: =>pptp flush =>pptp ifadd dest=BrPPPoE_ph ac=keep (eller always) Har ikke troa på at rate forandrer noe som helst, siden verdiene den oppgir er så ulogiske (stiller på noe uvesentlig, tror jeg)... men du kan jo teste. Lenke til kommentar
kpolberg Skrevet 9. desember 2006 Del Skrevet 9. desember 2006 Vet du egentlig forskjellen på VC-MUX og NLPID? Prøvde å søke litt på wikipedia, men det kom ikke opp noe særlig. Lenke til kommentar
Tankakern Skrevet 10. desember 2006 Forfatter Del Skrevet 10. desember 2006 Enda et skudd i blinde... LLC koding kanskje? Ser kanskje sånn ut i RFC2364, som er den protokollen som brukes for å lage array fra PPPoA til PPTP... Men, noen suksess? Lenke til kommentar
Lars Dongeri Oppholdsnes Skrevet 18. desember 2006 Del Skrevet 18. desember 2006 Kom bare tilfeldig innom denne tråden. Har litt info om MTU for PPTP: Det normale er 1492 Bytes for PPPoE og 1436 for PPTP. Lenke til kommentar
kpolberg Skrevet 18. desember 2006 Del Skrevet 18. desember 2006 Kom bare tilfeldig innom denne tråden. Har litt info om MTU for PPTP: Det normale er 1492 Bytes for PPPoE og 1436 for PPTP. 7526162[/snapback] Så PPTP protkollen er også begrenset av MTU størrelsen altså. Det var interessant. Lenke til kommentar
Tankakern Skrevet 19. desember 2006 Forfatter Del Skrevet 19. desember 2006 la7dfa-com: nice! what's your source? kpolberg: Testa ut med ny MTU-størrelse? Blir ting bedre? Lenke til kommentar
Lars Dongeri Oppholdsnes Skrevet 19. desember 2006 Del Skrevet 19. desember 2006 (endret) Kilden er min router (Netgear WPNT834). Med litt googling fant jeg dette: MTU er 1463 på pptp tunnelen, detter fordi dette er ip-pakker som er inni ip-pakker og den "ytterste" pakken er 1500 som er max, for å unngå fragmentering av alle pakker er dette gjort. Det kan derfor være en fordel å sette mtu/mru til 1463 eller mindre på maskiner innenfor den som er oppkoblet med VPN hvis du har flere maskiner. Noen "sære" siter har satt opp sine brannmurer/pakkefiltre til å ikke formidle ICMP kontroll meldinger inn til webserverne sine, dette er ikke i samsvar med tcp/ip grunntanker. Så når vpn serveren vår sender en icmp melding til en server som sender den 1500 pakker kommer ikke den meldingen helt til den avsendende maskinen, og den fortsetter å sende 1500 pakker med DF flagg som ikke er teknisk mulig å pakke inn i en tunnel. Pakker fra slike maskiner må derfor forkastes på VPN serveren og det vil virke som om webstedene er utilgjengelig for deg. Vi vet pr i dag om disse som har dette problemet ; banken.novit.no, www.nettavisen.no, www.hp.com og www.skandiabanken.no -------------------------------------------------------------------------------------------------- The Maximum MTU for PPTP tunneling VPN using Ethernet in Windows 9x/ME is 1462. In Windows XP/2k/2k3, it seems to be limited to 1400 by default. -------------------------------------------------------------------------------------------------- http://support.microsoft.com/default.aspx?...9&Product=winxp -------------------------------------------------------------------------------------------------- Endret 19. desember 2006 av la7dfa-com Lenke til kommentar
kpolberg Skrevet 19. desember 2006 Del Skrevet 19. desember 2006 Hehe, du kan forøvrig legge til google.no til den lista over sider som failer, med for høy mtu størrelse. Men større MTU størrelse enn 1400, hjelper ikke så mye nei. Det er først når du kommer lavere enn 1000 at du merker det på hastigheten. Lenke til kommentar
Tankakern Skrevet 19. desember 2006 Forfatter Del Skrevet 19. desember 2006 kpolberg: Men får du ting til å funke..? Lenke til kommentar
kpolberg Skrevet 20. desember 2006 Del Skrevet 20. desember 2006 (endret) kpolberg: Men får du ting til å funke..? 7537745[/snapback] Alt fungerer, er bare irriterende at MTU størrelsen skal være rundt 1400 Ellers så virker det som om NGT dropper connections, som holdes åpne lenger enn 3 døgn. Er ikke helt sikker på hvor lang tid, men i hvertfall har jeg ett VPN stående mot en kamerat, og etter noen døgn blir pakkene filtrert hos ngt sin gateway, jeg må da ta å restarte hele VPN scriptet for å få VPNet opp å gå igjen. Men ellers fungerer alt fin fint. EDIT: Forøvrig måtte vi bruke en iptables regel, for å endre MTU størrelsen på alle pakkene som går fra mitt nettverk og ut mot det store spindelvevet. Endret 20. desember 2006 av kpolberg Lenke til kommentar
Anbefalte innlegg
Opprett en konto eller logg inn for å kommentere
Du må være et medlem for å kunne skrive en kommentar
Opprett konto
Det er enkelt å melde seg inn for å starte en ny konto!
Start en kontoLogg inn
Har du allerede en konto? Logg inn her.
Logg inn nå