The latest version of this application is required for use of the tunnelbroker. Please make an ebuild of the latest version (2.1). Reproducible: Always Steps to Reproduce:
Created attachment 39704 [details] Proposed ebuild for version 2.1 It install tspc correctly, but the templates are broken. Only working mode is anonymous with the linux template. Please fix, perl ain't my thing.
*** Bug 64198 has been marked as a duplicate of this bug. ***
Created attachment 44763 [details] ebuild/digest/files/Changlog and stuff for tspc 2.1.1 this is a tar.bz2 file with net-misc/freenet6/ net-misc/freenet6/files/ net-misc/freenet6/files/tspc.conf net-misc/freenet6/files/digest-freenet6-2.1.1 net-misc/freenet6/files/tspc.rc net-misc/freenet6/freenet6-2.1.1.ebuild net-misc/freenet6/Manifest net-misc/freenet6/ChangeLog net-misc/freenet6/files/tspc.rc is exact the same from 1.0.0 and seens to work fine gentoo.sh needs update, will make it later (i hope)
Comment on attachment 44763 [details] ebuild/digest/files/Changlog and stuff for tspc 2.1.1 i've changed tspc.rc to let things..hmm.. pretty ;) start() { ebegin "Starting Freenet6 IPv6 Client" #wait some things settle down sleep 3 tspc -f /etc/freenet6/tspc.conf > /dev/null 2>&1 eend $? }
Created attachment 45803 [details] the so called gentoo.sh this is it.. sorry the delay.. all work and no play makes wolvie dull doy it works for me (just /whois wolvie at freenode ;p) but seens that i'm the only one using this package ;p
Created attachment 46100 [details] freenet6 client ebuild/manifest/digest/stuff ok, last try, everything is running nice and clean. init script fixed, gentoo.sh fixed, added support to radvd, added ewarn/einfo to the ebuild about changes.. well take a look at the changelog.. if someone is looking at this please give some feedback since aparently this package is abandoned.. -=;o/
i recently tried out this ebuild works ok i did change a couple items from what was attached last ill attach updated ebuild one thing i noticed but didnt look into yet dunno if its a problem or not is when tspc is brought down sit0 it ups was left still around and radvd was still loaded
Created attachment 48699 [details] freenet6-2.1.1.ebuild changed sed lines to use 1 sed instead of 2 and installed the sample config script that it generates note: sed prob needs to be ran on it to change the one path it makes that has the portage temp dir in it the einfo and ewarn items could prob stand to be updated they look to be out of date
The 2.1.1 ebuild worked great for me. The only issue is that the path in tspc.conf needed to be changed to /etc/freenet6
I just finished a very similar ebuild not realizing one had shown up on bugs.g.o Notes: tspc is now gpl2 and the homepage is now http://www.hexago.com
oh, and an additional note, I've emailed the developer of tspc, and he's agreed to keep 2 old versions in the same location on the server so that version bumps can exist happily as unstable ebuilds while old stable ones continue to work. Their policy had been to remove old versions to an archive.
Created attachment 50687 [details] another try.. License changed to GPL-2 Sugest the router Local USE Flag which trace dependencies to net-misc/radvd correct keyword to ~x86
The 2005-02-07 ebuild works great. Any idea when we can get this in portage?
Retrieved the tarball labelled "freenet6 client ebiuld/manifest/digest/stuff" and the ebuild labelled "another try..". Build worked fine, but I encountered the following problems when using tspc, the first two of which are probably tspc bugs rather than probs with the ebuild(?): * tspc always annoyingly places tspc.log into the current dir, I failed to find an option to specify a location * needed to add these to gentoo.sh: TSP_HOST_TYPE=router TSP_HOME_INTERFACE=eth0 of course, that's only a hack...printenv|logger showed these vars were not set * tspc.conf has template=linux in it, instead of template=gentoo * another hack: needed to change (in the router config part) Exec $ifconfig $TSP_HOME_INTERFACE add $TSP_PREFIX::1/64 to $ifconfig $TSP_HOME_INTERFACE add $TSP_PREFIX::1/64 because otherwise ifconfig would fail with SIOCSIFADDR: File exists. This may not be a problem when tspc is started at boot only, but when it's restarted it results in radvd not being started again (with the Exec in place) and that's a problem for people like me who are unfortunate enough to forcefully get a new IPv4 address every 24 hours, so tspc has to be re-run from pppd's ip-up script. This one is weird...ifconfig's output as used to set OLDADDR does *not* list the global address, but ip does: $ /sbin/ifconfig eth0 eth0 Link encap:Ethernet HWaddr 00:80:C8:D7:FE:1B inet addr:172.16.0.1 Bcast:172.16.0.255 Mask:255.255.255.0 inet6 addr: fe80::280:c8ff:fed7:fe1b/64 Scope:Link UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1 [snip, no more addresses follow] $ /sbin/ip addr show dev eth0 2: eth0: <BROADCAST,MULTICAST,UP> mtu 1500 qdisc pfifo_fast qlen 1000 link/ether 00:80:c8:d7:fe:1b brd ff:ff:ff:ff:ff:ff [snip lots of IPv4 addresses] inet6 2001:5c0:8799::1/64 scope global valid_lft forever preferred_lft forever inet6 fe80::280:c8ff:fed7:fe1b/64 scope link valid_lft forever preferred_lft forever Why not use the more versatile ip instead of ifconfig anyway? * This isn't generic either, but maybe some generic version should be added? /etc/init.d/tspc: commented out the sleep in start(). Okay, that's just to avoid the annoying wait, what exactly is it there for, the comment "wait some things settle down" isn't exactly precise ;-) commented out this one in stop() (tspc exits after the tunnel setup) # kill `pidof tspc` and added these for cleanup: if [ -f /var/run/radvd/radvd.pid ]; then /etc/init.d/radvd stop fi /sbin/ip link set sit1 down NB: the last command downs the tunnel, but /sbin/ip link show still lists it, is there a way to completely *remove* an interface?
Sorry, the necessity for TSP_HOST_TYPE=router TSP_HOME_INTERFACE=eth0 turned out to be my fault, I had set the prefixlen to 64 instead of 48 (misinterpreted the comment in tspc.conf about that value). With that changed, I actually get IPv6 connectivity from machines on the LAN other than the gateway :-) Cheers, Malte
Created attachment 55328 [details] My attempt to fix those issues Here's my go at it. I think it's reasonable to depend on iproute2 for something that has to do with IPv6 setup... Comments welcome :-)
Created attachment 55329 [details] route => ip route And given the dependency on /sbin/ip is there, this one gets rid of /sbin/route as well. Everything seems to work fine now, expect maybe stop() in tspc.rc should also remove the routes again?
*** Bug 94398 has been marked as a duplicate of this bug. ***
I installed tspc with the "My attempt to fix those issues" and "route => ip route" attachments. After I removed the "dns" dependency in the init script, it started right up and I had IPv6 connectivity. So far it is working ok. It would be nice to get that tspc.log moved into /var/log rather than sitting in /, though. Thanks for the ebuild!
Working great here too. Similarly, I removed the "dns" dependency in the /etc/init/tspc file and it's all good now. Only thing - and this may be out of scope here - I can't seem to get iptables to filter packets on a tun interface that provides v6udpv4 tunnelling to freenet6. Anyone else seeing this?
I've made a small ebuild and made some changes to the init script and added a "keepalive script" (since tspc has a tendency to die on me :/) it should work (works for me any way, so I figured I better see if it works for anyone else before doing something like trying to make an ebuild+patches (and possibly some use flag for the keep-alive) which makes installing it as easy as 'emerge freenet6') Download this tarball: http://student.stunet.se/scientica/tspc/tspc_rfc.tbz2 * unpack it somewhere (you can unpack it to / if you for some odd reason trust me more than I do my self - in other words: *don't unpack to /* even if that should work!) * put the ebuild ( usr/local/portage/net-freenet6/freenet6-2.1.1.ebuild ) in your portage overlay and digest it. * emerge -av freenet6 * cp/mv the 2 init scripts in etc/init.d (tspc and tspc.keepalive) to /etc/init.d * cp/mv the config file etc/conf.d/tspc.keepalive /etc/init.d (you might want to change the settings, even if the default settings should be ok) * Make the changes in your tspc config ( /etc/freenet6/tspc.conf ) if you got a username and pw or other settings to touch. * rc-update -a tspc default && rc-update -a tspc.keepalive default * /etc/init.d/tspc start && /etc/init.d/tspc.keepalive start TODO: * change the stop() in tspc to either invoke 'tspc.keepalive stop' or remove the lockfile. (I guess 'tspc stop' should implicity call 'tspc.keepalive stop' since tspc.keepalive depends on tspc, haven't tested yet) * possibly merge tspc.keepalive to tspc and make the tspc.keepalive config be config for the tspc init rc. This is sort of an RFC(request for comments) as the tarball name implies, so, constructive criticts are welcome - I know it's a sub optimal solution, and that I probably missuse /var/lock for holding a file I really should put somewhere else (if you know where the "right" place is, please enlight me). btw, some info: arch = amd64 stage = 1 kernel = 2.6.14-ck4 in the tspc.conf: template=gentoo (btw, I don't really care for the possible licensing, I only want it to be open, and I guess/assume/hope all this falls under GPL -- "I'm a hologram not a lawyer" ;) and just fyi (or -e s/y/'anyone who bothers'/), I'm going afk for the weekend, so don't expect an replies before earliest monday.
(In reply to comment #21) uhm... seems something has changed... I tried to get it to work on my brothers machine (fresh install), and I had to emerge the old freenet6 (1.0.0) and then emerge my overlay - other wise the gentoo-template and config file (/etc/freenet6/tspc.conf) wasn't created, and the config file that was created loos very different from mine which was created by an old version of frenet6, or if it was from the official tarball (long time ago), (ie I had to add something like 'tunnel_mode=v6anyv4'). Also the server was set to a wrong value.
Good, good.. That ebuild is now there and working for more than a year but still not in portage tree. I even made one myself thinking no one was still working on it. Come on guys!! Move on! I can submit mine if you want.
uberlord: this may be up your alley with networking stuff.
I'm taking over this package, so I'll be looking into these bugs.
*** Bug 105348 has been marked as a duplicate of this bug. ***
I'm currently working on a new 4.1 ebuild, so all of the problems with freenet6 should be fixed, soon. I hadn't realized that this ended up becoming abandoned, or I would have picked it up a long time ago.
*** Bug 143771 has been marked as a duplicate of this bug. ***
Created attachment 97604 [details] freenet6-4.1.ebuild Not the best, but better than not working!
Created attachment 97606 [details] tspc.rc-4.1 And that goes in the files
I'm aware the fetch URL is kind of bad, and the src_install part uses much mkdir/rm/mv stuff, but this ebuild has been waiting for too long, I had to revive it, from version 2.1.1 to 4.1 and no activity.. well, at least that one works-for-me (TM) :)
Created attachment 104294 [details, diff] TSP Gateway6 4.2.2 Source Code http://www.go6.net/4105/download.asp Client from freenet TSP Gateway6 4.2.2 Source Code will need ebuild ajusted
*** Bug 165244 has been marked as a duplicate of this bug. ***
Created attachment 109100 [details] freenet6-4.2.2 Ebuild for the last version. It's not fantastic but it works..the package isn't updated since 2003! I think that we shouldn't rename config files and bin files. The name is "gw6c" not "tspc"...if we rename them we could get confused someone who worked without the ebuild. Problem: SCR_URI is set temporary to my server since the official site has file.asp?something...that portage doesn't like.
Created attachment 109101 [details] freenet6-4.2.2 rc file The startup script, must be put into /files
Created attachment 109103 [details] freenet6-4.2.2 modified config file (also put in /files) The original config file with the path changed according to /etc/freenet6
This 4.2.2 ebuild works fine here on ~amd64 If the new names for init script and configuration file are kept, this should be detailled in the postinstall informations
Maybe we need a new maintainer for the bug and the package ? Last Steinar's post is from end 2004 ... of course I would not enjoy reassigning to "maintainer wanted" ... but it seems that is our case, thats what should be done. We need a maint to merge ebuild in portage; we need a maint who do things !
Version 4.2.2 finally made in portage (only ~amd64 and ~x86 for now), thanks everyone for your patience