Reinoud Zandijk wrote:
Hi Jurai and Naoki, i feel real dumb... i had a working port of the mos(4) build myself only initialisation didn't allways work fine. I think i promised to work on it and bring it in-tree to you before but i was swamped with work and completely forgot. Glad you took up the gauntlet and started too. When i was hacking a three days and nearly finished, i discovered the FreeBSD code and that code resets the device by setting its USB config. Most likely the OpenBSD code does that too. If you are interested i can send you the code-so-far i wrote for reference or guide.
It's no problem (at least for me). I've taken it as a research project to learn something new and the objective was achieved. I would be glad to look at your code.
I'll try out your code soon!
Cool, thank you.After a short break, I did some real world tests with ported driver and I had to add broadcast-enable code, because dhclient was unable to get an ip address unless I was running tcpdump which put the interface into promiscuous mode. Although a specification says (or at least I understood it that way) broadcast ethernet frames are received always, they presumably are not and their reception must be enabled in mos_setmulti().
With the latest broadcast patch (look in test/3/ directory), everything seems to work fine except copying larger data block (>10MB) from linux to netbsd (I'm getting the 'connection reset by peer' from ssh or ftp). Netstat utility doesn't say there are any input/output errors. It works fine between two netbsd's or from netbsd to linux. I should check with synchronized userland and kernel (userland is 5.0 RC1), kernel is 5.0 + mos driver.
With regards, Reinoud
Best Begards, Juraj