δεν μπορώ να συνδεθώ στο contra.gr

[subdee]

Με το Ubuntu Dapper και το Firefox και Firestarter, δεν μπορώ να συνδεθώ στο http://www.contra.gr

 

Άλλοι browsers δεν συνδέονται.

 

Με ping πέρνω απάντηση και ip αλλά με tracepath πάει καλά μέχρι το 14ο πηδηματάκι και μετά εξαφανίζεται!

 

Οι υπόλοιποι υπολογιστές στο ίδιο LAN συνδέονται κανονικά.

 

Το αρχείο /etc/hosts είναι καθαρό.

 

Τι μπορεί να συμβαίνει;

[NullScan]

Σε άλλα sites μπαίνεις κανονικά? Άν κάνεις clear την cache του firefox και ξαναδοκιμάσεις? Το ότι εξαφανίζεται το tracepath μετά από κάποιο hop δεν σημαίνει τίποτα, μπορεί απλώς να το έχουν στήσει έτσι το δίκτυό τους αυτοί.

[subdee]

σε όλα τα άλλα sites συνδέομαι κανονικά.

 

την cache την έχω καθαρίσει αλλά τίποτα.

[nske]

- Όταν δε μπορεί να συνδεθεί ο browser, μετά από ένα διάστημα, επιστρέφει ένα μήνυμα με το λόγο. Ποιο είναι αυτό;

 

- Δοκίμασε

>$ telnet www.contra.gr 80

 

και αφού συνδεθεί (αν συνδεθεί) στείλε ένα http request π.χ.

 

>
GET / HTTP/1.1
Host: www.contra.gr
Connection: Close

 

Λογικά πρέπει να σου έρθει το HTML source της κεντρικής. Έρχεται;

 

- Χρησιμοποίησε έναν sniffer σαν το TCPdump (console interface) ή το Ethereal (GUI) και κάνε paste τις πληροφορίες των πακέτων που συλλαμβάνουν την ώρα του προβλήματος.

[subdee]

-το μύνημα είναι: The connection has timed out

The server at http://www.contra.gr is taking too long to respond.

 

-μέσω telnet δεν μπορούσα να συνδεθώ.

 

-το Ethereal μου έβγαλε αυτά για τη προσπάθεια σύνδεσης με το contra.gr

 

[nske]

χμμ, πιθανόν να υπάρχει κάποιο πρόβλημα με το Path-MTU Auto Discovery, για δοκίμασε να μειώσεις το mtu της κάρτας δικτύου σου σε 1420 (MSS 1380):

 

"ifconfig eth0 mtu 1420"

[subdee]

ναι αλλά αυτό δε θα επηρέαζε και άλλες ιστοσελίδες;

 

παρόλα αυτά, δεν έκανε καμιά διαφορά

[nske]

Όχι απαραίτητα, καθώς κάθε site μπορεί να έχει διαφορετικό MTU, ανάλογα το χαμηλότερο mtu κάθε ενός από τους ενδιάμεσους routers. Π.χ. αν εσύ δήλωνες ότι μπορείς να δεχτείς MTU 1500 αλλά λόγω κάποιου vpn/pppoe link που προσέθετε κι άλλο protocol overhead, τα πακέτα θα έρχονταν πετσοκομένα (αν καν) μόνο από sites που στέλναν μεγαλύτερα πακέτα από αυτά που πράγματι μπορείς να δεχθείς (μιας και το 1500 είναι το μέγιστο MTU για fast ethernet). Βέβαια αυτό δεν φαίνεται να ισχύει στην περίπτωση σου, απλά έριξα άδεια μήπως πιάσω γεμάτη. :-P

 

Για το πρόβλημα δε ξέρω τι φταίει πάντως μου φαίνεται κάτι σε επίπεδο δικτύου. Εκτός αν τρέχεις κανένα περίεργο ruleset στα Iptables που παίζει με mangling.

[NullScan]

Έχεις δίκιο σε αυτό που λές nske αλλά το σύστημα στέλνει επιτυχημένα το sync πακέτο οπότε αν υπήρχε πρόβλημα με το mtu δεν θα μπορούσε να στείλει ούτε αυτο. Θεωρητικώς πάντα... Τί άλλες ρυθμίσεις έχεις κάνει στο σύστημα σε σχέση με το interface ? Κάποιο entry στο hosts.deny? Στο firewall κατα λάθος ίσως?

 

