lose ftp connection (or IP address) and have to reboot

R

rodp

Member
Hi All,

I'm new here but I've already had a good play with my new HDR T2 Box and almost got it working the way I'd like it to. I have one major problem though. I don't seem to be able to successfully transfer files to or from the unit either by FTP / SFTP or Samba. I've installed the relevant latest packages (plus tried the bog standard ftp service that comes with the box) and each time at some random point, the connection is lost and the transfer fails. I've been trying to transfer files as small as 700Mb and have even tried changing the buffer size on the ftp programs (512 / 4096 / 32768 bytes) which perhaps helped a little but then it still fails so can't be sure this has infact helped. There is no improvement using SFTP either. It just says connection time out and you can no longer ping the unit nor access it's webif content until you reboot.

The strange thing is that the router still says it's address (fixed IP address of 192.168.1.4) is still active by way of the green light on the port and it's status IP page (BT Voyager 2110) So the only way to sort it out is to put the Hummy into standby, wait for the HDD to spin down and then restart it (so not to the extent of cold booting but almost I suppose).

I don't think it's a network cable issue as it's a new cable and transfers can happily work for 5 even 10 minutes (or just a few seconds!) but then (and without warning) is suddenly lost.

Please could someone else confirm they've experienced this issue aswell and possible things to test.

Should I try a cross over network cable to remove potential issue with my router? Transferring files to other PCs via the router is perfectly fine though.

Many thanks in advance

Rodp
 
We have heard of various problems with traffic like this, and IIRC at least some of them have come down to the configuration of the router. You seem to have the technical know how, so by all means set up a point-to-point network (it may not be necessary to use a crossed cable, I think the Humax port auto-switches).
 
Hi Both - I'll try both... re the MTU setting. As per the notes you directed me to, is 1400 the best figure to use. I don't really know much about what is better / best.

Thanks

Rodp
 
I had to smile at "I've been trying to transfer files as small as 700Mb".

Can you run Wireshark or similar on the other machine to see what's happening ?

FWIW, it doesn't sound like MTU problems to me - they usually show up as soon as you try to move any real amount of data. E.g. you can telnet in and do "date" OK, but "ls -al" locks up. I'd suspect the router.

I'm fairly certain that the Humax auto-switches on the Ethernet port.
 
Hi All,

Update for you - I tried using my old 3com router (about 10 years old: 3CRWE754G72-A software version 1.31) and it's now all working fine!! - no loss of connection or anything. So could someone help me understand what might be different between the two routers (my current one is a BT Voyager 2110 firmware version 3.30r about 3-4 years old). The MTU on the voyager is set at 1500 which is the default but the MTU on the 3com is 1454 (however this setting is in the internet setting part which is confusing me as is that not then something to do with the internet / phone line connection and not the internal LAN?). Should I try changing this to 1400 / 1454? I've not changed anything on the hummy just yet so it must be the router that is the problem.

Andrew Benham>>> Hiya, if you still don't think it's the MTU setting what would i be looking for in the packet data obtained by wireshark?

Thanks in advance


Rodp
 
Is this between two devices both cabled to the router LAN ports, or is one wireless? If you change the IP address of your 3com router to something different on the LAN side and connect one of the LAN ports to your BT router you can use the remaining ports on either as LAN ports and/or drop a 5 port gigabit switch on there etc.

Unless there is some setting on the router for switch settings that interfere with traffic between ports like QoS, something to block port based on traffic it sees etc. then it should just forward packets from switch port to switch port based on the devices seen on that port. It may be worth checking the router logs at the time it drops connection, and see if anything happens to the link / activity lights for the port. Also in general removing, replacing cable in a port with short gap should reset a port back into life.
 
Hiya, No this was all wired. no wireless involved.. yes I've changed my 3com router to 192.168.1.20 and my bt voyager one is on 192.168.1.1 (using as gateway to internet) with a short cat5 cable going from the 3cpm to the bt voyager. I have all my network cables going into the 3com. I don't seem to have much in the way of logs for the bt voyager. Are there some hidden pages like there is in the 3com (dynamic dns)? I've checked Bridge QoS and IP QoS on the voyager but nothing is setup. On the voyager I have one IP filter which is set for inbound traffic for FTP set to my normal PC.

Protocol Source IP addr Dest IP addr Port Range
Start End
TCP ALL 192.168.1.2 20 22


I was having trouble with Samba / normal windows explorer communication too (until I changed to using the 3com) and so I don't expect this IP filter to be causing a problem, right? I could removed it or untick the allow as I'm not using it at the moment.

