Témata

1

Sítě / Kontaktuje WireGuard peera vždy?

« kdy: 29. 08. 2023, 21:38:59 »

Měl bych takový dotaz k fungování wireguardu  v situacích, kdy druhý peer je nedostupný.  Mám modelový příklad: na VPS běží Wireguard a přes PREROUTING mám naforwardován vybraný port na koncové zařízení.


Pokud dojde k výpadku připojení koncového připojení, bude se ho VPS snažit kontaktovat  pokaždé, když přijde paket který má být forwardovaný? Nebo jsou tam nějaké timeouty (třeba vycházející z conntrack)?

Tím spíš, když koncové zařízení je za NATema výpadek trvá déle než  2 minuty. pak by vysílal VPS UDP do "černé dírky", jelikož NAT ISP už rozetnul spojení.


Zatímco v druhé situaci, kdy místo UDP je využit  (z koncového zařízení) ssh -w 1:2 prostě  root@vps.com "ip addr add x y peer z;ip link set tun2 up; ip r add x via y;", s vhodně zvolenými parametry Clieant/ServerAliveInterval/TCPKeepAlive prostě  ssh tunel zkolabuje jako magnetické pole po vypnutí proudu.

Vite o něčem. co by podobného chování docílilo u wireguardu (konfigurace, určo tam je nějaký keepalive, ale to je jen interval přeposílání "handshaku"), aspoň co by dalo interface do down.

2

Sítě / Tcpdump nezachytí některé pakety

« kdy: 09. 08. 2023, 14:50:27 »

Když zachytávám přes su(do) tcpdump se stejným filtrem pakety, tak na androidu mi jich zachytí méně (za stejné období 24 oproti 87)
Proč tomu tak je?

Konkrétně jde o UDP pakety na výpisu  s označením nat-isakmp-keepalive : na druhém výpisu z telefonu, chybí. Mělo by jít o IPSec tunel.

Nemůže  právě odtud IPSec # Implementations vítr vát ?  Zde se píše o dvou implementacích stacku. Může nějak to mluvit i následně do toho, co tcpdump/uvidí/zachytí?

Jaké je vysvětlení, že ty pakety tam prostě nejsou? (Pro potvrzení, na routeru jsem capturoval taky i vnější rozhraní a pakety tam viděl, tedy stejný výsledek jako na vnitřením rozhraní)

Jde jen o útržek z logu, nechtěl jsem postovat všech 87 řádků

Kód: [Vybrat]

su -c " tcpdump -ni wlan0  'port 4500 || port 500|| net 62.0.0.0/8 '" -t
tcpdump: verbose output suppressed, use -v or -vv for full protocol decode
listening on wlan0, link-type EN10MB (Ethernet), capture size 262144 bytes

IP 192.168.3.26.41404 > 62.33.99.59.4500: NONESP-encap: isakmp: child_sa  inf2[I]       
IP 62.33.99.59.4500 > 192.168.3.26.41404: NONESP-encap: isakmp: child_sa  inf2[R]       
IP 192.168.3.26.41404 > 62.33.99.59.4500: NONESP-encap: isakmp: child_sa  inf2[I]       
IP 62.33.99.59.4500 > 192.168.3.26.41404: NONESP-encap: isakmp: child_sa  inf2[R]       
IP 192.168.3.26.41404 > 62.33.99.59.4500: NONESP-encap: isakmp: child_sa  inf2[I]       
IP 62.33.99.59.4500 > 192.168.3.26.41404: NONESP-encap: isakmp: child_sa  inf2[R]       
IP 192.168.3.26.41404 > 62.33.99.59.4500: NONESP-encap: isakmp: child_sa  inf2[I]       
IP 62.33.99.59.4500 > 192.168.3.26.41404: NONESP-encap: isakmp: child_sa  inf2[R]       
IP 192.168.3.26.41404 > 62.33.99.59.4500: NONESP-encap: isakmp: child_sa  inf2[I]       
IP 62.33.99.59.4500 > 192.168.3.26.41404: NONESP-encap: isakmp: child_sa  inf2[R]       
IP 192.168.3.26.41404 > 62.33.99.59.4500: NONESP-encap: isakmp: child_sa  inf2[I]       
IP 62.33.99.59.4500 > 192.168.3.26.41404: NONESP-encap: isakmp: child_sa  inf2[R]       
IP 192.168.3.26.41404 > 62.33.99.59.4500: NONESP-encap: isakmp: child_sa  inf2[I]       
IP 62.33.99.59.4500 > 192.168.3.26.41404: NONESP-encap: isakmp: child_sa  inf2[R]       
IP 192.168.3.26.41404 > 62.33.99.59.4500: NONESP-encap: isakmp: child_sa  inf2[I]       
IP 62.33.99.59.4500 > 192.168.3.26.41404: NONESP-encap: isakmp: child_sa  inf2[R]       
IP 192.168.3.26.41404 > 62.33.99.59.4500: NONESP-encap: isakmp: child_sa  inf2[I]

