Share

More
Transparent Mobile IP Icon

Transparent Mobile IP

alpha

by slysimon


This project aims to provide IP mobility across multiple networks, ensuring that all active TCP sessions will be maintained upon migration. No client side software or alteration to IP stack is required. The network itself changes to provide connectivity.


http://www.slyware.com/projects_tmip.shtml





Separate each tag with a space.

Release Date:

2003-06-16

Topics:

License:

Ratings and Reviews

Be the first to post a text review of Transparent Mobile IP. Rate and review a project by clicking thumbs up or thumbs down in the right column.

Project Feed

  • Code committed

    slysimon committed patchset 14 of module tmipcore to the Transparent Mobile IP CVS repository, changing 103 files

    posted by slysimon 2128 days ago

  • Code committed

    slysimon committed patchset 13 of module tmipcore to the Transparent Mobile IP CVS repository, changing 103 files

    posted by slysimon 2128 days ago

  • TMip future development

    Unfortunately, due to moving house and starting a new job, I have been unable to work on this project since the summer. However, I plan to resolve this in the near future! The aim is to take the current 0.5a alpha version and push for a stable beta version, as the majority of the primary features are now present. Details will appear later. If you would like to get involved in the development or testing of TMip, please contact me! (sly@slyware.com)

    posted by slysimon 2153 days ago

  • Developmental version 0.5a

    I have made some significant changes to TMip over the past month or so. The major changes are support for multiple mobile interfaces per CN (within the same tmipd instance), and upstream route multiplexing. The latter enables TMip to route/tunnel upstream traffic from mobile clients to specific gateways/CNs (on a per client basis). This allows clients to maintain the same default route off a network (very important if the gateways are running NAT for example). Note that this is an early developmental release! I hope to put up a real release soonish. Download the archive using the following URL: http://www.slyware.com/downloads/tmip/tmipcore_0.5a-pre.tar.gz

    posted by slysimon 2308 days ago

  • Code committed

    slysimon committed patchset 12 of module tmipcore to the Transparent Mobile IP CVS repository, changing 11 files

    posted by slysimon 2337 days ago

  • TMip v0.14a released..

    A few bug fixes and feature enhancements. Includes ability to send HUP/USR1/USR2 signals to control both the MLR and CNs.

    posted by slysimon 2337 days ago

  • File released: /tmip/TMip Alpha 0.14a/tmip_0.14a_release.tar.gz

    posted 2337 days ago

  • tmip TMip Alpha 0.14a file released: tmip_0.14a_release.tar.gz

    v0.14a: (16/06/2003) - Bug fixes & minor features - Fixed a bug when using more than one CN per physical node. The same tunnel names were being used for every instance of tmipd, hence they end up deleting each others tunnels! So, I've added a 'tunnel_prefix' option to tmipd.rc, and each CN should define it's own UNIQUE string for this. It will simply get appended onto the front of the tunnel name. The default is 'tmip'. - Note that the default setting for 'purge_tunnels' has changed, it now defaults to true. - MLRCache now uses an exclusive read lock to protect iterations through the host cache. - Changed the MLRCache poll to 5 seconds (how often it checks for timed out hosts). - Added configuration options to the CN and MLR - 'status_file': See below. - 'log': Specifies whether logging will occur. Used with 'log_file'. Useful if you want to HUP a process to stop it from logging to file. - Both the MLR and the CN support various user signals to control them. - CN: - Send it SIGHUP and it will reread its configuration file in. Note that not all the options will be reread, see tmipd.rc for details. - Send it SIGUSR1 and it will cause tmipd to write out its internal state (i.e. mobile client lists) to the file specified by the 'status_file' option. This can also be achieved by typing 'status' at the interactive prompt. - Send it SIGUSR2 and it will cause tmipd to resynchronise with the MLR. This has the same effect as shutting down tmipd, then restarting it. This can also be achieved by typing 'resync' at the interactive prompt. - MLR - Send it SIGHUP and it will reread its configuration file in. Note that not all the options will be reread, see mlrd.rc for details. - Send it SIGUSR1 and it will cause mlrd to write out its internal state (i.e. all registered clients) to the file specified by the 'status_file' option. This can also be achieved by typing 'status' at the interactive prompt. - Send it SIGUSR2 and it will cause mlrd to clear out all dynamic mobile host records. - When sending HUP to the MLR or tmipd applications, it allows you to change both whether logging is occuring (log and log_file options), and the debug level. Note that you can change the location of the log file whilst it is running. - Sorted out error reporting and generally made mlrd and tmipd a bit easier to debug. When they are in daemon mode, they will output on the initial standard out any generated warnings as well as adding to the log file (if being used) on startup. This means you should be informed of any problems whilst bringing up the MLR/TMipd without having to tail the log file. Also made the warnings a bit more useful! - Made the 'addr_pool' command for the CNs a bit more sane. As well as the old form, you can now specify 'addr_pool eth0 * +0.0.0.32', which will allocate the first eight client subnets, starting from one client subnet in from the network address of eth0. Note that 'addr_pool eth0 * 0.0.0.32' is the same as 'addr_pool eth0 * -0.0.0.32', allocting up to the last eight client subnets before the broadcast address of eth0. Also fixed a few bugs so you can't allocate more address space than you have :-) - Changes the LinuxStdTunnelMan class so that it now uses purely ioctl commands to set up the tunnels, rather than nasty system() type commands!

    posted 2338 days ago

  • Major bug fix in relation to multiple CNs per host

    I've just fixed a bug that occurs when using more than one CN per physical node. Previously, the same tunnel names were being used for every instance of tmipd, hence they end up deleting each others tunnels! So, I've added a 'tunnel_prefix' option to tmipd.rc, and each CN on a single node should define it's own UNIQUE string for this. This will simply get appended onto the front of the tunnel name. The default is 'tmip'. Note that also the default setting for 'purge_tunnels' has changed, it now defaults to true. The fixed version is in CVS, tmipcore module, version 0.13a-cvs.

    posted by slysimon 2345 days ago

  • Code committed

    slysimon committed patchset 11 of module tmipcore to the Transparent Mobile IP CVS repository, changing 10 files

    posted by slysimon 2345 days ago

Rate and Review

Be the first person to add a text review.

Would you recommend this project?






<

Related Projects

Transparent Mobile IP Actions

Thanks for your rating!

Would you also like to write a review?





Skip Review