I see where you mean, but that's not it. When I break, eth_outp_len is
always $012C. I wondered whether it could be from replying to some
other packet, but the return address always shows as the line after
"jsr udp_send" in send_dhcprequest.

I tried putting a 100ms timer check in and if it got stuck for that long,
forcing the buffer clear (TxCMD bit 8), but that didn't seem to help
either. The odd thing is that if I've spent quite a bit of time with the
program frozen in the debugger, it always seems to transmit successfully
when I let it start running again. I suppose I could try querying the
transmit status registers to see what it might be, but at this point, I'm
stumped.

Meanwhile, I got my first successful ping and response, although I had
a hard crash as soon as the first pong was received :) If it still looks
good after some more rigorous testing, I'll send a patch to icmp.s.

_________________
"...and all watched over by machines of loving grace."

can you post another wireshark capture?

Both of these dumps were generated with the 100ms patch in place:
http://lyonlabs.org/ip65-timer-wait.txt

first dump: http://lyonlabs.org/ip65-dump3.pcap
There are usually five discovers and five offers; in this case there are
only four. Note how quickly my router (192.168.1.99) sends the offer
packets (2-3 ms apart). Is it possible that ip65 is trying to send
another request immediately after one had just been put into the buffer
but before the CS8900A has had time to send it? or would the send happen
independently of ip65 repeatedly checking for buffer space? Maybe if a
"don't send anything else while I'm doing this" flag were set...? I broke
into the debugger several times to verify that he was stuck in the transmit
loop; eventually, one of the times I started running again, the packet was
immediately sent (see last packet, at 318 seconds). The router shows that
an IP address of 192.168.1.109 was assigned.

second dump: http://lyonlabs.org/ip65-dump4.pcap
This time, I just let it sit while I went to get a cup of coffee, and the
request was eventually sent... over 200 seconds after the last offer! The
router shows 192.168.1.109 assigned; notice again how quickly the offer
packets were sent.

Am I just being impatient? Should it be considered normal for the request
packet to go out after so long?

_________________
"...and all watched over by machines of loving grace."

How bizarre.

Is this on a real c64 or an emulator? If real, can you try it under Vice? What other devices are plugged in?

Have you tried any other ip65 progs, e.g. the gopher code I posted in another message in this forum (which will do a dhcp request, so we can isolate whether the issue is with a change made to the code to get it working under GEOS, or something about your C64 or router setup)

Bizarre indeed. I'm using a real 64C with 1541 Ultimate (REU mode enabled) or either MMC Replay with an REU. I recompiled VICE with Ethernet enabled and attached your latest Gopher cartridge image (interesting that, first time I've used Gopher in about 100 years...).

I hard-reset the emulator several times and did not see the stall. In addition, as you can see, the traces were quite different:

http://lyonlabs.org/gopher1.pcap
http://lyonlabs.org/gopher2.pcap

1) server sends a ping after client sends the first DHCP discover
2) server sends a DHCP ACK after client sends DHCP request
3) ARP requests for the client's address come after the entire cycle is complete

To make things even stranger, I made up a D64 of my current test disk for the GEOS program and ran that in the emulator (with REU enabled)... which also didn't stall:

http://lyonlabs.org/nettest-vice1.pcap
http://lyonlabs.org/nettest-vice2.pcap
http://lyonlabs.org/nettest-vice3.pcap

I'm not quite sure what to make of this. I'll have a closer look at the dumps to see if there's anything interesting there.

_________________
"...and all watched over by machines of loving grace."

One last test - can you try the on your real system?

That will help determine if the issue lies in with geos vs without geos or real hw vs emulator.

It's probably easier to use the 'stand alone' gopher app (i.e.download/file.php?id=196 )
on a disk than try and get the cart image into an eprom.

I don't know much about the cs8900a physical interface (that code was done by Doc Bacardi and VagerMalp years ago I think) but could easily imagine
some interference at a critical junction either from e.g. the power drain from the REU or an IRQ or such.

Cheers

Jonno

ps - I don't think this is related to your issue, but just curious about something.
After the DHCP request generated by your app, your router does an ARP request, presumably to check whether the IP address it intends to use is already in use elsewhere.

After the DHCP request generated by the gopher cient, your router does a PING (presumably with the same purpuse, i.e. to see if the address it want's to use is already in use?). What's particularly interesting about this is, it doesn't do an ARP request first - the ICMP packet has the c64 MAC address in it.

I also noticed that the MAC address in your code is different - I assume you modified config.s to change this?

Did you set up a DHCP reservation on your router for one MAC address but not the other? Just wondering why your router would respond differently.

Regards

Jonno

I tried the standalone gopher client on the real hardware and it worked great.

I did a lot of testing this weekend, with three different types of network cards (RetroReplay/RR-Net, MMC Replay, and 1541 Ultimate), as well as with and without the REU. As far as I can see, the problem was largely in my test procedure: it actually works right when I read my saved settings (on initial program start after a hard reset), but not always from the setup screen. I was testing by invalidating the lease at the router, then reloading the setup screen and clicking "OK" (see link below). I'm still not sure why that doesn't work, since it resets the network card before doing anything. I'm going to set that aside for now so I can get some interesting code written.

I have ping working (simultaneously from '64 to PC and PC to '64); I just need to fix a bug with the sequence numbers.

No, I have my own setup screen. I use the pointer returned by NB65_GET_IP_CONFIG to copy the settings to ip65.

http://lyonlabs.org/commodore/nettest-setup.png

The changes to ip65 are really minimal; 95% of what I did was in creating a function dispatcher that is able to call into the ip65 API at a finer level (e.g. breaking up the initialization routine into several pieces) and adding the appropriate NB65_... constants.

So the good news is that it seems ip65 can work with both GEOS and an REU.

_________________
"...and all watched over by machines of loving grace."

Is there any filtering in the packet traces you've been posting? For example, could any ARP requests be excluded? One thing that may explain what's happening is if :
1) the router is not responding to ARP requests after you've invalidated the lease, and
2) those ARP requests were not included in the packet trace


neat!

I filtered them manually to make them easier to read. I'm sure there was nothing interesting missing, but there's also the possibility that the machine Wireshark was running on wasn't seeing all the packets. I was trying various combinations of cabling straight into the router, into a switch connected to the router, etc.

_________________
"...and all watched over by machines of loving grace."

Hello new wallpaper! That's very cool, and very chindōgu. Great job.



You probably know this, but for serious network debugging nothing beats a plain, dumb hub. Newer routers/switches filter packets based on MACs, so you might not see everything, even with your NIC in promiscuous mode. A hub lets every port see all the packets.

So we have got GEOS internet enabled now! That's really cool! Also, I never knew that GEOS had such good development tools with debugging and everything. So writing apps for GEOS suddenly looks feasible. Now where's that REU


I had to google that one! Learned a new word today

What's next

This is so cool!

Easy there, big fella! It's still just a proof of concept! If it becomes interesting, I may give a presentation at ECCC.
Yes, the geoProgrammer environment is fantastic, especially the debugger. It's worth a presentation in itself. In fact, I have one prepared here, somewhere...

_________________
"...and all watched over by machines of loving grace."

Cool! I'd like to take a look at that. If I understand it correctly, GEOS is now free for non-commercial use? But I can't seem to find it on the net. Only the Apple II version...