IP 62.33.99.59.4500 > 192.168.3.26.41404: NONESP-encap: isakmp: child_sa  inf2[R]       
IP 192.168.3.26.41404 > 62.33.99.59.4500: NONESP-encap: isakmp: child_sa  inf2[I]       
IP 62.33.99.59.4500 > 192.168.3.26.41404: NONESP-encap: isakmp: child_sa  inf2[R]       
IP 192.168.3.26.41404 > 62.33.99.59.4500: NONESP-encap: isakmp: child_sa  child_sa[I]   
IP 62.33.99.59.4500 > 192.168.3.26.41404: NONESP-encap: isakmp: child_sa  child_sa[R]   
IP 192.168.3.26.41404 > 62.33.99.59.4500: NONESP-encap: isakmp: child_sa  inf2[I]       
IP 62.33.99.59.4500 > 192.168.3.26.41404: NONESP-encap: isakmp: child_sa  inf2[R]
^C
24 packets captured
24 packets received by filter
0 packets dropped by kernel

Na routeru:

Kód: [Vybrat]

sudo tcpdump  -ti eth0 "port 4500 || net
62.0.0.0/8 || port 500" -n
IP 192.168.3.26.41404 > 62.33.99.59.4500: isakmp-nat-keep-alive
IP 192.168.3.26.41404 > 62.33.99.59.4500: isakmp-nat-keep-alive
IP 192.168.3.26.41404 > 62.33.99.59.4500: isakmp-nat-keep-alive
IP 192.168.3.26.41404 > 62.33.99.59.4500: NONESP-encap: isakmp:
IP 62.33.99.59.4500 > 192.168.3.26.41404: NONESP-encap: isakmp:
IP 192.168.3.26.41404 > 62.33.99.59.4500: isakmp-nat-keep-alive
IP 192.168.3.26.41404 > 62.33.99.59.4500: isakmp-nat-keep-alive
IP 192.168.3.26.41404 > 62.33.99.59.4500: isakmp-nat-keep-alive
IP 192.168.3.26.41404 > 62.33.99.59.4500: isakmp-nat-keep-alive
IP 192.168.3.26.41404 > 62.33.99.59.4500: isakmp-nat-keep-alive
IP 192.168.3.26.41404 > 62.33.99.59.4500: isakmp-nat-keep-alive
IP 192.168.3.26.41404 > 62.33.99.59.4500: NONESP-encap: isakmp:
IP 62.33.99.59.4500 > 192.168.3.26.41404: NONESP-encap: isakmp:
IP 192.168.3.26.41404 > 62.33.99.59.4500: isakmp-nat-keep-alive
IP 192.168.3.26.41404 > 62.33.99.59.4500: isakmp-nat-keep-alive
IP 192.168.3.26.41404 > 62.33.99.59.4500: isakmp-nat-keep-alive
IP 192.168.3.26.41404 > 62.33.99.59.4500: isakmp-nat-keep-alive
IP 192.168.3.26.41404 > 62.33.99.59.4500: isakmp-nat-keep-alive
IP 192.168.3.26.41404 > 62.33.99.59.4500: isakmp-nat-keep-alive
IP 192.168.3.26.41404 > 62.33.99.59.4500: NONESP-encap: isakmp:
IP 62.33.99.59.4500 > 192.168.3.26.41404: NONESP-encap: isakmp:
IP 192.168.3.26.41404 > 62.33.99.59.4500: isakmp-nat-keep-alive
IP 192.168.3.26.41404 > 62.33.99.59.4500: isakmp-nat-keep-alive
IP 192.168.3.26.41404 > 62.33.99.59.4500: isakmp-nat-keep-alive
IP 192.168.3.26.41404 > 62.33.99.59.4500: isakmp-nat-keep-alive
IP 192.168.3.26.41404 > 62.33.99.59.4500: isakmp-nat-keep-alive

