Strange Shopping Cart Problem on InvadeIT

[doctormann]

Hi Guys

I'm experiencing a really odd problem when trying to buy stuff on the InvadeIT.co.th web site.

I can get onto the site OK and can browse the product pages but no way can I actually add anything to the shopping cart! If I try to add an item I just get a 'waiting for www.invadeit.co.th' message in the status bar and nothing further happens. The system doesn't hang - I can cancel the operation and go back but I can't get any further.

I've spoken to InvadeIT about this but they can't find anything wrong at their end. I've rebooted my router, to no avail. Turning the firewall off makes no difference either. I thought that I might possibly have a DNS problem but changing from 8.8.8.8 to open DNS or to the default ToT address makes no difference.

I'm getting the problem on both my desktop machine, running WIN7, and on my laptop, running Linux Mint 13. Using Chrome or Firefox browsers gives the same result. The common factor here has to be the router - or maybe ToT - but I can't figure out what the problem can be. Short of doing a factory reset and starting over I'm a bit stuck.

The router is an Asus DSL-N55U and I have a ToT ADSL 10/512 connection. Apart from this problem, everything seems to be working normally.

Any ideas?

Thanks,

DM

[Chicog]

Have you tried running either browser in safe mode, i.e. with no plugins/extensions running? (I'm assuming you have some). That would be my first check.

[doctormann]

Have you tried running either browser in safe mode, i.e. with no plugins/extensions running? (I'm assuming you have some). That would be my first check.

I can certainly try that on the WIN7 machine but I'm not hopeful. I'm getting the same issue on my Linux machine so the problem is not going to be a virus or malware. Not likely to be a browser extension problem either - I normally use Chrome and have a few extensions running on that but Firefox, which I don't normally use, is just 'bare bones' with no extensions at all.

I don't think that Linux has a 'safe mode'. It's very odd that the same thing happens on both OSs and on both browsers. I've had a good look at all the router settings but everything seems normal. It's always possible that the router has developed a fault but, if so, it's a very strange one. I may totally reset the router tomorrow once there is no-one else wanting to use the system.

DM

[Tywais]

I just placed an order from them last week with 3BB with no problems. Another option, if you have already tried a different DNS server, and is to check what proxy (cache/transparent) is being used. Can try another proxy other than TOT from the below list or even disable proxy for testing. Not sure if this list is up to date though.

A-Net : proxy.a-net.net.th port 8080
Asia Access : proxy.asiaaccess.net.th port 8080
Asia Infonet : proxy.asianet.co.th port 8080
CS Internet : proxy.cscoms.com port 8080
Data Linethai : proxy.linethai.co.th port 8080
IdeaNet : proxy.idn.co.th port 8080
InfoNews : proxy.infonews.co.th port 8080
Internet Thailand : proxy.inet.co.th port 8080
KSC : proxy.ksc.net.th port 8080 : 172.16.0.2 port 8080
Loxinfo : proxy.loxinfo.co.th port 8080
proxy.trueinternet.co.th port 8080

RoyNet : proxy.roynet.co.th port 8080
Samart : proxy.samart.co.th , proxy_server.samart.co.th port 8080
Siam IT Online : proxy.siamit.co.th port 8080
WorldNet : proxy.wnet.net.th port 8080
TOT : 203.113.0.31 port 8080

[transam]

Try using Opera for stuff...........

[rhodie]

Try using IE. Most developers test on IE. I find a lot of sites that don't work on Chrome or FF work fine on IE.

[doctormann]

Thanks for all the replies - gives me a few things to try.

I think that I've probably eliminated OS and browser possibilities. I've tried Chicog's suggestion of using safe mode - in WIN7 - but no joy there. I also booted my Linux machine off a live CD and this also made no difference.

I also tried connecting to my neighbour's wifi - still ToT but with a different router - and the problem didn't occur. Looks more and more likely that something is amiss with my router but I've no idea what.

I have used the InvadeIT site on several occasions before with no issues - same router, same computers. This seems to be a recent problem - haven't bought from InvadeIT for about six months though so maybe not that recent. As a matter of interest, I tried another, totally unconnected, site to see if I could buy something from there. I didn't do a thorough test - as I didn't actually want to buy anything - but the indications were that everything was normal. I could certainly put stuff in the cart, which I can't currently do with InvadeIT. This is weird!

DM

Edited June 15, 2014 by doctormann

[doctormann]

An interesting development - if I turn off QOS on the router the problem seems to go away. Response is very slow but so is my connection today.

So, maybe I have to play with the QOS settings - it would help if I actually knew what i was doing!

DM

[RichCor]

I remember reading about ASUS routers and IP fragments not possible when QOS was enabled...

Since you're using ADSL, I'll assume you have your router and devices using MTU: 1492

[doctormann]

I remember reading about ASUS routers and IP fragments not possible when QOS was enabled...

Since you're using ADSL, I'll assume you have your router and devices using MTU: 1492

Yes, MTU is set to 1492, which is the default. I've never tried changing it. There are 101 different things that can be tweaked but the trick is spotting the right one. I haven't really got a clue - everything worked until recently so there was no need to change anything. Most settings were left at their default values - the main thing that I did do was to set up reserved LAN IP addresses for my various devices. The Asus router is very good for this - nice and user-friendly.

I'm having vague thoughts now about the changes that have been made by many sites to combat the 'heartbleed' virus. Presumably, site security will have been changed and I wonder if that could be my problem? I'm stumbling around in the dark really - I'm OK with straightforward IT stuff but this is all a bit beyond me.

DM

[RichCor]

Well, you've found that the QOS switch is involved in the issue. There's no problem leaving that OFF.

QOS reserves resources for apps that request it, at the cost delaying packet transport for apps that don't request it. Leaving it off allows all packets to be treated the same and utilize the full resources of the connection.

Though the curious question is, why is this happening now; why is this happening at all?

What does a Java / Javascript / Cookie (or whatever InvadeIT utilizes in their cart) have to do with a QOS setting?

[doctormann]

Well, you've found that the QOS switch is involved in the issue. There's no problem leaving that OFF.

QOS reserves resources for apps that request it, at the cost delaying packet transport for apps that don't request it. Leaving it off allows all packets to be treated the same and utilize the full resources of the connection.

Though the curious question is, why is this happening now; why is this happening at all?

What does a Java / Javascript / Cookie (or whatever InvadeIT utilizes in their cart) have to do with a QOS setting?

A good question and I've no idea of the answer. It all seems a bit tenuous really. I'll have to do some more testing. Connection speed is atrocious today so getting anything done is a challenge. I don't think that this is connected with the problem though as it's been a few days since I noticed it. I was hoping that it was a temporary glitch that would go away - but it hasn't.

The behaviour is really odd - it's almost as though the connection to InvadeIT is being blocked but it can't be that as I can connect to the site OK, it's only when I try to do some shopping that everything comes to a stop. I'm still wondering if it's some sort of a security problem - maybe the security level changes once you try to put stuff in the cart? That sort of makes sense I suppose - I'll try to check.

DM

[RichCor]

Can you verify that

• not logged into shopping site
• selecting the button "ADD TO SHOPPING CART" fails (how does it fail?)
• adding item does not change page to /basket/
• occurs on two machines, WinOS and LinuxOS, in any/all browsers
• no proxy service used -- no extensions (ie: adblockers, script blockers, etc...)
• changing router DNS to 8.8.8.8, dyndns, or TOT 203.113.24.199/203.113.127.199 or 203.113.5.130/203.113.7.130 ...has no effect
• QOS is enabled in router firmware on home router
• ... no other shopping carts seem affected (ie: Lazada, 7-catalog,
  
• Does not occur...
• when logged into neighbors network with previously affected device
• when QOS is disabled in firmware on home home router

The site has one connection to the

main site,
assets.zendesk.com,
static-ak.facebook.com, and
s-static.ak.facebook.com.

Most shopping sites 'should' switch to https before logging-in or when requesting/exchanging sensitive data.

The site does not use https: as they don't ask for sensitive/critical user data when placing the web order -- so you don't need to look at that at all.

If the issue isn't your adsl connection, you might try installing HOLA! Proxy on your browser and setting it to run through Singapore or Malaysia.

It's not unheard of that a home router gets flaky after updating a page and requires a full reset before working correctly again. If the above checklist stands true, it really looks to be either a router or some infrastructure creating a very weird issue.

[doctormann]

Can you verify that

• not logged into shopping site
• selecting the button "ADD TO SHOPPING CART" fails (how does it fail?)
• adding item does not change page to /basket/
• occurs on two machines, WinOS and LinuxOS, in any/all browsers
• no proxy service used -- no extensions (ie: adblockers, script blockers, etc...)
• changing router DNS to 8.8.8.8, dyndns, or TOT 203.113.24.199/203.113.127.199 or 203.113.5.130/203.113.7.130 ...has no effect
• QOS is enabled in router firmware on home router
• ... no other shopping carts seem affected (ie: Lazada, 7-catalog,

• Does not occur...
• when logged into neighbors network with previously affected device
• when QOS is disabled in firmware on home home router

The site has one connection to the

main site,

assets.zendesk.com,

static-ak.facebook.com, and

s-static.ak.facebook.com.

Most shopping sites 'should' switch to https before logging-in or when requesting/exchanging sensitive data.

The site does not use https: as they don't ask for sensitive/critical user data when placing the web order -- so you don't need to look at that at all.

If the issue isn't your adsl connection, you might try installing HOLA! Proxy on your browser and setting it to run through Singapore or Malaysia.

It's not unheard of that a home router gets flaky after updating a page and requires a full reset before working correctly again. If the above checklist stands true, it really looks to be either a router or some infrastructure creating a very weird issue.

Hi.

I'll try to take your points in order:

1. Problem occurs whether or not logged in to site - no difference.

2. Selecting the 'add to cart' button results in a 'uploaded 100%' display in the status bar and sometimes 'waiting for www.invadeit,co,th'. This eventually times out. System does not hang - can revert to previous page OK.

3. Trying to add an item does not change page to 'basket'. Can open the basket but it remains empty.

4. Occurs on WIN7 and Linux machines and also on my Android phone. Tried on Chrome and Firefox - no difference.

5. Turning off adblock+ on Chrome makes no difference. No extensions running on Firefox. Using Hola - various servers - makes no difference.

6. Changing DNS makes no difference.

7. QOS is normally enabled on Asus router.

8. No problem with Lazada, however I seem to get the problem with 7-catalog. Status message says 'uploading 27%' and then sticks there. Eventually times out.

9. Problem does not occur when using neighbour's wifi - also ToT ADSL connection but different brand router -DLink.

10. QOS may have been a red herring - now NOT working with QOS disabled.

I don't understand your next papagraph, viz.

The site has one connection to the

main site,

assets.zendesk.com,

static-ak.facebook.com, and

s-static.ak.facebook.com.

I may just try to reset the router to the factory default and then start over. Not too much hassle to do this but I'm not hopeful that this will solve anything. I hope that I'm not going to have to put the router in the bin!

DM

[doctormann]

This gets weirder by the minute! I've just tried accessing InvadeIT using Internet Explorer - which I normally never use - and the site works perfectly!

I don't understand why the problem affects Chrome and Firefox but not IE. Never mind - the problem is not resolved but at least I've been able to place my order now.

Thanks for all the help and suggestions. By all means, continue to carry on with this if you have the time and inclination as anything that we find out might be helpful to others.

DM

[RichCor]

So, from what you described it's an issue where JavaScript is sending small amounts of data back to the main site and waiting for an acknowledgment and other data to be returned... and it's getting stuck.

<button onclick="__doPostBack('ctl00$ContentPlaceHolder_Main$Button_Basket','')" id="ctl00_ContentPlaceHolder_Main_Button_Basket" class="btn action add_basket">

Add to shopping cart <span></span>

</button>

Why is it getting stuck?

Could be unreliable router packet filter, adsl circuit, DNS resolver, gateway... something to do with small packet transactions.

I wonder if IE working was just a timing fluke, or if it packages the small packet transaction differently? Try it again, does IE work consistently?

And... why this site (well, and 7-catalog). ThaiVisa does similar small transactions when you click "Mark this forum as read". When I encounter this type of issue I usually envoke a proxy server (using HOLA! proxy settings) and if the cause is external to my system that sidesteps it nicely.

If using a proxy service like zenmate or Hola! doesn't resolve the issue for you then I'll suggest looking at your router or adsl circuit for the issue.

[sammycic]

I am having virtually the same problem but with thai airways online booking site when it tries to go to the actual page where you can make a booking. Both IE and Chrome not working. I tried using my tablet on wifi and would not connect. I switched to 3g and connected no problems. From reading above does seem to indicate router problem. I have a D-Link dir 655. Any thoughts welcome as it is driving me nuts.

[doctormann]

Quick update.

Using IE 11 on my WIN7 machine seems to work consistently. I installed Opera on my Linux machine - no joy with that either.

Something else that might be connected - I can no longer stream BBC iPlayer Radio using Chrome, Firefox or Opera although it works OK using IE. This is a recent problem - previously I could stream radio with no issues and could even stream BBC TV using Hola! as a proxy. Now I can't stream TV either - eventually just get a 'content unavailable' message. Maybe Microsoft is trying to take over the World - again!

DM

[RichCor]

@DM, Have you completely reset your router yet (the type of reset where you are required to re-enter the ISP account into)?

[doctormann]

@DM, Have you completely reset your router yet (the type of reset where you are required to re-enter the ISP account into)?

Not yet - this is probably the only thing left to try.

Power cycling the router has no effect on the problem and neither does reloading the configuration from disk. I may well try a factory reset tomorrow - need to find a quiet window with no-one on the intranet. There have been a couple of firmware upgrades since I bought the device so I suppose another option is to revert to an earlier version. Might be a danger of bricking the thing if I try this though!

DM

[doctormann]

Further update: did a factory reset on the router this morning but this had no effect on the problem.

DM

[sammycic]

My problem was DNS not the same on PC and router.Still cannot access thai airways booking.

[doctormann]

My problem was DNS not the same on PC and router.Still cannot access thai airways booking.

I set my DNS on the router only. Each machine on the intranet gets its DNS by pointing at 192.168.1.1, in my case, which is the router default gateway. DNS on the router is then set, in my case, to 8.8.8.8 with 208.67.222.222 as the secondary address. This seems the best way to do things from a network management point of view.

As far as the problem is concerned, I don't think that it is a DNS problem as I have changed the DNS addresses to alternatives and it has made no difference whatsoever.

I'll maybe have a go at doing a dummy Thai Airways booking to see if it works for me. Watch this space.

DM

[IMHO]

The only thing I can spot that hasn't yet been mentioned is that the invadeIT website has a *huge* amount of data it needs to POST to the product page, before it updates the cart and redirects you to /basket... (typical ASP.Net ViewState junk)

Perhaps your router is truncating that in some way?

[doctormann]

OK, sammycic, just tried to do a dummy booking with Thai and it went OK.

Using Chrome, I followed the procedure to the point where they actually wanted paying - aborted it at that point. There didn't seem to be any issues so I guess that your problem and mine are not related - or at least not in any obvious way.

DM

[doctormann]

The only thing I can spot that hasn't yet been mentioned is that the invadeIT website has a *huge* amount of data it needs to POST to the product page, before it updates the cart and redirects you to /basket... (typical ASP.Net ViewState junk)

Perhaps your router is truncating that in some way?

Well, I suppose that anything is possible. No problem if using IE on WIN7 though - just no joy with Chrome or Firefox on either WIN7 or Linux.

DM

[IMHO]

The only thing I can spot that hasn't yet been mentioned is that the invadeIT website has a *huge* amount of data it needs to POST to the product page, before it updates the cart and redirects you to /basket... (typical ASP.Net ViewState junk)

Perhaps your router is truncating that in some way?

Well, I suppose that anything is possible. No problem if using IE on WIN7 though - just no joy with Chrome or Firefox on either WIN7 or Linux.

DM

I'm still putting my money on it...

http://weblogs.asp.net/lduveau/viewstate-chunking-in-asp-net-2-0-maxpagestatefieldlength

[doctormann]

The only thing I can spot that hasn't yet been mentioned is that the invadeIT website has a *huge* amount of data it needs to POST to the product page, before it updates the cart and redirects you to /basket... (typical ASP.Net ViewState junk)

Perhaps your router is truncating that in some way?

Well, I suppose that anything is possible. No problem if using IE on WIN7 though - just no joy with Chrome or Firefox on either WIN7 or Linux.

DM

I'm still putting my money on it...

http://weblogs.asp.net/lduveau/viewstate-chunking-in-asp-net-2-0-maxpagestatefieldlength

Well, that's well over my head! Are you suggesting that this is something that the web site operator needs to look at or is it something that I can do from my end?

DM

[sammycic]

It's got me stuffed what it is. Anyway Scoot was a lot cheaper. Cheers

[RichCor]

I think we can probably say this is a connection issue to ASP servers. (Both InvadeIt and Catalog-7 run ASP)

It may be that packet data is being dropped, possibly from oversized packets that are then truncated.

@DM, I'd like to you try two separate experiments:

Set your router MTU to 1100. reboot and test.

Set your router and PC to matching MTU: 1492 (or smaller; 1400)

Your streaming issue may related. Probably. Possibly.