![]() |
Home
| Calendar
| Mail Lists
| List Archives
| Desktop SIG
| Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings Linux Cafe | Meeting Notes | Linux Links | Bling | About BLU |
unfortunately, i can't change the location of the server. it was moved behind the firewall for security purposes (obviously). it would take an act of congress to move back out again. prior to being behind the firewall, scp worked well (no complaints anyway). the firewall is setup to only allow one host inside our network to access this server and still allow connections from the 'net. so, i'm limited in what configuration changes i can make. 'googling, i found several references to mtu settings. testing this morning shows that small files (less than 10k) transfer very quickly. as the file size goes up (last test 50k), the transfer completes quickly, but closing the connection takes longer as the file size increases. the network guy collected debugs on traffic between the two servers, we could see the traffic moving along nicely until about 144k into the file (500k), scp reports stalled, and no further packets are seen in the debugs. after some amount of time (always more than 30 seconds, sometimes 3 minutes), the transfer resumes. we can see the traffic startup again in the debug. but, there aren't any requests to resume in the debugs. i'll keep y'all posted on the outcome. thanks. On 5/5/07, Kristian Hermansen <kristian.hermansen at gmail.com> wrote: > > On 5/5/07, John Boland <jj.boland at gmail.com> wrote: > > the firewall rules are setup to allow ftp. ftp-data, and ssh through and > > nothing else. that's why i was asking about another port for return > > communication. > > I would remove that firewall as a variable and re-test. Or, also use > another host -- one that is not being firewalled. Then report your > results... > -- > Kristian Hermansen > -- If it ain't broke, you're not trying hard enough! -- This message has been scanned for viruses and dangerous content by MailScanner, and is believed to be clean.
![]() |
|
BLU is a member of BostonUserGroups | |
We also thank MIT for the use of their facilities. |