D.i.N.S. v1.0C
D.i.N.S. v1.0C
Greetings once again!
For all the members that aren't logged in, I attached two screenshots to accompany this update.
In this update I have added a significant amount of client signatures and blocking techniques that reduce network overhead due to unecessary 'callback packets'. I have started to focus on filterring out 'info-retrieving' packets from various clients that send info about the host computer/user to the core server and to other users. I don't believe that this is meant to invade privacy, but other people may see otherwise.
I added a poll-based timer routine to test how long it takes to perform certain actions and see how they compare to various optimizations. I may be utilizing the timer routine later to set acceptable parameters in which a process must complete its task by. It isn't exactly a RT-OS, but its one step closer. Once again though, that is only an idea, and it hasn't been worked out as far as details or code goes; it may not even happen.
I added "-Os -march=pentium4 -ffast-math -funroll-loops" optimizations to the entire OS resulting in faster speeds (measured by the timer). It seems stable with the heavy optimizations, but its only been about 24-hours of burn-in, so I wont call it offically stable yet.
----------------------------------------------------------------------------------
The current p2p/bittorrent client blacklist is as follows:
Azureus v2.5.0.4,
Vuze v3.1.0.0,
uTorrent v1.8b,
KaZaA v3.2.5,
ARES v2.0.9,
LimeWire v4.18.3,
eMule v0.49a,
Shareaza v4,
BearShare v6,
BitTornado v0.4.17,
ABC v3.1,
Deluge v0.5.9.3,
BitComet v1.02,
XBT v0.7.3,
Arctic v1.2.3,
g3torrent v1.01,
Rufus v0.6.9,
mlDonkey v2.9.5,
BitTyrant v2.5.0.0,
Tribler v4.1.9
Bittorrent v6.0.3
----------------------------------------------------------------------------------
I also went through after blocking the default installs and re-ran all of the applicable clients with encryption enabled and went back through and added signatures based off of the encryption that was impelemented. The screenshot for the BitTorrent client shows the blocking of an early encryption handshakes.
The OS has been so stable in the past week or two that I have been running my personal computer through it and have actually forgotten that it was being tunneled through D.i.N.S., needless to say, I was displeased when my Ubuntu torrent wasn't downloading.
I began working on the base-code for the web UI. Nothing to really report yet, I havent even been able to dish out even the most basic of pages back, but I've been focusing on adding client signatures. I have decided on implementing both the Web UI and the Serial-based terminal UI. By default, the serial terminal UI will be enabled only, then through the terminal CLI the administrator could then enable the Web UI for added 0-day security.
Thanks for tuning in.
For all the members that aren't logged in, I attached two screenshots to accompany this update.
In this update I have added a significant amount of client signatures and blocking techniques that reduce network overhead due to unecessary 'callback packets'. I have started to focus on filterring out 'info-retrieving' packets from various clients that send info about the host computer/user to the core server and to other users. I don't believe that this is meant to invade privacy, but other people may see otherwise.
I added a poll-based timer routine to test how long it takes to perform certain actions and see how they compare to various optimizations. I may be utilizing the timer routine later to set acceptable parameters in which a process must complete its task by. It isn't exactly a RT-OS, but its one step closer. Once again though, that is only an idea, and it hasn't been worked out as far as details or code goes; it may not even happen.
I added "-Os -march=pentium4 -ffast-math -funroll-loops" optimizations to the entire OS resulting in faster speeds (measured by the timer). It seems stable with the heavy optimizations, but its only been about 24-hours of burn-in, so I wont call it offically stable yet.
----------------------------------------------------------------------------------
The current p2p/bittorrent client blacklist is as follows:
Azureus v2.5.0.4,
Vuze v3.1.0.0,
uTorrent v1.8b,
KaZaA v3.2.5,
ARES v2.0.9,
LimeWire v4.18.3,
eMule v0.49a,
Shareaza v4,
BearShare v6,
BitTornado v0.4.17,
ABC v3.1,
Deluge v0.5.9.3,
BitComet v1.02,
XBT v0.7.3,
Arctic v1.2.3,
g3torrent v1.01,
Rufus v0.6.9,
mlDonkey v2.9.5,
BitTyrant v2.5.0.0,
Tribler v4.1.9
Bittorrent v6.0.3
----------------------------------------------------------------------------------
I also went through after blocking the default installs and re-ran all of the applicable clients with encryption enabled and went back through and added signatures based off of the encryption that was impelemented. The screenshot for the BitTorrent client shows the blocking of an early encryption handshakes.
The OS has been so stable in the past week or two that I have been running my personal computer through it and have actually forgotten that it was being tunneled through D.i.N.S., needless to say, I was displeased when my Ubuntu torrent wasn't downloading.
I began working on the base-code for the web UI. Nothing to really report yet, I havent even been able to dish out even the most basic of pages back, but I've been focusing on adding client signatures. I have decided on implementing both the Web UI and the Serial-based terminal UI. By default, the serial terminal UI will be enabled only, then through the terminal CLI the administrator could then enable the Web UI for added 0-day security.
Thanks for tuning in.
Website: https://joscor.com
Re: D.i.N.S. v1.0C
I have nothing other to say than that is jaw-droppingly impressive.
Re: D.i.N.S. v1.0C
Very cool. Out of curiosity (isn't it all) how modular is the OS? It would be good if you could add filter plugins or something similar that extend the base filtering functionality.
The cake is a lie | rackbits.com
Re: D.i.N.S. v1.0C
I am working on a way to add signatures modularly. I think I will be using the whole kernel update method, by sending a whole new kernel to the computer being updated, and have the existing kernel 'self-update'. That way I can make huge changed to the core infrastructure if need be and still be able to allow hosts to remotely update.ucosty wrote:Very cool. Out of curiosity (isn't it all) how modular is the OS? It would be good if you could add filter plugins or something similar that extend the base filtering functionality.
Website: https://joscor.com
Re: D.i.N.S. v1.0C
Hi,
Looks very good. One thing that I still don't quite understand (I probably didn't read the blurb enough) - is this a system that sits in the way of connections (i.e. acts as a proxy server - boxen <-> D.I.N.S <-> WWW) or as a peer to other boxen on the network? (i.e. D.I.N.S is just another box on the network that happens to snoop for P2P traffic and blocks/disrupts it?)
Cheers,
James
Looks very good. One thing that I still don't quite understand (I probably didn't read the blurb enough) - is this a system that sits in the way of connections (i.e. acts as a proxy server - boxen <-> D.I.N.S <-> WWW) or as a peer to other boxen on the network? (i.e. D.I.N.S is just another box on the network that happens to snoop for P2P traffic and blocks/disrupts it?)
Cheers,
James
Re: D.i.N.S. v1.0C
i think it's meant to work as a firewall, from what i've gathered.
yet again, very nice work, i swear you must work 24/7 on this project, you seem to be making progress all the time
yet again, very nice work, i swear you must work 24/7 on this project, you seem to be making progress all the time
Re: D.i.N.S. v1.0C
Lukem95 is correct in its placement in the network. It is designed to be placed either before or after a server (before to decrease server load), and is designed to be placed after all the smaller network implementations (switches, hubs, etc). It should be getting the full network load passing through it, then it sniffs. Also, DiNS 'could' be put throughout sub-networks or clusters, but it would be inefficient. Right now I'm working on a way to allow admins to direct traffic through DiNS irrelevant of its physical location (via proxy).JamesM wrote:Hi,
Looks very good. One thing that I still don't quite understand (I probably didn't read the blurb enough) - is this a system that sits in the way of connections (i.e. acts as a proxy server - boxen <-> D.I.N.S <-> WWW) or as a peer to other boxen on the network? (i.e. D.I.N.S is just another box on the network that happens to snoop for P2P traffic and blocks/disrupts it?)
James
Website: https://joscor.com
Re: D.i.N.S. v1.0C
mini-update:
DiNS can now parse all of the SMBios structures. I now have it setup to show the bios/motherboard/system info as well as the processor. Took quite a while (3 hours) to get the stupid offsets correct and build a smbios post-struct string parser.
DiNS can now parse all of the SMBios structures. I now have it setup to show the bios/motherboard/system info as well as the processor. Took quite a while (3 hours) to get the stupid offsets correct and build a smbios post-struct string parser.
Website: https://joscor.com
- piranha
- Member
- Posts: 1391
- Joined: Thu Dec 21, 2006 7:42 pm
- Location: Unknown. Momentum is pretty certain, however.
- Contact:
Re: D.i.N.S. v1.0C
How many hours per day do you work on this?
-JL
-JL
SeaOS: Adding VT-x, networking, and ARM support
dbittman on IRC, @danielbittman on twitter
https://dbittman.github.io
dbittman on IRC, @danielbittman on twitter
https://dbittman.github.io
Re: D.i.N.S. v1.0C
about 3 hours on non-work days and 1-2 on work days.
sometimes I work for a long time on weekends.
I really don't work all that much on my OS, deff not like full-time coding.
sometimes I work for a long time on weekends.
I really don't work all that much on my OS, deff not like full-time coding.
Website: https://joscor.com
Re: D.i.N.S. v1.0C
I don't know how much of a 'wow' factor this one has, but I added the -pedantic command at compile time. This really brought out the worse in my coding habits, made me rethink common practices and to cleanup my code. Now all my OS files compile without any warnings even with the -std=c89 -pedantic options on. I will eventually get around to updating to ISO C99, but not for a while.
I would really recommend implementing one of the ISOs and use the -pedantic (if using gcc) and see just how horrid your code really is compared to the 'standard' lol.
I would really recommend implementing one of the ISOs and use the -pedantic (if using gcc) and see just how horrid your code really is compared to the 'standard' lol.
Website: https://joscor.com
Re: D.i.N.S. v1.0C
ok, nvm about the last post. Now my OS is fully ISO C99 standardized. No warning or errors with optimisations on and using '-std=c99 -pedantic'.
Website: https://joscor.com
Re: D.i.N.S. v1.0C
I second the recommendation to follow the standards. To me, following the language should be a no-brainer. Congrats on getting it all fixed up though. How many errors and warnings were there in the old code?
Now where is Solar?
Now where is Solar?
Re: D.i.N.S. v1.0C
Great work, E-69!
Actually, you could start to sell your OS for money
Actually, you could start to sell your OS for money
My web site: http://inflater.wz.cz (Slovak)
Derrick operating system: http://derrick.xf.cz (Slovak and English )
Derrick operating system: http://derrick.xf.cz (Slovak and English )
- piranha
- Member
- Posts: 1391
- Joined: Thu Dec 21, 2006 7:42 pm
- Location: Unknown. Momentum is pretty certain, however.
- Contact:
Re: D.i.N.S. v1.0C
I'm jealous, your OS actually has potential.
-JL
-JL
SeaOS: Adding VT-x, networking, and ARM support
dbittman on IRC, @danielbittman on twitter
https://dbittman.github.io
dbittman on IRC, @danielbittman on twitter
https://dbittman.github.io