Re: lug-bg: Re: dhcpcd когато временно няма сървър
Ами незнам, по-скоро коя версия използваш ти?При мен и в man нищо непише за -t 0:-t timeout Specifies (in seconds ) for how long dhcpcd will try to get an IP address. The default is 60 seconds. dhcpcd will not fork into background until it gets a valid IP address in which case dhcpcd will return 0 to the parent process. In a case dhcpcd times out before receiving a valid IP address from DHCP server dhcpcd will return exit code 1 to the parent process. -c ExecFilePath.Цитат на писмо от Damyan Ivanov [EMAIL PROTECTED]: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 [EMAIL PROTECTED] wrote: Много странно, но при мен dhcpcd не приема опция -t 0. Версията при мен е dhcpcd-1.3.22-p12. Изтеглих си от сайта и компилирах последната версия dhcpcd-1.3.22-p14, но тя също не приема опция -t 0! Bugreport до автора?дам - -- Damyan Ivanov 0x9725F63B Creditreform Bulgaria [EMAIL PROTECTED] http://www.creditreform.bg/ phone: +359(2)928-2611, 929-3993 fax: +359(2)920-0994 mob. +359(88)856-6067 ICQ 3028500 [EMAIL PROTECTED]/Gaim -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDBXJMHqjlqpcl9jsRAu04AJ97SiOuQ1mILQSUvXQGB/DbRMWMEwCfQLJP V+OYdu3T2jVXczOPph0LryE= =ZzPo -END PGP SIGNATURE- -- Безплатната поща в mail.bg вече е 1GB!
Re: lug-bg: Re: dhcpcd когато времен но няма сървър
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 [EMAIL PROTECTED] wrote: Ами незнам, по-скоро коя версия използваш ти? При мен и в man нищо непише за -t 0: -t timeout Specifies (in seconds ) for how long dhcpcd will try to get an IP address. The default is 60 seconds. dhcpcd will not fork into background until it gets a valid IP address in which case dhcpcd will return 0 to the parent process. In a case dhcpcd times out before receiving a valid IP address from DHCP server dhcpcd will return exit code 1 to the parent process. -c ExecFilePath $ dpkg -l dhcpcd ... ii dhcpcd 1.3.22pl4-22 DHCP client for automatically ... $ man dhcpcd-bin | grep -A 12 -- -t Reformatting dhcpcd-bin(8), please wait... -t timeout Specifies (in seconds ) for how long dhcpcd will try to get an IP address. The default is 60 seconds. dhcpcd will not fork into background until it gets a valid IP address in which case dhcpcd will return 0 to the parent process. In a case dhcpcd times out before receiving a valid IP address from DHCP server dhcpcd will return exit code 1 to the parent process. Setting the timeout to zero disables it: dhcp will keep trying forever to get a lease, and if the lease is lost, it will try forever to get another. -c ExecFilePath dhcpcd will try to execute ExecFilePath script instead of Погледнах в dhcpcd_1.3.22pl4-22.diff.gz и няма корекции в оригиналния dhcpcd.8 (от което се генерира dhcpcd-bin(8)) и логично приемам, че няма корекции по въпроса и в демона. Забележи, че версията е 1.3.22pl4 и pl сигурно значи patch level. дам - -- Damyan Ivanov 0x9725F63B Creditreform Bulgaria [EMAIL PROTECTED] http://www.creditreform.bg/ phone: +359(2)928-2611, 929-3993fax: +359(2)920-0994 mob. +359(88)856-6067 ICQ 3028500 [EMAIL PROTECTED]/Gaim -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.1 (GNU/Linux) Comment: Using GnuPG with Thunderbird - http://enigmail.mozdev.org iD8DBQFDBZUuHqjlqpcl9jsRAk2GAJ9D8XqsemMKHGJyKPuhwsxSExJHsgCfSeRa wn3sJLdFMevFPtlfk+UR4gM= =RKPk -END PGP SIGNATURE-
lug-bg: Тъжно ми е с 50% - 60% загуба на пакет и.
Това е проблем между мене и интернет доставчика ми. На 18 вечерта някъде от 19:00 до 19 сутринта до към 9:30 имах около 50% - 60% загуба на пакети. Машината е Abit BH6, паметта е свалена от сървър и при минаване с memtest не дава грешки. Диска е WesternDigital и досовска програма на фирмата производител не дава никакви отклонения или грешки. Мрежовата карта е RealTek 8029AS - 10Mbit-ова, с програмата на фирмата производител RSET8029.EXE не дава никакви грешки при тестването. Операционните системи са: Linux 2.6.11 #2 SMP Thu May 26 20:53:11 CEST 2005 i686 GNU/Linux и Microsoft Windows XP [Version 5.1.2600] Развитие на проблема във времето: Вечерта към 19:00 - 20:00 почва да нямам ама абсолютно никакъв интернет, виждам че пинга е умрял в кожата си и се обаждам на поддръжката на фирмата. След това излизам от офиса и се връщам към 21:30, заварвам същото положение с над 50% загуби на пакетите. Говоря си с тях и тогава правя пинг и от Уиндоуса и от Линукса и от двете има над 50% загуби. Пингвах уеб сървъра на доставчика ми който има IP адрес от мрежата в която съм и аз. За малко да ме убедят че проблема е при мене!!! Правя пинг под Линукс ping -c 100 127.0.0.1 и ми връща резултат 0% загуби. Същия пинг до localhost-a под Уиндоус ми дава абсолютно същия резултат - 0% загуби. Майката... Лелята... И оставям компютъра. На другия ден сутринта в 8:00 същото нещо, над 50% загуби. Заебавам компютъра. В 9:00 - 9:00 всичко се оправи. В 14:00 идва представител на фирмата (когато вече всичко е наред) и казва че само аз съм се оплаквал от 10 човека които са в нашия блок. Каза че не разбира от софтуер евентуално можело да бъде от вирус(!?!) и ще ми прати софтуерист от фирмата - аз отказах, стига толкова. Прикрепения файл съм логнал част от нещата. Търся в кой е причината и евентуално каква е. -- Best Regards Alex Panov ICQ: 18926904 00359 898521957 www.evitatrade.com www.karatebulgaria.com www.karatebulgaria.com/alex uname -a Linux 2.6.11 #2 SMP Thu May 26 20:53:11 CEST 2005 i686 GNU/Linux date Thu Aug 18 21:47:07 EDT 2005 ping -c 10 127.0.0.1 PING 127.0.0.1 (127.0.0.1): 56 data bytes 64 bytes from 127.0.0.1: icmp_seq=0 ttl=64 time=0.1 ms 64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.1 ms 64 bytes from 127.0.0.1: icmp_seq=2 ttl=64 time=0.1 ms 64 bytes from 127.0.0.1: icmp_seq=3 ttl=64 time=0.1 ms 64 bytes from 127.0.0.1: icmp_seq=4 ttl=64 time=0.1 ms 64 bytes from 127.0.0.1: icmp_seq=5 ttl=64 time=0.1 ms 64 bytes from 127.0.0.1: icmp_seq=6 ttl=64 time=0.1 ms 64 bytes from 127.0.0.1: icmp_seq=7 ttl=64 time=0.1 ms 64 bytes from 127.0.0.1: icmp_seq=8 ttl=64 time=0.1 ms 64 bytes from 127.0.0.1: icmp_seq=9 ttl=64 time=0.1 ms --- 127.0.0.1 ping statistics --- 10 packets transmitted, 10 packets received, 0% packet loss round-trip min/avg/max = 0.1/0.1/0.1 ms PING www.sellinet.net (82.199.192.2): 56 data bytes ping -c 25 www.sellinet.net 64 bytes from 82.199.192.2: icmp_seq=0 ttl=62 time=1.7 ms 64 bytes from 82.199.192.2: icmp_seq=1 ttl=62 time=4.0 ms 64 bytes from 82.199.192.2: icmp_seq=2 ttl=62 time=1.6 ms 64 bytes from 82.199.192.2: icmp_seq=3 ttl=62 time=4.1 ms 64 bytes from 82.199.192.2: icmp_seq=4 ttl=62 time=4.1 ms 64 bytes from 82.199.192.2: icmp_seq=5 ttl=62 time=7.8 ms 64 bytes from 82.199.192.2: icmp_seq=6 ttl=62 time=10.8 ms 64 bytes from 82.199.192.2: icmp_seq=8 ttl=62 time=4.0 ms 64 bytes from 82.199.192.2: icmp_seq=11 ttl=62 time=2.6 ms 64 bytes from 82.199.192.2: icmp_seq=12 ttl=62 time=7.8 ms 64 bytes from 82.199.192.2: icmp_seq=13 ttl=62 time=6.9 ms 64 bytes from 82.199.192.2: icmp_seq=14 ttl=62 time=2.8 ms 64 bytes from 82.199.192.2: icmp_seq=17 ttl=62 time=4.6 ms 64 bytes from 82.199.192.2: icmp_seq=18 ttl=62 time=3.7 ms 64 bytes from 82.199.192.2: icmp_seq=19 ttl=62 time=4.1 ms 64 bytes from 82.199.192.2: icmp_seq=20 ttl=62 time=4.8 ms 64 bytes from 82.199.192.2: icmp_seq=22 ttl=62 time=5.1 ms 64 bytes from 82.199.192.2: icmp_seq=23 ttl=62 time=10.1 ms --- www.sellinet.net ping statistics --- 25 packets transmitted, 18 packets received, 28% packet loss round-trip min/avg/max = 1.6/5.0/10.8 ms ping -c 35 www.sellinet.net PING www.sellinet.net (82.199.192.2): 56 data bytes 64 bytes from 82.199.192.2: icmp_seq=5 ttl=62 time=8.9 ms 64 bytes from 82.199.192.2: icmp_seq=8 ttl=62 time=9.8 ms 64 bytes from 82.199.192.2: icmp_seq=10 ttl=62 time=9.2 ms 64 bytes from 82.199.192.2: icmp_seq=11 ttl=62 time=5.4 ms 64 bytes from 82.199.192.2: icmp_seq=16 ttl=62 time=2.6 ms 64 bytes from 82.199.192.2: icmp_seq=17 ttl=62 time=2.2 ms 64 bytes from 82.199.192.2: icmp_seq=18 ttl=62 time=2.1 ms 64 bytes from 82.199.192.2: icmp_seq=19 ttl=62 time=5.2 ms 64 bytes from 82.199.192.2: icmp_seq=22 ttl=62 time=4.3 ms 64 bytes from 82.199.192.2: icmp_seq=23 ttl=62 time=4.1 ms 64 bytes from 82.199.192.2: icmp_seq=27 ttl=62 time=2.8 ms 64 bytes from 82.199.192.2: icmp_seq=28 ttl=62 time=3.6 ms 64 bytes from 82.199.192.2: icmp_seq=32 ttl=62 time=6.6 ms --- www.sellinet.net ping statistics --- 35 packets
Re: lug-bg: Тъжно ми е с 50% - 60% загуба на п акети.
Alexander P. Panov wrote: Това е проблем между мене и интернет доставчика ми. На 18 вечерта някъде от 19:00 до 19 сутринта до към 9:30 имах около 50% - 60% загуба на пакети. [snip] Търся в кой е причината и евентуално каква е. Слагаш mtr (My traceroute) и го пускаш с: mtr www.sellinet.net и гледаш откъде нататък падат пакетите (някои хостове не връщат пинга, така че пингиш по-надалече /google примерно/ и търсиш постоянни издропвания от някъде нататък). Проблемчето ще се види между кои машини е. Вероятно ти е скъсан кабела или се е смарангясала мрежовата карта. И м/у прочем от пингването на localhost няма много полза, защото пингът дори не се доближава до мрежовата карта, ами си бичи отвътре през ОСа, който очевидно е ОК, щом и Линукс и Уиндоус реагират еднакво. Успех, Андро -- Andrey Andreev University of Helsinki Dept. of Computer Science
Re: lug-bg: Тъжно ми е с 50% - 60% загуба на пакети.
Здравей Alexander P. Panov, Le vendredi 19 août 2005 à 14:24 +0300, Alexander P. Panov a écrit : Това е проблем между мене и интернет доставчика ми. На 18 вечерта някъде от 19:00 до 19 сутринта до към 9:30 имах около 50% - 60% загуба на пакети. Машината е Abit BH6, паметта е свалена от сървър и при минаване с memtest не дава грешки. Диска е WesternDigital и досовска програма на фирмата производител не дава никакви отклонения или грешки. Мрежовата карта е RealTek 8029AS - 10Mbit-ова, с програмата на фирмата производител RSET8029.EXE не дава никакви грешки при тестването. Операционните системи са: Linux 2.6.11 #2 SMP Thu May 26 20:53:11 CEST 2005 i686 GNU/Linux и Microsoft Windows XP [Version 5.1.2600] Определено проблема не е бил в теб при мен се получаваше същото нещо но с повече упоритост и късни обаждания до съпорта им стигаш до успех ;) Обикновенно проблемите им са в устроствата накачени по трасето до техния център. А с mtr можеш да да проследиш къде е горе-долу може да е проблема. Развитие на проблема във времето: Вечерта към 19:00 - 20:00 почва да нямам ама абсолютно никакъв интернет, виждам че пинга е умрял в кожата си и се обаждам на поддръжката на фирмата. След това излизам от офиса и се връщам към 21:30, заварвам същото положение с над 50% загуби на пакетите. Говоря си с тях и тогава правя пинг и от Уиндоуса и от Линукса и от двете има над 50% загуби. Пингвах уеб сървъра на доставчика ми който има IP адрес от мрежата в която съм и аз. За малко да ме убедят че проблема е при мене!!! Правя пинг под Линукс ping -c 100 127.0.0.1 и ми връща резултат 0% загуби. Същия пинг до localhost-a под Уиндоус ми дава абсолютно същия резултат - 0% загуби. Майката... Лелята... И оставям компютъра. На другия ден сутринта в 8:00 същото нещо, над 50% загуби. Заебавам компютъра. В 9:00 - 9:00 всичко се оправи. В 14:00 идва представител на фирмата (когато вече всичко е наред) и казва че само аз съм се оплаквал от 10 човека които са в нашия блок. Каза че не разбира от софтуер евентуално можело да бъде от вирус(!?!) и ще ми прати софтуерист от фирмата - аз отказах, стига толкова. Прикрепения файл съм логнал част от нещата. Търся в кой е причината и евентуално каква е. Поздрави, Цветан
Re: lug-bg: Тъжно ми е с 5 0% - 60% загуба на пакети.
Незнам какво очакваш от 127.0.0.1, все пак пакетите до там не минават през никакви устройства (като изключим дъното, процесора и рам паметта). В такива случаи може да пингваш: 1) хора от локалната ти мрежа (същия блок, съседен блок), ако до тях имаш загуби е или ланка или омазано мрежово устройство (пробвай с големи пакети -l 1). Ако не ти е от ланката, доставчикът е виновен 2) ако до съседите има пинг без загуби, отиваш на шлюза (gateway-a), ако до там имаш загуби е нещо по мрежата, пак доставчикът е виновен 3) ако имаш загуби след gw-то (dir.bg, други български машини) причината си е в доставчика - заразил си се с вурис (под джамбоза) те обикновено наводняват локалната мрежа с огромно количество пакети (също така може да ти запълнят исходящия канал, ако пращат към интернет). При тази ситуация е възможно под windows да имаш загуби - някой друг се е заразил с вирус и наводнява локалната мрежа в този случай също е възмножно да имаш загуби Интересна ситуация се получава, когато към мрежата има вкючени потребители с 10 (или картата е за 10 или по незнайни причини започва да работи на 10) и 100 мегабитови карти . Случва се устройствата (евтините суичове) да се ошашавят и да започнат да правят мизерии (обикновено се оправя като се разкарат 10mbit-отвите потребители) Причини много :)
Re: lug-bg: Тъжно ми е с 50% - 60% загуба на п акети.
Andrey Andreev wrote: Това е проблем между мене и интернет доставчика ми. На 18 вечерта някъде от 19:00 до 19 сутринта до към 9:30 имах около 50% - 60% загуба на пакети. Търся в кой е причината и евентуално каква е. Слагаш mtr (My traceroute) и го пускаш с: mtr www.sellinet.net и гледаш откъде нататък падат пакетите (някои хостове не връщат пинга, така че пингиш по-надалече /google примерно/ и търсиш постоянни издропвания от някъде нататък). Проблемчето ще се види между кои машини е. Това е явно решението. Вероятно ти е скъсан кабела Как може да е скъсан кабела? Може да е бил скъсан и сутринта да са го сменили, ама да не си признават. или се е смарангясала мрежовата карта. Как може да сам най големия карък, да попадна на мрежова карта със собствено мнение по цвета и вкуса на пакетите. И м/у прочем от пингването на localhost няма много полза, защото пингът дори не се доближава до мрежовата карта, ами си бичи отвътре през ОСа, Това не го знаех, но поне от тука следва че зофтуера при мене е добър, а не се е скапал и да дропи пакетите. който очевидно е ОК, щом и Линукс и Уиндоус реагират еднакво. Успех, Андро -- Best Regards Alex Panov ICQ: 18926904 00359 898521957 www.evitatrade.com www.karatebulgaria.com www.karatebulgaria.com/alex
Re: lug-bg: Тъжно ми е с 50% - 60% загуба на п акети.
Alexander P. Panov wrote: Andrey Andreev wrote: Вероятно ти е скъсан кабела Как може да е скъсан кабела? Може да е бил скъсан и сутринта да са го сменили, ама да не си признават. Може да се е нагънал особено и да не прави хубав контакт при магнитни бури или нещо от сорта. ;) На мен ми се е случвало да си отива лека полека кабел. или се е смарангясала мрежовата карта. Как може да сам най големия карък, да попадна на мрежова карта със собствено мнение по цвета и вкуса на пакетите. Може и да не си ти, както казват Цветан и Момчил, може и да е от тяхно мрежово устройство да е мизерията, или в наводнена мрежа. Дай mtr и тогава пак ще се изкарват хипотези. Андро -- Andrey Andreev University of Helsinki Dept. of Computer Science
Re: lug-bg: Тъжно ми е с 50% - 60% загуба на п акети.
Alexander P. Panov wrote: Това е проблем между мене и интернет доставчика ми. На 18 вечерта някъде от 19:00 до 19 сутринта до към 9:30 имах около 50% - 60% загуба на пакети. Машината е Abit BH6, паметта е свалена от сървър и при минаване с memtest не дава грешки. Диска е WesternDigital и досовска програма на фирмата производител не дава никакви отклонения или грешки. Мрежовата карта е RealTek 8029AS - 10Mbit-ова, с програмата на фирмата производител RSET8029.EXE не дава никакви грешки при тестването. Не разбрах какъв модел ти е фритюрника и готварската печка. Операционните системи са: Linux 2.6.11 #2 SMP Thu May 26 20:53:11 CEST 2005 i686 GNU/Linux и Microsoft Windows XP [Version 5.1.2600] Развитие на проблема във времето: Вечерта към 19:00 - 20:00 почва да нямам ама абсолютно никакъв интернет, виждам че пинга е умрял в кожата си и се обаждам на поддръжката на фирмата. След това излизам от офиса и се връщам към 21:30, заварвам същото положение с над 50% загуби на пакетите. Говоря си с тях и тогава правя пинг и от Уиндоуса и от Линукса и от двете има над 50% загуби. Пингвах уеб сървъра на доставчика ми който има IP адрес от мрежата в която съм и аз. За малко да ме убедят че проблема е при мене!!! Правя пинг под Линукс ping -c 100 127.0.0.1 и ми връща резултат 0% загуби. Същия пинг до localhost-a под Уиндоус ми дава абсолютно същия резултат - 0% загуби. Майката... Лелята... И оставям компютъра. На другия ден сутринта в 8:00 същото нещо, над 50% загуби. Заебавам компютъра. В 9:00 - 9:00 всичко се оправи. В 14:00 идва представител на фирмата (когато вече всичко е наред) и казва че само аз съм се оплаквал от 10 човека които са в нашия блок. Каза че не разбира от софтуер евентуално можело да бъде от вирус(!?!) и ще ми прати софтуерист от фирмата - аз отказах, стига толкова. Прикрепения файл съм логнал част от нещата. Търся в кой е причината и евентуално каква е. uname -a Linux 2.6.11 #2 SMP Thu May 26 20:53:11 CEST 2005 i686 GNU/Linux date Thu Aug 18 21:47:07 EDT 2005 ping -c 10 127.0.0.1 PING 127.0.0.1 (127.0.0.1): 56 data bytes 64 bytes from 127.0.0.1: icmp_seq=0 ttl=64 time=0.1 ms 64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.1 ms 64 bytes from 127.0.0.1: icmp_seq=2 ttl=64 time=0.1 ms 64 bytes from 127.0.0.1: icmp_seq=3 ttl=64 time=0.1 ms 64 bytes from 127.0.0.1: icmp_seq=4 ttl=64 time=0.1 ms 64 bytes from 127.0.0.1: icmp_seq=5 ttl=64 time=0.1 ms 64 bytes from 127.0.0.1: icmp_seq=6 ttl=64 time=0.1 ms 64 bytes from 127.0.0.1: icmp_seq=7 ttl=64 time=0.1 ms 64 bytes from 127.0.0.1: icmp_seq=8 ttl=64 time=0.1 ms 64 bytes from 127.0.0.1: icmp_seq=9 ttl=64 time=0.1 ms --- 127.0.0.1 ping statistics --- 10 packets transmitted, 10 packets received, 0% packet loss round-trip min/avg/max = 0.1/0.1/0.1 ms PING www.sellinet.net (82.199.192.2): 56 data bytes ping -c 25 www.sellinet.net 64 bytes from 82.199.192.2: icmp_seq=0 ttl=62 time=1.7 ms 64 bytes from 82.199.192.2: icmp_seq=1 ttl=62 time=4.0 ms 64 bytes from 82.199.192.2: icmp_seq=2 ttl=62 time=1.6 ms 64 bytes from 82.199.192.2: icmp_seq=3 ttl=62 time=4.1 ms 64 bytes from 82.199.192.2: icmp_seq=4 ttl=62 time=4.1 ms 64 bytes from 82.199.192.2: icmp_seq=5 ttl=62 time=7.8 ms 64 bytes from 82.199.192.2: icmp_seq=6 ttl=62 time=10.8 ms 64 bytes from 82.199.192.2: icmp_seq=8 ttl=62 time=4.0 ms 64 bytes from 82.199.192.2: icmp_seq=11 ttl=62 time=2.6 ms 64 bytes from 82.199.192.2: icmp_seq=12 ttl=62 time=7.8 ms 64 bytes from 82.199.192.2: icmp_seq=13 ttl=62 time=6.9 ms 64 bytes from 82.199.192.2: icmp_seq=14 ttl=62 time=2.8 ms 64 bytes from 82.199.192.2: icmp_seq=17 ttl=62 time=4.6 ms 64 bytes from 82.199.192.2: icmp_seq=18 ttl=62 time=3.7 ms 64 bytes from 82.199.192.2: icmp_seq=19 ttl=62 time=4.1 ms 64 bytes from 82.199.192.2: icmp_seq=20 ttl=62 time=4.8 ms 64 bytes from 82.199.192.2: icmp_seq=22 ttl=62 time=5.1 ms 64 bytes from 82.199.192.2: icmp_seq=23 ttl=62 time=10.1 ms --- www.sellinet.net ping statistics --- 25 packets transmitted, 18 packets received, 28% packet loss round-trip min/avg/max = 1.6/5.0/10.8 ms ping -c 35 www.sellinet.net PING www.sellinet.net (82.199.192.2): 56 data bytes 64 bytes from 82.199.192.2: icmp_seq=5 ttl=62 time=8.9 ms 64 bytes from 82.199.192.2: icmp_seq=8 ttl=62 time=9.8 ms 64 bytes from 82.199.192.2: icmp_seq=10 ttl=62 time=9.2 ms 64 bytes from 82.199.192.2: icmp_seq=11 ttl=62 time=5.4 ms 64 bytes from 82.199.192.2: icmp_seq=16 ttl=62 time=2.6 ms 64 bytes from 82.199.192.2: icmp_seq=17 ttl=62 time=2.2 ms 64 bytes from 82.199.192.2: icmp_seq=18 ttl=62 time=2.1 ms 64 bytes from 82.199.192.2: icmp_seq=19 ttl=62 time=5.2 ms 64 bytes from 82.199.192.2: icmp_seq=22 ttl=62 time=4.3 ms 64 bytes from 82.199.192.2: icmp_seq=23 ttl=62 time=4.1 ms 64 bytes from 82.199.192.2: icmp_seq=27 ttl=62 time=2.8 ms 64 bytes from 82.199.192.2: icmp_seq=28 ttl=62 time=3.6 ms 64 bytes from 82.199.192.2: icmp_seq=32 ttl=62 time=6.6 ms ---
Re: lug-bg: Re: dhcpcd когато временно няма сървър
Ето какво пише в Debian Changelog:dhcpcd (1:1.3.22pl4-20) unstable; urgency=low * Added -p option, for use with NFS-root. * Made -t 0 work to disable timeouts entirely.Явно от Debian са правили промени в демона. Когато го закърпих със споменатия diff файл и опцията се появи. Погледнах в dhcpcd_1.3.22pl4-22.diff.gz и няма корекции в оригиналния -- Безплатната поща в mail.bg вече е 1GB!
Re: lug-bg: Тъжно ми е с 5 0% - 60% загуба на пакети.
така е -- ping 127.0.0.1 ще ти покаже дали tcp(/ip?) стека на операционната ти система е наред (понеже се случва и той да се скапе понякога). а ако искаш да се убедиш, че мрежовата ти карта е наред, пускаш ping до ip адреса, който си и дал (примерно ping 192.168.0.10). a Понякога дори и развалена, тя връща пинг. Това не е най-точният начин за определяне дали работи както трябва или не. ping до gateway ти ще ти даде информация какво е състоянието на физическата връзка между него и теб. изобщо съвета за mtr си е съвсем актуален. -- the lunatics are in my head --- Nick Angelow
Re: lug-bg: Тъжно ми е с 50% - 60% загуба на пакети.
On Fri, 2005-08-19 at 14:24 +0300, Alexander P. Panov wrote: Това е проблем между мене и интернет доставчика ми. На 18 вечерта някъде от 19:00 до 19 сутринта до към 9:30 имах около 50% - 60% загуба на пакети. Машината е Abit BH6, паметта е свалена от сървър и при минаване с memtest не дава грешки. Диска е WesternDigital и досовска програма на фирмата производител не дава никакви отклонения или грешки. Мрежовата карта е RealTek 8029AS - 10Mbit-ова, с програмата на фирмата производител RSET8029.EXE не дава никакви грешки при тестването. Първо смени мрежовата карта. Най-евтина карта с чип 8139D струва между 5 и 7 долара. Тая RealTek 8029AS - 10Mbit-ова я хвърли в контейнера на фирма Чистота. Операционните системи са: Linux 2.6.11 #2 SMP Thu May 26 20:53:11 CEST 2005 i686 GNU/Linux и Microsoft Windows XP [Version 5.1.2600] Развитие на проблема във времето: Вечерта към 19:00 - 20:00 почва да нямам ама абсолютно никакъв интернет, виждам че пинга е умрял в кожата си и се обаждам на поддръжката на фирмата. След това излизам от офиса и се връщам към 21:30, заварвам същото положение с над 50% загуби на пакетите. Говоря си с тях и тогава правя пинг и от Уиндоуса и от Линукса и от двете има над 50% загуби. Пингвах уеб сървъра на доставчика ми който има IP адрес от мрежата в която съм и аз. За малко да ме убедят че проблема е при мене!!! Правя пинг под Линукс ping -c 100 127.0.0.1 и ми връща резултат 0% загуби. Същия пинг до localhost-a под Уиндоус ми дава абсолютно същия резултат - 0% загуби. Майката... Лелята... И оставям компютъра. На другия ден сутринта в 8:00 същото нещо, над 50% загуби. Заебавам компютъра. В 9:00 - 9:00 всичко се оправи. В 14:00 идва представител на фирмата (когато вече всичко е наред) и казва че само аз съм се оплаквал от 10 човека които са в нашия блок. Каза че не разбира от софтуер евентуално можело да бъде от вирус(!?!) и ще ми прати софтуерист от фирмата - аз отказах, стига толкова. Прикрепения файл съм логнал част от нещата. Търся в кой е причината и евентуално каква е. plain text document attachment (sellinet.txt) uname -a Linux 2.6.11 #2 SMP Thu May 26 20:53:11 CEST 2005 i686 GNU/Linux date Thu Aug 18 21:47:07 EDT 2005 ping -c 10 127.0.0.1 PING 127.0.0.1 (127.0.0.1): 56 data bytes 64 bytes from 127.0.0.1: icmp_seq=0 ttl=64 time=0.1 ms 64 bytes from 127.0.0.1: icmp_seq=1 ttl=64 time=0.1 ms 64 bytes from 127.0.0.1: icmp_seq=2 ttl=64 time=0.1 ms 64 bytes from 127.0.0.1: icmp_seq=3 ttl=64 time=0.1 ms 64 bytes from 127.0.0.1: icmp_seq=4 ttl=64 time=0.1 ms 64 bytes from 127.0.0.1: icmp_seq=5 ttl=64 time=0.1 ms 64 bytes from 127.0.0.1: icmp_seq=6 ttl=64 time=0.1 ms 64 bytes from 127.0.0.1: icmp_seq=7 ttl=64 time=0.1 ms 64 bytes from 127.0.0.1: icmp_seq=8 ttl=64 time=0.1 ms 64 bytes from 127.0.0.1: icmp_seq=9 ttl=64 time=0.1 ms --- 127.0.0.1 ping statistics --- 10 packets transmitted, 10 packets received, 0% packet loss round-trip min/avg/max = 0.1/0.1/0.1 ms PING www.sellinet.net (82.199.192.2): 56 data bytes ping -c 25 www.sellinet.net 64 bytes from 82.199.192.2: icmp_seq=0 ttl=62 time=1.7 ms 64 bytes from 82.199.192.2: icmp_seq=1 ttl=62 time=4.0 ms 64 bytes from 82.199.192.2: icmp_seq=2 ttl=62 time=1.6 ms 64 bytes from 82.199.192.2: icmp_seq=3 ttl=62 time=4.1 ms 64 bytes from 82.199.192.2: icmp_seq=4 ttl=62 time=4.1 ms 64 bytes from 82.199.192.2: icmp_seq=5 ttl=62 time=7.8 ms 64 bytes from 82.199.192.2: icmp_seq=6 ttl=62 time=10.8 ms 64 bytes from 82.199.192.2: icmp_seq=8 ttl=62 time=4.0 ms 64 bytes from 82.199.192.2: icmp_seq=11 ttl=62 time=2.6 ms 64 bytes from 82.199.192.2: icmp_seq=12 ttl=62 time=7.8 ms 64 bytes from 82.199.192.2: icmp_seq=13 ttl=62 time=6.9 ms 64 bytes from 82.199.192.2: icmp_seq=14 ttl=62 time=2.8 ms 64 bytes from 82.199.192.2: icmp_seq=17 ttl=62 time=4.6 ms 64 bytes from 82.199.192.2: icmp_seq=18 ttl=62 time=3.7 ms 64 bytes from 82.199.192.2: icmp_seq=19 ttl=62 time=4.1 ms 64 bytes from 82.199.192.2: icmp_seq=20 ttl=62 time=4.8 ms 64 bytes from 82.199.192.2: icmp_seq=22 ttl=62 time=5.1 ms 64 bytes from 82.199.192.2: icmp_seq=23 ttl=62 time=10.1 ms --- www.sellinet.net ping statistics --- 25 packets transmitted, 18 packets received, 28% packet loss round-trip min/avg/max = 1.6/5.0/10.8 ms ping -c 35 www.sellinet.net PING www.sellinet.net (82.199.192.2): 56 data bytes 64 bytes from 82.199.192.2: icmp_seq=5 ttl=62 time=8.9 ms 64 bytes from 82.199.192.2: icmp_seq=8 ttl=62 time=9.8 ms 64 bytes from 82.199.192.2: icmp_seq=10 ttl=62 time=9.2 ms 64 bytes from 82.199.192.2: icmp_seq=11 ttl=62 time=5.4 ms 64 bytes from 82.199.192.2: icmp_seq=16 ttl=62 time=2.6 ms 64 bytes from 82.199.192.2: icmp_seq=17 ttl=62 time=2.2 ms 64 bytes from 82.199.192.2: icmp_seq=18 ttl=62 time=2.1 ms 64 bytes from 82.199.192.2: icmp_seq=19 ttl=62 time=5.2 ms 64 bytes from 82.199.192.2: icmp_seq=22 ttl=62 time=4.3 ms 64 bytes from 82.199.192.2: icmp_seq=23 ttl=62 time=4.1
Re: lug-bg: проблем с ifcon fig
Veselin Mihailov wrote: Имам следния проблем с ifconfig, който се мъча вече сумати време да реша - и не се получава. ifconfig eth1 inet add 192.168.0.1 netmask 255.255.255.0 up SIOCSIFNETMASK: Cannot assign requested address Ами защо не пробваш да прочетеш синтаксиса на тая команда man ifconfig и да решиш дали ще ползваш или ifconfig или ip addr , а не и двете заедно :)
Re: lug-bg: проблем с ifcon fig
ifconfig eth1 eth1 Link encap:Ethernet HWaddr 4C:00:10:60:6D:47 inet6 addr: fe80::4e00:10ff:fe60:6d47/64 Scope:Link UP BROADCAST MULTICAST MTU:1500 Metric:1 RX packets:0 errors:0 dropped:0 overruns:0 frame:0 TX packets:0 errors:0 dropped:0 overruns:0 carrier:0 collisions:0 txqueuelen:1000 RX bytes:0 (0.0 b) TX bytes:0 (0.0 b) Interrupt:21 Base address:0xd000 А и пропуснах , а на всичко отгоре имаш ли IPv4 все пак компилирано в ядрото
Re: lug-bg: проблем с ifcon fig
Dean Stoeff wrote: Veselin Mihailov wrote: Имам следния проблем с ifconfig, който се мъча вече сумати време да реша - и не се получава. ifconfig eth1 inet add 192.168.0.1 netmask 255.255.255.0 up хмм тук май аз сам в грешка :) явно по-новите версии на ifconfig позволяват такъв синтаксис! относно IPv4 беше шега, освен ако не си с някакво измислено ядро. Сега сериозно по въпроса грешката означава: 1. или не можеш да създаваш синоними /alias/ на интерфейса 2. или вече си вдигнал такъв адрес на някой от другите