87 packets captured
87 received
0 dropped

Verze na androidu(kde je méně paketů) je :

Kód: [Vybrat]

su -c tcpdump --version                                                             tcpdump version 4.9.2                                                                   libpcap version 1.9.0-PRE-GIT (with TPACKET_V3)                                         BoringSSL


Na routeru:
tcpdump --version
tcpdump version 4.9.3
libpcap version 1.8.1
OpenSSL 1.1.1d  10 Sep 2019

3

Windows a jiné systémy / Windows Firewall - specifikace bloku IP adres kromě určitých adres

« kdy: 09. 08. 2023, 13:28:19 »

Lze v windows firewallu určit takové firewallové pravidlo(nebo dvě), které  danému procesu  (Tab "Programy a služby"=cesta k exe) zablokuje (Tab: Obecné: akce=Blokovat) konektivitu  všem adresám(Tab:Obor=  přepínač libovolná adresa) kromě pár vybraných IP? (políčko vzdálená adresa)

Zkoušel jsem udělat druhé pravidlo pro stejný proces, ale s Tab:Obecné=Povolit a Tab:Obor:přepínač =vybrané adresy:a do seznamu je vepsat)

jenže je dále blokovano?

Jak to řešit? problém lze řešit jen aplikačním FW na tomto PC. Má windows firewall v sadě pravidel nějaké pořadí?

PS: hledal jsem i na stackoverflow, jenže tam radí odpověď na jiný problém. Radí zmenit politiku firewallu a následně povolit pár IP adres. To by uplně rozhasilo politiku firewallu na tomto pc. tu chci nechat. Já jen chci řešit sadu pravidel pro jeden program.

Snad mě nečeká  řešení pouze jednoho pravidla Blokovat a v obor se pokusit čarova s maskami typu 0.0.0.0/1,128.0.0.0/2,192.0.0.0/2..... 194.0.0..... to bych na to zaprvý musel mít nějaký generátor a naklikat by trvalo 15 minut

Přitom by stačilo jediné, aby (v rámci 1 jednoho pravidla)do Obor šlo přidat něco jako vyjímka nebo zápis s prefixem + a -, takže například bych danému programu zablokoval 180.2.1.0/24 a v zápětí vyjmout 180.2.1.16/28

Jenže když dám 2 pravidla, tak pravidlo povolit ho nepřepíše. P

zde je obrázek té hrůzy:

4

Server / Význam reason→comment:arc=fail v DMARC

« kdy: 09. 08. 2023, 10:44:23 »

Zdravicko,narazil jsem v DMARC reportu posílaném mě v uzlu ROW na neznámý atribut REASON (vyznačen v prostředním bloku). Co to prosím znamená? jde o normálně poslanou novou zprávu
, žádné FWD , ani bounce ani přeposílku ani SRS ani čachry. Tedy na mé straně aspoň.


Vypadá to, že to dělá jen pro jeden konkrétním SMTP MX server .kam posílám poštu. (Samozřejmě že dmarc-odesílající server není totožný s příslušným SMTP. Nutně. )

Nějaké ARC je pro mě spanělská vesnice, tak prosím o nějaké stručné shrnutí a vůbec, jak tyto řádky chápat, co znamenají a co si z toho odnest

Kód: [Vybrat]

<policy_published>
        <domain>xy.cz</domain>
        <adkim>r</adkim>
        <aspf>r</aspf>
        <p>quarantine</p>
        <sp>quarantine</sp>
        <pct>100</pct>
    </policy_published>
…
<record>  <row>
            <source_ip>254.0.68.2?9</source_ip>
            <count>1</count>
            <policy_evaluated>
                <disposition>none</disposition>
                <dkim>fail</dkim>
                <spf>pass</spf>

Tady:

Kód: [Vybrat]

             <reason>
                    <type>local_policy</type>
                    <comment>arc=fail</comment>
                </reason>

pokračování

Kód: [Vybrat]

            </policy_evaluated>
        </row>
        <identifiers>
            <header_from>xy.cz</header_from>
        </identifiers>
        <auth_results>
            <spf>
                <domain>xy.cz</domain>
                <result>pass</result>
            </spf>
        </auth_results>
    </record>

5

/dev/null / co jsou béčkové subdomény domény facebook

« kdy: 05. 08. 2023, 18:47:22 »

b-graph a b-www domény facebook.com. v čem se odlišují od těch bez b-?

6

Sítě / Android v tcpdump ukazuje komunikaci z jiné sítě

« kdy: 31. 07. 2023, 19:29:57 »

Všiml jsem si v tcpdump v telefonu (na AP ne ani v dmesg|grep martian) zvláštních paketů v rozsahu 10.x.x.x přestože je v režimu offline. Takovou síť ani na domácí síti nemám(router  ani takový paket nezachytí, ani přes martian, jak tohle vysvětlit).Jako kdyby šlo o pakety patřící do rozsahu rozhraní  rádiového rozhraní rmnetdata1:

Kód: [Vybrat]

  ~ $ su -c ip r                                      
10.1.100.116/30 dev rmnet_data1 proto kernel scope link src 10.1.100.117

0: rmnet_data1: <UP,LOWER_UP> mtu 1280 qdisc htb state UNKNOWN group default qlen 1000                       link/(530)                                          
inet 10.1.100.117/30 scope global rmnet_data1           valid_lft forever preferred_lft forever

su -c logcat  grep 10\\.1 nebo 65 nic neukazuje

Bohužel už to nedokážu nasimulovat
 přes tcpdump -ni wlan0 "udp||arp:
 ale bylo to n+co jako 10.65.něco:random port  > na 10.1.100.117:50020 ..


taky su -c ss -ap |grep 50020 hlásil  TCP - LISTEN  0.0.0.0:50020 users=netmgrd

pro jistotu jsem projeil přes cat /proc/1115/{comm,cmdline} že jde /system/vendor/bin/netmgrd


-Co dělá?
-Proč tcpdump vypsal na wlan0 tento UDP paketu (payload length  45)

-čemu patří port 50020(v tomto kontextu)?
Telefon byl v režimu offline, jen wifina běžela, připojena
-Proč ip adresa rádiového rozhraní prosákla na wlan0?
Je rozhraní skrytě zapnuté? (jsou vidět záhlaví rozhraní rmnet_data... LOWER_UP atd)
Další věc, která je divná, že  v tcpdumpu bylo UDP ale ss hlásí TCP

Je fakt smůla, že nynÍ se to nepodaří zachytit.

7

Hardware / Zvláštnost myši Logitech, závislost na typu USB

« kdy: 30. 07. 2023, 21:50:36 »

Dumá mi hlavou, čím může být způsoben tento problém. Jaké si ladění myši, ale proč to vyžaduje USB 2.0? Vždyť myš přece je taky USB 2.0  a tím pádem USB 3.0 nevidí.

Myš má být schopna se automaticky vyladit na povrch, na němž ji budeme používat, k čemuž slouží jednoduchý proces. Ten vyžaduje, abychom stiskli levé tlačítko a s myší pár sekund opisovali ležatou osmičku, přičemž její senzor se přitom sám kalibruje.

Nicméně tento proces se nedařilo nastartovat, ale řešení bylo opět jednoduché. V tu dobu byla G502 zapojena k USB hubu v monitoru, přes což se aplikace nedokázala přenést, takže bylo nutné myš zapojit přímo k jednomu z USB 2.0 na základní desce. Ne USB 3.0, protože na tom ladění také nefunguje. Logitech o problému ví, ovšem už dva měsíce, takže se teprve uvidí, kdy přijde na svě nová verze Gaming Software.
REcenze

(recenze g502)

Napadá mě snad jedna věc, která by se toho mohla a týkat a asice jakýsi muxing USB 3.0, 2.0 a 1x portů. Omlouvám sem, už nevím kterých verzích se to týká Platí, že USB 2.0 používá jiné vedení než superspeed signál a  Že usb řadiče (řekl bych ty v těch hubech) mají jakési 2 režimy pro uplink: buď nižší verze USB trafficu přimíchají do toho aktuálního (do 3.0) a nebo to jde odděleně. Tady je link : Transaction  Translator Ale netuším, jestli tohle s tím vůbec souvisí, mám pocit, že by nemělo

8

Sítě / Jak operátoři blokují zahraniční VoWiFi?

« kdy: 15. 07. 2023, 12:41:05 »

V článku "Dovolená mimo EU: jak neprodělat na předraženém roamingu "  z 3.7. (tedy novějším než hulánův článek, ale za boha mě se tam neukazuje datum vydání článku, ale ostatním prý ano, článek nemá ani HTTP hlavičku Last-Modified, ani datum v zdrojáku nevidím) jsem četl, že prý operátoři blukují zahraniční Vo-wi-fi. Jakým způsobem?

Kontrolují, jestli IP, ze které se telefon přes wlan0 rozhraní snaží připojit k IMS nebo _PDG serveru ( reply epdg.epc.mnc
00x.mcc230.pub.3gppnetwork.org is 62.x.y.zz která se podle nějakého pochybného maxmind seznamu nejeví jako česká?

Pomůže se tím tunelování tohoto provozu přes tunel (případně bohatě stačí, když wifina bude mít vnější IP adresu českou a na telefonu není potřeba hnout brvou)?
Nebo nějak jinak? (to dělají a nebo jak to obejít)

Případně je to opravdu pravda? To by pak nesouhlasilo i třeba s tím odkazovaným článkem. (Nebo je něco jako selektivní blokace, že zrovna v thajsku to šlo)

 

VoWiFi), toho čeká nepříjemné zklamání. Čeští operátoři tuto službu v zahraničí blokují. Tedy není možné být v roamingu s aktivní českou SIM kartou a us
"Dovolená mimo EU: jak neprodělat na předraženém roamingu "

9

Software / Aplikace Newpipe nepřežije půlnoc (0:00)

« kdy: 10. 07. 2023, 17:14:31 »

Měl jsem asu hodinu  spušteny newpipe na androudu , hrál.mi na pozadí.

Jenže přesně o půlnoci hraní přestalo a po 3minjsem(0:03) se podival na mobil a notifikace s broukem:
Otevřu a poleje mě Guru mediation v čase 0:00.


Co to sakra je? Někde soudruzi udělali chybu při výpočtu času třeba ? (Chyba asserce monitoniho času  hrabní třeba)

10

Windows a jiné systémy / Nefunguje vytáčení odklepnutné entrem-chybný kód MMI

« kdy: 09. 06. 2023, 15:16:58 »

