@olsen

On some of the previous post I have made here, we have discussed about differents topics related on roadshow.

some suggestions has been made about the need to have the modem synced and dataed before booting the amiga and for the missing ethernet link cable:

improvements for addnetinterface:

adding the possibility to addnetinterface to open a screen and show messages for 2 cases.

- The modem isn't synced or dataed. a message said that the OS wait after the modem to be synced and dataed before continuing to boot. (and information explanation and a please wait).

- The amiga isn't linked with an ethernet cable. a message said that and a counter to zero show to the user when the amiga will restart to boot.

for sure on this 2 kind of window mesages, the user could use continue or cancel but at least the main improvements are:

- the user know what happened.
- Security check are added to addnetinterface to give the OS more professionnal.

just my point of view/suggestion

_________________
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

@Mrodfr

Quote:

Mrodfr wrote: @olsen On some of the previous post I have made here, we have discussed about differents topics related on roadshow. some suggestions has been made about the need to have the modem synced and dataed before booting the amiga and for the missing ethernet link cable: improvements for addnetinterface: adding the possibility to addnetinterface to open a screen and show messages for 2 cases. - The modem isn't synced or dataed. a message said that the OS wait after the modem to be synced and dataed before continuing to boot. (and information explanation and a please wait). - The amiga isn't linked with an ethernet cable. a message said that and a counter to zero show to the user when the amiga will restart to boot. for sure on this 2 kind of window mesages, the user could use continue or cancel but at least the main improvements are: - the user know what happened. - Security check are added to addnetinterface to give the OS more professionnal. just my point of view/suggestion

I understand why these features would be useful, and especially useful for you. The big difficulty in implementing them is in that our networking driver standard SANA-II does not provide the information required to show you the state of the modem or whether it is even properly connected to the Amiga

Quote:

- The modem isn't synced or dataed. a message said that the OS wait after the modem to be synced and dataed before continuing to boot. (and information explanation and a please wait). - The amiga isn't linked with an ethernet cable. a message said that and a counter to zero show to the user when the amiga will restart to boot.

maybe the commodity showing status icons like on other OSs would be even better... i mean less talking way, just indicators

but as long as there are no new enhanced SANA-II drivers, we are screwed

Last edited by ExiE on 17-Sep-2010 at 11:49 AM.

@olsen

You mentioned Zeroconf in another thread, I think. How and when is link local addressing used? Must it be specifically enabled, or will it be used automatically if DHCP fails?

_________________
Sam440ep-flex 733 MHz/1 GB RAM/Radeon 9250/AmigaOS4.1 Update 2
borked A1200/Blizzard1260+SCSI-IV/Z4+MediatorZIV/Deneb/Voodoo3/CatweaselMk3
more borked A1200/MBX1200z/Indivision
A500/clockport/RRNet
A600/A603

Quote:

I understand why these features would be useful, and especially useful for you. The big difficulty in implementing them is in that our networking driver standard SANA-II does not provide the information required to show you the state of the modem or whether it is even properly connected to the Amiga

How about SANA-III then ? :)

_________________
http://www.warpdesign.fr/

@Trev

Quote:

Trev wrote: @olsen You mentioned Zeroconf in another thread, I think. How and when is link local addressing used? Must it be specifically enabled, or will it be used automatically if DHCP fails?

It is an alternative to DHCP. That is, you either choose DHCP configuration or "automatic" configuration. The latter is Zeroconf link local address allocation, with ARP packets used to announce/defend the address picked. I did not consider Zeroconf as a a fall-back for DHCP address assignment, although many operating systems will do just that.

In Roadshow the interface address comes out of the hardware address, through a cryptographic hash function. Which means that your local interface address should always start with the same preset. If subsequent address changes are necessary, the addresses also come out of hashing. A deterministic process picks the address to use.

@Leo

Quote:

Leo wrote: Quote: I understand why these features would be useful, and especially useful for you. The big difficulty in implementing them is in that our networking driver standard SANA-II does not provide the information required to show you the state of the modem or whether it is even properly connected to the Amiga How about SANA-III then ? :)

It has been suggested numerous times, and the feature list just keeps on growing...

