- luv-main - luv.asn.au

IPSec over IPv6 - packet routing
by Jason White 17 Sep '11

17 Sep '11

I've raised this on the StrongSwan list over the last several weeks, but with no reply so far - hence I'm raising the question here as well to gain a broader audience. I have been experimenting with Strongswan as an implmentation of IKEv2 (my ultimate interest is also in its implementation of mobile IPv6, but that's not of immediate concern). If I set up an IPSec tunnel with StrongSwan 4.5.2 between my laptop and an external host (or a virtual machine and another host with a single network interface such as eth0) all appears to work; but my desktop machine has both eth0 and ppp0 interfaces. The tunnel appears to be established correctly on both sides and the IPSec policy appears to be correct, but my machine can't send packets over the tunnel. The kernel log contains messages regarding pmtu discovery, and packet monitoring shows that neighbour discovery packets are being sent out the eth0 interface rather than ppp0, i.e., if I try to ping the remote host over the tunnel, I get a lot of neighbour discovery packets on eth0, whereas the traffic needs to be routed through the ESP encapsulation to ppp0 and onward to the destination. Obviously I can provide much more detail; the main problem at this stage is how to bring the problem to the attention of someone who is familiar with Linux IPSec sufficiently to identify the cause. I may yet get a response on the strongSwan list, of course.

2 3

source the output of a file
by James Harper 17 Sep '11

17 Sep '11

I have a command that has output like: VAR1=A VAR2=B VAR3=C I want to execute that command in a shell script such that those statements are execute into my environment, so $VAR1 is now equal to 'A'. I can just put the output in a temporary file and then source that file, but is there a more direct way? Thanks James

2 2

iet or tgt?
by James Harper 17 Sep '11

17 Sep '11

Has anyone used iet or tgt and can comment on the performance? I am using iet at the moment because it's what I've used before and because tgt doesn't have 'iscsi' in the package name I missed it when I was first searching the Debian archives, but tgt seems to have a few features that might be nice. Thanks James

1 0

Re: [luv-main] Thank-You (Was: LUV lists; down-time and unsubscribe notice)
by Tony Langdon 16 Sep '11

16 Sep '11

At 07:29 PM 9/15/2011, Joel W Shea wrote: >On 15 September 2011 17:40, Peter Lieverdink ><me(a)cafuego.net> wrote: <...> > Earlier this >week LUVs mail server broke down and a current >backup of the list subscribers was not >available. As I setup new lists ysterday, I >temporarily used an older backup of list >subscribers to populate these new lists. > > >Today I rescued current subscriber data from the >old server and used that to populate the new >lists. Before I did that, I had to clear the >lists, and I forgot to make the system NOT send >notifications when doing that. You were all >(silently) re-subscribed approximately a minute >later. > I know this kind of work can usually go >underappreciated, so here's a big >THANKYOU!OU! > Apologies if I caused any >unnecessary freak-outs :-) If it weren't for >that, or the slight change in the domain in the headers; I think we'd barely Thank you for such a smooth changeover. If it wasn't for the change of domain and that little slip with the unsubscribe, I'd have not really noticed. Good job and much appreciated. :) 73 de VK3JED / VK3IRL http://vkradio.com

1 0

Thank-You (Was: LUV lists; down-time and unsubscribe notice)
by Joel W Shea 15 Sep '11

15 Sep '11

On 15 September 2011 17:40, Peter Lieverdink <me(a)cafuego.net> wrote: <...> > Earlier this week LUVs mail server broke down and a current backup of the list subscribers was not available. As I setup new lists ysterday, I temporarily used an older backup of list subscribers to populate these new lists. > > Today I rescued current subscriber data from the old server and used that to populate the new lists. Before I did that, I had to clear the lists, and I forgot to make the system NOT send notifications when doing that. You were all (silently) re-subscribed approximately a minute later. > I know this kind of work can usually go under–appreciated, so here's a big THANK–YOU! > Apologies if I caused any unnecessary freak-outs :-) If it weren't for that, or the slight change in the domain in the headers; I think we'd barely even notice there was an issue > The list archives are not yet available on the new system, but rest assured these archives were backed up properly and are not lost. You'll be notified when the come back online. Once again, thanks for the recovery effort. (Apologies to everyone for the slight cross-post) -- Joel Shea <jwshea(a)gmail.com>

4 3

Routing change handling in recent kernels.
by Deon George 15 Sep '11

15 Sep '11

I'm hoping somebody can help me understand what has changed in recent kernels, with regard to routing. I'm having a problem with Centos 6 hosts (and the same problem I had with a Ubuntu 10.10 host), that I dont have with Centos5 hosts. I can only conclude that its changes in IP handling that may have occurred with these later kernels. (Or changes in IP kernel configuration in these later distros?) I have this configuration: * Firewall Router eth0 10.10.3.1/26 PPOEServer (running over eth0) - handing out public addresses to pppoe clients * Centos 5 hosts (many) eth0 10.10.3.0/26 - (with a route 10/8 via this interface) ppp0 (running over eth0) - getting a A.B.C.x address (this is a public accessible address) * My laptop eth0/wlan0 10.10.3.128/26 (a different interface on the router) My laptop has been very successful in communicating with C5 hosts via eth0 address and ppp0 address. Specifically, on my laptop, when I connect to A.B.C.x, the packet arrives on the host on the ppp0 interface, and the reply goes out the eth0 interface (because of a default 10/8 route via that interface). Obviously if I talk to the host on its 10.10.3.0/26 address, the packet arrives and leaves via the eth0 interface. I implemented both Ubuntu 10.10 and Centos 6 servers with exactly the same configuration, ie: eth0 10.10.3.0/26 ppp0 (running over eth0) - getting A.B.C.x address However, I cannot talk to the hosts via the ppp0 interface, when I'm on a network that the reply would go via the eth0 interface. Specifically, if the packet arrives on the ppp0 interface and *would* leave via the eth0 interface, it appears as if the host is not even processing the packet. iptables confirms that it doesnt count the packets coming in. Chain INPUT (policy ACCEPT 0 packets, 0 bytes) pkts bytes target prot opt in out source destination 0 0 all -- ppp0 * 0.0.0.0/0 0.0.0.0/0 If I communicate with the host, where the packet arrives and leaves on the same interface - no problem. If I change my routing so that access to my laptop (10.10.10.128/26) is back via the ppp0 interface - then all is good (but not want I want) - if I access the host via its 10.10.3.0/26 address, then no problems either - again not really what I want. Here's some network tracing to show whats going on... (And yes, all this is done with firewall rules turned off - to make sure that there wasnt an offending rule) Here is what I see (if I ping the host via its A.B.C.x address from my laptop 10.10.3.130) Router (pppoes interface): 10:41:45.461588 IP 10.10.3.130 > A.B.C.28: ICMP echo request, id 38224, seq 1, length 64 10:41:46.461205 IP 10.10.3.130 > A.B.C.28: ICMP echo request, id 38224, seq 2, length 64 10:41:47.460768 IP 10.10.3.130 > A.B.C.28: ICMP echo request, id 38224, seq 3, length 64 10:41:48.461881 IP 10.10.3.130 > A.B.C.28: ICMP echo request, id 38224, seq 4, length 64 Host: (ppp0) (ICMP echo, but no reply) listening on ppp0, link-type LINUX_SLL (Linux cooked), capture size 65535 bytes 10:41:44.220727 IP 10.10.3.130 > A.B.C.28: ICMP echo request, id 38224, seq 1, length 64 10:41:45.219741 IP 10.10.3.130 > A.B.C.28: ICMP echo request, id 38224, seq 2, length 64 10:41:46.218733 IP 10.10.3.130 > A.B.C.28: ICMP echo request, id 38224, seq 3, length 64 10:41:47.219735 IP 10.10.3.130 > A.B.C.28: ICMP echo request, id 38224, seq 4, length 64 Host: (eth0) (only the PPPoE packets - no reply) listening on eth0, link-type EN10MB (Ethernet), capture size 65535 bytes 10:41:44.219726 PPPoE [ses 0x4b] IP 10.10.3.130 > A.B.C.28: ICMP echo request, id 38224, seq 1, length 64 10:41:45.219005 PPPoE [ses 0x4b] IP 10.10.3.130 > A.B.C.28: ICMP echo request, id 38224, seq 2, length 64 10:41:46.218227 PPPoE [ses 0x4b] IP 10.10.3.130 > A.B.C.28: ICMP echo request, id 38224, seq 3, length 64 10:41:47.218992 PPPoE [ses 0x4b] IP 10.10.3.130 > A.B.C.28: ICMP echo request, id 38224, seq 4, length 64 And for info, here's hosts routing table: 172.31.3.1 0.0.0.0 255.255.255.255 UH 0 0 0 ppp0 10.10.3.0 0.0.0.0 255.255.255.224 U 0 0 0 eth0 169.254.0.0 0.0.0.0 255.255.0.0 U 1002 0 0 eth0 10.0.0.0 10.10.3.1 255.0.0.0 UG 0 0 0 eth0 0.0.0.0 172.31.3.1 0.0.0.0 UG 0 0 0 ppp0 What's changed in the new kernels - or the new distro versions? ...deon

3 3

Re: [luv-main] You have been unsubscribed from the luv-main mailing list
by Rohan McLeod 15 Sep '11

15 Sep '11

luv-main-bounces(a)lists.luv.asn.au wrote: >Alright why ?; regards Rohan McLeod

7 7

Re: [luv-main] backkuppc and ZFS (was Re: Back ups)
by Craig Sanders 15 Sep '11

15 Sep '11

On Mon, Sep 12, 2011 at 01:20:19PM +1000, Jason White wrote: > Regarding ZFS, it is my impression that all of the people who > understand the internals of the file system and its implementation > are Sun/Solaris developers, some of whom may have left after the > acquisition by Oracle. I don't know what situation this creates as to > the availability of expertise (at the level of understanding the code > well enough to debug it) for projects porting it to BSD and Linux. many of them now work on the same code at Joyent or Nexenta and similar places. And it looks like they, through the Illumos community, will end up forking OpenSolaris (incl. ZFS and other solaris goodies) by default if Oracle doesn't start actively participating. LLNL, who are working on the zfsonlinux port, are also involved in the Illumos-centred ZFS development. Disclaimer: nothing past my first paragraph is "fact". it's just my 2c summary/interpretation of various things i've read on various web sites and mailing list archives. craig -- craig sanders <cas(a)taz.net.au> BOFH excuse #148: Insert coin for new game

3 2

list-id issue -- we have a change in list naming?
by Andrew McGlashan 15 Sep '11

15 Sep '11

Hi, I had anew message from the list (James Harper), but it didn't get to the right folders via my rules in my .forward -- this seems to be due to the List-Id head being different, possibly running over two lines? List-Id: "Main LUV community and support mailing list." <luv-main.lists.luv.asn.au> This from my .forward $h_List-Id: matches "luv-main.luv.asn.au" Hmm, okay it might not be multi-line issue, but still a change? luv-main.luv.asn.au luv-main.lists.luv.asn.au Are other lists changing this way? Was this an error? -- Kind Regards AndrewM Andrew McGlashan

7 9

Re: [luv-main] list-id issue -- we have a change in list naming?
by peren＠melbpc.org.au 15 Sep '11

15 Sep '11

Can you guys stop these excess LUV emails.. ? I was on the LUV list and got about 3-4 emails per week... OK.. Now its suddenly about 40 per day... Seems like something has gone astray with the email system... thanks Peter ----------------- > On Thu, 15 Sep 2011, Erik Christiansen <dvalin(a)internode.on.net> wrote: > > As craig suggested, it'd be very nifty, though, if we could lose the > > "[luv-main]" pollution in the Subject header. The plethora of list > > headers on which to filter, make it entirely redundant. > > Also mangling the subject breaks DKIM in almost all cases as the Subject is > signed in all typical configurations. Appending a footer doesn't necessarily > break things as the signer can use the l= flag. > > -- > My Main Blog http://etbe.coker.com.au/ > My Documents Blog http://doc.coker.com.au/ > _______________________________________________ > luv-main mailing list > luv-main(a)lists.luv.asn.au > http://lists.luv.asn.au/listinfo/luv-main Message sent using MelbPC WebMail Server

2 1