Když na androidu do dialeru vyťukám číslo pro zjištění kreditu (*103#) a "vytočím" ťuknutím na zelené dotykové tlačítko, vše je OK. Dokonce i když samotných pět znaků napíšu na externí klávesnici. Záleží jen na  té "koncovce"
Když místo ťuknutí na zelené tlačítko ale odpálím příkaz Entrem, tak se mi vrátí  hned dvě(sic!) hlášky:

Problém s připojením nebo neplatný kód MMI.
----
Problém s připojením nebo neplatný kód MMI.

Druhá hláška (popup až po zavření toho prvního popupu:)

Problém s připojením nebo neplatný kód MMI.

OS Android 11. AOSP.


Setkal jste se někdo s tímto problémem? Tak vám to blbne? Je někdo, kdo mu to funguje odklepnout i entrem?



Kde je problém?


PS: vytáčení numerických telefoních čísel je OK(iniciace hovoru), *#06# tak OK(jenže) tam se nemusí nic odpálit, stačí napsat poslední znak a už to jede

11

Desktop / Nefunguje zvuk v Chrome

« kdy: 29. 05. 2023, 16:26:11 »

Chrome mi nedokáže přehrát zvuky.
- videa bez zvukové stopy mi chrome přehrává OK .
 videa se zvukovou stopou se nepřehrají
- když otevřu file:// zvuk.wav nebo ogg , okénko s progresbarem a stopáží se ukáže ale nic se nepřehrává (identické jako přechozí odrážka)
hlásí  mi chrome(z terminálu):

Kód: [Vybrat]

../../sandbox/linux/seccomp-bpf-helpers/sigsys_handlers.cc:**CRASHING**:seccomp-bpf failure in syscall 0242
../../sandbox/linux/seccomp-bpf-helpers/sigsys_handlers.cc:**CRASHING**:seccomp-bpf failure in syscall 0242
../../sandbox/linux/seccomp-bpf-helpers/sigsys_handlers.cc:**CRASHING**:seccomp-bpf failure in syscall 0242
../../sandbox/linux/seccomp-bpf-helpers/sigsys_handlers.cc:**CRASHING**:seccomp-bpf failure in syscall 0242
Received signal 11 SEGV_MAPERR 0000000000f2
../../sandbox/linux/seccomp-bpf-helpers/sigsys_handlers.cc:**CRASHING**:seccomp-bpf failure in syscall 0242
../../sandbox/linux/seccomp-bpf-helpers/sigsys_handlers.cc:**CRASHING**:seccomp-bpf failure in syscall 0242
../../sandbox/linux/seccomp-bpf-helpers/sigsys_handlers.cc:**CRASHING**:seccomp-bpf failure in syscall 0242

kde je chyba? před měsícem to šlo. sw jsem neaktualizoval.

12

Server / Smysluplnost "aliasů" v hlavičkách To,Cc

« kdy: 28. 04. 2023, 20:20:45 »

Chtěl bych zde kriticky a revisionisticky probrat užitečnost, a smysl "Jmen" v jednotlivých příjemcích v e-mailové zprávě (MIME Message) v hlavičkách To,Cc,Reply...

Jde o : To: "Petr Pavel" <ruskytrol@media.ru>, Petr Paul <petr@pavel.cz> , "£1b0r Obusek" <chiucpebomber@xgs.cz>, milenka  <zlata@adamovska.cz> (to byl jen příklad)

Dává to v dnešní době smysl?

0. Je to k nečemu dobré reálně?. Odesilatel tuto informaci nepotřebuje, resp. není potřeba ji cpát do přenášené zprávy. Pro Příjemce to může mít jistou, diskutabilní hodnotu

1. Je správná aby MSA hlavičku To: vyčistil? (nechal jen <a@b.dom>)

3. Jak se k tom ustaví MUA(programy), když příjemce má kontakty uložené pod jiným jménem?

4. (podobné trochu 3., ale lišící se)Jak se k tomu staví webmailové MUA(kde může být být podobný Adresář  na straně mailové infrastruktury přijemce, zde je šance, že to bude víc enterprise adresář)
Za druhé, nemůže to sloužit k fingerprintingu, jelikož jednotlivé páry jméno-mail nesou jistou entropii.

13

Server / SMTP: uvádění parametrů a extension až za EHLO

« kdy: 28. 04. 2023, 20:12:45 »

Je možné v SMTP komunikaci na straně serveru
avizovat doplňkové příkazy (typicky 250-.... co avizují přítomnost rozšíření)
až v pozdější fázi, tedy až za BLOK serveru EHLO  ?

MAIL FROM: velky@uploadder.com
250-SIZE 9999999999999999942
250 sender OK

Jsou natoto klienti připraveni, bude to fungovat?

14

Software / tcpdump: výstup bez ecr a ttt bez milisekund

« kdy: 28. 04. 2023, 15:05:16 »

Je mozno nejak v tcdumpu (textovy output)
Nastavit, aby:

-Cas byl v celych sekundach
-- jak absolutni cas ()
--tak delta (při -ttt)
Pripadne cas v celych milisekundach,(integer sec,  float : sec.ms)
-skryt "minuty:"


Neukazovaly se detaily paketu,win,options  (jako noecr,, ts-val), ale v druhem.kole ani ack,seq
Tedy neco jako opak -v,-vv


Dal drobnost: cislo portu oddelene dvojtexkou misto tecky

Tedy :
Z
00:00:58.058516 IP src-dst : Flags [P.], seq 52:104, ack 29, win 11657, options [nop,nop,TS val 2109328276 ecr 3777480036], length 52

Na:
00:58 IP 192.src.0:34102 > dst:22: Flags [P.], (seq 52:104, ack 29, )length 52
Pripadne "58 IP (sekund integer)
(00:)58.26( desitky ms, bez minut i s.minutami, aby tam nebylo 60000 za kazdou minutu)


Cilem je usetrit misto  na terminalu (ma to silenou sirku)

15

Windows a jiné systémy / Zobrazení velikosti SMB disku

« kdy: 26. 04. 2023, 19:21:52 »

Mám otázku do vod windows,... normálně SMB server(třeba druhý počítač).  a dotaz míří pro počítače, které se k smb serveru připojují.  Cesta je např. \\uloziste, konkrétní share \\uloziste\okruh

Je nějaké vysvětlení, proč Total commander(z roku 2015)mi (v cestě \\ulozisko\okruh) normálně napíše v záhlaví Velikost  i volné místo

zatímco průzkumník nic takového ne. Ani po kliknutí - vlasnosti - Velikost se zobrazuje 0 bajtů

(na tom samém PC, Win7)

a linuxová otázka, lze nějak přes příkazovou řádku, jako smbstatus nebo smbcontrol (bez roota) zjistit tutéž velikost obsazeno a volno? (samozřejmě to vidím, když si daný share mountnu přes mount.cifs nebo mount -t cifs, ale nechci mountovat několik bodů abych je hned odmountoval)