@Mrodfr

Quote:

dding the possibility to addnetinterface to open a screen and show messages for 2 cases. - The modem isn't synced or dataed. a message said that the OS wait after the modem to be synced and dataed before continuing to boot. (and information explanation and a please wait).

Ethernet is not the medium you think it is. It uses broadcasts, and when a device is listening, it might respond; when a device is not listening, it definitely will not respond. Your modem behaves like an Ethernet bridge, which makes it "invisible" to other devices. (That is not entirely true, but with respect to Roadshow initialization, it may as well be.)

Read another way, Ethernet cabling is not the same as serial cabling. There is no direct negotiation between Ethernet devices, and Ethernet devices do not have direct knowledge of each other without the use of a higher level protocol.

With knowledge about your device and your ISP, e.g. the modem's Ethernet address and your expected default IP gateway, there might be a way to abuse ARP or another protocol to guess about the availability of your modem, but this is not something that belongs in Roadshow. It would be a hack to work around the fact that you have applied power to your modem and computer in the wrong order. EDIT: In your case, and perhaps all related cases, it would in fact be a very useful hack, I agree. It just might not be practical.

Last edited by Trev on 20-Sep-2010 at 03:46 AM.

_________________
Sam440ep-flex 733 MHz/1 GB RAM/Radeon 9250/AmigaOS4.1 Update 2
borked A1200/Blizzard1260+SCSI-IV/Z4+MediatorZIV/Deneb/Voodoo3/CatweaselMk3
more borked A1200/MBX1200z/Indivision
A500/clockport/RRNet
A600/A603

Quote:

It has been suggested numerous times, and the feature list just keeps on growing...

When does it get started then ? :)

_________________
http://www.warpdesign.fr/

@Trev

Quote:

Trev wrote: @Mrodfr Quote: dding the possibility to addnetinterface to open a screen and show messages for 2 cases. - The modem isn't synced or dataed. a message said that the OS wait after the modem to be synced and dataed before continuing to boot. (and information explanation and a please wait). Ethernet is not the medium you think it is. It uses broadcasts, and when a device is listening, it might respond; when a device is not listening, it definitely will not respond. Your modem behaves like an Ethernet bridge, which makes it "invisible" to other devices. (That is not entirely true, but with respect to Roadshow initialization, it may as well be.)

It would be nice if our driver framework had the means to tell you about simple stuff, such as what medium types the hardware supports, which types are actually usable, whether there is a carrier signal on the link, etc. And there should be an API to notify you if this information changes. Based upon that you could do "traffic fishing", looking for ARP announcements, DHCP discovery packets, or maybe something like UPnP (which is built around DHCP and SSDP, if I remember correctly).

Currently, we have none of that...

@olsen

Quote:

t would be nice if our driver framework had the means to tell you about simple stuff, such as what medium types the hardware supports, which types are actually usable, whether there is a carrier signal on the link, etc. And there should be an API to notify you if this information changes. Based upon that you could do "traffic fishing", looking for ARP announcements, DHCP discovery packets, or maybe something like UPnP (which is built around DHCP and SSDP, if I remember correctly).Currently, we have none o

I have made, months ago, a sugestion to an amiga programmer, about porting or making a program like:

http://addgadget.com/network_meter/

Roadshow have the feature and the API to manage (realtime) and resume (max and min) download and uplaod traffic or this is also things that roadshow don't have untill now ???


Now that greatly explained that the modem must be synced and dataed before booting the Amiga and impossible to add check about that on roadshow, the only solution is:

- Inform the lambda amiga user to wait his modem before booting the amiga.

For sure, most of them use allways connected Internet or use last ADSL2+ or cable modem that conect surely before the amiga boot reach addnetinterface, but I think this fact should be written somewhere (and for me on the original amiga book that came with AOS4.1). This is my point of view.


I have greatly appreciated your technical and well explained posts about roadshow

Last edited by Mrodfr on 20-Sep-2010 at 06:48 PM.

_________________
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

@Mrodfr

Quote:

