Wat gateway-ping-timeout yn NetworkManager echt ôfwachtet

Do fine connection.gateway-ping-timeout yn in diskusje oer in laptop dy't opkomt foardat it netwurk brûkber is, do ferheegest it, en der feroaret wat. Oft de feroaring holp om 'e reden dy'tsto tinkst, is in aparte fraach. It antwurd begjint by wat de aktivaasje eins docht wylst dy timer rint, en by it feit dat it wachtsjen twa mooglike einen hat.

Folchje ien ferbining fanôf de opdrachtline en de betsjutting wurdt konkreet.

Folchje ien aktivaasje

Begjin by de bewarre ferbining ynstee fan by in algemiene standert, want dit is in eigenskip per ferbining. Foegje --show-secrets allinnich ta as do it eins nedich hast; de ynstelling sels is gjin geheim.

nmcli -f connection.id,connection.gateway-ping-timeout connection show
nmcli connection show "Wired connection 1" | grep gateway-ping

Mei de eigenskip op nul, dat is de dokumintearre standert, giet de aktivaasje fierder sadree't de adressearring klear is. Set it op in positive wearde en de aktivaasje fan 'e IP-konfiguraasje wachtet oant der in antwurd fan 'e gateway komt of de timeout ferrint.

Bring de ferbining dan del en wer omheech wylstst it barrenstream folgest. De oarder dy'tsto sjochst is de ynstelling oan it wurk: apparaatsteat, adressearring, it wachtsjen en úteinlik de aktivearre steat dêr't ôfhinklike tsjinsten meastentiids op ôfstimd wurde.

It wachtsjen hat twa einen

Beide einen binne fan belang, en de measte minsken betinke mar ien. In antwurd fan 'e gateway makket it wachtsjen betiid dien, en de timeout makket it ek dien, of der no wat antwurde hat of net. De eigenskip ferget gjin suksesfolle ping foardat de aktivaasje klear wêze kin.

Dy iene sin helpt in soad betizing fuort oer laptops yn hotels en konferinsjesintra, dêr't in captive portal ICMP faak wegert oantst ynloggest. De ferbining aktivearret noch altyd nei't de timeout ferrûn is; se docht it allinnich letter as nedich wie, en elke tsjinst dy't nei de ferbining oardere is wachtet mei.

It is ek gjin kontrôle oft de ferbining noch libbet. Neat yn 'e beskriuwing begjint in gateway te pingjen nei't de ferbining omheech is, en neat ferbrekt in aktyf profyl omdat in lettere ping mislearret. As do ferliesdeteksje nedich hast, heart dat by de eigner fan it protokol of de tunnel, net by in eigenskip dy't ien kear by de aktivaasje rûn.

Twa objekten, ien ynstelling

It bedrade basisprofyl en in VPN-profyl binne aparte konfiguraasjeobjekten, en de eigenskip op ien sette hat gjin ynfloed op 'e oare. In VPN-profyl dat in basisferbining neamt, ervet gjin fan har aktivaasje-ynstellingen, en dêrom kin de wearde dy'tsto feroare hast lykje gjin effekt te hawwen op watsto folgest.

nmcli -f NAME,UUID,TYPE connection show
nmcli connection show "Office VPN" | grep gateway-ping

Lês de UUID's ynstee fan 'e nammen. Nammen wurde dûbeld nei in werinstallasing of in werombrocht profyl, en twa ferbiningen mei deselde sichtbere namme stjoere dy it ferkearde bestân te bewurkjen wylst it echte ûnferoare bliuwt.

De ynstallearre NetworkManager-ferzje makket ek út. It gedrach fan 'e plugin en hoe't in ferbiningstype dizze eigenskip op syn eigen aktivaasjestappen mappet, ferskille, dus test op 'e ferzje dy'tsto útbringe, ynstee fan oan te nimmen dat in berjocht datsto fûn hast ûnferoare jildt.

Wat it wachtsjen net bewierskje kin

Hjir is it part dat de measte tiid kostet. In antwurd fan 'e lokale router bewiist dat ien host ien ICMP-echo beantwurde by de aktivaasje. It bewiist net dat in VPN-einpunt oplost, dat de identiteit fan 'e klant akseptearre wurdt, dat priveerûtes ynstallearre waarden, dat de kantoarresolver antwurdet, of dat de applikaasje dy'tsto bedoelst wurkje sil.

Dat binne aparte ôfhinklikheden mei apart bewiis. In gateway kin antwurdzje wylst DNS mislearret, en in gateway kin ICMP stilwei neffens belied falle litte wylst elk applikaasjepaad wurket. Dêrom is it poarten op dizze eigenskip in gissing oer hokker laach let is, gjin mjitting derfan.

As do wachtest op in ôfhinklike tsjinst, neam wat dy nedich hat. In tawiisd adres wurdt beantwurde troch adressearring. In tunnel wurdt beantwurde troch de eigen steat fan 'e tunnel. In privénamme wurdt beantwurde troch in query. In applikaasje wurdt beantwurde troch de applikaasje, en gjin fan dy antwurden komt fan in timer dy't nei de gateway neamd is.

As do it feroarrest, skriuw dan op wêrom

Skriuw de foarige wearde en de reden op foar in goedkarde wiziging, en set it dan op 'e spesifike ferbining ynstee fan oeral. In langer wachtsjen ferskoot de aktivaasjetiid foar alles dat nei dy ferbining oardere is, wat in stadich systeem goed lykje litte kin en in fluch systeem kapot.

Ien histoaryske falstrik is it neamen wurdich: in wearde as dizze wurdt soms feroare om in âldere editor in profyl akseptearje te litten. As dat it echte ferhaal is, hast twee barrens, net ien. De editor bewarre, en in libbend netwurkbelied feroare. Reparearje de editor of de plugin en set de timer werom.

De NetworkManager-boarne definiearret de eigenskip as in fertraging fan it sukses fan IP-adressearring oant in gateway-antwurd of de timeout, mei in standert fan nul, en de definysje fan 'e ferbiningsynstelling is de referinsje om te lêzen foardatsto fertroust op hokker gedrach dan ek dat fan hearsaai beskreaun is.