DHCP Server "offered" prosím o rady

jchudoba

hapi Spíš bych to viděl na cizí DHCP v síti.

Rozhodně je to první věc kterou bych vyloučil.

Takže: Na začátku input chainu logovat cokoli co přileze na udp/68. Pokud se něco fakt logne, vzít MAC adresu a pátrat proč. Protože pokud něco přilezlo na udp/68 DHCP serveru, nemůže to být nic jiného než OFFER nebo ACK od nežádoucího DHCP serveru.

Pokud se nic nechytí, potom teorii o DHCP zahodit.

krystofklima všude pomohl jedině dowgrade. odpověď od MikroTiku je velmi podobná tomu, co zde píše Okoun, ale výsledek nula, ať měníem cokoli. downgrade to povětšinou vyřešil. zatím se mi zpět ani jeden neozval.

DHCP protokol je dost primitivní - jen 4 fáze: DISCOVERY, OFFER, REQUEST, ACK. Pokud se to sekne na fázi offer tak to znamená že klient nereagoval na OFFER zasláním REQUEST (třeba protože dostal offer odjinud), nebo že reakce na server nedorazila. Oboje se dá jednoduše sniffnout nebo lognout. Měnit kvůli tomuhle verzi ROS a tvrdit že to pomohlo...no, dost odvážné.

"Výsledek nula ať měníme cokoli" - nulový výsledek je tam kde se začíná měněním, nikoli diagnostikou. Tarže sniffnout a teprve potom měnit.

CarrolShellby Dobrý večer, můžete někdo poradit proč mi MT nepřipojí nějaká zařízení a napíše mi "offered" (kabel,wifi)

Zapni si to logování a dej vědět výsledek, půjdeme dále.

/ip firewall filter add action=log chain=input dst-port=68 log-prefix="parazitni DHCP" protocol=udp place-before=0

Stejně by posloužil DHCP Snooping, i ten vypíše detekci parazita do logu.

krystofklima

