Can't join gameserver since last update

[Guest]

[Agila]

ping -f -l 1472 (insert the server details here)

unfortunately ICMP request has been block for this server.

I have tried wireshark. test it with 72.232.225.66:23071 and with other servers.
It shows an extra line with fragment IP protocol and a lot of bad checksum.

I guess thats the reason why comodo is blocking it. 

[Quill]

 This is from my system:

ping -f -l 1372 72.32.225.66

Pinging 72.32.225.66 with 1372 bytes of data:
Reply from 72.32.225.66: bytes=1372 time=295ms TTL=56
Reply from 72.32.225.66: bytes=1372 time=292ms TTL=56
Reply from 72.32.225.66: bytes=1372 time=293ms TTL=56
Reply from 72.32.225.66: bytes=1372 time=293ms TTL=56

Ping statistics for 72.32.225.66:
    Packets: Sent = 4, Received = 4, Lost = 0 (0% loss),
Approximate round trip times in milli-seconds:
    Minimum = 292ms, Maximum = 295ms, Average = 293ms

ping -f -l 1373 72.32.225.66

Pinging 72.32.225.66 with 1373 bytes of data:
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.
Packet needs to be fragmented but DF set.

Ping statistics for 72.32.225.66:
    Packets: Sent = 4, Received = 0, Lost = 4 (100% loss),


1372 is the ping packet size but does not include IP/ICMP header of 28 bytes. So, 1372+28=1400, the actual MTU.

As I said this right for my system, it may well be different for yours, it will depend on things like make and model of router, the configuration at your ISP etc.

The fact that data is being lost/corrupted (Bad CRC) very likely goes a good way to explaining why you're having problems. The question to answer now would be, why is data getting lost?  That's a much harder question to answer.

[Agila]

ping -f -l 1372 72.32.225.66

Sorry. didn't even tested it before. it do work.


From what i understand regarding MTU , if it was setup incorrectly there is a possibility that I can't access the server, right?

I was looking at the logs from wireshark and i also notice that it has larger frame length compared to other servers, which i can access (611 bytes)
Does this have relation with MTU settings?

Code:

No.     Time        Source                Destination           Protocol Info
      4 3.449158    72.232.225.66         192.168.1.2           IP       Fragmented IP protocol (proto=UDP 0x11, off=0, ID=ffe6) [Reassembled in #5]

Frame 4 (1514 bytes on wire, 1514 bytes captured)
    Arrival Time: Jul 11, 2009 12:01:01.452042000
    [Time delta from previous captured frame: 0.290273000 seconds]
    [Time delta from previous displayed frame: 0.290273000 seconds]
    [Time since reference or first frame: 3.449158000 seconds]
    Frame Number: 4
    [b]Frame Length: 1514 bytes[/b]
    Capture Length: 1514 bytes
    [Frame is marked: False]
    [Protocols in frame: eth:ip:data]
Ethernet II, Src: AztechEl_e6:ee:89 (00:30:0a:e6:ee:89), Dst: AsustekC_59:b8:ce (00:17:31:59:b8:ce)
Internet Protocol, Src: 72.232.225.66 (72.232.225.66), Dst: 192.168.1.2 (192.168.1.2)
Data (1480 bytes)

[Quill]

Yes, frame size is important. When the data to be sent reaches the Datalink Layer of the stack, it is is placed in to a frame. The frame size is dictated by the underlying network type, such as Ethernet, FDDI etc.

We essentially come back to the earlier discussion. For what ever reason, the server you cannot reach, is doing something different to the servers you can reach. Whether, that's network related or configuration related is difficult to discern.

It would probably be easier to send the host an email asking for the relevant details...
 

[Agila]

Thank a lot for your help, toggie.  

I just wanted to make sure about the discrepancy with frame sizes.

It would probably be easier to send the host an email asking for the relevant details...
 

that I will do.

[Tags:]