Roadshow for 68K -Needs your support!

[jj]

Yeah a bet Microsoft is quaking in its boots.  

[TCMSLP]

Any news on Roadshow?  I'm about to get my A1200 networked so a decent TCP/IP stack would be very useful right now

[mechy]

Last message i sent to olaf was about a week or 2 ago, he mentioned he is tidying up stuff and fixing a few small bugs.He didnt reply with a eta though,but expect it will be soon to be released.

Mike

[olsen]

Any news on Roadshow?  I'm about to get my A1200 networked so a decent TCP/IP stack would be very useful right now

Thank you for asking

I am still in the process of squashing one of the known bugs, namely the DHCP client code not working correctly with certain cable modems and whatnot. One thing led to another, and while the DHCP support now works where it previously did not, this uncovered related problems that did not show up because the DHCP client code previously did not work as intended. It's bug fixes and more bug fixes... Which I believe is a good thing. A number of necessary changes, and code reviews did not happen in the past couple of years. I am just catching up

My current plan is to look over the documentation during the weekend of September 18/19 and figure out what needs to be updated or added to. To be followed by putting a distribution disk together, and writing/testing an installer script.

The software is (basically) ready, has been for years, it's just that I never went the extra mile to mold it into something you could install

[actung_bab]

yes l be into that l reg both maimi and miami dx back in the day
whould buy roadshow ive run it on classic ppc os 4.0 was nice

since have sold ppc blizzard and use 020 1200 and just getting my cnet bbs going
so whould be perfect for me

[magnetic]

Olsen

Ok. Good news. Flawless DHCP is very important.  Also a good installer. And last but not least as I said before take the time and do a gui for the stack. In amigaworld this is important. Just look up countless gui threads..the last thing anyone wants to do after spending $30=$40 on a tcp stack is manual configs

[kolla]

What wouldn't be more natural than a GUI made with gtlayout?

[olsen]

Olsen

Ok. Good news. Flawless DHCP is very important.

But surprisingly hard to implement. My original DHCP client code was written according to the relevant RFCs current in 2001/2002, and I tested it with the ISC reference implementation. Further tweaks were made as I upgraded my home network over the years, and following reports from the OS4 beta testers. This was not enough, though

Today's DHCP servers, as found in embedded systems, or as part of dedicated server hardware, are an odd bunch. Some expect you to carry information in the DHCP requests which according to the documentation is not even mandatory, and duplicates the information already provided in the basic BOOTP packet. Some refuse to respond to your DHCP requests unless these requests are at least 300 bytes in size. Some respond with more data than your client code stated it can handle.

These discoveries prompted a slew of changes...

 Also a good installer. And last but not least as I said before take the time and do a gui for the stack. In amigaworld this is important. Just look up countless gui threads..

I hear you. The GUI issue is still unresolved. I am not going to put any work into writing one, as I have been there and it contributed to the excessive delay in getting the product published.

I did get an interesting offer in the last two weeks which may help to resolve the GUI issue. But in the mean time, I'd rather get Roadshow "finished" as far as is this may be possible, and prepare it for a GUI-less release. I really cannot tell how long it would take to make a proper GUI for Roadshow, if that would come to pass in the first place. So it's (for now) a decision of shipping Roadshow, or not to ship it at all.

the last thing anyone wants to do after spending $30=$40 on a tcp stack is manual configs

Some assembly will always be required. And the absensence of a GUI would have to affect the price. I don't expect Roadshow to sell in the $30+ range without a GUI.

[olsen]

What wouldn't be more natural than a GUI made with gtlayout?

I would have to spend time debugging gtlayout.library first As nice as gtlayout.library was for its time, building a Roadshow GUI from it would probably delay the creation of the GUI even further.

Whatever happens next, it probably won't be using gtlayout.library for development.

[LoadWB]

But surprisingly hard to implement. My original DHCP client code was written according to the relevant RFCs current in 2001/2002, and I tested it with the ISC reference implementation. Further tweaks were made as I upgraded my home network over the years, and following reports from the OS4 beta testers. This was not enough, though

Today's DHCP servers, as found in embedded systems, or as part of dedicated server hardware, are an odd bunch. Some expect you to carry information in the DHCP requests which according to the documentation is not even mandatory, and duplicates the information already provided in the basic BOOTP packet. Some refuse to respond to your DHCP requests unless these requests are at least 300 bytes in size. Some respond with more data than your client code stated it can handle.

These discoveries prompted a slew of changes...

This illustrates a small problem with the notion of "be liberal in what you accept, and conservative in what you send."  I have seen many network services which completely ignore the second part and absolutely demand the first, irrespective of the consequences.

I hear you. The GUI issue is still unresolved. I am not going to put any work into writing one, as I have been there and it contributed to the excessive delay in getting the product published.

I did get an interesting offer in the last two weeks which may help to resolve the GUI issue. But in the mean time, I'd rather get Roadshow "finished" as far as is this may be possible, and prepare it for a GUI-less release. I really cannot tell how long it would take to make a proper GUI for Roadshow, if that would come to pass in the first place. So it's (for now) a decision of shipping Roadshow, or not to ship it at all.

