@itix

Now I say that I don't have Olaf's email anywhere with the details. Why do my emails go missing?

Anyway, IIRC, Roadshow doesn't skip anything in the negotiation process.

@itix

Quote:

What checks you are talking about?

The DHCP lease renewal process breaks down into several steps to make sure that both the server and the client acknowledge what the other party wanted to be done.

In this case the client ought to tell the server that it wants to keep the IP address the server assigned to it. The server has to look at this request and either reject it, acknowledge it, or hand the client a new address.

Once it has communicated its decision to the client, the client is supposed to respond to the server with a message along the lines of "I will be using the IP address a.b.c.d from now on until it needs to be renewed again".

Miami's implementation of the DHCP lease renewal process consists only of the last step. The client just sends the server an acknowledgement for a message the server never even sent. This is of course faster since there is no turnaround and waiting for the server's decision.

The DHCP client in Miami merely says "I'm going to hang onto this IP address I got a while ago, and there's nothing you can do about it".

This probably works most of the time, DHCP being a well-defined and robust protocol. But occasionally you're stuck with a DHCP server that's poorly configured. I remember that in the early days we had a lot of trouble with cable modem users and DHCP lease renewal. The problem was that the server completely ignored what the DHCP client said. You don't have many options to react to that on the client's part, which is why Roadshow can get into trouble under such circumstances.

@Hypex

Quote:

This is better IMHO for OS3.5 users who got riped off without a proper stack.

That actually contributed to my decision to investigate how one might port a TCP/IP stack to the Amiga, especially since the 3.9 update later shipped without a robust TCP/IP stack at all.

@cv643d

Quote:

cv643d wrote: I just hope he has got a license to sell it on the Amiga market.

There are some limits to what I can do with the TCP/IP stack, but I own the property and can make my own decisions on releasing it for the 68k platform. I'm the guy who hands out the licenses

@olsen
There have been a few discussions recently here and/or on Amigans.net (maybe you followed them) about certain limitations of OS4's networking - which maybe you could comment on? The ones which I think you might have some influence on as the author of Roadshow are:

* AddNetInterface pauses for (say) 1.5 minutes if there is no ethernet cable plugged in, when configured for DHCP. This halt's the boot process on OS4. Couldn't it detect the lack of a cable plugged in, like Windows/etc does?

* If DHCP fails at boot (say due to the lack of a cable) you then have to reboot (or issue some cryptic shell command that about 3 people remember) if you want to retry DHCP. Ideally Roadshow would (a) detect a cable being plugged in & retry automatically (probably related to the previous point), and (b) if DHCP failed with cable plugged in then it could keep trying at regular intervals. This would bring it's behaviour in line with Windows/etc, and make it much more user-friendly.

* Some people report DHCP failing with certain (broadband) routers. No doubt they don't conform to spec, but is there anything you could do to improve compatibility without dodgy routers (since Windows/etc seem to get by just fine)?

Last edited by ChrisH on 27-Aug-2010 at 09:07 AM.
Last edited by ChrisH on 27-Aug-2010 at 09:06 AM.

_________________
Author of the PortablE programming language.
It is pitch black. You are likely to be eaten by a grue...

@ChrisH

Quote:

ChrisH wrote: @olsen There have been a few discussions recently here and/or on Amigans.net (maybe you followed them) about certain limitations of OS4's networking - which maybe you could comment on? The ones which I think you might have some influence on as the author of Roadshow are: * AddNetInterface pauses for (say) 1.5 minutes if there is no ethernet cable plugged in, when configured for DHCP. This halt's the boot process on OS4. Couldn't it detect the lack of a cable plugged in, like Windows/etc does?

Unless I misremember this, the SANA-II driver interface has no notion of hardware connectivity detection. You cannot ask the driver to probe the hardware for the presence of a carrier signal, for example.

If the NIC is not connected, or the connection is down, the only way to find out if something is wrong is to try and broadcast a message and wait for an echo of sorts. Now this isn't exactly what Roadshow does. It may just try to get a response from a DHCP server, and it might take a while for the timeout to elapse after which AddNetInterface just moves on.

