75 replies to this topic

[janj]

Hoi pieterg,

Vanavond de laatste openpli build geflashed.
Tijdens preparing first use gaat de instelling 1080i goed zonder dat lg fullhd op zwart gaat.
Probleem met netwerk herkenning via dhcp als handmatig blijft installatie scherm mekkeren dat
netwerk niet geactiveerd is. Na reboot is netwerk wel geactiveerd. Schoonheids foutje denk ik.
Mijn DM800HD is van het bouwjaar juli 2008 misschien dat de netwerk herkenning tijdens installatie daarom niet goed werkt. Blijft toch lastig met al die verschillende series die DMM van de DM800HD heeft uitgebracht. Op de ene serie werkt het wel op de andere niet.

mvg Jan

[pieterg]

maar is het netwerk ook echt niet geactiveerd? of zegt alleen de netwerk plugin maar dat hij vindt dat het netwerk niet geactiveerd is?
Ik bedoel eigeniljk, is die reboot ook echt nodig, of is het puur cosmetisch?

[janj]

maar is het netwerk ook echt niet geactiveerd? of zegt alleen de netwerk plugin maar dat hij vindt dat het netwerk niet geactiveerd is?
Ik bedoel eigeniljk, is die reboot ook echt nodig, of is het puur cosmetisch?

Hoi Pieterg,

Reboot is noodzakelijk, om netwerk aktief te krijgen. Na de first use installatie is dm800hd via telnet niet bereikbaar op het door mij tijdens installatie ingegeven ip adres, na reboot wel via ipnummer bereikbaar.

mvg Jan

[pieterg]

maar vermoedelijk als je de netwerk wizard afbreekt, en niks instelt, is de box wel gewoon bereikbaar op het adres wat hij van de dhcp server gekregen heeft?

Ik zit hier momenteel ook een aantal dhcp zaken te debuggen. We hebben busybox geupdate naar een recente stand om wat vreemde dhcp problemen op te lossen, maar met deze versie heb ik zelfs op de 8000 nu de grootste problemen...

[janj]

Hoi Pieterg,

Omdat ik tijdens de first use installatie via dhcp geen ipnummer toegewezen kreeg heb ik het dus maar handmatig ingegeven ook al kreeg ik toen de melding dat netwerk niet geactiveerd was. Is de preinstallatie niet voor elk image hetzelfde, dit is toch wat van DMM af komt. In de Experimental CVS 2.6 werkt de dhcp netwerkdetectie gewoon of is dit in openpli op een andere wijze geimplementeerd.

mvg Jan

[pieterg]

zoals gezegd gebruiken we een nieuwere busybox versie. Juist om een aantal problemen te voorkomen. Maar er gaat nog steeds iets niet helemaal goed.

[janj]

Hoi Pieterg,

Nou ja uiteindelijk loopt de openpli build 03122009 inmiddels een paar uur. Zijn jullie als Pli Team van plan om gebruik te gaan maken van de 2.6.30 kernel of is dit nog verre toekomst muziek.

mvg Jan

[pieterg]

momenteel geeft dat alleen nog maar nadelen (zoals de noodzaak gebruik te maken van hele oude bcm drivers, en niet mee te kunnen met de laatste ontwikkelingen op dat gebied), dus voorlopig niet nee.

[hemertje]

mijn algemene ervaring met de 800 is ook dat een herstart nodig is om een werkend netwerk te krijgen
ben nog niet in staat geweest om de laatste busybox te testen

[Sjaaky]

> mijn algemene ervaring met de 800 is ook dat een herstart nodig is om een werkend netwerk te krijgen

Vreemd. Dit gedrag had mijn dm7025 ook. Bij een koude boot kon er de eerste keer nooit een ip verkregen worden. Omdat zeroconf het daarna overnam en zaken fout instelde kon mijn box alleen op het LAN en niet op internet. Na een netwerk herstart werkte het dan weer. Om dat te op te lossen had ik zeroconf toegevoegd aan busybox. Daarna was het bij mij over. Maar voor de 800 dus nog niet.

