why abandom -r parameters but not support n2n-router tools on windows??what should I do to add router on windows? Raw command??

[galaxyskyknight]

Hello

I have upgraded to latest code and compiled it on windows and now I find the n2n binary has abandomed the '-r' parameter to allow me adding the static routes on windows any more, and it prompts I can use 'n2n-router' tools to do that, however, what makes me very disappointed is when I run this n2n-router tools, it says only support on Linux? I am very puzzled how it could be a feature so easily removed and make a very important change to break some basic function like adding routes for a peer 2 peer vpn software but non plan B for user's choise? This is totally destroyed my senario of usage on windows platform: run the n2n binary and specificy all static routes via '-r' option to all edge peers‘ subnets run on different sites via a '.bat' batch script in one shot on a windows cmd admin terminal.

In one word, I am very suprised the point of your consideration and decesion made on legacy features looks like taking none priority of its continuity and os platform compatibility/continuity which to me is hard to be understandable.... I understand to reduce the application size and ligth weigh it and get more focus on the P2P core function itself is proper way and good, but it should not stand at cost of breaking any current working function or OS compatibility, right? Or you should migrate it after there is an alternative solution but not deploy directly by breaking or deprecate other functions/OS compatiblity etc w/o any fully covered solution or you totally count on the common user to find out the way in source code... After all, not everyone has the skillset to dig it out from the source code.

[galaxyskyknight]

I do this in the past with one shot .bat file and the console will be like this, and now, it doesn't work any more:

[Logan007]

Hi there,

first of all, please keep in mind that we are talking about dev and not stable.

why abandom -r parameters ...

We are and will be removing all non-core functionalities from the core (speed, lightweightness, accessibility for debugging...). So, we only keep essential features in the core daemon. This includes setting system routes. The routing tool shall replace it.

... but not support n2n-router tools on windows?

The routing API on Windows is different from the Linux part, so the coding part is different.

On Windows, n2n was not able to specify dynamic routes before (which is the main intent of the new routing tool). As you mentioned, it only was for static cli-provided routes. And for that, the edge actually called the Windows command line route command, something we want to avoid.

what should I do to add router on windows? Raw command??

Indeed. Until the Windows implementation of n2n-route tool shows up, it would be the intermediate way to go. In your case, you could just add the command lines from n2n log output to your .bat file: route add ... > nul.

[galaxyskyknight]

Hi there,

first of all, please keep in mind that we are talking about dev and not stable.

why abandom -r parameters ...

We are and will be removing all non-core functionalities from the core (speed, lightweightness, accessibility for debugging...). So, we only keep essential features in the core daemon. This includes setting system routes. The routing tool shall replace it.

... but not support n2n-router tools on windows?

The routing API on Windows is different from the Linux part, so the coding part is different.

On Windows, n2n was not able to specify dynamic routes before (which is the main intent of the new routing tool). As you mentioned, it only was for static cli-provided routes. And for that, the edge actually called the Windows command line route command, something we want to avoid.

what should I do to add router on windows? Raw command??

Indeed. Until the Windows implementation of n2n-route tool shows up, it would be the intermediate way to go. In your case, you could just add the command lines from n2n log output to your .bat file: route add ... > nul.

OK, so I have to be stopped at the commit on '-r' option deprecated before you have a new solution for windows platform.

[Logan007]

Any volunteers to test #1023 on Windows?

[galaxyskyknight]

Any volunteers to test #1023 on Windows?

Will try it on next Monday, thanks

[galaxyskyknight]

I tried to compile your winRoute branch and run the n2n-route tools, however, it require to connect to local edge management port? it prompts the socket problem, but obiously the local edge port 5644 is open becoz I can use NC to connect it. see the snapshot, let me know if there is any tricky? thanks @Logan007

[Logan007]

Thank you for testing.

No, no special trick. It turns out that Windows seems to need special network initialization which I have just added to the code.

This works much better in my meanwhile restored Windows VM. I also see that route commands are issued (use -vvv to see them), but it seems that they are not really effective? Can anyone confirm if there is anything wrong with the issued route commands?

[galaxyskyknight]

Thank you for testing.

No, no special trick. It turns out that Windows seems to need special network initialization which I have just added to the code.

This works much better in my meanwhile restored Windows VM. I also see that route commands are issued (use -vvv to see them), but it seems that they are not really effective? Can anyone confirm if there is anything wrong with the issued route commands?

Tested, indeed not effect. there is no route added with my issued subnet and gate way when using 'route print' to check in command line. What's the different impl here comparing from the code which used before? Have you previously scratched and assigned the proper TAP/TUN virtual network adapter interface index(Ifidx) present on windows which the edge used to the program for attaching the route?

[Logan007]

here is no route added with my issued subnet and gate way when using 'route print' to check in command line.

I see some routes added by the tool ...

What's the different impl here comparing from the code which used before?

... albeit with the "wrong" interface index, check with -vvvv on edge and n2n-route. Seems that my idea to retrieve the interface index does not work out in some detail, see get_interface_index (struct in_addr addr) in tools/n2n-route.c of the PR (it delivers 9 instead of the correct 8 in my case). Anyone got an idea what is wrong with it?

Have you previously scratched and assigned the proper TAP/TUN virtual network adapter interface index(Ifidx) present on windows which the edge used to the program for attaching the route?

If not, I could just pass the interface index from the edge through the management port.

[Logan007]

... albeit with the "wrong" interface index, ...

Nah, scratch that. Turns out that the interface numbers are highly correct. Must be something else... any clues?