abclinuxu.cz AbcLinuxu.cz itbiz.cz ITBiz.cz HDmag.cz HDmag.cz abcprace.cz AbcPráce.cz
AbcLinuxu hledá autory!
Inzerujte na AbcPráce.cz od 950 Kč
Rozšířené hledání
×
eParkomat, startup z ČR, postoupil mezi finalisty evropského akcelerátoru ChallengeUp!
Robot na pivo mu otevřel dveře k opravdovému byznysu
Internet věcí: Propojený svět? Už se to blíží...
dnes 06:00 | Zajímavý software

OMG! Ubuntu! představuje emulátor terminálu Hyper (GitHub) postavený na webových technologiích (HTML, CSS a JavaScript). V diskusi k článku je zmíněn podobný emulátor terminálu Black Screen. Hyper i Black Screen používají framework Electron, stejně jako editor Atom nebo vývojové prostředí Visual Studio Code.

Ladislav Hagara | Komentářů: 3
dnes 06:00 | Zajímavý článek

I letos vychází řada ajťáckých adventních kalendářů. QEMU Advent Calendar 2016 přináší každý den nový obraz disku pro QEMU. Programátoři se mohou potrápit při řešení úloh z kalendáře Advent of Code 2016. Kalendáře Perl Advent Calendar 2016 a Perl 6 Advent Calendar přinášejí každý den zajímavé informace o programovacím jazyce Perl. Stranou nezůstává ani programovací jazyk Go.

Ladislav Hagara | Komentářů: 4
3.12. 16:24 | Nová verze

Byla vydána Mageia 5.1. Jedná se o první opravné vydání verze 5, jež vyšla v červnu loňského roku (zprávička). Uživatelům verze 5 nepřináší opravné vydání nic nového, samozřejmě pokud pravidelně aktualizují. Vydání obsahuje všechny aktualizace za posledního téměř půldruhého roku. Mageia 5.1 obsahuje LibreOffice 4.4.7, Linux 4.4.32, KDE4 4.14.5 nebo GNOME 3.14.3.

Ladislav Hagara | Komentářů: 9
3.12. 13:42 | Pozvánky

V Praze probíhá konference Internet a Technologie 16.2, volné pokračování jarní konference sdružení CZ.NIC. Konferenci lze sledovat online na YouTube. K dispozici je také archiv předchozích konferencí.

Ladislav Hagara | Komentářů: 0
2.12. 22:44 | Komunita

Joinup informuje, že Mnichov používá open source groupware Kolab. V srpnu byl dokončen dvouletý přechod na toto řešení. V provozu je asi 60 000 poštovních schránek. Nejenom Kolabu se věnoval Georg Greve ve své přednášce Open Source: the future for the European institutions (SlideShare) na konferenci DIGITEC 2016, jež proběhla v úterý 29. listopadu v Bruselu. Videozáznam přednášek z hlavního sálu je ke zhlédnutí na Livestreamu.

Ladislav Hagara | Komentářů: 24
2.12. 15:30 | Zajímavý projekt

Společnost Jolla oznámila v příspěvku Case study: Sailfish Watch na svém blogu, že naportovala Sailfish OS na chytré hodinky. Využila a inspirovala se otevřeným operačním systémem pro chytré hodinky AsteroidOS. Použita je knihovna libhybris. Ukázka ovládání hodinek na YouTube.

Ladislav Hagara | Komentářů: 8
2.12. 14:15 | Nová verze

Byla vydána verze 7.1.0 skriptovacího jazyka PHP používaného zejména k vývoji dynamických webových stránek. Jedná se o první stabilní verzi nejnovější větvě 7.1. Přehled novinek v dokumentaci. Podrobnosti v ChangeLogu. K dispozici je také příručka pro přechod z PHP 7.0.x na PHP 7.1.x.

Ladislav Hagara | Komentářů: 4
2.12. 12:55 | Nová verze

Google Chrome 55 byl prohlášen za stabilní. Nejnovější stabilní verze 55.0.2883.75 tohoto webového prohlížeče přináší řadu oprav a vylepšení (YouTube). Opraveno bylo také 36 bezpečnostních chyb. Mariusz Mlynski si například vydělal 22 500 dolarů za 3 nahlášené chyby (Universal XSS in Blink).

Ladislav Hagara | Komentářů: 4
2.12. 11:55 | Pozvánky

Máte rádi svobodný software a hardware nebo se o nich chcete něco dozvědět? Přijďte na 135. sraz spolku OpenAlt, který se bude konat ve čtvrtek 8. prosince od 18:00 v Radegastovně Perón (Stroupežnického 20, Praha 5). Sraz bude tentokrát tématický. Bude retro! K vidění budou přístroje jako Psion 5mx nebo Palm Z22. Ze svobodného hardwaru pak Openmoko nebo čtečka WikiReader. Přijďte se i vy pochlubit svými legendami, nebo alespoň na pivo. Moderní hardware má vstup samozřejmě také povolen.

xkucf03 | Komentářů: 1
2.12. 00:10 | Nová verze

Byla vydána verze 3.2 svobodného systému pro detekci a prevenci průniků a monitorování bezpečnosti počítačových sítí Suricata. Z novinek lze zmínit například podporu protokolů DNP3 a CIP/ENIP, vylepšenou podporu TLS a samozřejmě také aktualizovanou dokumentaci.

Ladislav Hagara | Komentářů: 0
Kolik máte dat ve svém domovském adresáři na svém primárním osobním počítači?
 (32%)
 (24%)
 (29%)
 (7%)
 (5%)
 (3%)
Celkem 771 hlasů
 Komentářů: 50, poslední 29.11. 15:50
Rozcestník
Reklama

Dotaz: tftp - ztráta paketů

26.11.2007 14:29 Dvořák | skóre: 1
tftp - ztráta paketů
Přečteno: 381×
Dobrý den, nefunguje mi tftp server. Při posílání paketů z klienta na server se pakety někde ztrácí. Vypadá to, jako kdyby byly filtrovány firewalem, ale je vypnutý. Při žádosti z klienta o soubor pxelinux.0 se na serveru neobjeví žádný paket. Zkušebně jsem nainstaloval tftp server i na klienta a opačně funguje komunikace v pořádku (zde stahuji soubor a.txt):

Klient (192.168.0.4):
linux:/home/dvorak # tcpdump -i eth0 -n host 192.168.0.50
14:15:32.450942 IP 192.168.0.4.1101 > 192.168.0.50.69:  22 RRQ "pxelinux.0" netascii
14:15:37.449382 arp who-has 192.168.0.50 tell 192.168.0.4
14:15:37.449502 arp reply 192.168.0.50 is-at 00:14:5e:f8:96:26
14:15:37.450421 IP 192.168.0.4.1101 > 192.168.0.50.69:  22 RRQ "pxelinux.0" netascii
14:15:42.450549 IP 192.168.0.4.1101 > 192.168.0.50.69:  22 RRQ "pxelinux.0" netascii
atd... A teď žádost ze server na clienta:
14:16:21.140372 IP 192.168.0.50.32770 > 192.168.0.4.69:  17 RRQ "a.txt" netascii
14:16:21.140374 IP 192.168.0.50.32770 > 192.168.0.4.1111: UDP, length: 4
14:16:21.142230 IP 192.168.0.4.1112 > 192.168.0.50.32770: UDP, length: 516
14:16:22.141680 IP 192.168.0.4.1112 > 192.168.0.50.32770: UDP, length: 516
14:16:24.141287 IP 192.168.0.4.1112 > 192.168.0.50.32770: UDP, length: 516
14:16:26.138073 arp who-has 192.168.0.4 tell 192.168.0.50
14:16:26.138091 arp reply 192.168.0.4 is-at 00:11:2f:95:8f:74
14:16:26.146094 IP 192.168.0.50.32770 > 192.168.0.4.1111: UDP, length: 4
14:16:28.140591 IP 192.168.0.4.1112 > 192.168.0.50.32770: UDP, length: 516
14:16:28.140854 IP 192.168.0.50.32770 > 192.168.0.4.1112: UDP, length: 4
Atd...
Server (192.168.0.50):
ibm:/home/dvorak # tcpdump -i eth0 -n host 192.168.0.4
14:15:37.463766 arp who-has 192.168.0.50 tell 192.168.0.4
Prostě nic... A teď žádost ze server na clienta:
14:16:21.154611 IP 192.168.0.50.32770 > 192.168.0.4.69:  17 RRQ a.txt netascii
14:16:21.154630 IP 192.168.0.50.32770 > 192.168.0.4.1111: UDP, length 4
14:16:26.152326 arp who-has 192.168.0.4 tell 192.168.0.50
14:16:26.152470 arp reply 192.168.0.4 is-at 00:11:2f:95:8f:74
14:16:26.160344 IP 192.168.0.50.32770 > 192.168.0.4.1111: UDP, length 4
14:16:28.155028 IP 192.168.0.4.1112 > 192.168.0.50.32770: UDP, length 516
14:16:28.155104 IP 192.168.0.50.32770 > 192.168.0.4.1112: UDP, length 4
atd...
iptables jsou vypnuté:
iptables -L 
Chain INPUT (policy ACCEPT)
target     prot opt source               destination