SHIP SHIP!  As for the GUI, I think leaving it without one gives the option of providing our own.  Have an officially-supported one, but not make it mandatory, that way some of us MUI-Rexx hacks or C/C++ jockeys (or E, or whatever your flavor) can make simple ones for ourselves, or even complex ones.  I am a "function over form" kind of person for the most part, so having a fast and workable TCP/IP stack is far more important to me than a pretty interface.

Some assembly will always be required. And the absensence of a GUI would have to affect the price. I don't expect Roadshow to sell in the $30+ range without a GUI.

What about a volume discount?  Seriously, I, for one, like the price notion.

[TCMSLP]

I'll buy just as soon as it's available!

I assume the command line would be similar to ifconfig under linux?  Lack of GUI doesn't bother me but I can appreciate others would prefer this.

Will basic network commands (ping, traceroute etc) come with this?

I'm new to networking on the amiga - I guess as long as we have a working interface and tcp/ip stack any other tools could be downloaded from Aminet?

*waiting with anticipation*


Steve

[olsen]

This illustrates a small problem with the notion of "be liberal in what you accept, and conservative in what you send."  I have seen many network services which completely ignore the second part and absolutely demand the first, irrespective of the consequences.

I suspect that the design of the DHCP protocol contributed to the odd client and server behaviour. The purpose of DHCP is to allow a client to learn about the network it is part of, and to share network resources without interfering with other clients. To this end DHCP makes sure that the exchange of information between clients and servers is well-defined and produces results: either the client gets what it wants, or it can be certain that no requested information will be forthcoming.

That's the plan, but there is no mechanism in DHCP to specifically help uncovering implementation errors. You have packet exchanges which say something along the lines of "here is the choice I can offer you", "this is what I want", "here is what I can give you".

But there is no packet exchange which says "I did not understand what you asked for". In place of that missing packet there is only silence. And that silence is interpreted as the complete absence of a server, which may be wrong since the server may have chosen to reject the (subjectively) malformed packet.

I remember that during OS4 testing, there were reports from cable modem users who said that they were losing their DHCP-assigned IP addresses. It turned out that the IP address leases assigned by DHCP were relatively short, and the Roadshow DHCP client correctly sent out lease extension requests, and eventually address renewal requests. Only that the DHCP server paid no attention to either, which eventually led Roadshow to stop using its assigned IP address altogether (all according to spec).

It would have been helpful to know why the DHCP server chose not to respond to the DHCP client messages. I now believe that the DHCP server found something in the packets it did not like. But as the DHCP protocol has no mechanism for notifying the client of such glitches, there was no way to figure out what was going on.

SHIP SHIP!  As for the GUI, I think leaving it without one gives the option of providing our own.  Have an officially-supported one, but not make it mandatory, that way some of us MUI-Rexx hacks or C/C++ jockeys (or E, or whatever your flavor) can make simple ones for ourselves, or even complex ones.  I am a "function over form" kind of person for the most part, so having a fast and workable TCP/IP stack is far more important to me than a pretty interface.

How the configuration files work, where they are stored, etc. is documented. Source code for all the shell tools is included, right down to the tcpdump/libpcap ports I cooked up. Anybody curious enough to start tinkering can do so with my blessings.

If you want to make a GUI, using the provided SDK material should allow you to do so.

What about a volume discount?  Seriously, I, for one, like the price notion.

Whoa! I haven't thought that far yet. Really, the imperative now is to get the thing ready to ship, and then ask the really difficult questions.

[olsen]

I'll buy just as soon as it's available!

I assume the command line would be similar to ifconfig under linux?

Um, no. I hope that they are better than that

Since the TCP/IP stack I built upon comes out of the BSD Unix heritage, the usual set of network setup/control/information commands to ship with it would include "ifconfig", "route", "arp", "netstat", "traceroute" and "ping". Of these I chose only to keep "arp", "traceroute" and "ping" and wrote Amiga-fied versions of the rest.

For example, to set up and configure interfaces and routing you would use the "AddNetInterface" and/or "ConfigureNetInterface" commands (they combine what "ifconfig" and "route" can do). To change the routing, you would use the "AddNetRoute" and "DeleteNetRoute" commands (these do what "route" could do). To obtain information about the state of the network you would use the "ShowNetStatus" and/or "GetNetStatus" commands (these do what "netstat" could do, and a bit more than that).

The point of making new commands was that, well, the originals were very terse and cryptic, and if they had been deliberately designed to make them harder to use, the designers couldn't have done a better job. I repeatedly ran afoul of the BSD "ifconfig" and "route" syntax, at which point I really had it, and I started to write Amiga-specific APIs for doing what these configuration tools would do (the "ifconfig" and "route" code itself is incredibly convoluted and crufty, too). Then I wrote new Amiga-specific commands to use these APIs.

