Very informative! I'll investigate some more.
Local port randomization could be done by TOD clock, set upon reset by IDE64 or from an ntp server... It should be random enough anyway, unless autostarted in emulator.

However, I've also seen a connection attempt where the server was repeatingly sending (syn?) packets which geolink never understood.

Third thing I've noticed is that geolink doesn't understand default gateway, it asks for the mac of the irc server on the lan. Putting a fake arp entry for the irc server passes the traffic on. I also have to put a static arp entry for my c64, as geolink seems to be busy with something else than answering arp requests during connect. This could sure be the root of all evil.

_________________
Tools: IDE64 3.2 with USB and RRNET. Toys: 1541u

Ah!
It's not asking for the MAC address of the IRC server, it's asking you to specify the MAC address that your RR-NET will use. Setting it to the MAC address of something else on your LAN will definitely cause all sorts of problems, and may well be the cause of your RSTs

Try using this 00:80:10:64:64:64

There is a feature request on ShadowM's todo list to choose a random MAC address for you.

This is one of the pains of the RR-NET & equivalent - it doesn't have an EPROM on which to store a globally unique MAC address. It's up to each app to set the MAC address during initialisation of the RR-NET, If you hardcode the MAC address into your prog, then you will get problems if ever 2 versions of your program are running on the same LAN.

That one already solved, but it sure asked for the MAC of the irc-server too, but that one seemed to be solved by a slight adjustment of netmask. (That shouldn't have been a problem, but it was)

My rr-net is using 49:44:45:36:34:00 which is IDE64\0 (default of IDE64)

In my opinion RR, IDE64 or whatever "host interface" should store the MAC to the rr-net.

Now I have some ideas about tcp sequence numbers or something....

Tcpdump on my LAN interface:

16:15:10.591108 IP (tos 0x0, ttl 64, id 13330, offset 0, flags [DF], proto TCP (6), length 40)
130.243.7.114.46416 > 130.240.22.202.6667: Flags [S], cksum 0xfa15 (correct), seq 2991652864, win 4096, length 0

16:15:10.615468 IP (tos 0x0, ttl 53, id 32415, offset 0, flags [DF], proto TCP (6), length 44)
130.240.22.202.6667 > 130.243.7.114.46416: Flags [S.], cksum 0x629e (correct), seq 3544620131, ack 2991652865, win 8192, options [mss 1460], length 0

16:15:10.623873 IP (tos 0x0, ttl 64, id 13330, offset 0, flags [DF], proto TCP (6), length 40)
130.243.7.114.46416 > 130.240.22.202.6667: Flags [.], cksum 0x3cae (correct), seq 1303314432, ack 1, win 4096, length 0

16:15:10.647982 IP (tos 0x0, ttl 53, id 32420, offset 0, flags [DF], proto TCP (6), length 40)
130.240.22.202.6667 > 130.243.7.114.46416: Flags [R], cksum 0x4cba (correct), seq 3544620132, win 0, length 0

...and geolink has totally locked up. Even "mouse" (joystick) is stuck.

One more try, with tcpdump on my WAN interface instead.


16:26:24.507328 IP (tos 0x0, ttl 63, id 13330, offset 0, flags [DF], proto TCP (6), length 44)
217.142.134.19.59503 > 130.240.22.202.6667: Flags [S], cksum 0xa4e2 (correct), seq 3882614784, win 4096, options [mss 1460], length 0

16:26:24.531612 IP (tos 0x0, ttl 54, id 61270, offset 0, flags [DF], proto TCP (6), length 44)
130.240.22.202.6667 > 217.142.134.19.59503: Flags [S.], cksum 0x3050 (correct), seq 337203304, ack 3882614785, win 8192, options [mss 1460], length 0

16:26:24.539710 IP (tos 0x0, ttl 63, id 13330, offset 0, flags [DF], proto TCP (6), length 40)
217.142.134.19.59503 > 130.240.22.202.6667: Flags [.], cksum 0x3f7b (correct), seq 412352512, ack 1, win 4096, length 0

16:26:24.563154 IP (tos 0x0, ttl 54, id 61276, offset 0, flags [DF], proto TCP (6), length 40)
130.240.22.202.6667 > 217.142.134.19.59503: Flags [R], cksum 0x4f87 (correct), seq 337203305, win 0, length 0

...and geos/geolink totally stuck again.

_________________
Tools: IDE64 3.2 with USB and RRNET. Toys: 1541u

Now I have connection with irc.swipnet.se
Something seems a little picky about the server... or some servers are picky about geolink.

_________________
Tools: IDE64 3.2 with USB and RRNET. Toys: 1541u

This looks like the geoLink tcp variables are being messing up.
Look at the SEQ number used in the first packet (2991652864) vs the last packet (1303314432).
Also, the number being ACKed in the last packet (1) is not correct ( should be 3544620132)

Are you using version 1.01 of geoLink?

1.01 it is, with latest ip65.

_________________
Tools: IDE64 3.2 with USB and RRNET. Toys: 1541u

I've investigated some more...
Seems like geolink (rather ip65 I guess) thinks all adresses starting with 192 should be on my local network, therefore sending arp requests who-has ip-of-irc-server, when it should know that those packets need to get routed.

_________________
Tools: IDE64 3.2 with USB and RRNET. Toys: 1541u

ip65 will default to using a 192.168.1.x address if it can't get an address via DHCP.

Sure, but it gets 192.168.0.23 from dhcp, no problem there.
That doesn't explain why it thinks that 192.121.49.1 is on my LAN.
I suspect some kind of netmask problem, but I haven't Read The Fine Source so careful yet.

_________________
Tools: IDE64 3.2 with USB and RRNET. Toys: 1541u

Sounds like either your client is getting a netmask of 255.0.0.0 from dhcp or ip65 is incorrectly masking the 192.168/16 private network as 192/8.

Exactly. Geolink claims to get 255.255.255.0 as netmask, so I'm suspecting 192/8.

_________________
Tools: IDE64 3.2 with USB and RRNET. Toys: 1541u