[Date Prev][Date Next] [Thread Prev][Thread Next] [Date Index] [Thread Index]

Re: Undermålig dhcp hos Comhem.



Hej!

--- Den tis 2009-10-06 skrev Anders Jackson <anders.jackson@gmail.com>:

>Den 4 oktober 2009 01.52 skrev Mats Erik Andersson <ynglingatal@yahoo.se>:
>>
>> Hej!

>Hej, liten notering om att det anses snyggast att skicka oformaterad
>datorpost till listor. (inte HTML)

Nu lärde jag mig att slå av eländet hos yahoo.se!
Tack, det uppskattar jag. Jag kan tyvärr inte nyttja
"mutt" från yahoo-kontot.

>(Oslussbart nät = Icke routbart, privat nät?)
> Sluss = Router? )
> Jag tror jag förstår scenariot, men inte riktigt problemet.
> Vad är det för svar som du förväntar dig att få som är blockerat
> två timmar?
> Varför behöver du bootps/bootpc från deras dhcp-server?

Saken är den, att ett fullgott operativsystem får sin första
hyreslina (åtminstone med dhcp) genom att på adressen 
255.255.255.255 fråga efter en godtycklig dhcp-tjänst.
Ett vettigt svar skall då innehålla en post 

     option dhcp-server-identifier 1.2.3.4;

med den för anslutningen ansvariga maskinen.

Felet Comhem gör, är att i mitt fall bevisligen maskinen
83.253.240.1 bär detta ansvar, men likafullt innehåller
dhcp-svaret en hänvisning

      option dhcp-server-identifier 10.125.1.11;

Denna nya maskin svarar förvisso på ping-förfrågan, men
protokollen bootpc/bootps når inte fram. Felfunktionen
uppstår nu på följande sätt:

En adresshyra utdelas tillsammans med tre tidsgränser,
nämligen "renew", "rebind" och "expire". Ett välskapt
operativsystem som varje fullvuxet GNU/Linux, liksom
OpenBSD och FreeBSD, kommer när tidpunkten "renew" är
utlupen, att till den adress som "dhcp-server-identifier"
uppgav, från porten "bootpc" till porten "bootps" skicka
en förfrågan om förnyad adresshyra. Märk väl, att meddelandet
nu är riktat till en enda maskin, inte som ett allmänt rop
på hjälp ut i etern!

Det är först när tidpunkten "rebind" är förlupen, då ett
nytt utrop till 255.255.255.255 kan ske. Skillnaden mellan
dessa tidpunkter kan gott vara tå timmar, om man i 
"dhclient.conf" ser till att önska en lång hyrestid.

Förvisso är alla 10.0.0.0/8 nätt oslussbara enligt RFC 1918,
men jag hade förväntat mig att Comhem åtminstone tillåter
trafik till 10.125.1.11, eftersom man så istadigt uppgiver
den maskinen som dhcp-ansvarig. Emellertid skulle en kunnig
nätoperatör se till att min adresshyra utdelades med en
duglig post 

    option dhcp-server-identifier 83.252.240.1;

vilket man alltså inte har förstått hos Comhem.

Det är troligen så att de små inbyggda nätslussarna, med eller
utan trådlös åtkomstpunkt, som finns att tillgå på marknaden,
inte håller till protokollet rörande "renew", utan omedelbart
utför det som egentligen tillfaller "rebind" enligt ovan.

Den intresserade finner hyresposternas innehåll i filer som

   /var/lib/dhcp3/dhclient.eth0.leases

under GNU/Linux. För BSD gäller "db" i stället för "lib".

>> Jag kunde komma runt problemet när jag körde en nätsluss
>> med OpenBSD, men nu har jag åter samma problem med
>> en ny nätsluss under Linux, så jag undrar hur Ni andra
>> kommer runt eländet.

>Hur gjorde du i OpenBSD?
>Hur jag ungår det?  Jag har en annan operatör.

I OpenBSD gjorde jag en liten systemtjänst, ett enkelt
ksh-program som läste av bokföringen "dhclient.leases.ep0"
och strax innan tidpunkten "renew" nåddes, då lät jag
"dhclient" begära en helt ny hyra av Comhem, alltså utan
att stödja sig på den tidigare medgivna hyreslinan.
Tekniskt sätt lät jag tjänsten räkna fram fördröjningen,
sedan sova så länge, följt av ett anrop

      sh /etc/netstart ep0

och att därefter gå tillbaka i evighetsslingan.

Utan denna nödlösningen kommer systemloggen att innhålla en
stor mängd utsagor liknande

    dhclient: DHCPREQUEST on ep0 to 10.125.1.11 port 67
    last message repeated 7 times

nämligen från tidpunkten "renew" till "rebind". Ytterst störande.

Den lösningen fungerade utmärkt i ett halvår, men nu ville jag
sätta upp en nätsluss i Debian GNU/Linux och dessutom ville jag
undvika denna nödlösning jag snickrade ihop i OpenBSD.

Till saken hör väl att nätslussarna i OpenBSD och Debian GNU/Linux
båda kör från varsitt CF-kort med anpassningar i system för att
hålla ned skrivning till flashminnet så långt det går.
 
>> Comhem svarade i mars månad:
>>
>>     "Våra tekniker känner till problemet och
>>      arbetar på en lösning"!
>>
>>Jag  väntar än på deras åtgärder.

> Kanske dags att fråga vad som händer eller inte händer?
> Sedan så  kan du även fundera på att byta operatör, eftersom
> de inte verkar ha tillräcklig kompentens för att driva en ISP.

Trångmålet är nog att Comhem är den enda operatör som når in i
bostadsrättsföreningen, och att jag behöver adresshyran för
inkommande smpt-trafik och http-trafik.

>> Många hälsningar.

> Detsamma
> /Anders

Jag upptäckte nyss att under gårdagen kom tidpunkterna
"rebind" och "expire" så olyckligt i tiden att nätslussen
utan min vetskap tilldelades en helt ny ip-adress. Mitt misstag
var nog det, att i "dhclient.conf" sätta en parameter "retry 900"
så lång att maskinen inte lyckades hinna med "rebind" innan
tidpunkten "expire" hade infunnit sig, och att alltså Comhems
system bedömde hyran som förlupen. Med erfarenhet kommer väl
färdighet.

Det vart en lång utläggning, men jag hoppas uppriktigt att
jag fäster allas uppmärksamhet i saken, eller att någon
finner mitt tankefel och att saken ordnar sig på så sätt.


God jakt i Er felsökning, hälsar

Mats Erik Andersson


      __________________________________________________________
Ta semester! - sök efter resor hos Kelkoo.
Jämför pris på flygbiljetter och hotellrum här:
http://www.kelkoo.se/c-169901-resor-biljetter.html?partnerId=96914052


Reply to: