Beantwoord

Eigen modem - geen internet na reboot ook niet met T-Mobile modem


Hallo,

Ik heb sinds een maand een t-mobile glasvezel. Na dit mooie topic gelezen te hebben (https://community.t-mobile.nl/t-mobile-thuis-algemeen-490/glasvezel-draytek-vervangen-met-je-eigen-router-met-vlan-297061) heb ik 2 weken geleden geprobeerd om het huawei modem te vervangen door een Netgear R7000 (met DD-WRT).

Dus deze setup: Glasvezel -> Media Converter -> Netgear R7000.
In DD-WRT heb ik wat moeten prutsen om vlan 300 werkend te krijgen maar uiteindelijk is dat gelukt (https://forum.dd-wrt.com/phpBB2/viewtopic.php?p=1151657) en had ik internet.

Wat is er mis gegaan?
Vorige week moest ik de stroom even van de router halen en vanaf dat moment heb ik een hoop problemen gehad om weer internet te krijgen.
Op dat moment zag ik dat als ik de Netgear weer omwissel naar het huawei modem van tmobile dat ik daar dan ook geen internet kreeg. (Al zie ik dat vlan 640 en vlan 100 wel verbinding hebben in de huawei web ui). Ik heb toen ook al even geprobeerd met t-mobile te bellen (omdat het huawei modem het ook niet doet) maar daar kom ik niet verder dan het standaard wifi problemen script ("Ik zal proberen het wifi kanaal wijzigen").
Uiteindelijk heb ik het even laten liggen en na bijna precies een dag kreeg ik in eens weer internet in het huawei modem en daarna ook in het Netgear modem, prima dacht ik misschien een kleine hikup ergens


Nou is gisteren is hetzelfde gebeurt, router is gereboot en ik heb nu al bijna een dag geen internet meer.

Ik ben even in de router gedoken en ik zie via tcpdump het volgende:

code:
01:13:31.063680 IP (tos 0x0, ttl 64, id 0, offset 0, flags [none], proto UDP (17), length 328)
0.0.0.0.68 > 255.255.255.255.67: [udp sum ok] BOOTP/DHCP, Request from 1c:59:9b:c9:23:18, length 300, xid 0x4fd64b1b, Flags [none] (0x0000)
Client-Ethernet-Address 1c:59:9b:c9:23:18
Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message Option 53, length 1: Discover
Client-ID Option 61, length 7: ether 1c:59:9b:c9:23:18
MSZ Option 57, length 2: 576
Parameter-Request Option 55, length 10:
Subnet-Mask, Default-Gateway, Domain-Name-Server, Hostname
Domain-Name, BR, Static-Route, NTP
Classless-Static-Route, Classless-Static-Route-Microsoft
Vendor-Class Option 60, length 12: "udhcp 1.29.3"
END Option 255, length 0
PAD Option 0, length 0, occurs 17
01:13:31.086641 IP (tos 0xc0, ttl 30, id 62701, offset 0, flags [none], proto UDP (17), length 334)
31.201.208.1.67 > 31.20.203.92.68: [udp sum ok] BOOTP/DHCP, Reply, length 306, xid 0x4fd64b1b, Flags [none] (0x0000)
Your-IP 31.20.203.92
Client-Ethernet-Address 1c:59:9b:c9:23:18
Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message Option 53, length 1: Offer
Server-ID Option 54, length 4: 31.201.208.1
Lease-Time Option 51, length 4: 3600
Subnet-Mask Option 1, length 4: 255.255.255.0
Default-Gateway Option 3, length 4: 31.20.203.1
Domain-Name-Server Option 6, length 8: 37.143.84.228,37.143.84.229
Domain-Name Option 15, length 20: "ftth.glasoperator.nl"
BR Option 28, length 4: 31.20.203.255
END Option 255, length 0
01:13:31.113659 IP (tos 0x0, ttl 64, id 0, offset 0, flags [none], proto UDP (17), length 328)
0.0.0.0.68 > 255.255.255.255.67: [udp sum ok] BOOTP/DHCP, Request from 1c:59:9b:c9:23:18, length 300, xid 0x4fd64b1b, Flags [none] (0x0000)
Client-Ethernet-Address 1c:59:9b:c9:23:18
Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message Option 53, length 1: Request
Client-ID Option 61, length 7: ether 1c:59:9b:c9:23:18
Requested-IP Option 50, length 4: 31.20.203.92
Server-ID Option 54, length 4: 31.201.208.1
MSZ Option 57, length 2: 576
Parameter-Request Option 55, length 10:
Subnet-Mask, Default-Gateway, Domain-Name-Server, Hostname
Domain-Name, BR, Static-Route, NTP
Classless-Static-Route, Classless-Static-Route-Microsoft
Vendor-Class Option 60, length 12: "udhcp 1.29.3"
END Option 255, length 0
PAD Option 0, length 0, occurs 5
01:13:31.380351 IP (tos 0xc0, ttl 30, id 6126, offset 0, flags [none], proto UDP (17), length 328)
31.201.208.1.67 > 31.20.203.92.68: [udp sum ok] BOOTP/DHCP, Reply, length 300, xid 0x4fd64b1b, Flags [none] (0x0000)
Client-Ethernet-Address 1c:59:9b:c9:23:18
Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message Option 53, length 1: NACK
Client-ID Option 61, length 7: ether 1c:59:9b:c9:23:18
Server-ID Option 54, length 4: 31.201.208.1
END Option 255, length 0
PAD Option 0, length 0, occurs 41


Oftewel, mijn router vraagt aan tmobile's dhcp server een ip, de dhcp server geen het ip, maar zodra de router dat ip wilt gebruiken nack'd de dhcp server. Maar het hele vlan 300 gebeuren werkt


Heeft iemand een idee wat hier mis zou kunnen gaan? Het komt op mij over dat alleen de huawei een ip krijgt van de DHCP server maar ik heb geen idee waarom dit zou zijn + bij andere werkt deze setup wel goed?
icon

Beste antwoord door Richard_d 24 april 2019, 19:21

Ah ik denk dat ik er achter ben. Mijn router stond ingesteld op Europe/Berlijn timezone, nu ik deze heb aangepast naar Europe/Amsterdam werkt het direct, zelfs na het rebooten van mijn router.

Geen idee of dit het verholpen heeft en al helemaal niet waarom dit het zou verhelpen, Berlijn heeft immers dezelfde tijdzone als Amsterdam, maar volgens mij werkt dit.

Hopelijk helpt het iemand anders die hier tegen aanloopt 🙂

Bekijk origineel

21 reacties

Reputatie 4
Badge +2
Hallo Richard_d,

Het kan soms nodig zijn om een mac release uit te laten voeren na het wisselen van het modem. (Vrijgeven van het mac adres) Wellicht dat dit na een bepaalde tijd automatisch gaat.
Je kan proberen via de servicedesk een mac release aan te vragen. Backoffice van T-mobile zou dit dan moeten uitvoeren.
E.e.a. wordt officieel natuurlijk niet ondersteund.

Mvg. Marcel
Hi Marcel,

Bedankt goeie tip!

Mijn router's firmware heeft een 'clone Mac' functie en ik heb daar het huawei Mac adres ingevuld. Via tcpdump zie ik ook dat het huawei mac adres gebruikt wordt maar helaas zie ik precies hetzelfde.

Ik denk wel dat ik het in die hoek moet zoeken.. een of andere dhcp whitelist of iets dergelijks..

Heb je nog andere tips wat het zou kunnen zijn?
Reputatie 4
Badge +2
Misschien heeft @Hidden.nld nog tips?
Reputatie 6
Badge +11
@Richard_d Opmerkelijk is wat mij betreft de combinatie van IP adressen 31.201.208.1 en 31.20.203.92

Zie ook:
https://bgp.he.net/AS50266#_prefixes
@tmoesel dat is wel interessant ja..

Ik heb even gekeken en mijn IP adres van gisteren was toch ook in die range 31.20.203.xy

Het zou me niet verbazen als de mismatch tussen die 2 ranges de reden is dat de dhcp server de aanvraag afwijst. Alleen hoe kom ik er achter of dat echt een probleem is...

Is iemand toevallig in de gelegenheid een tcpdump te doen terwijl er een dhcp renew gedaan wordt?
Heel vreemd.

Ik heb vandaag niets aan de instellingen veranderd (op de clone mac address hierboven na aanleiding van @Marcel MCi 7 uur geleden).

De hele dag heeft de dhcp server het het adres 31.20.203.92 zitten aanbieden (om deze vervolgens nack'en zoals je ziet in de openings post).

Maar nu ineens heb ik internet, op het ip adres van gisteren!? 🤔

Het vervelende is dat ik er vrij zeker van ben dat als ik nu de router reboot ik weer een dag geen internet heb....
Reputatie 6
Badge +11
Je zou eens een traceroute kunnen doen naar een pseudo-random website ergens verder weg. De 31.20.0.0/16 range staat beschreven als "Pool for fixed WBA users". Is verder niet een conclusie uit te trekken maar zet wel aan het denken.
Verder blijken klanten met IP adres uit de range 31.201.0.0/16 soms achter een privaat netwerk van 10.x.x.x te zitten, dus publiek IP adres achter een privaat netwerk vanuit internet gezien.
Er is momenteel ook een storing bij TMT, misschien is dat een reden tot disfunctioneren.
@tmoesel Ik heb een traceroute gedaan in ik kom inderdaad langs 10.x.x.x

code:
traceroute to whitehouse.gov (23.57.17.36), 64 hops max, 52 byte packets
1 dd-wrt (192.168.1.1) 1.796 ms 0.916 ms 0.823 ms
2 1-208-201-31 (31.201.208.1) 76.512 ms 98.826 ms 79.417 ms
3 10.10.10.205 (10.10.10.205) 85.633 ms 96.307 ms 86.477 ms
4 10.10.10.197 (10.10.10.197) 84.897 ms 74.246 ms 95.511 ms
5 ae16-xcr1.dus.cw.net (195.2.28.254) 112.078 ms 101.056 ms 97.003 ms
6 akamaiint-gw-xcr1.dus.cw.net (195.2.15.122) 361.876 ms 307.564 ms 411.724 ms


Ik vraag me af of een storing dit zou kunnen veroorzaken gezien ik het zelfde probleem ook vorige week gehad heb. Maar het zou kunnen natuurlijk...

Wellicht dat 1 van de t-mobile mods weet wat het verschil van de ip ranges zou kunnen zijn?
Reputatie 6
Badge +11
@Richard_d Het zal niet met die storing in Overijssel te maken hebben bij nader inzien.
Wat opvalt is dat hop 2 van de trace hetzelfde adres (31.201.208.1) toont als in de eerdere DHCP sequentie de DHCP server zou moeten zijn, ook al is het nu een andere situatie (later tijdstip in ieder geval). De WAN zijde van de R7000 heeft nu dus hetzelfde adres als de DHCP server als ik het wel heb. Dat kan niet goed zijn m.i. Het zou kunnen dat een DHCP server in R7000/DD-WRT op 'zichzelf reageert', ten dele althans. Ik kan het in ieder geval niet plaatsen. Zoals je al aangeeft, hopelijk kan iemand anders met eigen router en TMT kijken wat de normale gang van zaken is. Verder zou je kunnen kijken of default gateway en netmask te verklaren waardes hebben.
Ik heb sinds een aantal dagen last van precies hetzelfde probleem op VDSL, na het herstarten van systemd-networkd krijg ik alleen nog maar NAK's terug op DHCP requests..

De verbinding komt meestal wel weer terug na een nacht wachten.

Ik zal de klantenservice eens vragen om een mac release..

Tcpdump voor de liefhebber:
code:
18:50:04.812410 70:85:c2:8a:3b:f5 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 320: (tos 0xc0, ttl 64, id 0, offset 0, flags [none], proto UDP (17), length 306)
0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 70:85:c2:8a:3b:f5, length 278, xid 0xb0ca8693, secs 64, Flags [none]
Client-Ethernet-Address 70:85:c2:8a:3b:f5
Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message Option 53, length 1: Discover
Client-ID Option 61, length 19: hardware-type 255, 56:50:4d:98:00:02:00:00:ab:11:be:cc:2b:61:25:28:a3:44
Parameter-Request Option 55, length 7:
Subnet-Mask, Default-Gateway, Hostname, Domain-Name
Domain-Name-Server, Static-Route, Classless-Static-Route
MSZ Option 57, length 2: 576
18:50:04.846388 00:02:00:00:00:03 > 70:85:c2:8a:3b:f5, ethertype IPv4 (0x0800), length 342: (tos 0xc0, ttl 30, id 30832, offset 0, flags [none], proto UDP (17), length 328)
85.146.100.1.67 > 85.146.103.13.68: BOOTP/DHCP, Reply, length 300, xid 0xb0ca8693, secs 64, Flags [none]
Your-IP 85.146.103.13
Client-Ethernet-Address 70:85:c2:8a:3b:f5
Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message Option 53, length 1: Offer
Server-ID Option 54, length 4: 85.146.100.1
Lease-Time Option 51, length 4: 3600
Subnet-Mask Option 1, length 4: 255.255.252.0
Default-Gateway Option 3, length 4: 85.146.100.1
Domain-Name Option 15, length 20: "ftth.glasoperator.nl"
Domain-Name-Server Option 6, length 8: 37.143.84.228,37.143.84.229
18:50:04.846938 70:85:c2:8a:3b:f5 > ff:ff:ff:ff:ff:ff, ethertype IPv4 (0x0800), length 332: (tos 0xc0, ttl 64, id 0, offset 0, flags [none], proto UDP (17), length 318)
0.0.0.0.68 > 255.255.255.255.67: BOOTP/DHCP, Request from 70:85:c2:8a:3b:f5, length 290, xid 0xb0ca8693, secs 64, Flags [none]
Client-Ethernet-Address 70:85:c2:8a:3b:f5
Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message Option 53, length 1: Request
Client-ID Option 61, length 19: hardware-type 255, 56:50:4d:98:00:02:00:00:ab:11:be:cc:2b:61:25:28:a3:44
Parameter-Request Option 55, length 7:
Subnet-Mask, Default-Gateway, Hostname, Domain-Name
Domain-Name-Server, Static-Route, Classless-Static-Route
MSZ Option 57, length 2: 576
Server-ID Option 54, length 4: 85.146.100.1
Requested-IP Option 50, length 4: 85.146.103.13
18:50:05.261745 00:02:00:00:00:03 > 70:85:c2:8a:3b:f5, ethertype IPv4 (0x0800), length 342: (tos 0xc0, ttl 30, id 48240, offset 0, flags [none], proto UDP (17), length 328)
85.146.100.1.67 > 85.146.103.13.68: BOOTP/DHCP, Reply, length 300, xid 0xb0ca8693, Flags [none]
Client-Ethernet-Address 70:85:c2:8a:3b:f5
Vendor-rfc1048 Extensions
Magic Cookie 0x63825363
DHCP-Message Option 53, length 1: NACK
Client-ID Option 61, length 19: hardware-type 255, 56:50:4d:98:00:02:00:00:ab:11:be:cc:2b:61:25:28:a3:44
Server-ID Option 54, length 4: 85.146.100.1
Reputatie 6
Badge +11
@Richard_d Het zal niet met die storing in Overijssel te maken hebben bij nader inzien.
Wat opvalt is dat hop 2 van de trace hetzelfde adres (31.201.208.1) toont als in de eerdere DHCP sequentie de DHCP server zou moeten zijn, ook al is het nu een andere situatie (later tijdstip in ieder geval). De WAN zijde van de R7000 heeft nu dus hetzelfde adres als de DHCP server als ik het wel heb. Dat kan niet goed zijn m.i. Het zou kunnen dat een DHCP server in R7000/DD-WRT op 'zichzelf reageert', ten dele althans. Ik kan het in ieder geval niet plaatsen. Zoals je al aangeeft, hopelijk kan iemand anders met eigen router en TMT kijken wat de normale gang van zaken is. Verder zou je kunnen kijken of default gateway en netmask te verklaren waardes hebben.

De trace is op router zelf uitgevoerd, daardoor wordt het WAN adres vervangen/gemaskeerd door 192.1681.1. Dus 31.201.208.1 zal de gateway zijn (en ook DHCPserver), dus ziet het er eigenlijk wel goed uit bij nader inzien. Wel vaag blijft het adress aanbod in de eerste tcpdump (31.20.203.92).
Ik heb als experiment het Huawei modem terug gezet op routed ipv bridged en zie in de logs dat deze ook een NAK's ontvangst. Maar het Huawei modem is een stuk brutaler en blijft DHCP server bestoken met requests en kreeg na 10 minuten wel een lease.

Dit is waarschijnlijk de reden waarom niet meer mensen hier last van hebben.
Reputatie 6
Badge +11
Ik heb als experiment het Huawei modem terug gezet op routed ipv bridged en zie in de logs dat deze ook een NAK's ontvangst. Maar het Huawei modem is een stuk brutaler en blijft DHCP server bestoken met requests en kreeg na 10 minuten wel een lease.

Dit is waarschijnlijk de reden waarom niet meer mensen hier last van hebben.

"het Huawei modem terug gezet op routed ipv bridged" roept vragen op. Voor zover ik weet kan de door TMT geleverde Huawei geen bridge, dus je doelt op een ander type Huawei of je hebt firmware veranderd en/of toegang tot het admin account. Dan gaat het dus in alle gevallen om 'eigen modem'. En is het glasvezel of DSL? Ik gok het laatste.
Reputatie 6
Badge +2
@Richard_d en @IPoAC

De DHCP server (67) client (68) communicatie lijk op orde.

  1. DHCP-Message Option xx, length 1: Discover
  2. DHCP-Message Option xx, length 1: Offer
  3. DHCP-Message Option xx, length 1: Request
  4. DHCP-Message Option xx, length 1: NACK i.s.o ACK
De Request vanuit de client is dus op de server niet goed verwerkt, terwijl de offer vanuit de server zelf is gekomen.
De vraag is dus nu eigenlijk, waarom negeert de DHCP zijn eigen offer?
"het Huawei modem terug gezet op routed ipv bridged" roept vragen op. Voor zover ik weet kan de door TMT geleverde Huawei geen bridge, dus je doelt op een ander type Huawei of je hebt firmware veranderd en/of toegang tot het admin account. Dan gaat het dus in alle gevallen om 'eigen modem'. En is het glasvezel of DSL? Ik gok het laatste.

Ik heb een generieke Huawei firmware op de HG659 gezet waardoor je inderdaad toegang krijgt tot de admin account. Het gaat over DSL, anders had ik het ding helemaal niet aangesloten natuurlijk 😉
Reputatie 3
Badge +2
Hoi IPoAC en Richard_d, duizendmaal sorry voor mijn late reactie. Jullie berichten zijn er vanwege een fout systeem tussendoor geglipt, vandaar dat jullie eerder niets van mij hebben vernomen. Hoe staat er het ondertussen voor? Omdat het een poosje geleden is hoop ik stiekem dat het ondertussen netjes is opgelost. Mochten jullie mijn hulp toch nog nodig hebben, laat het mij dan meteen weten. Ik sta voor jullie klaar! 😄
Het probleem is na een paar dagen vanzelf weggegaan en is niet meer terug gekomen. Bedankt voor de ondersteuning 🙂
Hi @Cheyenne ,

Bij mij is dit helaas nog niet opgelost. De afgelopen tijd heb ik er geen last van gehad omdat mijn router niet opnieuw is opgestart.

Maar we hadden vanochtend een korte stroomstoring en sinds een uur of 12 hebben we geen internet meer vanwege het bovenstaande.

Is het mogelijk om een Mac release uit te voeren zoals @Marcel MCi hierboven aangaf als optie? Of in ieder geval iemand bij jullie vragen of dit een mogelijke oplossing kan zijn?
Ah ik denk dat ik er achter ben. Mijn router stond ingesteld op Europe/Berlijn timezone, nu ik deze heb aangepast naar Europe/Amsterdam werkt het direct, zelfs na het rebooten van mijn router.

Geen idee of dit het verholpen heeft en al helemaal niet waarom dit het zou verhelpen, Berlijn heeft immers dezelfde tijdzone als Amsterdam, maar volgens mij werkt dit.

Hopelijk helpt het iemand anders die hier tegen aanloopt 🙂
Reputatie 7
Badge +10
Hey @Richard_d,

De pro's hebben gewoon de media convertor modem en nas gewoon achter een UPS hangen :)
Dan heb je dat gedonder met stroomstoringen ook niet 🙂
Reputatie 6
Badge +6
Hi @Richard_d, top dat je er achter bent. Ik heb je antwoord gemarkeerd als 'beste antwoord' voor eventuele andere gebruikers die tegen hetzelfde probleem aanlopen. Wel bijzonder dat de tijdzone de oorzaak blijkt te zijn 🤷🏻

Reageer