Επίσης: Το πρόβλημα πόσο καιρό το παρατηρείς? Είναι σημερινό φαινόμενο? από το PC σου τι connections έχεις ανοιχτά με τον εξω κόσμο? Μήπως έχει κανει καποιο tweak στο about:config του firefox?

[apoikos]

Έχεις δίκιο σε αυτό που λές nske αλλά το σύστημα στέλνει επιτυχημένα το sync πακέτο οπότε αν υπήρχε πρόβλημα με το mtu δεν θα μπορούσε να στείλει ούτε αυτο. Θεωρητικώς πάντα...

 

Όχι, διότι το SYN είναι πάντα πολύ μικρότερο από το MTU. Τα προβλήματα με το PMTU παρουσιάζονται όταν θες να στείλεις πολύ μεγάλα μηνύματα, με MSS > MTU, και έχουν το DF (Do not Fragment) flag set. Τυπικά αυτό εμφανίζεται όταν πας να αντλήσεις μεγάλες ποσότητες δεδομένων, π.χ. να κάνεις ένα ls -l σε ένα ssh terminal ή να τραβήξεις μια μεγάλη σελίδα. Στις περιπτώσεις αυτές, αν το MSS είναι μεγαλύτερο από το PMTU, η σύνδεση κρεμάει. Υπάρχει workaround target στα iptables γι' αυτό το σκοπό ;-)

 

@xaxa1982: Τι πύρηνα έχεις; Δοκίμασε να κάνεις ένα

>
echo 4096 87380 174760 > /proc/sys/net/ipv4/tcp_rmem

 

Αν δε δουλέψει, δοκίμασε να απενεργοποιήσεις τελείως το TCP window scaling:

>
echo "0" > /proc/sys/net/ipv4/tcp_window_scaling

[nske]

Τα SYN πακέτα, άσχετα με τι mss έχουν δηλωμένο, έχουν μηδαμινό μέγεθος οπότε δε θα είχαν πρόβλημα. Τα πακέτα με τα data είναι αυτά που θα είχαν πρόβλημα, καθώς αναγκαστικά γεμίζουν όλο το MSS. Με βάση τα στοιχεία μάλλον δεν ευσταθεί αυτό που είπα, απλά έκρινα αποκλειστικά από τα συμπτώματα

 

edit -- Γκουχ.. πάλι έφαγα τη σκόνη του Apoikou, μάλλον πρέπει να κλείνω το MSN όταν post-άρω στο forum :-P

[NullScan]

Συγγνώμη κιόλας που επιμένω, αλλά και τα ACK πακέτα έχουν το ίδιο μηδαμηνό μέγεθος. Γενικώς η όλη διαδικασία 3-way-handshake σχεδιάστηκε ώστε να είναι γρήγορη, γύρω στα 70 bytes το κάθε πακέτο. Για να μήν πώ ότι το SYN είναι μεγαλύτερο για τί στέλνει στον server και κάποια options καθώς και το max segment που δέχεται ο client που το ACK δεν στέλνει. Αλλιώς τα 2 πακέτα διαφέρουν μόνο στο TCP flag.

No offence πάντα, έτσι

[nske]

Σίγουρα, γενικά όλα τα SYN/ACK/RST/FIN πακέτα δε θα επηρεάζονταν καθόλου από το MTU. Για να είμαι ειλικρινής δεν μπορώ να ερμηνεύσω ακριβώς το "ACKed lost segment" μήνυμα του Ethereal, οπότε δεν μπορώ να είμαι σίγουρος αν το handshaking ολοκληρώνεται. Μάλλον όχι βέβαια, για να μην στέλνει στη συνέχεια HTTP request ο client, αλλά γιατί; :-P

 

Subdee μήπως μπορεί να δώσει κάποια παραπάνω πληροφορία το ethereal; Ειδικά πάνω στο Lost Segment (request για επανάληψη αποστολής; ).

[subdee]

λοιπόν, αποίκος, δε βοήθησε η απενεργοποίηση του window scaling.

 

παραθέτω μια ακόμα προσπάθεια που δείχνει χειραψίες κάθε τόσο χωρίς να προχωράει;

 

και μια εικόνα με την ανάλυση του Lost Segment...

 

τι πράγμα είναι αυτό ρε γμτ...

[or1onas]

Τσέκαρε το log του firestarter. Αναφέρει μήπως τίποτα σχετικό με 'RPC-Sun Portmap'; Έχω το ίδιο πρόβλημα με το google.com.