HTTP response missing

[rjt]

I have an application (currently working) which reads UDP packets and forwards them to another microprocessor (and sends the responses back). We decided to merge in the web server that lets you change parameters for the NetBurner (SB72 in this case) through an internal web site. I used an example web site and left only the IPMode, IP address, mask, gateway, dns server, dhcp name, and my own parameter. It all works except (you knew there was an except) if I change the mask, gateway, or dns server IP the server does not send the HTTP response (the redirect). The changes are made, but the browser displays an error.

I used Microsoft Network Monitor to grab the exchanges that worked and the ones that did not.

I'm using Rel23_rc7a.

Richard Threlkeld

[rjt]

I forgot to mention, the same problem happens in the example web server code.

[thomastaranowski]

Are you using the "ChangeFlashIPSettings" API or the "ChangeRuntimeIPSettings" to change the IP settings of the target? If changing dynamically with the ChangeRuntimeIPSettings, you'll have to defer the change for a little while after your post handler returns, otherwise the network stack will reconfigure under your, and your post response will probably not get out in time.

[rjt]

Here is the code. I just added the If statement for the two RedirectResponse calls. It used to just do the first one all the time. It made no difference. I was trying to determine if prefixing with the IP address was the problem.

I just used wireshark and got a slightly different reading. It shows that the redirect gets back. Then, when it works, the browser sends the request for the page as a GET. When it does not work, it sends a continuation? But the problem is the first two letters of the GET (i.e. the GE) get dropped. The rest is OK. But this is from my browser and it happens with IE8 and Firefox 3.x. ???

char buf[80];
ConfigRecord new_rec;
memcpy( &new_rec, &gConfigRec, sizeof( new_rec ) );
if (new_addr != gConfigRec.ip_Addr)
{
PBYTE ipb = ( PBYTE ) & new_addr;
siprintf( buf,
"http://%d.%d.%d.%d/index.htm",
( int ) ipb[0],
( int ) ipb[1],
( int ) ipb[2],
( int ) ipb[3] );
RedirectResponse( sock, buf );
}
else
{
RedirectResponse( sock, "index.htm");
}

close( sock );

OSTimeDly( TICKS_PER_SECOND * 2 ); /* Let Stuff clear in Network land */

/* Set up new address */
EthernetIP = new_addr;
EthernetIpMask = new_mask;
EthernetIpGate = new_gate;
EthernetDNS = new_dns;

new_rec.ip_Addr = new_addr;
new_rec.ip_Mask = new_mask;
new_rec.ip_GateWay = new_gate;
new_rec.ip_DNS_server = new_dns;
UpdateConfigRecord( &new_rec );

[thomastaranowski]

Hmm, I never close() the input socket descriptor in my post handlers. I assume the calling code will clean that up when it's complete. That may cause some issue.


Here's a sample post handler here.
int licensingPost(int sock, char *url, char *pData, char *rxBuffer) {
char tmp[40];
if(ExtractPostData("snmpLicense", pData, tmp, sizeof(tmp))!=-1) {
//Check hash
snmpRegisterLicense(tmp);
}

RedirectResponse( sock, pageNames[OPTIONS] );
return 1;
}

For what it's worth, I've also noticed broken behavior with several different windows firewalls, even when they are disabled. BitDefender, for example, had to be uninstalled for http access to the netburner to work. BT can be configured to work properly, but it doesn't do so out of the box. You could be running into a similar situation. It may be worthwhile to try your test from a different client workstation.

[rjt]

Thanks for your attention.

I already commented out the close and it did not fix the problem. In fact, I put a breakpoint on the close and waited a minute or so. The error happened after the redirect call while I waited.

As to the firewall, I am on a 1Gb network connection to a switch which is also connected to the netburner in one of our products. Only the Zonealarm on my laptop in between. To make sure though, I used IE8 on one of my Win 7 machines with no firewall software (also connected to the switch) and it got the same result.

Richard

[greengene]

Looks interesting.
Is this what is happening?
1) you pass over the new ip, mask, gateway, and dns server.
2) you redirect index.htm to the new ip
3) you wait 2 seconds
4) you update the stack with the new stuff

seems to me that the following is probably happening:
a) you send redirect to new ip to your client/browser
b) client says ok and sends request for index to the new ip
c) the netburner says, that's not me
d) the client/browser says nobody responded to that request
e) netburner changes its ip stuff in flash and continues to wait for
requests to its old ip address until it is rebooted

this together with thomastaranowski's directing you to the api should get
you going. look at section 7.3 of the nndk progr man should be of assistance.
you are affectively doing the ChangeFlashIPSettings() processing already.

[rjt]

I think I found it.

If you do the close on anything except an IP address change, it screws up the tcp layer which then sends an ACK to a non-existant packet which, in turn, confuses the client. I'm not clear about the lowest level details there, but if you remove the close ( sock ), then everything except the IP address changes work.

On the other hand, you have to close the socket when you change the IP address or the change does not happen. When I moved the close into the part of the IF statement, it worked for both cases.

I have not tried to change the mask yet, so I'll have to decide which leg it must fall into. But it appears to work just fine now.

Richard