Image Map Image Map
Page 2 of 3 FirstFirst 123 LastLast
Results 11 to 20 of 28

Thread: DOS Networking / Win 3.11 Networking

  1. #11
    Join Date
    Sep 2016
    Location
    Rhode Island, US
    Posts
    9

    Default

    I'll second using mTCP if you really want TCP/IP networking.

    If you are just looking for a way to get file shares mounted in DOS http://etherdfs.sourceforge.net/ is the way to go.

    Like mTCP it just requires a packet driver but requires the server to be running Linux.

  2. #12

    Default

    I try to refrain from commenting on other networking projects, but EtherDFS scares the crap out of me and I would be very cautious when using it.

    People here found a data corruption problem with it in this thread: http://www.vcfed.org/forum/showthrea...-drive-for-DOS . We had a vigorous debate about the packet driver spec and padding on Ethernet frames, and eventually the bug was fixed. But it took a while to convince the author that they were in violation of the spec. More troubling to me is that they released software that manipulates data without adding something as basic as a checksum or a CRC.

    I might pick up that code one day and build on it, but based on that exchange I don't trust it as is. This is a personal opinion - read the linked thread and draw your own conclusions.

  3. #13
    Join Date
    Sep 2016
    Location
    Rhode Island, US
    Posts
    9

    Default

    That's really good to know, thanks. I was drawn to it because of the simplicity of the redirector interface. Do you think I would have a bad time trying to graft the redirector interface from etherdfs onto an mTCP-based application? (Assuming the old source version of mTCP is still floating around.)

    It would likely need some custom server but it wouldn't need to be Linux since it won't be using raw Ethernet frames.

  4. #14

    Default

    The redirector interface is a mixed bag. There is enough sample code out there but the interface was never formally documented by Microsoft. So it is usable but there is no one specification to consult; you have to consult open source code and some 3rd party books to get the full picture.

    There is also the block device approach which should be simpler and it is well documented. Just make a DOS block device that is backed by the network. It looks and smells like a DOS drive but under the covers it uses UDP or something else to send and receive the blocks. (UDP can easily transport two disk blocks with meta data in a single packet.) Implement a small local cache and you can probably get reasonable performance out of it with minimal memory cost. You'd need to run a dedicated server on another machine, but with UDP that is not a big deal - Windows and Linux would be good targets for that server, and it would not have to have raw network access. This is probably the approach I will use when I get around to it.

    "Old" mTCP source is still pretty current. I'm working on some bug fixes and probably will release source code again this time. If you start with the currently available source code you won't be hit with too many incompatible changes.

    As for EtherDFS try it out. But read the source code ... Something that handles data should be CRCing the data and doing basic sanity checking like mad.


    Mike

  5. #15

    Default

    Quote Originally Posted by mbbrutman View Post
    We had a vigorous debate about the packet driver spec and padding on Ethernet frames, and eventually the bug was fixed. But it took a while to convince the author that they were in violation of the spec.
    That wasn't something I needed to be convinced about, really, and you certainly did not convince me. I implemented the fix as soon as I deduced the problem, that is immediately after I received debug data kindly provided by Brian (keenerg) and Jim (Trixter). At that time, you were still claiming that the problem is impossible because, I quote: "If the PE3 was adding extra bytes to a packet it would have never been sold.". Confronted to facts, you later changed your strong opinion. All that to say that it is easy to be smart after the fact.

    But since you mention a spec - would you mind quoting the spec your are referring to exactly? I asked for this back then, but instead you only provided loose assumptions. I am genuinely interested in knowing whether or not it is "legal" to pad frames whose length fulfills CSMA/CD requirements already. Unfortunately I was (and am) unable to find this information. Not that it would be of any practical importance anyway, since EtherDFS deals with such situations now, but it would still be nice to know what the formal spec says exactly (if at all defined). Do you have access to the related IEEE documentation?

    Quote Originally Posted by mbbrutman View Post
    More troubling to me is that they released software that manipulates data without adding something as basic as a checksum or a CRC.
    EtherDFS computes and validates a custom checksum since v0.8.1 (in addition to the Ethernet checksum). May prevent corruptions that happen between the PC and its network card.

    Quote Originally Posted by mbbrutman View Post
    There is also the block device approach which should be simpler and it is well documented.
    That is a very valid option, but one has to be aware that with such solution, only one PC must be allowed to access the drive at any given time - because of the risk of concurrent writes of course, but also because of the fact that the OS is fooled into believing it's a "real" drive that is being accessed, and as such it could be tempted to perform caching on its own, unaware that the data may spontaneously change at the other end.

  6. #16

    Default

    Relevant post here:

    http://www.vcfed.org/forum/showthrea...493#post456493

    I was quite surprised that the Xircom adapter was adding a byte of padding, and I was wrong about that. However, I also knew to read the spec to get the correct value for the frame length so my code never experienced that problem. [1] You used the wrong length and [2] you released your code first without a basic checksum or CRC check, opening people up to data corruption.

    I'm glad you added the checksum during that debug process. But I think that entire thread is very instructive, and my warnings about "buyer beware" still stand.

  7. #17

    Default

    And for the record, this is the post where I pointed out the specific error in your code. You worked around a problem problem you didn't understand. I identified the flaw in your code.

    The problem was also pretty clear to the other experienced programmer in that thread; the length of your packets needs to be encoded in the packet and read from the packet, not from the packet driver or the equivalent of the recv syscall. There is no TCP/IP or Ethernet text that will tell you it's safe to do a recv call and use that as your length; you always have to get the length that was embedded in the packet. The fact that packet drivers and/or hardware don't allow runt frames and will pad them is a direct signal. Padding to word boundaries is an ancient performance optimization (depending on the architecture).

    Jim also pointed out that the Intel 8/16 card he was using was having the same problem, so it was not strictly a Xircom problem.

    Don't compare my misplaced faith in the Xircom packet driver with your not knowing now to write communications code and not being cautious by protecting things with a checksum. I certainly don't need a lecture on the dangers of caching or concurrent writes from you.

  8. #18

    Default

    Quote Originally Posted by mbbrutman View Post
    However, I also knew to read the spec to get the correct value for the frame length so my code never experienced that problem.
    I hate to say that, but you did not invent anything - you re-implemented protocols known for a few decades based on widely available RFCs. You read the IP length header because someone else placed it there, that doesn't make you a genius. Moreover, your reaction to my findings about the PE3 behavior is proof that you were very much clueless in the matter.

    Quote Originally Posted by mbbrutman View Post
    And for the record, this is the post where I pointed out the specific error in your code. You worked around a problem problem you didn't understand. I identified the flaw in your code.
    You clearly think that I'm stupid. And that's your right - I have no problem with that. It's also your right to be an arrogant fart, it's none of my business really. But what you do above is lying, and that I cannot tolerate. You did not identify anything - your patronizing comments conveniently came over a day after I fixed and documented the issue.

    Quote Originally Posted by mbbrutman View Post
    There is no TCP/IP or Ethernet text that will tell you it's safe to do a recv call and use that as your length;
    This only means the spec is ambiguous. And yet, you keep blabbing about "spec violation" every now and then, which fools me every time into believing you know something that I don't. I am *not* arguing about the reality of things here - some adapters evidently perform padding even on big frames, and I was the first to point this out (much to your surprise). I am only arguing about whether or not this is something that should happen, according to formal rules.

    Quote Originally Posted by mbbrutman View Post
    I certainly don't need a lecture on the dangers of caching or concurrent writes from you.
    You thinking that I was addressing you is symptomatic of your state of mind. I was warning "astamp" that your advice about emulating a block device for the purpose of sharing files between PCes is flawed - or at least burdened by limitations. He may or may not accept these limitations, but at least he's now aware of them.

  9. #19
    Join Date
    Sep 2006
    Location
    Silicon Valley
    Posts
    2,018

    Default

    Quote Originally Posted by mateuszviste View Post
    You clearly think that I'm stupid. And that's your right
    MANY people are going to think you are stupid for arguing with mbbrutman
    on a site that he runs and frequently demonstrates he has little tolerance
    for people who do.

  10. #20

    Default

    I never claimed to invent anything. However, being able to read, understand and follow specifications is a good skill to have. And once again, I quickly admitted that I was surprised by the behavior of the Xircom adapter but my surprise is irrelevant - I never had to worry about the behavior of the Xircom or Intel adapters because my code was safe and correct by reading the encoded packet length. You designed code that didn't bother encoding a length, and didn't bother with a higher level check on the data other than the Ethernet CRC. And then you gave it to other people. Bad.

    Once again, the spec is not ambiguous. Everybody knows to read the length of the encoded data from the header in the data. You don't trust recv calls because sometimes they come up short and sometimes there is padding, because adding padding was a common technical trick.

    The history of the debug effort on your code is clear in the thread for everybody to read. I did my part to help you understand your bug. My advice; test more before releasing code. Especially code that might corrupt data.
    Last edited by mbbrutman; September 10th, 2019 at 07:55 AM.

Bookmarks

Posting Permissions

  • You may not post new threads
  • You may not post replies
  • You may not post attachments
  • You may not edit your posts
  •