[linux] Re: ADSL en default route (Aanvulling)

[Marc Fellman]

Hallo Kees,

Alvast bij voorbaat dank voor de input.

Op 3-8-06 heeft Kees Theunissen<theuniss op rijnh.nl> het volgende geschreven:
> On Wed, 2 Aug 2006, Marc Fellman wrote:
>
<SNIP>
> >Ik heb ook nog geen idee. Voorlopig ben ik maar begonnen aan een
> >script. Hieronder staat het prototype en ik ben van plan dit script
> >elke minuut te draaien zodat het automagisch de routes toevoegt als de
> >interface in de lucht komt. Er zullen vast nog wel onvolkomenheden in
> >zitten (Ik moet geloof ik ook nog even afvragen of er wel een zinnig
> >IP-nummer op de externe interface zit (RED)).
>
> Voor mijn gevoel ben je veel te moeilijk bezig. Als het in het verleden
> gewerkt heeft met standaard tools dan zou het nu ook moeten kunnen
> werken met standaard tools. Dat zou een kwestie kunnen zijn van de juiste
> opties kiezen bij de installatie, of naderhand de juiste packages nog
> installeren en activeren.

Dat is nu net het probleem. Het werkt met de standaardtools en een
oudere kernel (2.4). Alle modernere distributies worden geleverd met
2.6 en die kernel lijkt het op één of andere manier niet prettig te
vinden dat de gateway op een subnet zit dat niet rechtsreeks in de
route tabel staat. Daar waar in de oudere versie automagische een
route naar een host werd toegevoegd (+ de default route naar deze
host) lijken dezelfde dhcp clients dat niet voor elkaar te krijgen in
een nieuwere distributie (voor zover mijn ervaringen tot nu toe). Het
pump programma komt bijvoorbeeld van de MNF (Mandrake Firewall)
machine die geen problemen heeft met deze techniek.

> Ik ken jouw distributie niet en kan dus weinig concreets zeggen.
> Maar bij een point-to-point verbinding met adsl denk ik toch al heel
> snel aan "ppp over ethernet". Ik gebruik dat zelf niet, maar mijn
> slackware 10.2 heeft het volgende ter beschikking:
>
<SNIP>

Ik zie dat Endian in ieder geval PPPoE ondersteund. Ik heb alleen 4
jaar geleden die SpeedTouch het DHCP_spoof truukje geleerd en ik ben
nog in afwachting van XS4ALL op de login gegevens (mogelijk dat ik
toch ook een password reset moet aanvragen maar dat is niet zo
beroerd, hoop ik). Ik verwacht namelijk dat ik de Speedtouch voor dit
truukje weer anders moet gaan configureren. Ik ben bang dat dit wel de
meest geschikte manier is (Alleen is het dan weer afwachten of ik de
speedtouch in PPPoE mode kan krijgen maar dat zal ik vandaag alvast
proberen uit te zoeken).

> Zoek eens in deze richting in plaats van zelf je scripts te hacken.
>

Maar blijft vor mij het feit dat ik het vreemd vindt dat een dhcp
client het tegenwoordig niet meer voor elkaar krijgt. In feite zou het
toch ongeveer (maar dan veel slimmer ;-) ) dezelfde route info kunnen
toevoegen?

>
> >
> >Hieronder mijn (prototype) script:
>
> Zomaar een paar algemene opmerkingen.
> Dat staat meestal los van de functie van het script. Het heeft meer te
> maken met robuust programmeren.

(Had ik al gezegd dat het een prototype was ;-) ).

Ik kan me redelijk redden op het gebied van scripting (en als het goed
is wordt mijn bankrekening ook elke keer aan het einde van de maand
aangezuiverd omdat ik voor mijn dagelijkse werk programmeer (Progress)
) maar op het gebied van scripting leer ik nog dagelijks bij (zo ook
nu ;-) ).

>
> ><BEGIN>
> >#!/bin/bash
> >
> >PUMPTIME=`date|cut -b 10-16`
>
> Die "cut -b 10-16" maakt je erg afhankelijk van de exacte output die
> "date" prodceert. Er hoeft maar iets te veranderen in de layout van
> "date" en je script werkt niet meer.
> Eerst maar eens kijken wat je precies wilt.
>
> kees op pcict9:~$ date
> Thu Aug  3 00:49:56 CEST 2006
> kees op pcict9:~$ date|cut -b 10-16
> 3 00:50
>
> Hmm. Dag_van_de_maand uur:minuut.
> Maar bedoelde je niet "cut -b 9-16"?
> Of wreekt zich hier al het feit dat ik een andere versie van date heb
> dan jij?
>
> kees op pcict9:~$ date|cut -b 9-16
>  3 00:50
>
> Ook vanaf 10 augustus tot en met 31 augustus geeft "date|cut -b 9-16"
> de volledige dag weer. Terwijl "date|cut -b 10-16" dan, bij mij
> althans, alleen maar het laatste cijfer van de dag zou geven.
> Maar je hoeft je helemaal niet afhankelijk te maken van dit soort
> details in de output van "date". Je hebt een uitgebreid scala aan
> opties om zelf de output van "date" te bepalen.
> Bijvoorbeeld:
>
> kees op pcict9:~$ date "+%e %H:%M"
>  3 00:50
>

Ja gisterenavond even niet aan gedacht maar dit is inderdaad een beter
manier (en dat terwijl ik het al regelmatig heb gebruikt in het
verleden). Ik ben blijkbaar toe aan een vakantie.

> >DHCPTEST=`ps -eaf|grep "dhclient -pf"|grep -v grep|wc -l`
>
> Dit heeft misschien meer met smaak te maken dan met robuustheid.
> Persoonlijk heb ik een erge hekel aan die "grep -v grep" na een
> "ps .... | grep .... |" in een pipe.
> Als je voor de eerste "grep" een regular expression kunt vinden die
> wel de goede output geeft, maar die niet de _letterlijke_ tekst bevat
> die je zoekt, dan heb je daarna die "grep -v grep" niet meer nodig.
> In dit geval zou je bijvoorbeeld hetzelfde resultaat krijgen met:
>
> DHCPTEST=`ps -eaf|grep "[d]hclient -pf"|wc -l`

ik had in het verleden wel eens geexperimenteerd met "\" maar dat
werkte niet zo als verwacht. Deze oplossing ben ik (in ieder geval
niet bewust) nog niet tegengekomen. Weer iets geleerd.

>
<KNIP weer wat leerzaam spul>

> Ik heb trouwens nog steeds het gevoel dat je met dit script op de
> verkeerde weg zit. Had ik je al aangeraden om eerst eens naar de
> standaard pppoe tools te kijken?   :-)
>

Kees, nogmaals bedankt voor deze input. Zoals gezegd zal ik gaan hopen
dat ik de juiste info van XS4ALL voor het weekend binnen heb en eens
met PPPoE aan de slag.

>
> Groeten,
>
> Kees.
>

-- 
Met Vriendelijke Groet / With Kind Regards

Marc Fellman