Spidey, Garion, come help. Broken file sending, could really use the help.

[skyking]

First off, the client is my brother. He has purchased a mobile x-ray business, and was using mid-90's equipment and protocols to send images over dialup.
I found some dicom compliant software, Digital Jacket, that will connect to his old scanner, and then send the images over the internet via a dicom send operation.
I have sent numerous test files to the remote dicom server from my location, and several others in Western Washington.
He is in Eastern Washington on Charter's cable network. He has a "business" account with a static IP.
He will send off exams, the software will indicate a successful send, but 2 out of 4 will get there intact, or sometimes none. It is always flaky, and random.
What I mean by intact is, they will be there at all. My understanding is that if a few packets get routed out into never land, the entire file is kaput, and does not show up on the server.
We tried this with the wrt54g wirelessly in his driveway, with a wired connection to the router, and then I had him pull the router out, hook up the computer to the modem directly,and manually configure the static IP. In that case, nothing went.
I can connect to his computer, a fresh win2k build, and look into his archives with my copy of the software. I can send from his archive, which involves pulling the file to my computer and sending in one operation, and that fails too.
There is little choice for ISP even for testing there. I had one network security friend tell me that it could very well be a layer 3 problem with the ISP's equipment. He mentioned trying an extended ping and traceroute, and see if there are cyclical trends in that ping. This would indicate to him that there was a parity or timing mismatch somewhere along the line. This is way over my head, fellas.
I mention the ISP at all because a local wireless ISP in that area had reported of flakiness in charter's network. I also went 0 for 3 downloading ISO's there.
To top it off, I have another client using the same software, with about 10 sucessful transactions from my area. That isn't much of a record, but it is 100%. I am heading there with different computers, routers, network cards, and the kitchen sink.

UPDATE:

I think it was operator error! The program has several transfer syntax options in a dropdown menu, and the operator was choosing one I had not tested, nor intended them to use. It turns out that the remote server would indeed accept the files, but the remote clients would not view them, nor detect the presence of the files on the server. The randomness of it has me worried though.

 

[Garion]

Phew, that's a tough one. Without more information, it's hard to do too much troubleshooting. I've never used any kind of Dicom software, so I can't be of any help there.

I think that your first step should be to make sure that you have your basic network connection working and solid. This means you should clean a bit of house on the local network - Make sure the cables are good, make sure you can transfer files properly (at a decent speed, say 30+Mb/s) across the local LAN, etc.

Once you've validated that your LAN is good, move to your Internet connection. Use a tool like Ping Plotter to try to get some metrics on the reliability of the path between you and one of the clients you're trying to send the images to. It's possible that you won't be able to ping the exact destination host, but do a standard traceroute (tracert -d (ip-address-of-destination) from the command prompt) and then run Ping Plotter to the last hop that returns something. If you're seeing a lot of packet loss on one of the hops, try to see if it's in your ISP's network or somewhere else. If it's in your ISP's network, try to get them involved and show them the output of Ping Plotter (It can save the screen as a graphic to be sent off to your ISP).

Once you're sure the Internet is clean, start to narrow it down to your application. Try to setup something to simulate the transfer in various places. Can you do it across your LAN? Can you do it to another machine on the same ISP?

If it still fails in all those scenarios, look at different applications, different versions, etc. If there's a problem with client X talking to server Y, but server Z can talk to client X fine, then look at that for a solution.

Lastly, the best thing to do is to try to create a end-to-end solution that you have FULLY tested and know works well and is compatible, assuming the network is good. Something you can support and can troubleshoot. I'm not sure if this is feasible, but try to pick one client app that you can distribute that you KNOW works. It looks like this protocol is a bit like FTP - There's a lot of clients and a lot of servers out there. If you can find a good pair that work well together, recommend it to your customers.

I wish I could provide more details, but without knowing how things work and a LOT more details there's not much more I can do. What I've outlined is a fairly methodical and typical troubleshooting scenario that will, hopefully, serve you well.

- G

 

[skyking]

Garion, that was what I was looking for. I had suggestions about extended ping test, but no recommendation of a tool. I will try ping plotter tomorrow morning when I get there. I do suspect the bridge device provided by charter: it is a cable modem/router, with the default gateway at .166 and the static IP at .165, with a subnet of 255.255.255.252.
I prefer a setup that lets me use the standard .1 gateway layout, myself. I guess I am just used to that.
I will test the protocol at other locations with other modems, both on charter's network and at another ISP's.