Mrodfr wrote: @olsen Quote: t would be nice if our driver framework had the means to tell you about simple stuff, such as what medium types the hardware supports, which types are actually usable, whether there is a carrier signal on the link, etc. And there should be an API to notify you if this information changes. Based upon that you could do "traffic fishing", looking for ARP announcements, DHCP discovery packets, or maybe something like UPnP (which is built around DHCP and SSDP, if I remember correctly).Currently, we have none o I have made, months ago, a sugestion to an amiga programmer, about porting or making a program like: http://addgadget.com/network_meter/ Roadshow have the feature and the API to manage (realtime) and resume (max and min) download and uplaod traffic or this is also things that roadshow don't have untill now ???

I don't know if this actually ships with OS4, but Roadshow includes a tool which calculates and visualizes the upload/download rates. This information can be obtained either per interface, or globally for all interfaces.

While that tool (called SampleNetSpeed) is very unsophisticated, source code is available, and if you wanted to, you could build something much nicer from it.

Quote:

Now that greatly explained that the modem must be synced and dataed before booting the Amiga and impossible to add check about that on roadshow, the only solution is: - Inform the lambda amiga user to wait his modem before booting the amiga. For sure, most of them use allways connected Internet or use last ADSL2+ or cable modem that conect surely before the amiga boot reach addnetinterface, but I think this fact should be written somewhere (and for me on the original amiga book that came with AOS4.1). This is my point of view. I have greatly appreciated your technical and well explained posts about roadshow

The whole network startup needs rethinking, actually. My original idea was that getting the network operational should not be much different from mounting a disk. This is what AddNetInterface does: you just tell it which network interface to "mount", and the rest of the network should become operational as a result of that.

But that turned out to be a poorer idea than what I intended it to accomplish. The problem is that bringing up the network is a two-step operation, but how it's being done now defaults to complete it in one step. First you need to tell the system which network interfaces should be used. Then you tell the network to put them to use.

The big flaw is in that AddNetInterface can be used to perform both steps, whereas it was originally intended to take care of only the first step. The second step would have involved the ConfigureNetInterface command.

To simplify things considerably for the user I enhanced AddNetInterface to also do what the ConfigureNetInterface command should have been solely responsible for. While this allows you to bring up the network in one single step, it causes major problems.

The major problems are:

* The system startup can get stuck for no reason visible to the user when the DHCP server is slow, or there is no DHCP server to assign an interface address.

* If you want to delay the network startup because your cable modem or ADSL modem needs to become operational first, it will delay the entire system startup, with, again, no visible reason given to the user.

* You cannot abort the network startup, because it happens as part of Startup-Sequence.

* If the network startup produces errors, these are lost to the user because the startup happens as part of Startup-Sequence, and the error messages are not saved for later.

So, while under perfect (or reasonably good) conditions AddNetInterface gets the job done just fine, it's more of a burden if things do not turn out exactly according to plan.

Last edited by olsen on 23-Sep-2010 at 08:41 AM.
Last edited by olsen on 23-Sep-2010 at 08:32 AM.

@Leo

Quote:

Leo wrote: Quote: It has been suggested numerous times, and the feature list just keeps on growing... When does it get started then ? :)

Good question.

There have been plenty of good ideas on what should be provided in terms of functionality. This would have to be collected and organized.

The ideas would have to be rewritten as a spec document, and need to be talked over by the few and the brave willing to delve into enhancing SANA-II.

Then we ought to have a test bed to experiment with, namely an Ethernet driver which can be modified and tested as necessary. This driver would implement the changes outlined in the spec.

It's all doable, within a modest timeframe (say, a couple of months). All that's needed is a bit of spare time for everybody to contribute to the effort who would need to get involved.

@olsen

That would be a very good thing ! How many guys would be needed in your opinion ?

I would say the best would be to have each current NG system to be "officially" represented : AmigaOS 4, AROS and MorphOS. Some other guys with deep technical knowledge would be a plus too (thinking about Trev here).

IMHO this "council" must be equilibrated : the same number of people from each system should be present, so that means at least 3 guys. That's doesn't seem impossible to find !
If needed I might even volunteer to gather ideas and turn them into a redacted document to serve as specification.
Would you agree to represent the AmigaOS 4 ? If yes then I might go on and publish news on several Amiga forums to form this "council".

