Sziasztok!
Egy elég érdekes anomáliába futottam..
1 db ubuntu server router, 30 linuxos gép..
29 gép tökéletesen működik, egy viszont 30mp-ként dhcp request-et küldözget szerencsétlen routernak.
Kliens gép friss, javítások letöltve, csakúgy mint a többi kliensen.
Találkozott már vmikőtök ilyennel?
Sziasztok!
Most olvastam ezt a cikket:
http://itcafe.hu/hir/t-home_80_megas_internet_szeptember_ftth_kabel.html
és azon gondolkodtam, vajon emelik-e a meglévő hűségnyilatkozatosak sávszélességét is? Vagy esetleg újra lehet kötni a szerződést a hűségnyilatkozat meghosszabításával?
Itt is van 1 kis infó:
Üdv...G.
Mi a legegyszerubb, legcelravezetobb megoldas a kovetkezo problemara?
Szeretnek egy kivulrol (internetrol) elerheto SSH daemont futtatni egy virtualbox guest-ben, ugy, hogy a host egy router mogott van.
Amit eddig probaltam: a router egy tetszoleges portot (mondjuk 11111) forwardol a host egy tetszoleges portjara (22222) amit a vbox forwardol a guest 22-es portjara. Ez ott akadt el, hogy host-ot nem tudtam ugy beallitani, hogy a 22222-es portra erkezo csomagokat ne dobalja el, hanem kezdjen veluk valamit.
De biztos van ennel egyszerubb megoldas is, remelem tudtok segiteni.
Sziasztok,
Hercules emulátorral futtatok egy z/OS 1.5 (guest) oprendszert amelyet szeretnék elérni a hálózat bármely gépéről.
Info:
Hálozat: 192.168.1.0/255.255.255.0
router : 192.168.1.1
host : 192.168.1.10 (eth0) (linux 2.6 oprendszer, ezen fut az emulátor)
zOS : 192.168.1.11 (tap0)
IPL után így néznek ki a fontosabb paraméterek:
ifconfig (host):
eth0 Link encap:Ethernet HWaddr 00:1a:4d:57:b4:38
inet addr:192.168.1.10 Bcast:192.168.1.255 Mask:255.255.255.0
inet6 addr: fe80::21a:4dff:fe57:b438/64 Scope:Link
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:259576 errors:0 dropped:0 overruns:0 frame:0
TX packets:267575 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:1000
RX bytes:127924739 (127.9 MB) TX bytes:189166714 (189.1 MB)
Interrupt:251 Base address:0x4000
lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
inet6 addr: ::1/128 Scope:Host
UP LOOPBACK RUNNING MTU:16436 Metric:1
RX packets:108287 errors:0 dropped:0 overruns:0 frame:0
TX packets:108287 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:42546385 (42.5 MB) TX bytes:42546385 (42.5 MB)
tap0 Link encap:Ethernet HWaddr 8e:4a:a3:5f:4b:4d
inet6 addr: fe80::8c4a:a3ff:fe5f:4b4d/64 Scope:Link
UP BROADCAST RUNNING MTU:1500 Metric:1
RX packets:1 errors:0 dropped:0 overruns:0 frame:0
TX packets:5 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:500
RX bytes:64 (64.0 B) TX bytes:398 (398.0 B)
netstat -rn (host):
Kernel IP routing table
Destination Gateway Genmask Flags MSS Window irtt Iface
192.168.1.11 0.0.0.0 255.255.255.255 UH 0 0 0 tap0
192.168.1.0 0.0.0.0 255.255.255.0 U 0 0 0 eth0
169.254.0.0 0.0.0.0 255.255.0.0 U 0 0 0 eth0
0.0.0.0 192.168.1.1 0.0.0.0 UG 0 0 0 eth0
ping, ftp (from host):
gabor@quad ~ $ ping 192.168.1.11
PING 192.168.1.11 (192.168.1.11) 56(84) bytes of data.
64 bytes from 192.168.1.11: icmp_seq=1 ttl=64 time=1.48 ms
64 bytes from 192.168.1.11: icmp_seq=2 ttl=64 time=1.32 ms
^C
--- 192.168.1.11 ping statistics ---
2 packets transmitted, 2 received, 0% packet loss, time 1001ms
rtt min/avg/max/mdev = 1.329/1.407/1.485/0.078 ms
gabor@quad ~ $ ftp 192.168.1.11
Connected to 192.168.1.11.
220-FTPD1 IBM FTP CS V1R5 at p390.svo.dfw.ibm.com, 09:39:26 on 2009-08-07.
220 Connection will close if idle for more than 5 minutes.
Name (192.168.1.11:gabor):
routing info (zOS):
- 03.40.36 d tcpip,,net,rout
EZZ2500I NETSTAT CS V1R5 TCPIP FRAME LAST F E SYS=P390
DESTINATION GATEWAY FLAGS REFCNT INTERFACE
DEFAULT 192.168.1.1 UGS 000000 ETH1
127.0.0.1 0.0.0.0 UH 000003 LOOPBACK
192.168.1.0 0.0.0.0 US 000000 ETH1
192.168.1.11 0.0.0.0 UH 000000 ETH1
4 OF 4 RECORDS DISPLAYED
Jelenleg a host gépről elérem a zOS-t és vissza. Hogyan tudom a 192.168.1.11 címet más gépekről is láthatóvá tenni? Nem tudom, hogy ez a bridge-el megoldhato-e.
Köszi,
Gábor
Hali!
Nemregiben pannon internetre fizettek elo szuleim, OS: Vista, bongeszo IE8. Firefoxal, mas bongeszokkel nem mukodik. FF szerint a kapcsolodas sikertelen. Direkt van tiltva, vagy esetleg rejtett beallitas kerdese? Ugyfelszolgalat persze csak a fejet razza, mondvan hasznaljak IEt.
Azt akartam, hogy tudjon két kliens egy külön subnetben kapcsolódni a központi géphez.
Arra gondoltam, az szerver lesz 10.8.3.1, egyik kliens 10.8.3.2, másik 10.8.3.3
Azt hiszem, első körben elrontottam a konfigurációt, a ccd könyvtárban az egyiknek ezt írtam:
ifconfig-push 10.8.3.3 10.8.3.1
A másiknak
ifconfig-push 10.8.3.2 10.8.3.1
Ha nem tévedek, akkor fordítva kellett volna (bár ez most nekem eléggé konfúz, bevallom)
ifconfig-push 10.8.3.1 10.8.3.3
ifconfig-push 10.8.3.1 10.8.3.2
De nem is ez a gond, mert amíg csak az egyik kapcsolódik, voltaképp mindegy, hogy a szerver az egyes és a kliens a 3, vagy fordítva, hanem kapcsolódási kísérlet során ezt a hibaüzenetet kaptuk:
Mon Aug 03 17:34:03 2009 There is a problem in your selection of
--ifconfig endpoints [local=10.8.3.3, remote=10.8.3.1]. The local and
remote VPN endpoints cannot use the first or last address within a
given 255.255.255.252 subnet. This is a limitation of --dev tun when
used with the TAP-WIN32 driver. Try 'openvpn --show-valid-subnets'
option for more info.
Na ez micsoda? Nem biztos, hogy értem az üzenetet. 252 az 1111.1100, tehát szerintem annak az első címe az 10.8.3.0 lenne, az utolsó meg 10.8.3.3 Szóval ez a gond? A 3? Meg akkor gondolom a 4, de az 5 újra jó lesz?
Elég fura. Most nem tudom tesztelni sajnos.
Valaki találkozott már ilyennel?
Adott az alábbi Postfix Debina GNU/Linux Sarge rendszeren:
main.cf
--------------
smtpd_banner = $myhostname ESMTP $mail_name (Debian/GNU)
biff = no
append_dot_mydomain = no
mydomain = sajatdomain.hu
myhostname = mail.sajatdomain.hu
alias_maps = hash:/etc/aliases
alias_database = hash:/etc/aliases
myorigin = /etc/mailname
mydestination = sajatdomain.hu, server.sajatdomain.hu, localhost.sajatdomain.hu, localhost
relayhost =
mynetworks = 127.0.0.0/8 192.168.10.0/24
mailbox_size_limit = 0
recipient_delimiter = +
inet_interfaces = all
home_mailbox = Maildir/
smtpd_require_helo=yes
smtpd_helo_restrictons=reject_invalid_hostname
smtpd_sender_restriction=reject_unknow_address
smtpd_recipient_restriction=permit_mynewtworks,check_relay_domains,
reject_rbl_client = relays.ordb.org,
reject_rbl_client = blackholes.easynet.nl,
reject_rbl_client = cbl.abuseat.org,
reject_rbl_client = proxies.blackholes.wirehub.net,
reject_rbl_client = bl.spamcop.net,
reject_rbl_client = sbl.spamhaus.org,
reject_rbl_client = opm.blitzed.org,
reject_rbl_client = dnsbl.njabl.org,
reject_rbl_client = list.dsbl.org,
reject_rbl_client = multihop.dsbl.org,
reject_rbl_client = psbl.surriel.com,
reject_rbl_client = dnsbl.sorbs.net,
reject_rbl_client = dynablock.njabl.org,
reject_rbl_client = ralays.ordb.org,
reject_rbl_client = sbl.spamhaus.org,
reject_rbl_client = blcakholes.wirehub.net
maps_rbl_domains =
sbl.spamhaus.org,
relay.ordb.org,
list.dsbl.org,
dynablock.wirehub.net,
blackholes.wirehub.net,
relays.visi.com,
dialups.visi.com
smtpd_tls_auth_only = no
smtp_use_tls = yes
smtpd_sasl_auth_enable = yes
smtpd_sasl_type = cyrus
local_recipient_maps =
smtp_tls_note_starttls_offer = yes
smtpd_use_tls = yes
smtpd_tls_cert_file = /etc/postfix/smtpd.cert
smtpd_tls_key_file = /etc/postfix/smtpd.key
smtpd_tls_CAfile = /etc/postfix/cacert.pem
smtpd_tls_loglevel = 3
smtpd_tls_received_header = yes
smtpd_tls_session_cache_timeout = 3600s
tls_random_source = dev:/dev/urandom
------------
A szerver egyetlen domaint szolgál ki a sajatdomain.hu levelezését kezeli.
A dolgozók szerették volna ha kivülről is tudnának smtp azonosítás után
levelet küldeni. A fenti "smtpd_ ..., stb" sorokat ilesztettem a
beállítások végére. A dolog félig működik: Lehet hálózaton kivülről
levelet küldeni, de csak a sajatdomain.hu címekre. Hálózaton kivülre
nem lehet küldeni "kintről". A belső hálóról ugyanakkor lehet küldeni bárhová,
mint az korábban is működött. Persze lett egy szépséghibája, most már
belső hálón is csak azonosítás után lehet küldeni, de ezt beállítottuk
a dolgozok kliensein hamar.
Viszont a hálózaton kivülről a hálózaton kivülre levélküldés kellene,
mert az nem megy. Arra gondoltam, hogy ez csak a /etc/postfix/main.cf
egy helyes, helytelen vagy hiányzó beállítása hozhatja helyre, ezért
csak azt másoltam fent be. Van valakinek ötlete?
Baratnomnel az internet szornyu allapotban volt, hihetetlenul lassu volt, sokszor meg-megallt. A tippem bejott, korulbelul 50%os csomagvesztes volt tapasztalhato. A router egy MSI rg60SE okozta a hibat. Noha helyi halozaton semmi gondja nem volt, a wan fele dobalta a csomagokat.
Gondoltam magamban: hat elofordulnak szar hardverek. Azota egy lafonera routerrel tokeletesen megy. Annak viszont nincs LAN portja, kellett venni egy masik routert:
Egy TP-LINK WR340GD router lett veve. Mikor elosszor (baromi gyorsan) bebootolt lattam hogy ennek pontosan olyan admin felulete van mint a masiknak (A firmware szeria ugyan mas). Rossz eloerzetem beigazolodott mikor ugyanugy 50%os csomagvesztest produkalt.
Szar a firmware? Szar ez a szeria? Rosszul implementalja az rfc-t?
Update: Firmware upgrade utan is ugyanez.
(Remélem itt jó helyen lesz a totyik)
Sziasztok,
a probléma a címben :)
Kicsit bővebben:
Könyvelőméknél én rugdosom a rencert, és kitalálták, hogy legyen már hálózatos az abev + abevjava, mert az milyen jó.
Solaris 10 + samba, zfs mirroron csücsül a megosztott alkönyvtár. (vas: X2100M2, 5GB ram)
Egy nyomtatvány megnyitása (azaz a lista behozása) a klienseken (xp és win 2000, vegyesen) 1 perc körül van, ami rengeteg, idegőrlő... Mármint a használói szerint - elhiszem nekik, hiszen szinte percenként nyitogatják - nyitogatNÁK a bevallásokat.
Próbáltam sok paraméterrel játszani, de nem sikerült érezhető, igazán nagy különbségeket generálnom a betöltési időben...
A problémát nyilván az okozza, hogy az "abevjavapath"/mentes alkönyvtárban lennének a szóban forgó fileok, amik 2-3-4 és néhány tíz kb méret közöttiek, és most olyan 780-an vannak...
Jelenleg így néz ki az smb.conf-om, egyébként a "Solaris-szal szállított" samba-t használom, ha ez számít.
[global]
display charset = UTF8
domain master = no
local master = yes
preferred master = no
os level = 99
wins support = no
workgroup = WORKGROUP
Netbios Name = Solaris
server string = Solaris Server
log file = /var/samba/log/log.%m
max log size = 10240
# socket options = TCP_NODELAY SO_KEEPALIVE SO_RCVBUF=8192 SO_SNDBUF=8192
# socket options = TCP_NODELAY SO_KEEPALIVE IPTOS_LOWDELAY
socket options = TCP_NODELAY SO_KEEPALIVE SO_SNDBUF=65536 SO_RCVBUF=65536 IPTOS_LOWDELAY
load printers = no
ldap ssl = no
interfaces = bge0
invalid users = root
# veto files = .*/local.*/INBOX/INBOX.*
# hide files = .*/local.*/INBOX/INBOX.*
printcap name = /dev/null
load printers = no
lock spin time = 15
lock spin count = 30
read raw = yes
write raw = yes
kernel oplocks = yes
max xmit = 65535
[abev]
path= /abev
public = yes
writeable = yes
browseable = yes
create mask = 777
directory mask = 777
oplocks = yes
Esetleg valakinek van tapasztalata/ötlete?
Köszönöm, hogy elolvastad! :)
A korábbi dhcpcd-t érintő probléma, aminek során a hálózati interfészek MTU-ja 576 bájtra állítódott után itt az újabb. Azóta az MTU a korábbi és az internetszolgáltató által javasolt 1500-on van, tehát ez nem okozhatja a masszív packet loss-t, ami ma délelőtt óta folyamatosan jelentkezik.
A rendszert azóta nem frissítettem, tegnap még nem tapasztaltam lassulást.
A probléma vezetéknélküli internettel is jelentkezik, tehát nem a hálózati kártya vagy a kábel okozzák.
A router sem okozhatja, közvetlenül a modemre csatlakozva is packet loss jelentkezik.
Valaki tapasztalt már hasonlót?
(Mindjárt kiírok egy LiveCD-t megnézni egy másik operációs rendszerrel, késő délután pedig lesz egy másik gép is itthon, azzal is megnézem)
Update: Ubuntu 9.04 LiveCD-vel is 50% és afeletti packet loss.
Tehát vagy a kábelmodem rossz, vagy az ahhoz tartozó kábel, vagy valahol a T-Online-nál van a hiba. Az internetkapcsolat egyébként 2Mbit-es kábelnet, helyileg Gyulán (Békés megye).
(Még lemegyek haveromhoz letesztelni az ő T-Online-os kábelnetét ugyanezzel a géppel, de tartok tőle, hogy feleslegesen)
Update: Megoldódott a dolog magától, ezek szerint a szolgáltató volt a ludas. Egy kicsit talán elhamarkodottan csináltam ezt a topikot, de a tegnapi MTU-s hálózati gebasz után minden előfordulhat, de a hiba ezúttal nem itt volt.