Dropbox Uploads using CellC

[Viva]

And that's what we have in common. I'm also in Stellenbosch.

I asked the technician if this could be a tower related problem, but he was doubtful.

I think Cell C should get a tech team to Stellenbosch to conduct some tests.

To update:

- The issue is not with my specific modem, as uploads also fail with a different modem or my phone.
- The issue is not with my PC/OS, as uploads also fail on Linux or when using a phone (Dropbox app).
- The issue is not with my specific sim, as other people in Stellenbosch have reported the same issue.
- The issue does not occur in locations I tested outside of Stellenbosch. In Durbanville, for instance, uploads works perfectly.

Can Cell C please get technicians to come test this themselves?

Cell Tower ID's that I can confirm have this issue: 177C (6012) and AC32 (44082).

 

[Polymathic]

I can't even upload a file that's 500kb from my cellphone

 

[Viva]

I can't even upload a file that's 500kb from my cellphone

I even had issues with a 24kb Word document earlier today.

Where are you located? If you can, please also post your tower ID.

 

[sajunky]

- The issue is not with my specific modem, as uploads also fail with a different modem or my phone.

Expected, also it won't depend on tower ID. But it can depend on the assigned IP range or dialing option.

Does it depend on assigned IP range or always? Make note of assigned IP address every time you connect. Check your firewall settings. Does it the same on modem dialup connection when connecting modem directly to PC and using RAS (not NDIS or HiLink)?

 

[Tonberry]

I finally got around to doing some packet captures. In this case I used a USB dongle and was assigned an IP in the 197 range. The same IP address was seen as the source IP by the server I used for testing so there was no NATing taking place. I uploaded 4MB of random ASCII to the server. I used wireshark/tcpdump to capture the packets being transmitted to the server. I also compared the uploaded file to the original.

The uploaded file usually had somewhere between 5 and 10 errors in it. The error was always the 3rd bit being set from 1 to 0. For instance 01101101 (m) was received as 01101001 (i).

The TCP checksum of the received packet was always correct meaning it had to be recalculated somewhere after the packet was corrupted. In all non corrupted packets the TCP checksum matched with the transmitted checksum.

This disproves my original theory of there being a bad NAT router since there was no evidence of NATing. There is however still something that is recalculating TCP checksums of corrupted packets. This is unusual since without a NAT there is no reason to change the contents of the TCP/IP part of the packet at all.

I think Dropbox, gmail, scp etc all fail because the encryption used adds another layer of message authentication that will detect the corruption even if TCP cannot.

 

[Viva]

Thanks Tonberry for your efforts!

I don't quite understand everything you did, but it makes enough sense. I am hoping Cell C will try to get to the bottom of this.

If anybody else experience the same issue and can conduct some tests, please post some of your details like your location and assigned IP address range.

 

[Cell_C]

I finally got around to doing some packet captures. In this case I used a USB dongle and was assigned an IP in the 197 range. The same IP address was seen as the source IP by the server I used for testing so there was no NATing taking place. I uploaded 4MB of random ASCII to the server. I used wireshark/tcpdump to capture the packets being transmitted to the server. I also compared the uploaded file to the original.

The uploaded file usually had somewhere between 5 and 10 errors in it. The error was always the 3rd bit being set from 1 to 0. For instance 01101101 (m) was received as 01101001 (i).

The TCP checksum of the received packet was always correct meaning it had to be recalculated somewhere after the packet was corrupted. In all non corrupted packets the TCP checksum matched with the transmitted checksum.

This disproves my original theory of there being a bad NAT router since there was no evidence of NATing. There is however still something that is recalculating TCP checksums of corrupted packets. This is unusual since without a NAT there is no reason to change the contents of the TCP/IP part of the packet at all.

I think Dropbox, gmail, scp etc all fail because the encryption used adds another layer of message authentication that will detect the corruption even if TCP cannot.

Thanks Tonberry. This has been escalated to our technical team. *DM*

 

[sajunky]

This disproves my original theory of there being a bad NAT router since there was no evidence of NATing. There is however still something that is recalculating TCP checksums of corrupted packets. This is unusual since without a NAT there is no reason to change the contents of the TCP/IP part of the packet at all.

I think Dropbox, gmail, scp etc all fail because the encryption used adds another layer of message authentication that will detect the corruption even if TCP cannot.

You are right to your assessments. Good job, Cell C should award such users.
Re: NATting, I think it it still in place combined with gateway router which allows sharing the same IP amoung many users. It is why IP headers are modified. Poor job. Wait..., Error on the same bit - router has faulty RAM!

