mmmh, i have a strange problem with getting guruterm to work *shrug*

- my setup is like this: all boxes on the LAN, including the c64, are connected to a switch. that switch goes into router/firewall thing, and that is connected to cable modem
- using cgterm from my pc works just fine, which means there shouldnt be a problem with ports not beeing open or whatever else could be messed up in the router/firewall

now, when i use guruterm on the c64, i get ip/gateway/netmask via dhcp alright. but neither DNS works, nor does connecting directly via IP. (getting timeout). when i enter the IP of one of the boxes on the LAN, i correctly get "connection refused".

it looks all ok to me, except it doesnt work =P anyone has an idea?

_________________
http://hitmen.eu

That's a classic default route issue. Either your gateway is wrong, or there's some problem with your router. Perhaps if you haven't set a MAC address on the rrnet it's using the default ff:ff... and the router doesn't like it?

Check the router logs. Also check if it has any MAC filtering enabled.

For the DNS, is your DNS server (as configured by DHCP) pointing to something on the local subnet? I have an issue with GuruTerm where DNS didn't work if it was pointing to a server on a different subnet (i.e. at my ISP). I had to have it pointing to my router.

that was it. i totally forgot about it, somehow i thought mac filtering would only affect wlan =P works fine now \o/

_________________
http://hitmen.eu

D-Link?

yes, cheapass di-254

_________________
http://hitmen.eu

Ah, and I thought it was the good old problem where GuruTerm is too impatient waiting for "slow" DNS servers.


Hmm.. I kind of forgot about this. Is this really the case or could it just be an effect of the impatiance? I have to check this out. Anyway, Beta2 will be far more patient

I must admit, I don't know enough about DNS to answer that.

If I point DNS to my router, doesn't my router then have to forward the DNS requests to a 'real' DNS server to get the result, and return that? I don't see how that would be faster than going directly to the real DNS server. Yet, setting my local router as the DNS server works fine, whereas pointing to the 'real' DNS server does not.


Is there a quick change in Beta 1 that could be made so it waits longer, just as a test?

Schema is correct

Point the DNS to your router and the router will passes it on to the DNS setup in the router.

Making it wait a little longer for the DNS reply can't hurt but its not needed if your router is setup with your isp or any other reliable DNS server correctly.

Have Fun Shane

_________________
Have Fun!!

Hmm.. that's strange. I don't have this problem for instance. My DNS server is on a completely different network. Must be related to how the DNS server replies. If anyone could send me a UDP packet dump from your network that would be great. Maybe we can solve this problem once and for all.


Actually I've already addressed this in the upcoming Beta 2. But a packet dump could tell me if that's really the issue or not, or perhaps we're looking at 2 different problems even.

I already posted a packet dump in the old bug thread.

Oops! I had completely forgot about that one.

The only difference I see between the two dumps is that GT doesn't set the checksum in the UDP header (which I believe is optional for UDP if memory serves), the TTL is different (large enough so that should be irrelevant), and that the query is in upper case...

So, for now, I draw the conclusion that the problem is related to:

1) Time factors

or

2) The fact that the gateway or DNS is unable to recognize (and thereby authorize) GuruTerm as a host. The reason for this is uncertain. It could be that GT fails to respond to some kind of request or acknowledgement in an earlier phase.

And if we tend to Mr. Occam, the correct answer would be the sooner