Undermålig dhcp hos Comhem.

View: New views
4 Messages — Rating Filter:   Alert me  

Undermålig dhcp hos Comhem.

by Mats Erik Andersson :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Hej!

Jag har ett tekniskt spörsmål för att komma runt den
felinställning Comhem nyttjar för dhcp-hyra i deras
nätverk.

Saken är den Comhem sänder tillbaka

    dhcp-server-identifier 10.125.1.11,

vilket enligt rfc1918 ligger i ett oslussbart nät. Denna
maskin finns faktiskt -- den svarar på icmp-ping -- men
protokollen bootps/bootpc blockeras. Det är i själva verket
den närmsta närslussen 83.253.240.1 som kan svara på
våra dhcp-klienter, den värdet på ovanstående parameter
"dhcp-server-identifier" hindar det rätta gensvaret i upp
till två timmar.

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.

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.

Många hälsningar.


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

Re: Undermålig dhcp hos Comhem.

by Anders Jackson-2 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

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

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

> Jag har ett tekniskt spörsmål för att komma runt den
> felinställning Comhem nyttjar för dhcp-hyra i deras
> nätverk.
>
> Saken är den Comhem sänder tillbaka
>
>     dhcp-server-identifier 10.125.1.11,
>
> vilket enligt rfc1918 ligger i ett oslussbart nät. Denna
> maskin finns faktiskt -- den svarar på icmp-ping -- men
> protokollen bootps/bootpc blockeras. Det är i själva verket
> den närmsta närslussen 83.253.240.1 som kan svara på
> våra dhcp-klienter, den värdet på ovanstående parameter
> "dhcp-server-identifier" hindar det rätta gensvaret i upp
> till två timmar.

(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?

> 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.

> 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.

> Många hälsningar.

Detsamma
/Anders


--
To UNSUBSCRIBE, email to debian-user-swedish-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...


Parent Message unknown Re: Undermålig dhcp hos Comhem.

by Mats Erik Andersson :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Hej!

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

>Den 4 oktober 2009 01.52 skrev Mats Erik Andersson <ynglingatal@...>:
>>
>> 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


--
To UNSUBSCRIBE, email to debian-user-swedish-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...


Re: Undermålig dhcp hos Comhem.

by Anders Jackson-2 :: Rate this Message:

Reply to Author | View Threaded | Show Only this Message

Den 13 oktober 2009 12.25 skrev Mats Erik Andersson <ynglingatal@...>:
> Hej!

Hej igen.

> --- Den tis 2009-10-06 skrev Anders Jackson <anders.jackson@...>:
>
>>Den 4 oktober 2009 01.52 skrev Mats Erik Andersson <ynglingatal@...>:
>>>
>>> Hej!

...

>>(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.

De gör helt riktigt som ignorerar adresser från 10.0.0.0/8-nätet
utifrån.  Men de skall ju följa RFC:er, vilket de inte verkar göra. I
vart fall är det inte funktionellt att läcka ut en 10.0.0.0/24 adress
uanför det egna privata nätet (som 10.125.1.11-adressen i DHCP-paketet
ovan).

En logg från Wireshark med relevanta paket, borde visa dem var felet
finns.  Skulle tro att dhcp-servern som de kör har en IP-anslutet
gränssnitt till 10.0.0.0/8-nätet, förutom till det nät som du sitter
vid.  Så den felkonfigurerade dhcp-servern måste korrigeras för att få
det att fungera korrekt.
Tro att det blir lättare att få dem att förstå vari felet ligger om du
använder mer konventionella termer när du felanmäler det till dem.
En datafil med relevanta paket från Wireshark skulle i vart fall göra
det tydligare vad det är för problem de har.

> 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.

Gör som jag, använd ADSL i stället för ComHem som även finns i
bostadsrättsföreningen här.

>>> 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

Lycka till med ComHem och DHCP:n
Anders


--
To UNSUBSCRIBE, email to debian-user-swedish-REQUEST@...
with a subject of "unsubscribe". Trouble? Contact listmaster@...