And Yes, Dropbox, etc... detect errors on application layer and requests retransmition of corrupted packets. Not sure whether these requests are directed to TCP layer (this is not going to work anyway, as reception of TCP packet had been already confirmed) or application layer. Here is another problem for investigation, as these requests do not reach the sender.

 

[Viva]

Just to update:

I can still see no improvement.

Can the Cell-C representative please keep us updated about the progress of the technical team?

I have to make a choice with regards to my internet connectivity for next year (currently Cell C) and my phone's operator (currently MTN). If this issue can't be resolved, it will probably not be worth my while to stick around.

 

[wjkotze]

To update:

- The issue is not with my specific modem, as uploads also fail with a different modem or my phone.
- The issue is not with my PC/OS, as uploads also fail on Linux or when using a phone (Dropbox app).
- The issue is not with my specific sim, as other people in Stellenbosch have reported the same issue.
- The issue does not occur in locations I tested outside of Stellenbosch. In Durbanville, for instance, uploads works perfectly.

Can Cell C please get technicians to come test this themselves?

Cell Tower ID's that I can confirm have this issue: 177C (6012) and AC32 (44082).

Having the same problem in Central Stellenbosch with Dropbox and email attachments larger than 200kb. My son which lives just outside Stellenbosch ( next to Jamestown ) have the same problem.

 

[Cell_C]

Cell* C does not throttle uploads to any cloud servers or companies. Uploads are generally slower than downloads which might be the case depending on the area. The type of file being uploaded might be the issue.. *DM*

 

[Viva]

Cell* C does not throttle uploads to any cloud servers or companies. Uploads are generally slower than downloads which might be the case depending on the area. The type of file being uploaded might be the issue.. *DM*

Nobody said anything about throttling.

There is an issue with your network as Tonberry has pointed out. Please don't dismiss this as user ignorance or uploads generally being slower than downloads. If this is your reply, you're not understanding that there is a very real issue with Cell C's network. Tonberry has already pointed you in the right direction:

I finally got around to doing some packet captures. In this case I used a USB dongle and was assigned an IP in the 197 range. The same IP address was seen as the source IP by the server I used for testing so there was no NATing taking place. I uploaded 4MB of random ASCII to the server. I used wireshark/tcpdump to capture the packets being transmitted to the server. I also compared the uploaded file to the original.

The uploaded file usually had somewhere between 5 and 10 errors in it. The error was always the 3rd bit being set from 1 to 0. For instance 01101101 (m) was received as 01101001 (i).

The TCP checksum of the received packet was always correct meaning it had to be recalculated somewhere after the packet was corrupted. In all non corrupted packets the TCP checksum matched with the transmitted checksum.

This disproves my original theory of there being a bad NAT router since there was no evidence of NATing. There is however still something that is recalculating TCP checksums of corrupted packets. This is unusual since without a NAT there is no reason to change the contents of the TCP/IP part of the packet at all.

I think Dropbox, gmail, scp etc all fail because the encryption used adds another layer of message authentication that will detect the corruption even if TCP cannot.

 

[Viva]

Just an update: The issue is still ongoing. I've not heard anything from Cell C for weeks now - it looks like they're not interested in providing customer support. This is really disappointing. I was planning to get another Giga200 sim (in February), as well as move my primary smartphone's sim to Cell C (next month). Now I have no idea where to take my business.

 

[Mars04]

Here also still same problem. Cell C uploads wont work. Even little files doesnt work. I also live in the center of Stellenbosch... This problem is already there since I started with Cell C at beginning of the month. Helpdesk says I must contact them, while i know it isnt an usb modem problem, since i used this same modem last year a whole year with 8ta and then uploads did work. So it must be a problem at Cell C themself.

Hope this problem gets fixed soon, cause now you cant even send a normal email with little attachment.

 

[Viva]

Here also still same problem. Cell C uploads wont work. Even little files doesnt work. I also live in the center of Stellenbosch... This problem is already there since I started with Cell C at beginning of the month. Helpdesk says I must contact them, while i know it isnt an usb modem problem, since i used this same modem last year a whole year with 8ta and then uploads did work. So it must be a problem at Cell C themself.

Hope this problem gets fixed soon, cause now you cant even send a normal email with little attachment.

It is most definitely not our hardware. I've had this problem on Cell C with two different modems and my phone. I've seen the issue disappear when driving to a different location, like Durbanville/Belville.

I've send a few PM's to Cell_C, but it seems he doesn't want to respond to me. Maybe you will have better luck? Let him know you're having the same issue. Contact him via his profile.

 

[Viva]

Just an update: I've been informed that Cell C will have technicians investigate the issue in Stellenbosch. I'll report back when progress has been made.