When using the voyager and i get a lost connection, I have unplugged the lan cable to the humax for some time but that doesn't work, nor rebooting the voyager router, the only think that seems to work (reestablish a connection) is to warm boot the humax. However I will have another go at doing those checks when trying to go back to using the BT voyager as I'd like to go back to just using one router.

Is there anything else that I could look at. Can anyone answer on the MTU setting query?

Thanks

Rodp
 
MTU shouldn't matter at all on the local network or indeed for most things on the internet. All that it means is the biggest packet size that can be sent out in one go. 1500 is the normal maximum but devices can choose to use bigger packets between them etc.

As I see it if you send a bigger packet between routers but it is bigger than they can send they just split it up into two, that makes it inefficient, e.g. if your MTU is set to 1500 and a router a little down the line can only handle 1400 then it would split the packet into 1400 and 100 or similar so slowing things down a little as there is additional overhead in each packet for the header and the inefficiency of having wasted theose other 1300 bytes from the second packet.

You can check the MTU setting needed between two devices, open a cmd prompt on windows, and do:

ping -f x.x.x.x -l 1500

You will get back something like:
"Packet needs to be fragmented but DF set"

I think it is -S in linux but haven't got a box booted up to check.

now lower then 1500 to 1450 and it will PING OK. Something like 1472 you will find is the highest number ...

Now there is 28 bytes of header information in the packets and the above is the amount of data we could send IN the packet so the MTU between those two devices via and routers on the way is 1472 + 28 = 1500.

Pick a random host on the internet to PING and you will probably get a lower MTU, mine comes back with 1464... and having looked, my router shows an MTU of 1492 (1464+28).

So.... between humax and device on the same network MTU shouldn't come into it, and the MTU settings on the router is only what it handles passing through to the outside world, between ports on the switch it should just forward packets regardless (including much bigger packets than 1500).

Between humax and the internet, e.g. to the portal though if you maximum packet size you can get through to their portal site is 1400 at some point along the way and the humax sends out 1500 byte packets then somewhere along the way they get split up and issues.

Steve
 
Should say 1492 MTU size on router is supposed to be most efficient but it all depends on what is between you and the host you talk to along the way. If you do a fragment test and find your MTU needs to be lower than 1492 on the internet side then lowering it to the 'right' value can increase speed / make more reliable transfers.
 
Hi Steve,

Thanks for the reply - I understand MTU now! :)

So it shouldn't make a difference internally but perhaps there is some obscure thing happening which is somehow associated with this setting. I will plug everything back to how it was and do some testing (and now doubt warm booting of the hummy). I'll write an update once I've done this.

Thanks

Rodp
 
dragon-it said:
You can check the MTU setting needed between two devices, open a cmd prompt on windows, and do:

ping -f x.x.x.x -l 1500

You will get back something like:
"Packet needs to be fragmented but DF set"

I think it is -S in linux but haven't got a box booted up to check.
Click to expand...

"man ping" on Linux states:

-s packetsize
Specifies the number of data bytes to be sent. The default is
56, which translates into 64 ICMP data bytes when combined with
the 8 bytes of ICMP header data.

-M hint
Select Path MTU Discovery strategy. hint may be either do (pro‐
hibit fragmentation, even local one), want (do PMTU discovery,
fragment locally when packet size is large), or dont (do not set
DF flag).

$ ping -M do -s 1600 -c 2 192.168.1.254
PING 192.168.1.254 (192.168.1.254) 1600(1628) bytes of data.
From 192.168.1.33 icmp_seq=1 Frag needed and DF set (mtu = 1500)
From 192.168.1.33 icmp_seq=1 Frag needed and DF set (mtu = 1500)

--- 192.168.1.254 ping statistics ---
0 packets transmitted, 0 received, +2 errors
 
rodp said:
Andrew Benham>>> Hiya, if you still don't think it's the MTU setting what would i be looking for in the packet data obtained by wireshark?
Click to expand...
Probably best to post the captured data and we can look at it for you. Your later posts seem to be pointing the finger at the Voyager router - presumably it doesn't firewall traffic between LAN hosts ?
 
Andrew Benham said:
"man ping" on Linux states: . . .
Click to expand...
The version of ping on the Humax allows -s but doesn't allow -M. The Windows version won't allow -M either, however it does allow -f which = set Don't Fragment flag in packet, which, when used displays a message like 'Packet needs to be fragmented but DF flag is set', this kicked in for me at packet size = 1465 e.g. ping hummy.tv -l 1465 -f
 
Hi All,

Got my new router today from plusnet and it's working fine so will stick with that.... case closed (and sticker added to my old router high lighting the problem!!). Thanks to all for your replies.
 
You must log in or register to reply here.
Back
Top