I hope that these replacements provide better control, better error reporting and better platform-specific functionality than the original Unix commands would do. For example, you can use "GetNetStatus" (especially in script files) to test if specific aspects of the network are configured and operational; to the best of my knowledge there is no single Unix command which would provide you with this set of information.

I realize that ditching the "ifconfig", "route" and "netstat" commands may make it a bit more difficult to learn how Roadshow is set up and configured, assuming that you have prior knowledge of these Unix commands. But: to the best of my knowledge no two Unix/POSIX systems use the same syntax and switches, regarding these three commands. For example, the OpenBSD versions of "ifconfig" and "route" do not work like the Linux versions, or the Mac OS X versions, etc.

Bonus: the "traceroute" command has bugs fixed which have been around since 1987 and are still present in today's *BSD implementations of the command

Lack of GUI doesn't bother me but I can appreciate others would prefer this.

Will basic network commands (ping, traceroute etc) come with this?

Yes. "arp", "ping" and "traceroute" are included, as well as "tcpdump" and the BSD "ftp" client, and the tools that are part of Darren Reed's ip filter package. Source code for tcpdump/libpcap and the Amiga-fied shell commands is included (but not for the "ftp" client, etc. mentioned above; I didn't quite see the point since these tools are so simple).

I also ported "wget", which should become part of the shell command collection, but I'm not sure where I put the source code

[LoadWB]

But there is no packet exchange which says "I did not understand what you asked for". In place of that missing packet there is only silence. And that silence is interpreted as the complete absence of a server, which may be wrong since the server may have chosen to reject the (subjectively) malformed packet.

A cursory review of RFC 2131 would give me the notion that DHCPNAK should cover a situation of a bad client request, although the RFC only states a couple of scenarios in which the server would respond with a DHCPNAK.  I suppose that could encourage continuous bad behavior from a bad client, however.  I have never spent time delving into DHCP mechanics, and now I have yet more information that I am absolutely compelled to absorb... thanks :lol:

A problem I frequently saw in the past was that of identical IP schemes in use in multiple places.  The problem was DNS.  A laptop coming from home on 192.168.1.x would go to work and request the same IP address it was using at home.  The office DHCP server would happily approve the request, provided the IP was not in use on the network.  The client would then retain all of its network configurations including DNS, which may or may not work on the office network.  Or vice-versa.

[olsen]

A cursory review of RFC 2131 would give me the notion that DHCPNAK should cover a situation of a bad client request, although the RFC only states a couple of scenarios in which the server would respond with a DHCPNAK.

The purpose of the NAK message is to tell the client/server that the contents of a request are unsuitable. But in order to get as far as knowing that a NAK message should be sent in response, you have to have processed the meaning of the original message first.

If your code reads that original message and considers it malformed, prompting it to ignore it altogether, processing will never reach the state where a specific NAK would be sent in response.

What DHCP is lacking is a mechanism to notify the client/server of the rejection of a message prior to analyzing its meaning.

I suppose that could encourage continuous bad behavior from a bad client, however.  I have never spent time delving into DHCP mechanics, and now I have yet more information that I am absolutely compelled to absorb... thanks :lol:

There is a lot of bad news in how DHCP implementations actually behave, as compared to the deceptively simple RFC specification. Some of the quirks are really outlandish, such as the minimum packet size. With a lot of handwringing, that minimum packet size comes out of the original BOOTP specification (RFC 951). Why a server would have to reject such a packet purely based upon its size, rather than its contents, is (at least for me) puzzling.

A problem I frequently saw in the past was that of identical IP schemes in use in multiple places.  The problem was DNS.  A laptop coming from home on 192.168.1.x would go to work and request the same IP address it was using at home.  The office DHCP server would happily approve the request, provided the IP was not in use on the network.  The client would then retain all of its network configurations including DNS, which may or may not work on the office network.  Or vice-versa.

Sounds like a poorly-configured DHCP server to me

For example, the ISC DHCP server reference implementation allows you to lock down unsuitable address ranges, preventing clients from appropriating them.

[LoadWB]

If your code reads that original message and considers it malformed, prompting it to ignore it altogether, processing will never reach the state where a specific NAK would be sent in response.

What DHCP is lacking is a mechanism to notify the client/server of the rejection of a message prior to analyzing its meaning.

And thus I propose the DHCPSAYWHAT packet.

Sounds like a poorly-configured DHCP server to me

For example, the ISC DHCP server reference implementation allows you to lock down unsuitable address ranges, preventing clients from appropriating them.

Well, it is a pretty common issue between the LinkSys, D-Link, and Microsoft 2003 DNS services, so there you go.  But in this case it was not an issue of unsuitable address ranges, but identical ranges.  192.168.1.x at home AND at the office, so the machine would ask to use 192.168.1.100 and the DHCP server says yes, and the client keeps the same DNS settings because it does not see the need to change.

Now, it could be the client's fault and not the DNS server.  But I never bothered to sniff traffic to make that determination.  I may now just for shits and giggles.