Weird Issues with 3.2.2

[Ron]

Looking into problem 1, problem 2 I have never seen.

[Ron]

Logging is possible, get Marks logger plugin from the download section.

I've found the bug number 1, its a Base64 encoder issue, I'm working on it.

[Ron]

Maybe you could use a tcpip sniffer

[Ron]

Issue 1 has been solved in Girder 3.2.3 pre 1, available on the download page.

[Ron]

No, I'm not using UDP or port 137, this is a port that windows uses for remote administration if i'm not mistaking. There is something weird in your system i guess.

[Ron]

Remove all plugins except for the ones that came with Girder. I am 100% sure that they do NOT use port 137 ( unless you specified that in the internet server/client)

Girder does not attempt any TCP/IP connections on its own. You have my word on this. ( and anyone can check that ) Maybe one of the .dlls got infected with an virus. The main executable will warn if it is infected.

The only plugin that uses UDP is the SNTP plugin.

[Ron]

Have you found the culprit ? Would the source to the internet event client help you out ?

[Ron]

I'm 100% sure it is not the IEC, but you welcome to check the code. The client opens 1 port and that is the one that you specified. I guess that windows is messing around because 137 is one of the ports that windows uses to do its Filesharing (SMB). I'm sending you an email.

[Ron]

It would be really great if you did that and sent me the code back :-)

[Ben S]

I'm having some weird issues with Girder 3.2.2, the internet client plugin, and my PocketPC.

Issue number 1)
The payload data appears to get "clipped" by 1 character upon saving, particularly when the payload is a variable name. (Payload = "CurTime=[treg12]" becomes "CurTime=[treg12". It only seems to clip it the first time. It's like it's looking for []'s, and getting rid of the last one!

Issue number 2)
For some reason, the internet client can't connect to certain local addresses. I can telnet to the "broken" addresses, but cannot connect by InternetEvent client. I have my program pop up a message box on a client connect, before I try to get anything from the socket. I don't see it even -connect- on some IP addresses. Is there any way to get some logging information out of the internet event client? Successful connections, problems, timeouts, something?

Thanks folks!

[Ben S]

Hi Ron,
Another way to replicate #1 is to copy and paste a command using the InternetEvent client. It will almost always chop a character off.

It doesn't appear to be related to the []'s, it's done it on pure text, as well.

In regards to #2, is there any way I could enable logging of Girder and what it's doing? That would be great!

Thanks Ron!
-Ben

[Ben S]

Unfortunately I can only log incoming events. If I could log the results of an InternetEvent client (outgoing) command, I'd be all set.

Thanks for your help, Ron.

[Ben S]

Great Ron, works like a champ!

On #2, I am running my packet sniffer, and have discovered something. Are you doing anything regarding a UDP packet (vs. IP?).

Here's my test case. Girder's Internet event client always sends a UDP packet on port 137 before trying to connect to the port I've specified. I believe port 137 is involved with windows networking. Both of my windows machines (running Girder and the Win32 version of NetRemote) work great. The Pocket PC running NetRemote doesn't work, because Windows Networking is not running on the device.

Girder's InternetEvent client is waiting for an ACK on this port before it connects to the -real- port I've asked it to.

Is this something that you mean to do? Or something weird in a library you're using?

Thanks,
-Ben

[Ben S]

Can you (or someone else because I know Ron's busy) check this out, as well. Both of my machines definately send out a request on 137, but only from Girder. If I telnet, it does not do it. And Girder is definately -not- talking to my Pocket PC because it's waiting for an ACK on 137.

[Ben S]

Hi Ron,

No, I have not found the culprit. I am asking users on avsforum to take a look via their packet sniffer, Girder, and NetRemote and report back.

The source might help, if I had the source I could theoretically step through the code even if I don't have the source for Girder itself, right?

Stepping through might help me see where (on my computer) the 137 is coming from.

The reason I'm thinking that it might be something in the IEC is that I use WinSock in Girder to connect in a similar way, and don't see the weird connection. So you're either right, and the dll I have is corrupted/virused, or something is happening in the IEC.

I'd be happy to take a look.

I'll report back on what people on avsforum say.

Thanks Ron,
-Ben

[Ben S]

Hi Ron,

Thanks for your code. The only (major) difference between my client and yours is that for an IP address you call "gethostbyaddr".

I put the following code into my client.

MessageBox(NULL,TEXT("Trying gethostbyaddr"),NULL,MB_OK);
LPHOSTENT h = gethostbyaddr((const char *)(&addr), sizeof(struct in_addr), AF_INET);
MessageBox(NULL,TEXT("Did that try port 137"),NULL,MB_OK);

And sure enough, I get a messagebox, a (tried) connection on port 137, and then another messagebox.

Can we do this with the code instead?

hostentry,sock_addr_in,addr
addr = inet_addr(server)
if (!addr){
get hostentry
set server ip
}else{
set server ip
}

thus circumventing the gethostbyaddr call if it's an IP address? This would fix it, I'm sure, and then I'd have bidirectional communication through girder with my PocketPC