Quote:

* If DHCP fails at boot (say due to the lack of a cable) you then have to reboot (or issue some cryptic shell command that about 3 people remember) if you want to retry DHCP. Ideally Roadshow would (a) detect a cable being plugged in & retry automatically (probably related to the previous point), and (b) if DHCP failed with cable plugged in then it could keep trying at regular intervals. This would bring it's behaviour in line with Windows/etc, and make it much more user-friendly.

Again, the driver issue is there. You can do something manually by taking the network interface offline through the ConfigureNetInterface command, but that's all there is.

Sorry, we're stuck with an ancient API that was originally created for dial-up networking and ArcNet/Ethernet cards that were assumed to be always plugged in. The API design even predates what was used for Windows 3.1, and if that doesn't give you that sinking feeling in your stomach, I don't know what will

Quote:

* Some people report DHCP failing with certain (broadband) routers. No doubt they don't conform to spec, but is there anything you could do to improve compatibility without dodgy routers (since Windows/etc seem to get by just fine)?

The DHCP client code in Roadshow needs improving, no doubt. But you can't really use Windows a reference for DHCP compatibility. As with PC hardware, some particular software is tested with Windows only and therefore conforms more to the bugs in the Windows implementation than it conforms to the protocol specification.

I hope to get DHCP client reliability improved, but for that to work out I first need to understand better what exactly it is that causes trouble.

Last edited by olsen on 27-Aug-2010 at 09:15 AM.

@olsen
Many thanks for your answers - clears-up a lot!

Quote:

Sorry, we're stuck with an ancient API that was originally created for dial-up networking and ArcNet/Ethernet cards that were assumed to be always plugged in. The API design even predates what was used for Windows 3.1

OK, next question: If the SANA-2 driver interface is so old/pants, surely it's time it was updated? And you would seem to be an ideal candidate for the job!

Now, from reading what you said on Amiga.org, you would probably tell me SANA-2 needs to be completely replaced (not just updated) to allow DMA (for Gigabit ethernet performance), etc. And that this is a flippin big job, which you are not keen on tackling (yet). My response would be - sure, I understand that, but why not be pragmatic and merely do what you can by updating the existing SANA-2 interface? For example, would it really be that hard to just add the abiliity to check whether an ethernet cable is plugged in? It might not be pretty from a designer point-of-view, but surely it would be a lot better than nothing!

Quote:

I hope to get DHCP client reliability improved, but for that to work out I first need to understand better what exactly it is that causes trouble.

Would it be worth people reporting the make/model of the router they had DHCP problems with?

_________________
Author of the PortablE programming language.
It is pitch black. You are likely to be eaten by a grue...

@olsen

Any interest (your or anyone you know) in defining a SANA-III spec that adds in some of these missing features, speed grades, as well as more things for Wireless support? (Wireless accesspoint detection, autoconnect to known points, autodetect if no known points or no points at all thus no network, autodetect of wireless speed (A/B/G/N/Wimax/bluetooth/zigbee/whatever), etc?)

_________________
All glory to the Hypnotoad!

@thread

Since the thread (11 pages currently) on amiga.org has additional information and keeps popping on and off their front page, I thought it would be wise to link to it again.
Particularly of interest to some folks would be the speed test figures:

Post #161

#6

_________________
This posting, in its entirety, represents solely the perspective of the author.
*Secrecy has served us so well*

@olsen and all

My internet connection is an old ADSL1. The modem need maybe 20 seconds to be synchronized and maybe 20 seconds for connected with the DNS.

As the Amiga boot too speedy for the modem, the addnetinterface check before the modem fully connected (between synchronized and DNS resolving by DHCP).

the result for me is on some internet pages, a too long waiting time about some parts of the internet page (with Ibrowse the blue square rest forever in blue)

For resolving that, I switch on the modem and wait the modem is completely connected before switching on the SAM.