Chain FORWARD (policy ACCEPT)
target     prot opt source               destination

Chain OUTPUT (policy ACCEPT)
target     prot opt source               destination
Když stahuji soubor na localu (ze serveru na server), tak to funguje dobře.

Nevím, jestli to s tím souvisí, ale stejně tak mi něco zahazuje icmp pakety pingu. Při pingnutí ze serveru na klienta se ztratí některé příchozí odpovědi. Projde jich právě 5 za 30 sekund:
ibm:/home/dvorak # ping 192.168.0.4
PING 192.168.0.4 (192.168.0.4) 56(84) bytes of data.
64 bytes from 192.168.0.4: icmp_seq=6 ttl=64 time=0.159 ms
64 bytes from 192.168.0.4: icmp_seq=7 ttl=64 time=0.173 ms
64 bytes from 192.168.0.4: icmp_seq=8 ttl=64 time=0.182 ms
64 bytes from 192.168.0.4: icmp_seq=9 ttl=64 time=0.183 ms
64 bytes from 192.168.0.4: icmp_seq=10 ttl=64 time=0.174 ms
64 bytes from 192.168.0.4: icmp_seq=60 ttl=64 time=0.185 ms
64 bytes from 192.168.0.4: icmp_seq=61 ttl=64 time=0.179 ms
64 bytes from 192.168.0.4: icmp_seq=62 ttl=64 time=0.180 ms
64 bytes from 192.168.0.4: icmp_seq=63 ttl=64 time=0.181 ms
64 bytes from 192.168.0.4: icmp_seq=64 ttl=64 time=0.177 ms
64 bytes from 192.168.0.4: icmp_seq=114 ttl=64 time=0.174 ms
64 bytes from 192.168.0.4: icmp_seq=115 ttl=64 time=0.171 ms
64 bytes from 192.168.0.4: icmp_seq=116 ttl=64 time=0.187 ms
64 bytes from 192.168.0.4: icmp_seq=117 ttl=64 time=0.166 ms
64 bytes from 192.168.0.4: icmp_seq=118 ttl=64 time=0.167 ms

--- 192.168.0.4 ping statistics ---
119 packets transmitted, 15 received, 87% packet loss, time 118011ms
rtt min/avg/max/mdev = 0.159/0.175/0.187/0.019 ms
Příliš pravidelné, aby to byla náhoda nebo chyba sítě. Počítače jsou od sebe 2m propojené kabelem. Ping z klienta na server bez ztráty paketu. Ostatní protokoly fungují bez problémů.

Nevím, kde se dá mimo iptables blokovat pakety. Díval jsem se na /proc/sys/net/ipv4 soubory icmp_ratemask a icmp_ratelimit ale na obou počítačích jsou nastaveny stejně (defaultně) a i když jsem se je snažil změnit, tak se nic nestalo. Stejně by to asi nemělo vliv na UDP/IP.

Mám Suse Linux 10.3, jádro, 2.6.22.5.-31-default

Jestli víte jak na to, díky za dobrou radu.

Odpovědi

26.11.2007 18:46 petr_p | skóre: 59 | blog: pb
Rozbalit Rozbalit vše Re: tftp - ztráta paketů
Duplexita, případně máte podivnou kartu/ovladač. Slyšel jsem o problémech s ovladačem e100(0), který vypínal síťovku, takže než se síťovka probudila, tak několik rámcu bylo pryč.

Kdyby byly problémy jen s TFTP serverem, hledal bych chybu kolem tcpwrappers, inetd.

Založit nové vláknoNahoru

Tiskni Sdílej: Linkuj Jaggni to Vybrali.sme.sk Google Del.icio.us Facebook

ISSN 1214-1267   www.czech-server.cz
© 1999-2015 Nitemedia s. r. o. Všechna práva vyhrazena.