Wat ik zie is dat udhcpc nu wordt opgestart met udhcpc -R -n -p /var/run/udhcpc.%iface%.pid -i %iface%
Dit ziet eruit als one-shot. Ik mis de -b(ackground) optie die we wel in busybox 1.01 gebruikte.

[pieterg]

de background optie lost het niet op.
En ook het verwijderen van zeroconf niet.
Dus het lijkt hetzelfde als met de vorige versie op de 7025.
Maar het is wat anders. Alleen wat, dat weet ik nog niet.

Een '/etc/init.d/networking restart' levert bijvoorbeeld ook geen werkende lease op, dus dat is even het probleem waar ik me op aan het richten ben, mogelijk is alles het gevolg van dezelfde issue.
Overigens werkt op andere hardware dezelfde versie met dezelfde scripts vlekkeloos, dus een bug in de netwerkdrivers van de 800(0) is zeker niet uit te sluiten, probleem is alleen te vinden waardoor we die bug triggeren, en/of hoe de oudere versie daar juist weer omheen werkte.

[pieterg]

Oja, die background optie, ik heb er over zitten te twijfelen.
Uiteindelijk voegt hij weinig toe.
Als je geen lease krijgt, verdubbelt de retry tijd. Dus als je na een uurtje de netwerk kabel er pas inplugt, of je dhcp server aanzet, moet je vervolgens uren wachten tot je een lease krijgt.
Dus bij het niet krijgen van een lease in de background blijven proberen is niet noodzakelijk beter dan het na 3x opgeven.
(uiteindelijk wil je natuurlijk op link up reageren, en ifup daaraan hangen, maar ik ben voorlopig al lang blij als we dhcp weer werkend krijgen)

[Sjaaky]

> dus een bug in de netwerkdrivers van de 800(0) is zeker niet uit te sluiten.

root@dm7025 ~ # tcpdump host not 192.168.1.6 -v -s 1500
tcpdump: listening on eth0, link-type EN10MB (Ethernet), capture size 1500 bytes
11:31:16.216726 IP (tos 0x0, ttl  64, id 0, offset 0, flags [none], proto: UDP (17), length: 576) 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from ...... (oui Unknown),
length: 548, xid:0x8d74783f, flags: [none]
		Client Ethernet Address: ... (oui Unknown)
		Vendor-rfc1048:
		  DHCP:DISCOVER
		  CID:[ether].......
		  VC:"udhcp 1.13.2"
		  MSZ:576
		  PR:SM+DG+NS+HN+DN+BR+NTP
11:31:16.218476 IP (tos 0x0, ttl 255, id 25807, offset 0, flags [none], proto: UDP (17), length: 576) 192.168.1.254.bootps > 192.168.1.33.bootpc: BOOTP/DHCP, Reply, length: 548, xid:0x8d74783f, fl
ags: [none]
		Your IP: 192.168.1.33
		Server IP: 192.168.1.254
		Client Ethernet Address: ...... (oui Unknown)
		sname "adsl-modem"
		Vendor-rfc1048:
		  DHCP:OFFER
		  SM:255.255.255.0
		  DG:192.168.1.254
		  NS:192.168.1.254
		  HN:"dhcppc0"
		  DN:"lokaal^@"
		  RN:14400
		  RB:25200
		  LT:28800
		  SID:192.168.1.254
