Not all that easy to edit winsock.inc, since it un-tars as readonly, so had to chmod +w first. I didn't put it back to readonly - probably should have so it doesn't get modified accidentally...

Then, my "fakeapi" no longer works - apparently because "new NASMX" uses a different linker than "old NASMX". I solved it by "%define"ing the "true names" back to the "short names". Would have been easier if I'd done it that way in the first place! That finally got it to work (in Linux).

But this is merely a distraction from the project at hand - getting my IP from http://www.whatismyip.com . Going back to my "plain" version, if I deliberately butcher the "request", I get back "400 bad request". This indicates that my socket/connect/write/read are all working (doesn't it?). Yet if I write a "correct" (as nearly as I can determine) request, I get nothing at all back - the "read" just hangs...

Not all that easy to edit winsock.inc, since it un-tars as readonly, so had to chmod +w first. I didn't put it back to readonly - probably should have so it doesn't get modified accidentally...

Then, my "fakeapi" no longer works - apparently because "new NASMX" uses a different linker than "old NASMX". I solved it by "%define"ing the "true names" back to the "short names". Would have been easier if I'd done it that way in the first place! That finally got it to work (in Linux).

hmmm...GoLink has been in use for quite some time ( ie: even before my involvement ). This may be another issue altogether.

But this is merely a distraction from the project at hand - getting my IP from http://www.whatismyip.com . Going back to my "plain" version, if I deliberately butcher the "request", I get back "400 bad request". This indicates that my socket/connect/write/read are all working (doesn't it?).

Yes, at least as far as initial connection and request transmission.

Yet if I write a "correct" (as nearly as I can determine) request, I get nothing at all back - the "read" just hangs...

At the moment, I'm stumped!

Best,Frank

In the request header you are specifying:

db "Host: clax.inspiretomorrow.net" ,13 ,10

This returns 96.9.162.227 as the IP address when I ping it.However, you are specifying 75.126.1.55 for your connection which appears to be resolving to some host at softlayer.com.This appears to be a simple mismatch, thus the server is possibly dropping the request for the unknown host.

Ah ha! That's a good clue. In the "plain" version, I'm using www.whatismyip.com for the host, or sometimes automation.whatismyip.com - which appears to be the same IP, but "reversed" 72.233.89.198 vs 198.89.233.72. I may well be butchering the conversion of the "dotted quad" to a big-endian dword, as well.

I distinctly remember writting some code that converted something in the form "72.233.89.198" to a big-endian dword ("long" in Gas), but I can't find it. As I remember, I wasn't too happy with it anyway...

Lemme rework some of that from "square one" (or "square zero" in assembly :) ), and see if that provides any enlightenment...

It returns me in %eax: -22. So, it is clear that there is a problem.Before that, I would like to clear up some doubts that I have.In send() function, it returns me: 2736. The number of bytes sent if successful. So, it sent 2736 bytes... how I realised that the quantity bytes sent are correct?Then, according to recv(int s, void *buf, size_t len, int flags);I have to send the buffer pointer. My question is: how many bytes do I have to set to the buffer var? I set up 100 but because I had no idea what i had to write there.

P1ranha's tips were especially helpful! That "extra CRLF" at the end helped my version, too.

Making a request for just "/" rather than "/index.html" got rid of the 404!I made your buffer a little bigger, and re-arranged some of the parameters - at first, I didn't "get" that you were putting the file descriptor at (%esp) and leaving it there. Okay, but then you were putting remaining parameters at 8(%esp) and up - should have been at 4(%esp) and up (I think). Anyway, this "seems to work".

Mmmm... well, that doesn't get quite the whole page. There's quite a lot of it - almost 19k. What I've done in my Nasm version is to make the buffer bigger still, at which point I ran into a problem I know can occur with sockets: you don't always get the whole thing in one read. I'm using sys_read/sys_write instead of send/recv. So I put the read in a loop, until it returned zero. I think now I'm getting the whole "index.html" (although it apparently isn't named that). The "relevant portion", I think, goes like this:

I don't see how to parse my IP out of that mess, and they seem to be asking us not to do it. I guess that leaves us with their automation page. Can we just "GET" an .asp file? I don't even know what an .asp file is!

The request GET / HTTP/1.1 returns the default page of the site being visited. For most web sites this is the file index.html. Note that Windows servers ( and oddly configured Linux servers ) may expect default.htm or some other named file. Thus specifically requesting the file index.html from those servers may fail or will return a code to redirect the "browser" to the site's true home page.

That gets me a page telling me that the automation file has moved. Going where it says gets me the "rules" file (they don't want us to hit it more often than every five minutes). The actual n09230945.asp file is apparently at automation.whatismyip.com rather than www.whatismyip.com. I dunno...

I guess due to the fact that it could be possible that the bytes sent by a call to send() on oneend of a connection may not all be returned by a single call to recv() on the other end. I need to repeatedly receive bytes until I have received as many as we sent.

I think you've found the combination! I don't know how I missed that in all the things I've tried, but I did.

Your posted output ends at "Cache-control: private". Right after that is the text we're looking for: "my" IP. I don't think you need to read "as many as sent", but you need to read until "sys_recv" returns zero. At least, I read until "sys_read" returns zero. I haven't actually implemented it with "sys_recv" so it'll be a little bit different, but...

if %eax is negative, quit with an errorif %eax is positive subtract %eax from "bytes to read" if negative, quit - out of buffer space add %eax to buffer position read/recv moreif %eax is zero, all done - print it or whatever...

It may be a regular thing to read/recv once, up to "Cache-control: private", and the second read/recv is the "text we want"... or maybe that's coincidence? I haven't tested it much. Since they ask you to not hit it more often than every five minutes, I don't want to pound on it too much. Have a cup of that good Italian coffee between trials, or something. I think you've got it! Congratulations!

The Cache-Control reply header is used by both Proxy servers and your browser to determine the length of time that a page is valid. It helps reduce network congestion by having the Proxy maintain a local copy of the page which it can subsequently serve up to the specified length of time. It may also be used by a browser to reduce the number of server requests such that the browser does not have to resend the request for that particular resource again.FYI: If not evident by my prior posts, then yes, I've spent many years writing commercial http and https apps, mostly in C/C++ but assembly is so underground that it appeals to me! :)

Also, just a quick note: The User-Agent request header may be used by the server to determine the capabilities of the browser, and thus the returned response code and content based upon it may vary. For example, not specifying a Windows Internet Exporer or Mozilla compatible browser may not give you the identical results. This is something to consider when attempting various requests...Most developers I know capture the request/reply communications ( using WireShark or tcpdump for example ) and emulate the browser of choice...