Roadshow for 68K -Needs your support!

[Trev]

Most if not all broadband modems can be configured to operate as bridges. That's what I've always done. All moden SOHO routers support PPPoE, physical address spoofing, and all the other bits you need to work around your ISP's inane access policies. If your ISP is relying on your default use of their equipment and attempting to "manage" your service at the end point, well, they're being silly, especially if you own the equipment.

@olsen

I'd pay for it, in part as a thank you for all the help you provide re: other Amiga madness in your spare time.

Re: 68060, if the stack spends a relatively high amount of time computing checksums, a pipeline optimized checksum would be great. That same routine should run on other CPUs without issues, albeit linearly, yes?

[Trev]

Excuse me, but you obviously have no idea what trolling is - try a dictionary or the jargon file.

It's a mixed metaphor and an excellent example of the degradation of the English language and communication in general.

[Trev]

Without support for path MTU discovery you can end up in a situation where for example you seemingly at random can download from certain sites but not from others, even though you can ping them and reach them from other machines. I had this problem years and years ago with AmiTCP (it must have been, since Miami, appearantly, does support path MTU discovery).

That would only be a problem if a router could not fragment the packet (either because of the packet's don't fragment flag or other reasons) or the remote host couldn't accept the MTU used. The easiest way to fix that in all cases is to use an MTU of 576 bytes, the minimum that all hosts are required to accept. Performance may suffer, but that's how it goes.

If that doesn't work, you could write a packet filter that snoops for applicable ICMP responses, e.g. type 3, code 4 (fragmentation required), adjusts the MTU accordingly (probably using a path MTU discovery process to decide on the size), and drops the ICMP response. Assuming your MTU adjustment code is written properly, the IP stack would either retransmit the packet after not receiving an acknowledgement or not know even about the problem, depending on the transport protocol being used.

I know that's a lot of work, but it does solve the problem. :-P

The real culprit here is that since Roadshow is closed, the features of Roadshow is at the whim of one single person, which renders it rather useless for me at least, as I already have Miami.

That's kind of the same for all commercial software, including AmigaOS itself. Miami, on the other hand, is ... dead? ;-)

[Trev]

Yes, one could implement something path MTU discovery-ish as a filter.

;-) I'll give you this, though: a stack without path MTU discovery should probably automatically use an MTU of 576 (or a smaller MSS or whatever it needs to do given the architecture) when sending data to remote networks. It should be "safe" to assume the local MTU can be used, but as you experienced, that's not always the case.

And how long till Roadshow is dead? I don't see the big difference, really.

As long as Hyperion uses it as part of AmigaOS, I suspect it will be around. But let's not go down that path in this thread. :-P I've never heard or read a single bad thing about Olaf, so I don't have any reason not to trust that he won't continue to support the software as long as people are using it. (He still supports clib2, despite Hyperion moving to newlib as their default C library, and clib2 is free and open source.)

[Trev]

Awesome! Time to pull the classics out of storage.