11:31:16.218476 IP (tos 0xc0, ttl  64, id 659, offset 0, flags [none], proto: ICMP (1), length: 576) 192.168.1.33 > 192.168.1.254: ICMP 192.168.1.33 udp port bootpc unreachable, length 556
	   IP (tos 0x0, ttl 255, id 25807, offset 0, flags [none], proto: UDP (17), length: 576) 192.168.1.254.bootps > 192.168.1.33.bootpc: BOOTP/DHCP, Reply, length: 548, xid:0x8d74783f, flags: [no
ne]
		Your IP: 192.168.1.33
		Server IP: 192.168.1.254
		Client Ethernet Address: ....... (oui Unknown)
		sname "adsl-modem"
		Vendor-rfc1048:
		  DHCP:OFFER
		  SM:255.255.255.0
		  DG:192.168.1.254
		  NS:192.168.1.254
		  HN:"dhcppc0"
		  DN:"lokaal^@"
		  RN:14400
		  RB:25200
		  LT:28800
		  SID:192.168.1.254
	   MPLS extension v0 packet not supported
11:31:16.286870 IP (tos 0x0, ttl  64, id 0, offset 0, flags [none], proto: UDP (17), length: 576) 0.0.0.0.bootpc > 255.255.255.255.bootps: BOOTP/DHCP, Request from ...... (oui Unknown),
length: 548, xid:0x8d74783f, flags: [none]
		Client Ethernet Address: ...... (oui Unknown)
		Vendor-rfc1048:
		  DHCP:REQUEST
		  CID:[ether].......
		  VC:"udhcp 1.13.2"
		  RQ:192.168.1.33
		  SID:192.168.1.254
		  PR:SM+DG+NS+HN+DN+BR+NTP
...

(In dit geval heeft mijn interface al ip 192.168.1.33, maar nog een keer aanvragen kan nooit kwaad)
Wat ik raar vind is dat "ICMP 192.168.1.33 udp port bootpc unreachable, length 556" terug gaat naar de dhcp server. Terwijl alles wel door blijft werken. Wellicht dat andere dhcp-servers anders op dat icmp bericht reageren.

Ik bemerk net een irritante bug/feature in de nieuwe busybox. Ik ben nu 2x met telnet ingelogd en beide shells delen dezelfde commandhistory.

[pieterg]

dat kan de 'arpping' zijn (poging om te kijken of het verkregen adres echt door niemand in gebruik is). Heb ik al eens uitgezet, maar maakt geen verschil.
Overigens is het geen dhcp probleem.
Als ik het netwerk down breng, en daarna met ifconfig simpel een fixed ip instel, en dan een ping laat lopen op de box, duurt het minuten voordat de eerste replies terug komen. En na een paar minuten houdt het weer op (en krijg je soms na een paar minuten nog oude replies), en zo gaat het door.
Dus absoluut een gigantische bug in de netwerk drivers.
Ik zet nu even ipv6 uit, kijken of het daar mee te maken heeft.

[pieterg]

ipv6 is niet de oorzaak

[Erik Slagter]

Ik zet nu even ipv6 uit, kijken of het daar mee te maken heeft.

: -)

Maar heeft het zin om ipv6 aan te zetten op een dreambox? Er zijn toch
geen services die ermee om kunnen gaan, ssh misschien?

[pieterg]

(ipv6 werd default niet gebruikt, maar de code werd wel meegelinkt in busybox. Maar dat was niet de oorzaak)

[pieterg]

heel simpel:
ifconfig eth0 down
ifconfig eth0 up

en dan is het afgelopen, de ethernet adapter werkt vanaf dat moment niet of nauwelijks meer.

[Erik Slagter]

heel simpel:
ifconfig eth0 down
ifconfig eth0 up

en dan is het afgelopen, de ethernet adapter werkt vanaf dat moment niet of nauwelijks meer.

Lekker... misschien dat dat ook verklaart waarom hij af en toe niet
door-"boot" bij mij.

Ik zou het eventueel ook kunnen testen, maar ik heb geen seriele kabel
eraan hangen (en dat is ook vrij lastig).

Paar regels in de kernel code uitschakelen? ;-)

[Sjaaky]

> ifconfig eth0 down && sleep 1 && ifconfig eth up

Levert bij ook een verbroken connectie op. Dus kan ik nu niet meer verder testen.