Wow, now I'm really confused. Custom compiled kernel and userspace on 2 different arm devices, with the same software, compiler, kernel series, etc. It is my understanding that the changes from armel to armhf are simply optimizations to provide better floating point math, and any code relating to these functions is simply slower on armel, not broken. Is that correct?by tufkal - Debian
javatmn Wrote: ------------------------------------------------------- > Frankly speaking I do not think it is related with > kernel oddity. It is more likely an application > bug. I did some debug on this issue by turning on > "-v" option on edge process. Without "-r", you can > always see error logs like "Discarding routed > packet....". Foby tufkal - Debian
Confirming Yong's findings, adding the -r option to edge makes things work on kirkwood rootfs! I did a fresh install of 3.18, did my script, and as expected it didn't work. Then I added the -r and it works. Now the -r option is only needed in N2N if you are using a node as a routing point. For example, if I wanted to connect two networks completely, I would put edge binaries onby tufkal - Debian
Bodhi: Created the new initramfs, no change :/ The module if definitely loading properly, and before the edge binary runs from rc.local. Gravel: The binary in the repo is very old, v1 of N2N, which is incompatible with the current version i'm using. Is there a possibility in the architecture being the problem? I did this exact process on a RPi last night, but as you pointed outby tufkal - Debian
bodhi Wrote: ------------------------------------------------------- > tufkal, > > > As long as the kernel has the tun.ko driver > > enabled or as a module, the binary takes care > of > > the rest. > > Based on what you mentioned above and everybody's > suggestions: > > - On a fresh 3.18.5-kirkwood-tld-1 rootfs > - Add tun module tby tufkal - Debian
Gravelrash Wrote: ------------------------------------------------------- > @tufkal > the output you gave from the commands i listed > above, looks like i would expect from a standard > output.... > > and i think one of your comments earlier may > have hit the nail on the head. > > "As long as the kernel has the tun.ko driver > enabled or as a moduby tufkal - Debian
The other boxes have no special routing, no iptables even installed, and were given the same script on first boot. You can go ahead and install wheezy on VM or baremetal and setup a working N2N node without any change to the network setup or routing. No package installs, no IP settings, hell I didnt even change resolv.conf. Almost every one of them has it's main interface in default DHCP,by tufkal - Debian
Almaz Wrote: ------------------------------------------------------- > The answer is in this thread. I assume you got it working by installing bridge-utils, and bridging your interfaces. That's not how N2N works. If that's how you did it, it's a routing workaround. I have 7 other devices that don't even have that package (or even iptables in some cases) installed,by tufkal - Debian
OK, well I'm going to put a fresh rootfs on mine, can you outline what steps you took that are different from mine? I literally run that script I listed above on first boot, and then reboot. What steps do you take differently? And thanks for taking the time to try it on your hardware to help me figure it out, I appreciate it!by tufkal - Debian
Gravel, I will post your request in a sec: Just noticed this. I went to bed last night frustrated, and didn't stop some of my tcpdump and pings, and this morning I found something interesting. It's not that traffic is not being sent out of the kirkwood device, it is being sent out with a MASSIVE delay. On the tcpdump for the working laptop node, I saw a bunch of ping requests fromby tufkal - Debian
OK so another multiple hour session beating my head on this, and heres what I got. I did traffic back and forth from 2 brand new N2N nodes, one the kirkwood devices with bodhi's rootfs, and one my laptop with wheezy. As before, neither one could ping each other, but both show that they see each other on the ARP table. Using tcpdump I can now also report that the kirkwood device receivby tufkal - Debian
bodhi Wrote: ------------------------------------------------------- > @tufkal, > > Even though the kernel config is mostly the same > between mainline Debianwheezy and my config, I > think you've probly overlooked this point: if you > install from mainline, there are a lot of default > configurations settings were done by that process. > When you install aby tufkal - Debian
Ugh...i was hoping to avoid packet sniffing and going through pages of log files. tcpdump here I come I guess~ As to the comment on VM knowledge, I apolagize. I had just spent 5+ hours debugging this problem and I was cranky. I knew it couldn't be something that a VM would affect because I knew I wasn't routing or using iptables etc etc (which is now explained). I retract thatby tufkal - Debian
You guys are assuming I am bridging and creating an actual VPN with N2N. I am not. Each device can only contact other devices in the same /24, and can't connect to other devices on any other nodes network. It is a very simple setup, that I run on each machine I own (and several small machines in remote locations for backup). Iptables is not required, as no routing is done. My iptables -by tufkal - Debian
No luck on adding those sysctl options, the N2N binaries set those when it is run. I compared /proc/sys/net/ipv4/conf/*, and each setting is the same. I just did a wheezy install on a VM on my main desktop, and from the first boot I went through the same procedure. It worked fine. So it works on a fresh Debian in VM, and a fresh Raspbian on RPi. The process I follow goes like this:by tufkal - Debian
As requested by Bodhi on the kernel thread, I'm going to make a separate topic to unclutter that thread. I recently setup a Seagate DockStar with the 3.16 rootfs and latest Uboot. Everything is working fine on it, but have run into a potential limit of the kernel (or my understanding of the process). I have setup several "offsite sync" boxes in the past, using a Raspberry Piby tufkal - Debian