PS: I personally don't have deep network knowledge as you and Trev seem to have so I would only be able to have a coordinator place.

_________________
AOS 4.1 : I dream it, Hyperion did it !
Now dreaming AOS 4.2...
Thank you to all devs involved for this great job !

@olsen

Do we have an internal loopback interface? If so, is that interface active as soon as the IP stack comes up? Ideally, we would have a completely functional stack even without a physical network interface.

Re: SANA-II, I like the idea of a new or updated specification, but it doesn't have to be tied to any particular operating system. For example, a driver interface could be implemented using interfaces on AmigaOS 4.x, Exec devices/libraries on AmigaOS 3.x, etc. Extending SANA-II to support additional messages doesn't necessarily make things like zero-copy DMA or TOE (I know, that's a stretch) possible. Virtual interfaces are certainly possible, i.e. one that supports port aggregation, load-balancing, failover, etc.

@abalaban

I'm just a punter. I do think SANA-II or a new specification should be open but designed with AmigaOS in mind. Reference designs and implementations for AmigaOS 3.x and 4.x could be used by MorphOS and AROS folks if desired. This isn't a this versus that issue; it's really about where the specification is coming from and what's practical for the people involved, especially Olsen. Of course, only he can say what is or isn't doable.

Last edited by Trev on 23-Sep-2010 at 06:10 PM.

_________________
Sam440ep-flex 733 MHz/1 GB RAM/Radeon 9250/AmigaOS4.1 Update 2
borked A1200/Blizzard1260+SCSI-IV/Z4+MediatorZIV/Deneb/Voodoo3/CatweaselMk3
more borked A1200/MBX1200z/Indivision
A500/clockport/RRNet
A600/A603

@Trev

Quote:

Trev wrote: @olsen Do we have an internal loopback interface? If so, is that interface active as soon as the IP stack comes up?

Yes. As soon as you open the "bsdsocket.library" for the first time, the loopback interface is configured with 127.0.0.1 as its address. You can change that later through the "ConfigureNetInterface" shell command, or the API functions. But the initial address is fixed.

Quote:

Ideally, we would have a completely functional stack even without a physical network interface.

Well... there's functional, and there's functional

Quote:

Re: SANA-II, I like the idea of a new or updated specification, but it doesn't have to be tied to any particular operating system. For example, a driver interface could be implemented using interfaces on AmigaOS 4.x, Exec devices/libraries on AmigaOS 3.x, etc.

Yes. This has to work for Kickstart 2.04 and up, and it should deliver the same functionality for every platform. Otherwise it wouldn't be a good addition to the standard.

Quote:

Extending SANA-II to support additional messages doesn't necessarily make things like zero-copy DMA or TOE (I know, that's a stretch) possible. Virtual interfaces are certainly possible, i.e. one that supports port aggregation, load-balancing, failover, etc.

I think we have to ponder TOE and consider how it could be made to work. It would help to look at how a modern TCP/IP stack handles it. There's probably not a lot to be learned from how 4.4BSD-Lite2 might benefit from TOE support.

For DMA to be supported with the kind of NICs available today, the driver has to play a part in allocating and managing memory. Currently, the client software (TCP/IP stack, Envoy, etc.) performs the allocation, which forces copying operations to be performed by the driver. All OS4 Ethernet drivers, for example, manage their own DMA buffers, and the data that comes in and goes out must go through memmove() first.

The old SANA-IIR2 standard doesn't help here, since it requires that the hardware be capable of arbitrary memory access, and arbitrary packet sizes. The only hardware to ever support this method was the DEC "Tulip" chip on the DKB Wildfire board. None of today's NICs works anything like it.

So maybe the driver would have to be enhanced to support new memory management function calls, and not just the old BeginIO() and AbortIO() pair. It would be more "natural" than squeezing the same functionality out of IORequest operations.

@olsen

Quote:

First you need to tell the system which network interfaces should be used. Then you tell the network to put them to use.The big flaw is in that AddNetInterface can be used to perform both steps, whereas it was originally intended to take care of only the first step. The second step would have involved the ConfigureNetInterface command.To simplify things considerably for the user I enhanced AddNetInterface to also do what the ConfigureNetInterface command should have been solely responsible for.

