CyberDuck pisze:
Przy komendzie arp restart :
/etc/rc.d/arp restart
a wlasnie mialem CI dopisac abys wywalil z ethers komentarze.... u siebie posiadam czyste listy IP MAC i nigdy nie mialem problemow z tablica statyczna
| Freesco, NND, CDN, EOS http://forum.freesco.pl/ |
|
| arp nie działa..... http://forum.freesco.pl/viewtopic.php?f=22&t=16251 |
Strona 2 z 2 |
| Autor: | CyberDuck [ niedziela, 4 stycznia 2009, 14:23 ] |
| Tytuł: | |
Wiec tak. Usunolem wszystko co niepotrzebne z /etc/ethers i po podaniu arp -f zadzialalo. Okazuje sie, ze chyba nie sa tolerowane wpisy na koncu linii nawet po # . Wszystkie wpisy jedynie z symbolem spacji bez tabulatora. |
|
| Autor: | Osfald [ poniedziałek, 5 stycznia 2009, 13:55 ] |
| Tytuł: | |
CyberDuck pisze: Przy komendzie arp restart :
/etc/rc.d/arp restart
a wlasnie mialem CI dopisac abys wywalil z ethers komentarze.... u siebie posiadam czyste listy IP MAC i nigdy nie mialem problemow z tablica statyczna |
|
| Autor: | CyberDuck [ poniedziałek, 5 stycznia 2009, 16:41 ] |
| Tytuł: | |
No teraz tez nie ma 
Dziekuje za pomoc. Doszedlem do tego po probach. Normalnie w innych plikach komentarze na koncu sa dozwolone wiec pomyslalem, ze tutaj tez moga byc i dla porzadku dopisalem na koncu po # nicki osob w sieci zeby odrazu wiedziec kto jest kto, ale jak widac to niewychodzi. U mnie ten plik jest generowany przez skrypt php, ale wprowadzilem juz pare poprawek i jest ok. |
|
| Autor: | adamol [ środa, 1 grudnia 2010, 15:55 ] |
| Tytuł: | |
Odkopię. Jak w temacie arp nie blokuje dostępu dla błędnych par IP-MAC Co ciekawe na błędnym adresie poza tym, że wszystko działa to ping do serwera zamiast <1ms oscyluje w okolicach 3-4 ms, transfer jest 5-o krotnie słabszy i w sumie nie wiem w czym problem. Dla sieci 192.168.1.1/16 wpisy w ethers są zapełnione od 192.168.0.2 do 192.168.3.254 z pominięciem 192.168.x.1 Komendy arp -f itp nie wywalają żadnych błędów, w /etc/rc.d/ nie mam pliku arp i temu podobnych, tylko w /sbin. Zmajstrowałem nawet takie coś do /etc/rc.d/ #/etc/rc.d/arp # plik_arp=/etc/ethers [ -f $plik_arp ] || exit 0 # See how we were called. case "$1" in start) # Start daemons. echo "Adding arps records: " grep "^" $plik_arp |grep -v "^#"| while read ip hw_addr; do if [ "$hw_addr" = "" ]; then echo -n "" else /sbin/arp -s $ip $hw_addr # echo $ip $hw_addr fi done echo ;; stop) # Stop daemons. echo -n "Removing static arp records: " grep "^" $plik_arp | grep -v "^#"| while read ip hw_addr; do if [ "$hw_addr" = "" ]; then echo -n "" else /sbin/arp -d $ip >/dev/nul # echo -n "." fi done echo ;; restart) $0 stop $0 start ;; status) /sbin/arp -n ;; *) echo "Usage: static-arp {start|stop|restart|status}" exit 1 esac exit 0 Również błędów nie wyrzuca. arp -a -n ? (192.168.0.60) at 19:4B:D6:4C:xx:xx [ether] PERM on eth1 ? (192.168.1.145) at 00:A1:B0:xx:xx:53 [ether] PERM on eth1 ? (192.168.1.220) at 00:1D:xx:xx:D0:66 [ether] PERM on eth1 ? (192.168.1.131) at 00:00:xx:xx:B0:D0 [ether] PERM on eth1 ? (192.168.0.41) at 09:1B:2F:6A:xx:xx [ether] PERM on eth1 arp -n 192.168.0.60 ether 19:xx:xx:xx:xx:B9 CM eth1 192.168.1.145 ether 00:A1:xx:xx:xx:xx CM eth1 192.168.1.220 ether 00:xx:xx:xx:xx:xx CM eth1 192.168.1.131 ether 00:xx:xx:xx:xx:xx CM eth1 192.168.0.41 ether 09:1B:2F:xx:xx:xx CM eth1 Komentarzy w ethers oczywiście nie ma, pomysłu na rozwiązanie również więc proszę o rady
Co może mieć wpływ na działanie arpa co może być w konflikcie, żadnych wydziwień nie mam uruchomionych na serwerze, dnsmasq, dhcp, niceshaper, imqp2p. Kernelversion 2.4.32-10nnd Pozdrawiam |
|
| Autor: | JakubC [ piątek, 3 grudnia 2010, 04:39 ] |
| Tytuł: | |
Sprawdź czy coś innego w sieci nie dubluje Ci adresu bramy. PS Symetryk 4/4 Mbit za 39 pln?;) Konkurencja nie podkupuje łącza?;) |
|
| Autor: | adamol [ poniedziałek, 13 grudnia 2010, 04:56 ] |
| Tytuł: | |
Witam Dopiero zauważyłem odpowiedź. Nie mam dubla bramy, chyba, że jakiś niewidoczny. arping -I eth1 192.168.1.1 ARPING 192.168.1.1 from 192.168.1.1 eth1 Sent 4 probes (4 broadcast(s)) Received 0 response(s) ping 192.168.1.1 PING 192.168.1.1 (192.168.1.1) 56(84) bytes of data. 64 bytes from 192.168.1.1: icmp_seq=1 ttl=64 time=0.082 ms 64 bytes from 192.168.1.1: icmp_seq=2 ttl=64 time=0.067 ms 64 bytes from 192.168.1.1: icmp_seq=3 ttl=64 time=0.070 ms 64 bytes from 192.168.1.1: icmp_seq=4 ttl=64 time=0.064 ms --- 192.168.1.1 ping statistics --- 4 packets transmitted, 4 received, 0% packet loss, time 2999ms rtt min/avg/max/mdev = 0.064/0.070/0.082/0.012 ms Inna inszość, że na niektórych adresach wpisanych ręcznie w konfiguracji IP owszem blokuje dostęp do sieci, ale do serwera już nie blokuje a też powinno ... Nie tam, konkurencja nie dziaduje, ma swoje ... problemy
|
|
| Autor: | adamol [ czwartek, 6 stycznia 2011, 15:15 ] |
| Tytuł: | |
Co ciekawe z nowych obserwacji to: Problem braku "działania" arpa dotyczy się tylko IP które mają ttl wyższe niż 2. Wyłączenie arpa zwiększa ttl o 1 a jego ponowne włączenie zmniejsza ttl o 1 i dodatkowo ping do do bramy i dalej w świat rosną o około 2ms, transfer z arpem również spada, mowa tu oczywiście o parze IP-MAC nie zgodnym z MACiem w tablicy arpa czyli ręcznie wpisanym "błędnym" IP. Ciekawe ? 
|
|
| Autor: | rikardo7 [ piątek, 7 stycznia 2011, 16:18 ] |
| Tytuł: | |
Wygrzebałem plik startowy arpa z /etc/rc.d/ leżał sobie na dysku z NND i przeglądając ten plik trochę się rożni od twojego teraz jest TUTAJ . Można go odpalić jako demona,i z tego co pamiętam to arp działał mi na tym NND. |
|
| Autor: | adamol [ niedziela, 9 stycznia 2011, 00:30 ] |
| Tytuł: | |
Dzięki sprawdzę w wolnej
|
|
| Autor: | adamol [ niedziela, 22 maja 2011, 23:31 ] |
| Tytuł: | |
Sobie odpowiem. Dysk z systemem zainstalowany na maszynie A, wszystko działa, arp również. Ten sam dysk wrzucony na maszynę B, wszystko działa (chyba), arp NIE. Co ma na to wpływ ? Karty sieciowe te same, inne płyta, proc, zasilacz, kable, kolor obudowy
|
|
| Strona 2 z 2 | Strefa czasowa UTC+2godz. |
| Powered by phpBB® Forum Software © phpBB Group https://www.phpbb.com/ |
|