Re: ANNOUNCE: Enhanced IP v1.4
Hello Willy, netdev, Thank you for your reply and advice. I couldn't agree more with you about containers and the exciting prospects there, as well as the ADSL scenario you mention. As far as application examples, check out this simple netcat-like program I use for testing: https://github.com/EnIP/enhancedip/blob/master/userspace/netcat/netcat.c Lines 61-67 show how to connect directly via an EnIP address. The netcat-like application uses a header file called eip.h. You can look at it here: https://github.com/EnIP/enhancedip/blob/master/userspace/include/eip.h EnIP makes use of IPv6 records for DNS lookup. We simply put 2001:0101 (which is an IPv6 experimental prefix) and then we put the 64-bit EnIP address into the next 8 bytes of the address. The remaining bytes are set to zero. In the kernel, if you want to see how we convert the IPv6 DNS lookup into something connect() can manage, check out the add_enhanced_ip() routine found here: https://github.com/EnIP/enhancedip/blob/master/kernel/4.9.28/socket.c The reason we had to do changes for openssh and not other applications (that use DNS) is openssh has a check to see if the socket is using IP options. If the socket does, sshd drops the connection. I had to work around that to get openssh working with EnIP. The result: if you want to connect the netcat-like program with IP addresses you'll end up doing something like the example above. If you're using DNS (getaddrinfo) to connect(), it should just work (except for sshd as noted). Here's the draft experimental RFC: https://tools.ietf.org/html/draft-chimiak-enhanced-ipv4-03 I'll also note that I am doing this code part time as a hobby for a long time so I appreciate your help and support. It would be really great if the kernel community decided to pick this up, but if it's not a reality please let me know soonest so I can move on to a different hobby. :) Thank you. Sam Patton On 6/2/18 1:57 AM, Willy Tarreau wrote: > Hello Sam, > > On Fri, Jun 01, 2018 at 09:48:28PM -0400, Sam Patton wrote: >> Hello! >> >> If you do not know what Enhanced IP is, read this post on netdev first: >> >> https://www.spinics.net/lists/netdev/msg327242.html >> >> >> The Enhanced IP project presents: >> >> Enhanced IP v1.4 >> >> The Enhanced IP (EnIP) code has been updated. It now builds with OpenWRT >> barrier breaker (for 148 different devices). We've been testing with the >> Western Digital N600 and N750 wireless home routers. > (...) First note, please think about breaking your lines if you want your > mails to be read by the widest audience, as for some of us here, reading > lines wider than a terminal is really annoying, and often not considered > worth spending time on them considering there are so many easier ones > left to read. > >> Interested in seeing Enhanced IP in the Linux kernel, read on. Not >> interested in seeing Enhanced IP in the Linux kernel read on. > (...) > > So I personally find the concept quite interesting. It reminds me of the > previous IPv5/IPv7/IPv8 initiatives, which in my opinion were a bit hopeless. > Here the fact that you decide to consider the IPv4 address as a network opens > new perspectives. For containerized environments it could be considered that > each server, with one IPv4, can host 2^32 guests and that NAT is not needed > anymore for example. It could also open the possibility that enthousiasts > can more easily host some services at home behind their ADSL line without > having to run on strange ports. > > However I think your approach is not the most efficient to encourage adoption. > It's important to understand that there will be little incentive for people > to patch their kernels to run some code if they don't have the applications > on top of it. The kernel is not the end goal for most users, the kernel is > just the lower layer needed to run applications on top. I looked at your site > and the github repo, and all I could find was a pre-patched openssh, no simple > explanation of what to change in an application. > > What you need to do first is to *explain* how to modify userland applications > to support En-IP, provide an echo server and show the parts which have to be > changed. Write a simple client and do the same. Provide your changes to > existing programs as patches, not as pre-patched code. This way anyone can > use your patches on top of other versions, and can use these patches to > understand what has to be modified in their applications. > > Once applications are easy to patch, the incentive to install patched kernels > everywhere will be higher. For many enthousiasts, knowing that they only have > to modify the ADSL router to automatically make their inter
ANNOUNCE: Enhanced IP v1.4
Hello! If you do not know what Enhanced IP is, read this post on netdev first: https://www.spinics.net/lists/netdev/msg327242.html The Enhanced IP project presents: Enhanced IP v1.4 The Enhanced IP (EnIP) code has been updated. It now builds with OpenWRT barrier breaker (for 148 different devices). We've been testing with the Western Digital N600 and N750 wireless home routers. Interested in seeing Enhanced IP in the Linux kernel, read on. Not interested in seeing Enhanced IP in the Linux kernel read on. Here's the value proposition: if the Internet community wants to pass IP option 26 in the fast path (a scriptable single command enables this for Juniper and Cisco ISPs). Because this is easier than repeering globally(IPv6), this could in a relatively short period of time become a wide-spread option for use of IP option 26 WAN support. Further, for experimentation to begin with EnIP, it is not necessary for IP option 26 to be passed in the fast path. Quickly enabling WAN support is something IPv6 cannot do. Yes, NATs have to be upgraded. This is not optimal.All that being said, the protocol is much much simpler to understand than IPv6. It is an evolution (similar to how CIDR and NAT became pervasive over time in the 1990's). We have a lot of users who want to try the technology out but most of them are not patch your kernel kinds of people. It would work a lot better if Enhanced IP was an option available in standard kernels. We are new to the Linux kernel community and would take advice on the code. If you look at our repository you will find that every file we update has a comment with the phrase "enhanced ip" so it is easy to see where we have made changes. We are maintaining separate patches across five kernels at the moment. Each new kernel requires a seperate porting process. It takes 30 minutes-1 hour to get all the patch points reinstalled and a little more time to test. We are especially interested in ideas people might have about integrating Enhanced IP with the IPv4 icmp code. I have been able to shim the rest of the code into the existing tcp/udp/ipv4 code base without much trouble. However, the icmp code is a different animal and I would welcome help from another developer(e.g. code patches). At present you can do tcp and udp sockets only. If a message such as an icmp port unreachable needs to be sent to an EnIP address it does not work. We are also working on the process by which we will accept patches to EnIP. We were thinking about adopting the OpenWRT process but would certainly be willing to listen to other arguments based on experience. Enhanced IP is a hobby project, so we're not looking to come up with our own process. Rather, we would happily adopt a simple/terse process. We've used Apache, samba, and ssh/scp over EnIP. Basically, anything that uses getaddrinfo followed by connect should work fine. E.g. we think all the code that has already been ported to use getaddrinfo pattern for IPv6 compatibility should also work with EnIP. Our web site: http://www.enhancedip.org/ Our git: git clone https://github.com/EnIP/enhancedip.git Our test virtual machines (write kernel code with VMs to simulate end to end EnIP connections): http://www.enhancedip.org/ENIP/ Thank you for your time. -Sam Patton
BUG: netfilter hooks: problems porting to 4.4.6
Did something change in Netfilter on the 4.4.6 kernel that would affect my
Netfilter hook driver? I have a driver that works in 2.6.38, 3.10.49 and
3.15.3. I started porting the driver to the 4.4.6 kernel and
can't get it to work. Specifically, apply_eip_snat() in the driver never gets
called and it should get called as packets leave the NAT. The
print statement below where I print out maniptype is always returning 1.
e.g. NF_NAT_MANIP_DST.
Here's my iptables command:
iptables -t nat -A POSTROUTING -o eth0 -j MASQUERADE
Here's relevant code snippets.
static struct nf_hook_ops nf_nat_ops[] __read_mostly = {
// Before packet filtering, change destination
{
.hook = nf_eipnat_in,
.owner = THIS_MODULE,
.pf = PF_INET,
.hooknum= NF_INET_PRE_ROUTING,
.priority = NF_IP_PRI_NAT_DST,
},
// After packet filtering, change source
{
.hook = nf_eipnat_out,
.owner = THIS_MODULE,
.pf = PF_INET,
.hooknum= NF_INET_POST_ROUTING,
.priority = NF_IP_PRI_NAT_SRC,
},
};
nf_eipnat_in(unsigned int hooknum,
struct sk_buff *skb,
const struct net_device *in,
const struct net_device *out,
int (*okfn)(struct sk_buff *))
{
printk("nf_eipnat_in\n");
return nf_nat_fn("dnat in prerouting", hooknum, skb, in, out, okfn);
}
static unsigned int
nf_eipnat_out(unsigned int hooknum,
struct sk_buff *skb,
const struct net_device *in,
const struct net_device *out,
int (*okfn)(struct sk_buff *))
{
printk("nf_eipnat_out\n");
return nf_nat_fn("snat out postrouting", hooknum, skb, in, out, okfn);
}
static unsigned int
nf_nat_fn(char *instring,
unsigned int hooknum,
struct sk_buff *skb,
const struct net_device *in,
const struct net_device *out,
int (*okfn)(struct sk_buff *))
{
unsigned int retval = 0;
/* maniptype == SRC for postrouting. */
enum nf_nat_manip_type maniptype = HOOK2MANIP(hooknum);
printk("maniptype = %d\n", maniptype);
/* We never see fragments: conntrack defrags on pre-routing
and local-out, and nf_nat_out protects post-routing. */
NF_CT_ASSERT(!(ip_hdr(skb)->frag_off & htons(IP_MF | IP_OFFSET)));
//printskb(instring, skb, in, out);
if(maniptype == NF_NAT_MANIP_DST){
retval = apply_eip_dnat(in, skb);
}
else{
retval = apply_eip_snat(out, skb);
}
return retval;
}
Thanks!
-Sam