Thanks for the useful discussion. IMHO from the user perspective the shortcomings are not from the admixture of the configuration and activation steps, but the fact that the activation itself can be asynchronous with the rest of the boot process, yet because it is integrated directly in-line with other boot steps it acts like a synchronous step.

The network availability has its own set of applications and startup steps (dependant on it's completion not the just the start of DHCP), which is why many folks have created their own network-startup script as a decoupling step. That way, waiting for the DHCP reply and "interface UP" equivalent can be synchronous for the applications which have the network as a requirement, but the rest of the system/user startup is not made dependant on it. It seems like a perfect use for a docky which could display the status and "ifup/ifdown" control for each interfaces separate from bootup.

@abalaban

Quote:

abalaban wrote: @olsen That would be a very good thing ! How many guys would be needed in your opinion ?

As many as may want to help, have knowledge of writing drivers and the SANA-II standard as it exists today. That can't be a big crowd

Quote:

I would say the best would be to have each current NG system to be "officially" represented : AmigaOS 4, AROS and MorphOS. Some other guys with deep technical knowledge would be a plus too (thinking about Trev here). IMHO this "council" must be equilibrated : the same number of people from each system should be present, so that means at least 3 guys. That's doesn't seem impossible to find ! If needed I might even volunteer to gather ideas and turn them into a redacted document to serve as specification.

That sounds a little like a peace conference to me

Really, I'd rather prefer the approach taken by the IETF. Let the guys come together who have a vested interest in the standard, and who can build & test the things proposed.

Quote:

Would you agree to represent the AmigaOS 4 ? If yes then I might go on and publish news on several Amiga forums to form this "council".

Actually, I'd rather represent myself It's not as if this were officially sanctioned or sponsored business. This is strictly engineering and design in the good old skunkworks tradition.

Last edited by olsen on 23-Sep-2010 at 07:52 PM.

@olsen

Just for reference, here's our brief discussion on S2_ONLINE from a few years ago: http://amigaworld.net/modules/newbb/viewtopic.php?topic_id=25448&forum=15

Our hypothetical standard should probably have a concept related to carrier state (as you mentioned earlier in this thread), but it should be implemented in a way that abstracts it away from the actual link layer. CMD_START, CMD_STOP, S2_ONLINE, and S2_OFFLINE probably aren't necessary. Simply opening and closing the device should be sufficient for maintaining state, and an S2 or NSD-style query function could return the current state.

In the case of PPPoE and other link layer protocols, that state could be communicated and controlled by a separate piece of software using shared memory, message passing, or some other IPC mechanism.

So, that's one complication a new standard could do without. Network devices are link layer devices, after all, and it make sense for a network device driver to be an abstract interface to that layer. (Sorry, that was obvious.) Our friend PPPoE becomes a link layer device in this case, even if in actuality it's a link layer tunneled over another link layer device. (That, too, was obvious.)

In a nutshell, I think snipping away at the bits we don't need is a good place to start.

EDIT:

Quote:

This is strictly engineering and design in the good old skunkworks tradition.

A friend of mine worked in ground support for the SR-71 during the late 60's. It was on the edge of science fiction in the early 80's, so I can only imagine how awesome it must have seemed when it was developed and initially deployed.

Last edited by Trev on 23-Sep-2010 at 11:35 PM.

_________________
Sam440ep-flex 733 MHz/1 GB RAM/Radeon 9250/AmigaOS4.1 Update 2
borked A1200/Blizzard1260+SCSI-IV/Z4+MediatorZIV/Deneb/Voodoo3/CatweaselMk3
more borked A1200/MBX1200z/Indivision
A500/clockport/RRNet
A600/A603

Quote:

Having to look in the past to create a new driver standard isn't really looking forward to me...

WDM drivers didn't work on Windows 3.1...

Supporting 3.x as well as AROS would be a good point to me.

Last edited by Leo on 24-Sep-2010 at 02:31 PM.

_________________
http://www.warpdesign.fr/