Hi fellas! Here's some more follow-up.
For the last few days... I was really stumped on this project trying to figure out a better, smoother, more fluid alternative to not having any error checking thus far and avoiding the use of a timing cycle between the sending of commands to the router. (
Commands being HTTP/GET for status requests, or HTTP/POST for router control data )
Well... while doing further research with Google, I could not find the information I was looking for concerning the use of the Winsock API with UDP port 514. ( Syslog-RFC3164 )
Which left me having to wing things again. (
man I hate it when that happens 
)
After spending the whole evening last night tinkering around... I was finally able to reliably receive sysLog datagrams from the router on local port 514 in addition to TCP/IP datagrams on local port 80.
The end result now is having a solid and reliable mechinism for logging and evaluating router status in real-time,
without the need for using a fixed timing cycle or evaluting the content returned from the router on port 80 using HTTP requests, while gaining additional control of the router's connection state & ports through automation.
( Naturally HTTP is only being used to gather status information for display purposes for those items that are not monitored in the router's built-in sysloger )
Lets put it this way, it opens up a whole new ball game and more potential for this type of project!
Most notably in getting real-time status information on the LCP or PAP for ADSL or Fiber Optic connections, and again without sending HTTP requests with the GET method to analyze the status pages built into the router www engine.
Here, let me explain...When the router is configured to send syslog messages to a specific address,
or broadcasts, them over the LAN, the control can now intercept these messages in real-time, and behave accordingly in ways that were not possible with a fixed timing cycle and analyzing the internal log inside the router, or any of the status pages alone.
The bennefits...One added bennefit is real-time logging of "
all" router activity on the PC the control is running on, thus bypassing the 22KB log size limit inside the particular router being used for development.
Which by the way pans old data out in place of new once the log is full.
In layman's terms, we can have a local log that is only limited by free disk space or aggregated directly into other network traffic logs and saved or relayed to other SysLog servers/clients.
It's also very convienent to
not have to deal with the router's internal log if so desired.
Maybe even elegant and real smooth man. 
Best of all though... The administrating/server PC can now detect,
in real-time, any
monkey business going on with respect to outside traffic comming into the LAN.
Maybe a denial of service attack is launched at the LAN, www server(s), or perhaps a port scan? Besides local logging, we can actually make the control do something about what is taking place, based on the event, simply by analyzing the syslog message. How cool is that?
For example...Let's say you were asked to visit a URL with your browser that redirected you through a proxy in order obtain your Internet Gateway IP address with the sole purpose of scanning your Router/LAN/servers for open ports, whilst giving the party scanning for those ports some identity evasion & data collection forwarding abilty while doing the dastardly deed.
Oh s%*@!
Was someone being naughty? 
Or maybe the proxy wants to obatin this information whilst making it appear the individual who gave you the link is being naughty, thus trying to start a net war?
No matter, except that perhaps it was just a single port scan which might otherwise go un-noticed, like your VNC/Upnp ports?
Well... this control can now act accordingly and do something about it, without human interaction!
Now that's cool! 
But how does it respond?Maybe the control just renews the Gateway IP address, then lets the DynDNS client do the rest?
If you use DynDNS.Maybe it just evaluates the port scan further, to determine if its a legitimate request to activate that port on the router for incoming traffic?
You know... based on authentification and additional criteria from the party doing the scan?
Think of it kind of like a way to turn on remote management/remote access,
from remote, when remote management is off, or that particlar port is off due to a firewall exclusion.
Maybe we don't say what exactly it does and be more creative. Perhaps employ tarpits or honeypots to analyze what the intruder is up too for developement purposes?
Or maybe it just takes the LCP down and disconnects the LAN from the WAN to avoid further attack, scans, or all WAN activity LAN wide, forcing some sort of human administration?
Sounds intriguing huh... Pretty darn clever and cool don't ya' think?
Conclusion...As you can see we have lot's of potential now with the engine I've been crafting for a control of this type.
Verizon, Netgear, Linksys, et al., are you paying attention? Dr. Sea at your service!
For a fee of course. 
Now... back to crafting some more pa'zaz and Bruce Lee into this sucker.
Have a great day guys!
@RagdogWhat say you Zen Master Ragdog? Is Sea ready to advance from purple belt & receive black belt now?
Greet'z & Happy new year!
@ShoorickThere we were talking about schooling...
Cheers my friend!
@XeSYou lil' devil!
Thanks for helping me debug this bad boy and updating my help system bro, you are the man! Plus its good to see someone like you around!
@JimGAhem... where are you Jim?
Is a certain game still calling you?
@VulPeCulaHow you doing man? XeS didn't blow your brain up did he?
No offense XeS. Just keeping things boyant and playful. @EveryoneYou can read more about RFC3164 here...
http://www.ietf.org/rfc/rfc3164.txtIf you want a really nice freeware SysLog daemon for debugging your own projects, or just watching your network devices, 3Com/USrobotics has one here...
http://support.3com.com/software/utilities_for_windows_32_bit.htmThere are some other utilities that may be of interest too.
Close Topic Options