jchudoba Bohužel pro Vás i pro MikroTik, mám od pána potvrzeno, že pomohl downgrade, dokonce na jakoukoli verzi než 6.48.3...a to mi psali ze supportu, že určitě není chyba a musí to být kabela že máme prověřit zapojení /to se zkoušelo vícekrát, naposledy i s novým patchem CAT7 pro jistotu se zkusili i dva kusy/
Když jsem viděl tu smršť a diskuzi zde o tomto tématu, tak jsem se pro jistotu i zeptal znovu, zda to pomohlo.
Nyní to má support znovu na stole a předpokládám, že se k tomu vujádří opět stylem, že je to politováníhodné a záležitost jednoho kusu ;-(

Samozřejmě jen u zde zmiňované chyby OFFERED a také to může být i tak třeba kabelem...viz další oblíbená chyba FCS error

ludvik

V tomhle případě bych možná raději použil funkci Alert z DHCP serveru. To je aktivní test.

jchudoba

To je pravda. Účel by to splnilo, o tom žádná.

Tazatele jsem chtěl naučit primárně logovat, aby získal ten návyk že když mám s čímkoli problém, lognu nebo sniffnu si co se tam děje. Zrovna u DHCP to lze řešit i jinak než logem, u spousty jiných věcí ne -> logování je tedy univerzálnější.

Na druhou stranu slušně nastavený dhcpserver má na sobě jak snooping (má-li smysl), tak alerting, to je pravda.

disk

Take jsem mel problem. Mk router a unifi ap.
Nahodne ruzni klienti za ap.
Zmena tx power z auto na high a od te doby zatim klid.

iTomB

Taky se OFFER objevuje pri spatnem spojeni a nebo za nejakym blbym AP v rezimu klient. Zazil jsem tohle za extenderem TL-WA855RE.
06:35:57 dhcp,warning klient offering lease 192.168.1.122 for AE:84:C6:28:1D:9E without success 06:37:21 dhcp,warning klient offering lease 192.168.1.122 for AE:84:C6:28:1D:9E without success 06:38:45 dhcp,warning klient offering lease 192.168.1.122 for AE:84:C6:28:1D:9E without success 06:40:10 dhcp,warning klient offering lease 192.168.1.122 for AE:84:C6:28:1D:9E without success

# ADDRESS MAC-ADDRESS HOST-NAME SERVER RATE-LIMIT STATUS LAST-SEEN 0 D 192.168.1.109 66:17:59:A6:1A Galaxy-A42-5G klient bound 16h33m5s 1 D 192.168.1.100 AE:84:C6:51:EE klient bound 8h40m26s 2 D 192.168.1.122 AE:84:C6:28:1D:9E TL-WA855RE klient offered 5s 3 D 192.168.1.121 AE:84:C6:76:EC:7B klient bound 19h2s 4 D 192.168.1.105 AE:84:C6:FC:E9:50 IPC klient bound 1d7h1m39s 5 D 192.168.1.103 3C:58:C2:36:32:2E LAPTOP-3B2L... klient bound 18h18m56s 6 D 192.168.1.110 AE:84:C6:A6:1A:58 Galaxy-A42-5G klient bound 17h33m25s 7 D 192.168.1.112 AE:84:C6:36:32:2E LAPTOP-3B2L... klient bound 17h30m41s 8 D 192.168.1.104 B4:EC:02:8E:A5 MIB-WlanClient klient bound 16h19m13s

5 D 192.168.1.103 3C:58:C2:36:32:2E LAPTOP-3B2L... klient bound 18h18m56s 7 D 192.168.1.112 AE:84:C6:36:32:2E LAPTOP-3B2L... klient bound 17h30m41s

Predni cast powerline AE:84:C6, zadni daneho zarizeni 36:32:2E .

mpcz

Všechno nám to ukazuje na problém v narušené komunikaci, což je i můj názor kolemjdoucího. Asi by bylo dobré důkladně ověřit, zda k tomu opravdu dochází i na celotrasovém kabelu. Nebylo by taky špatné, pokud by Sergej tu hlášku vylepšil, t.j. zpodrobnil. Mám důvodné podezření, že ROS má jednoznačné zadání od programátora, kdy ji má vyhodit a o celém procesu má více podrobností, než plyne z té hlášky. To je letitý problém zjednodušených poruchových hlášek i jinde, hlavně v autech a IT, např. Win. mpcz, 21jul2021

CarrolShellby

Tak jsem nechal 3 dny běžet log a celkem často je problém na MT který je nastaven čistě jako switch s pevnou IP

Obr

krakonos

CarrolShellby Není tam nějaký pozůstatek v nastavení dhcp-server? Pošlete config.

CarrolShellby

Nemyslím si dle configu:

/interface bridge
add admin-mac=48:8F:5A:62:5D:06 auto-mac=no name=Bridge protocol-mode=none
/interface wireless security-profiles
set [ find default=yes ] supplicant-identity=MikroTik
/ip hotspot profile
set [ find default=yes ] html-directory=flash/hotspot
/interface bridge port
add bridge=Bridge interface=ether2
add bridge=Bridge interface=ether1
/ip address
add address=192.168.15.5/24 interface=Bridge network=192.168.15.0
/ip route
add distance=1 gateway=192.168.15.1

mpcz

CarrolShellby Ale ta hláška se poněkud liší od toho prvního popisu. Moc tomu nerozumím, to píše chvílemi česky? Nebo je to tvůj název něčeho? Jak je vlastně zapojeno celé zapojení tvého vláčku? Ta hláška se neustále opakuje pro stejné MACy/ IP? Ty IP a MACy patří čemu? Nebylo by nejlepší zachytit tu komunikaci, když se to vyskytuje často, strčit do Wiresharku? Ten záznam můžeš i tady poslat někomu, kdo tomu rozumí dopodrobna a máš detailní informace, které třeba povedou k řešení. mpcz, 23jul2021

CarrolShellby

mpcz
Log je s popisem česky dle návodu...

`Zapni si to logování a dej vědět výsledek, půjdeme dále.

/ip firewall filter add action=log chain=input dst-port=68 log-prefix="parazitni DHCP" protocol=udp place-before=0`

mpcz

krystofklima No tak to tedy nevím nevím, pokud jde o tu jeho ohlodanou hlášku "offered", která byla na přetřesu zpočátku, tak to mi dělá u některých klientů dlouhodobě, verzí to asi nebude. A dělá to permanentně u stejných DHCP klientů, ale jen občas, takže záchyt komunikace je dost problematický. Bohužel kolega ty informace podává po kouscích a ještě kusé. Svádět to na kabely dle mého asi nebude to pravé, protože to se dá vyloučit poměrně lehce a rychle. Proto je tady ta tzv. smršť. Kdyby pustil na MKT logování komunikace do souboru a udělal analýzu, pokud se mu nechce, tak to někomu poslal, viz výše, tak je to pořešené raz dva. Ale on to z nějakého důvodu nedělá, tak proto smršť. A třeba je v tom Sergej nevinně. Vidělo by se hned. Mě by to samotného zajímalo, v čem to vězí. mpcz, 23jul2021

krystofklima

souhlas, ale když pomůže jen čistý downgrade a žádná jiná změna ??
to je bohužel poměrně dost průhledné a ten problém provází MikroTik napříč verzemi od počátku věků

Teď mám zajímavý problém, kdy Audio Server Loxone si neumí vzít adresu z DHCP, respektive si ji vezme, ale za chvíli ji vrátí. Jinde supportem Loxone nevysledováno, pro jistotu jsme i vyměnili kus.
a budete se divit, s pitomým TP-Linkem se to neděje, dokonce ani s LinkSysem, který prostě v Rakousku mají
v MikroTiku samozřejmě ticho po pěšině. S tím, že MikroTik nedělá žádnou nestadardní operaci ani komunikaci, takže nevidí problém. druhá strana Loxone má velmi podrobný log k tomuto, logovací úroveň 3 se blíží Wiresharku nebo EtherDumpu a ti to ukončili jako chybu MikroTiku. Ten log jsem poslal do Lotyšska a od té doby zatím nic ;-(

začíná mi to být dost divné, na to, jak je DHCP jednoduchá služba

měl bych chválit MikroTik, bránit je, ale já jsem na to příliš rovný a jasný. Prostě tohle je šlendrián, ať s nima dělám 20let nebo ne

mpcz

Divíš se smršti a jen jsi ji rozšířil. Pokud máš tolik klientů, kteří mají tento problém, tak by asi bylo nejpřímější řešení, zachytit u nich komunikaci, to se dá i na dálku v každém mikrotiku tools/packet sniffer-em a je jasno.
Pokud bych já něco posílal Sergejovi jako chybu, tak by to byla právě ta komunikace a v ní označené místo, které neodpovídá normě nebo něco podobného. To je pak diskuze, která by k něčemu vedla. Tento problém takový postup umožňuje, tak proč to stále dokolečka okecávat, když existuje jednoduché řešení? Ještě by se to dalo vylepšit porovnáním komunikace na té funkční a údajně nefunkční verzi, což by mu dosti detailně ukázalo, kde je problém.
Pokud už to někdo "uzavřel" jako chybu Mikrotiku, docela by mě zajímalo, jak to jejich podání vypadalo. mpcz, 23jul2021

mpcz

Rozumí tomu někdo?

CarrolShellby

mpcz
Odpověď byla k tomu že to vypisuje v logu chvílemi česky.
Český popis je "parazitni DHCP"
To odhalilo zařízení které je hloupě nastaveno na switch s pevnou IP.
Ten jsem dnes vyměnil za jiný pro jistotu. Myslím že ale v tom chyba "offered" nebyla.Tento switch byl aplikován až později.

mpcz

OK, mluvíme oba o stejné hlášce? Ta tvoje je jen "offered" a nic dál?
OK, mluvíme o stejné detekci? Já mluvím o packet sniffer-u, ale cirkulují zde stále jen logy ze systému, které jak vidno, k cíli zatím nevedou. Zachyť si komunikaci přímo na rozhraní, pokud to dělá tak často, tak se ti to určitě podaří. Pak to rozeber paket po paketu a uvidíš, že uvidíš. Pokud na to nemáš čas, tak to tady někomu pošli. On se určitě někdo přihlásí. Pokud ne, tak to pošli mě.
Neustálou výměnou komponentů můžeš dosáhnout bezchybného stavu. Ale mysli na lidstvo. Pokud je to chyba Mikrotiku, tak se s tím bude trápit zbylých 7 miliard lidí zbytečně. 🙂 Nebylo by lepší to jednou pro vždy pořešit? Dík, mpcz, 23jul2021

CarrolShellby

mpcz
Ano, je jen "offered" DHCP server začne 30 sekund nabízet IP a pak zařízení vykopne.
To je pravda ale nejlehčí zatím bylo řešení parazitního DHCP což dnes opět něco vygenerovalo. A to na IP adrese NTB s WIN10.

Co se týče toho snifferu tak to se nějak pokusím nastudovat jak to nastavit.

mpcz

CarrolShellby Dle mého žádné velké studování není potřeba, nastavení je poměrně jednoduché a odehraje se na té jedné kartě snifferu. Je jen třeba zadat velký limit velikosti souboru, podle toho, jak často to háže tu hlášku. Studováním detailů procesu bych se být tebou teď nezabýval, to udělá v tomto případě někdo ochotný za tebe a taky z toho vysvětlení pak určitě nejlépe pochopíš, jak ten proces komunikace při DHCP probíhá, popř. měl by a neprobíhá. V ideálním případě, když už máš spadeno na toho klienta, který to dělá, tak chybu vyprovokovat, pak to máš chycené za pár minut. Pokud ne, dá se to v nastavení snifferu někdy vylepšit nahozením filtrů na porty, aby se ten log zbytečně nenafukoval do velkých rozměrů. Samozřejmě, pokud je ti studium koníčkem, studovat podrobnosti procesu klidně můžeš, ale dle mého to jen oddálí vyřešení problému. A o to se asi nyní jedná především.
Ta druhá věc - pokud by v síti byl druhý - nelegální DHCP server, mohlo by dojít k tomu, že by se NB nějak domluvil s ním. To by se asi dalo zjistit přímo v tom NB, na který ukázal ten Mikrotik, protože se pak stačí podívat, jakou má DHCP klient NB bránu, IP DHCP serveru atd. atd.
Pokud by zachycený chybující klient DHCP byl často ten NB s WIN10 a byl v tvé správě, pak je to úplně nejlepší varianta, nahrej Wireshark přímo na něj a máš to hned.
https://www.wireshark.org/download.html
mpcz, 26jul2021

jchudoba

Pozor, pro správnou interpretaci toho logování parazitů je třeba pročíst a pochopit https://en.wikipedia.org/wiki/Dynamic_Host_Configuration_Protocol#Operation, zejména kdo komu kdy posílá na udp/67 a kdy na udp/68.

Další stránka »