DHCP klient použije starou MAC po změně ip link set addr - DHCP neklapne

Poradíte mi debuggovat jeden podivný problém ohledně  MAC adresy a DHCP handshake??  Je to docela zapeklité, protože se to děje NÁHODNĚ (50% : funkční, 50% nefunkční)

Používám RPI jako router a mám na něm změněnou MAC adresu. Veškerá konfigurace je v skriptu, který je primitivně "spuštěn" sudo /home/me/startuj.sh v /etc/rc.local . (Samozřejmě moduly jako dnsmasq,stubby,  mají svoje konfiguráky , ale třeba i takový wpa_supplicant jde spustit onelinerem s argumentem -c <(wpa_passhrase ssid heslo) -i w1 )

První řádek skriptu je ip link set down w1; ip link set w1 address  XX-YY-----XX; ip link set up ew1h1, pak tam je sysctl, iptables -A, dnsmasq &,  stubby &, suplicant &   (s těmi & přeháním, většina toho má nějaký parametr aby to běželo jako daemon)



PROBLÉM:  V 50% případech   po spuštění WPA_SUPPLICANTU  odchozí komunikace DHCP obsahuje FIELD Client-Ethernet-Address což je políčko  v "aplikační" vrstvě DHCP starou MAC (před změnou pomocí ip link set addr).

A to dokonce i po manuální kill wpa_supplicant a dalším spuštění wpa_supplicant & tcpdum -enti w1 -vvv

Samozřejmě MAC adresa paketů je vždy správná (to je ale adresa na linkové vrstvě), kvůli této neshodě mi DHCP SERVER NEODPOVÍ
 
Kde se bere ale ta náhodnost, že někdy se stihne někde kdesi schovaná proměnná obsahující MAC adresu, která se vstříkne do Client-Address a jindy tam zůstane viset stará (a je následně nekonzistence, že ip a už hlásí novou)?

Vařím z vody, ale soudím, že to nebude něco "systémového", protože MAC adresa paketů vždycky sedí správně, ale problém je ta hodnota uvnitř dhcp paketu a to musí obsluhovat  nějaká služba DHCP.

Otázka 2: jak ručně vynutit, aby client-eth-addr byla aktuální, rovná mac adrese?

Otázka 3: je vůbec možné pole Client-eth-addr vypustit ? Nebo to je principiální nutnost, protože MAC adresu by mohl změnit router, když bude po cestě v  rozlehlejší síti, ? A i tak, jde vypustit , čímž by se implikovalo, že se má použít mac adresa z paketu? (ale asi je to nebezpečné řešení)


Rozumím, by to bylo nejlepší mít nakonfigurované v deseti souborech ve stylu systemd, na ideálně vlastní unity, ale tohle byl prostě takové nejjednodušší zprovoznění (v podstatě ne deklarativně, ale konstruktivně-procedurálně: přijdu k počítači kde nic neběží a rozběhám router přímočaře na zelené louce, že do něj zadám příkazy. Ta samá posloupnost příkazů pak je obsahem toho startovacího skriptu ).
« Poslední změna: 28. 09. 2021, 22:23:16 od mikesznovu »


Má to ešte nejakého iného správcu siete (napríklad niečo ako NetworkManager)?
Ak ano, asi bude potrebné v ňom vypnúť konkrétny interface.
Ak nie, tak systemd - treba riešiť závislosti.

RDa

  • *****
  • 2 467
    • Zobrazit profil
    • E-mail
Menit MAC na aktivnim rozhrani je blbost
Zmenil bych ji pred jakymkoliv poustenim WPA supplikantu a aktivaci sitovky.
Pak neni duvod aby tam visela stara.

Nastest v Gentoo skrze /etc/conf.d/net je to jen optiona a sitovy skripty to provedou na spravnem miste.


Možná jsem odhalil potenciální problémový článek - dhcpcd (ale ne co konkrétně tam blbne). Projistotu ještě upřesním že je problém v připojování do vnější sítě, tedy dhcp klienta. Vnitřní síť tady vůbec neřeším

No předpokládal jsem, že když je změna mac obalená příkazy set down  <> ; set up ; ,že není aktivní. A tahle změna je na začátku skriptu. wpa supplicant je na konci.

-Zkoušel jsem tam dávat i prodlevy sleep.
-Taky jsem zkoušel systemctl restart dhcpd po změně. Problém nezmizel,
-zkoušel jsem i  uplně na začátek dát stop dhcdp a po změně start dhcpcd.
- I přesunout start dhcpcd po wpa_supplicantu

V běžícím systému (tedy ne spuštění  routeru), když se v tom hrabu:

Divné je že příkaz dhcpd restart  skončí *někdy* chybou  (musel bych najít, něco jako lease expired)

Někdy pomůže druhé volání systemctl dhcpd restart, nebo stop  & start.
Pak už wpa_supplicant dává správné pole.

Je to dost záhadné, dějou se ty věci náhodně. Ještě zkusím rfkill block & unblock;

« Poslední změna: 29. 09. 2021, 12:57:05 od mikesznovu »

Re: dhcp<c>d restart fixuje mac...
« Odpověď #4 kdy: 29. 09. 2021, 13:03:41 »
Tak se omlouvám, přišel jsem, proč mi nejde ten ohejbák na dhcpcd. Měl jsem omylem zapsané systemctl start/stop/restart dhcpd místo dhcpcd

To takže narovnané to je, ale příčina zůstala, že bez restartu služby to  v 50% zaregistruje správně změněnou MAC a jindy tam visí stará
« Poslední změna: 29. 09. 2021, 13:05:33 od mikesznovu »


Re:dhcpd troubleshooting hlášek
« Odpověď #5 kdy: 29. 09. 2021, 14:16:03 »
Jenom pro informaci, ta chybová hláška dhcpcd restartu byla
Kód: [Vybrat]
dhcpcd[1108]  main: control_open: Connection refused.
dhcpcd[395]: wlan0: DHCP lease expired

toto nejspíš důsledek (oba dva řádky těsně po sobě)
 dhcpcd-run-hooks[471]: wlan0: failed to start wpa_supplicant
dhcpcd-run-hooks[472]: wlan0: Successfully initialized wpa_supplicant



taky systemd- (což ale asi není směrodatné)
systemd[1]: dhcpcd.service: Main process exited, code=killed, status=11/SEGV
 systemd[1]: dhcpcd.service: Failed with result 'signal'.

Možno ten ip link set w1 addr by by bolo vhodné dať v slučke s timeoutom so sledovaním status operácie, či sa MAC nastaví. Status OP by bolo vhodné si poznačiť do logu pre všetky tie príkazy 'ip'.
Čo keď sa lika nezhodí aj keď je ip link set w1 down?  máš ten príkaz pre zhodenie linky napísaný správne?
« Poslední změna: 29. 09. 2021, 16:12:48 od johanson14 »