Like that, the internet connection work fine and just only one time with Ibrowse the DNS resolving at start and all internet page after work fine.

Now most of the users maybe let their internet connection allways online or use ADSL2+ (verry short connection and synchronized time) but there are users like me with this kind of problem.


Also on AOS4.1U2, netshutdown command shutdown nothing. Working previoulsy.
Have opened a thread on amigans about that (AOS4 feedback part of amigans: don't know if you read amigans).

Also on AOS4.1U1, if I receive a big internet page and do a netshutdown (or save settings with internet program), I have a roadshow DSI (maybe resolved on AOS4.1U2.

_________________
BTW, what you have done for the amiga today ????

-A1200+Mediator+VooDoo3+060/50+96mo+SCSI-KIT
-SAM440EP-667mhz-on MapowerKC3000+AOS4.1

Amiga Docs Disks Preservation Project

Quote:

Sorry, we're stuck with an ancient API that was originally created for dial-up networking and ArcNet/Ethernet cards that were assumed to be always plugged in. The API design even predates what was used for Windows 3.1, and if that doesn't give you that sinking feeling in your stomach, I don't know what will

Then, the question is - as always -: what do we stick with these old APIs ?
Isn't it about time to create new up to date ones ?
When these limitations limits how easy the OS can be to use I see it as a problem...

_________________
http://www.warpdesign.fr/

@olsen

How about just taking the linux TCP/IP stack?

Just put SANA II wrapper on top, for legacy support.

Last edited by NutsAboutAmiga on 28-Aug-2010 at 12:18 AM.

_________________
http://lifeofliveforit.blogspot.no/
Facebook::LiveForIt Software for AmigaOS

@ChrisH

Quote:

ChrisH wrote: @olsen Many thanks for your answers - clears-up a lot! Quote: Sorry, we're stuck with an ancient API that was originally created for dial-up networking and ArcNet/Ethernet cards that were assumed to be always plugged in. The API design even predates what was used for Windows 3.1 OK, next question: If the SANA-2 driver interface is so old/pants, surely it's time it was updated?

A tiny market, little demand for networking hardware and drivers, very few people left who are able and willing to work on an update to the standard, and the SANA-II standard covers just about the majority of networking functionality present, leaving out only a small (but significant) part of unsupported hardware features. This isn't the kind of problem that naturally attracts developers willing to solve it in their spare time. It's sort of a problem on the cusp of attracting developer interest: once of one of them finds that he's in need of getting some hardware to work that the standard does not covers, you'll see progress.

Quote:

And you would seem to be an ideal candidate for the job!

But I can't do everything, can I? As much as software development is in my blood, as you get older, there is less and less spare time to you can spend on tasks such as this one, which promises to take up a lot of time and effort.

Quote:

Now, from reading what you said on Amiga.org, you would probably tell me SANA-2 needs to be completely replaced (not just updated) to allow DMA (for Gigabit ethernet performance), etc.

It's not that terrible. The basic framework for the drivers hasn't changed over some 20 odd years. Memory management functions may have to be added to the API in order to support DMA, though. All of this could be done as part of an incremental update.

Quote:

And that this is a flippin big job, which you are not keen on tackling (yet). My response would be - sure, I understand that, but why not be pragmatic and merely do what you can by updating the existing SANA-2 interface? For example, would it really be that hard to just add the abiliity to check whether an ethernet cable is plugged in? It might not be pretty from a designer point-of-view, but surely it would be a lot better than nothing!

You still have to rack your brain for a solution, talk it over with your peers, and you have to test this stuff. Not just in the sense of plugging in the cables and seeing how it fares. You have to modify existing drivers to support the experimental features, hook them up with the TCP/IP stack for further experimentation, and eventually publish your results. Even if you try to stick to the minimum of functional enhancements, it doesn't change the fact that you're still in for a lot of fundamental work that cannot be avoided.

Quote:

Quote: I hope to get DHCP client reliability improved, but for that to work out I first need to understand better what exactly it is that causes trouble. Would it be worth people reporting the make/model of the router they had DHCP problems with?

I expect that the issues will be with how the DHCP message interaction plays out, or fails to play out. This is something that can be examined by capturing wire traffic, and there's a tool included with Roadshow to do just that: tcpdump. When it's time to have a good close look at the DHCP issue, this is proably how it's going to work out.

Knowing the make and the models of the gear involved could help, but it's what's on the wire that is driving the DHCP client and server interaction, so this is what might produce better insights.

@billt

Quote:

billt wrote: @olsen Any interest (your or anyone you know) in defining a SANA-III spec that adds in some of these missing features, speed grades, as well as more things for Wireless support? (Wireless accesspoint detection, autoconnect to known points, autodetect if no known points or no points at all thus no network, autodetect of wireless speed (A/B/G/N/Wimax/bluetooth/zigbee/whatever), etc?)

Neil Cafferkey worked on updating SANA-II to support DMA transfers and wireless networking. That was in 2005. You have probably seen his work in prism2.device, and also in AROS, for which I believe he is a major contributor.

This is the most work done in the SANA-II driver field, in a long time, which I know of.

While this gives us no major driver architecture update that covers all the bases, it's the best that could be done so far. You are asking for a much broader and deeper development effort which I suspect is currently not within anybody's reach.

@Leo

Quote:

Leo wrote: Quote: Sorry, we're stuck with an ancient API that was originally created for dial-up networking and ArcNet/Ethernet cards that were assumed to be always plugged in. The API design even predates what was used for Windows 3.1, and if that doesn't give you that sinking feeling in your stomach, I don't know what will Then, the question is - as always -: what do we stick with these old APIs ? Isn't it about time to create new up to date ones ? When these limitations limits how easy the OS can be to use I see it as a problem...

And this motivates you to get up to speed in Amiga system development and join the cause to deliver an updated SANA standard?

@NutsAboutAmiga

Quote:

NutsAboutAmiga wrote: @olsen How about just taking the linux TCP/IP stack? Just put SANA II wrapper on top, for legacy support.

It is the word "just" which makes me smile

Porting a TCP/IP stack intended for enterprise use to AmigaOS is no mean accomplishment. The AmiTCP developers, who wrote it as their thesis project, if I remember correctly, worked hard on the task and delivered a blueprint of how this can be done for the BSD Unix family TCP/IP implementation. Miami and Roadshow followed this blueprint. Any further development work in this field is likely to build upon what is already reasonably well-understood.

Starting over with a different architecture (Linux) is likely to cause a lot more complications than merely "extending" existing ports would entail. If I were to start today, I would look into the OpenBSD, FreeBSD and NetBSD variants of the TCP/IP stack, since they are all directly related to code I already ported to the Amiga. Linux and embedded TCP/IP stacks would be very far down on my list of choices, because they are so different from what I am still vaguely familiar with.

Integrating SANA-II support into a TCP/IP stack is one of the most challenging parts of the task. This is where the operating system kernel functionality interfaces to the driver level, and Unix/Linux drivers are typically an underdocumented, unwieldy, ugly mess which gives no joy to the developer working on them. NetBSD and friends do tend to have nicer driver architectures than Linux, though, which makes the BSD TCP/IP stack more attractive to work on.

Last edited by olsen on 28-Aug-2010 at 08:22 AM.

Quote:

And this motivates you to get up to speed in Amiga system development and join the cause to deliver an updated SANA standard?

Unfortunately I am no low-level programmer. The best I have done so far is some basic C stuff. So writing driver specifications + actual implementation surely isn't for me. You have to understand everyone cannot magically become a developer.

That being said, if I was to do such a thing, I would surely make sure all 3 major AmigaOS of today would agree on a specification and all adopt it. Otherwise I wouldn't see the point... I'm against having to reinvent the wheel. I'm also against closing everything: this is what prevented the Amiga from evolving for at least a decade, and that's a shame. And I fear they wouldn't accept, not because it wouldn't be well-thought/written, but because they don't wanna open themeselves to other "camps"... Seeing some sort of non-existing enemy there.

_________________
http://www.warpdesign.fr/

Quote:

Porting a TCP/IP stack intended for enterprise use to AmigaOS is no mean accomplishment.

Slightly off topic and out of curiosity: Mr Olsen - you don't happen to know why Commodore Westchester chose to make the AS225 API a blueprint copy of the BSD TCP/IP API instead of coming up with some other and custom solution? It's hardly compliant with AmigaOS programming tradition per se.

In fact, I'm intrigued they didn't base the API on the standard AmigaOS device architecture instead, allowing for asynchronous (and protocol-independent) network communication in a unified fashion (network.device, where art thou?).

By the way - is the Roadshow API documentation is publically available? I'd really like to have a look at it.

_________________
That'll Put Marzipan In Your Pie Plate, Bingo
💻 Pro-Amiga, 🌍 Pro-Globalism, 🍅 Pro-Vegan, 🛦 Pro-NATO & 🇪🇺 Pro-Joint EU Defense Intervention Initiative

@Petah

Quote:

Petah wrote: Quote: Porting a TCP/IP stack intended for enterprise use to AmigaOS is no mean accomplishment. Slightly off topic and out of curiosity: Mr Olsen - you don't happen to know why Commodore Westchester chose to make the AS225 API a blueprint copy of the BSD TCP/IP API instead of coming up with some other and custom solution? It's hardly compliant with AmigaOS programming tradition per se.

The original networking group at Commodore will know the detailed answer. I only got to know some fragmentary information over the years, and it is not much.

From what I gather, the Amiga market at that time (1987-1989) was in something of a chicken-egg situation when it came to data network operations. Without the hardware, nobody would be likely to develop the software. Without the software, nobody would want to develop the hardware.

Well, "nobody" may be too strong a term here, but it certainly made it difficult to justify development work in either area. That was the time when an outfit sufficiently large and well-funded could have created its own hardware. For example, you might have expected NASA or the Stanford linear acceleration center to have put resources behind creating networking hardware for their own use, if the need had been great enough.

But apparently, this didn't happen. What did happen in the late 1980'ies was that Ameristar corporation built an Ethernet Zorro II card, and an ArcNet card. So there was hardware, but no TCP/IP software for it. What Commodore shipped as the A225 product looked to me like an engineering test implementation of a TCP/IP stack, fit to work well with the Ameristar hardware. As such it did not have the luxury of an architecture behind it that would last a while (SANA or SANA-II).

I am speculating here, but I suspect that this is what Ameristar built and sold to Commodore along with the rights to build the A2065 (Ethernet) and A2060 (ArcNet). Commodore released it as a product, and it lacked the sort of polishing one might have expected.

Curiously, I saw the A225 here in Germany, released around 1989 long before the A2060 and A2065 was announced or had appeared as a product. Not even the Amiga dealer I was friendly with knew what to make of this "weird" product.

Quote:

In fact, I'm intrigued they didn't base the API on the standard AmigaOS device architecture instead, allowing for asynchronous (and protocol-independent) network communication in a unified fashion (network.device, where art thou?).

As far as I know the networking group at Commodore did R&D in this area, but Commodore canned the group and everything they had produced (Envoy, AS225R2, to name only those products which were eventually released by the original developers later). By the time their work could have really changed things, they were either reassigned to different projects or no longer employed by Commodore. That's when AmiTCP appeared and managed to change everything.

Quote:

By the way - is the Roadshow API documentation is publically available? I'd really like to have a look at it.

It has been around awhile: it is part of the OS4 SDK, but may not be entirely complete in this form. Some example source code may be missing.

@thread

maybe the asm source code to cnet device (PCMCIA SANA2 Network Card driver
) is of use to developers. A bounty would be ideal.

http://aminet.net/driver/net/cnetdevice.lha

_________________
Download 499.26 Mbps, 659.94 Mbps Upload :)