Network issues with server
 

I just received a MikroTik RouterBoard RB951Ui-2HnD to replace my aging and unreliable Netgear router. I have not done anything advanced with it yet; I just set an SSID and password and connected to it. Everything is working without issue, except that I am having problems connecting to my server (which is on the WiFi network) from any other machine.

The server is at 192.168.88.253, and I have set a static IP for it in the router's DHCP leases. If I try to ping it after connecting to the network on my laptop:
However, I can ping other devices with no issue, for example, my phone:
The same thing happens if I try to ping it from another device, such as my phone. However, I have found that if I first ping in the other direction, from the server to the laptop or other device, this fixes the problem, and I can then ping from the other device to the server. Here is the result of pinging the server from my laptop after pinging the laptop from the server:
It will continue to work until my laptop (or other device) is disconnected from the network. Upon connecting again, it is not able to ping the server.

Now, this may be an issue with the router, but considering I have no problems pinging between other devices on the network, I think there must be something misconfigured on the router side. I've never seen anything like this before, and I'm at a loss for what could be causing it. As I mentioned, the server's DHCP lease is static, but the same behavior occurs when it is dynamic.

More information: the server uses Network Manager, specifically nmcli from the command line. I have tried clearing /etc/NetworkManager/system-connections and changing the network SSID and password. It is running Slackware64-14.2. I can provide any other information as needed.

I should clarify, the server is definitely connected to the network, and it appears on the web interface for the router. The problem seems to be that no other devices on the network can see it until they have been pinged by it.

If you assign the server's mac address/ip in the router's dhcpd and set the server to use dhcp what happens?

Your router has some more advanced capabilities and your reported issue looks to me as an ARP table (update) issue:
https://wiki.mikrotik.com/wiki/Manua...ocol_operation
- check on the router if the ARP table contains info about your Slackware system

Additionally, try arp -a on your Slackware system and check if you have the router (gateway IP) in the table.
To enforce a static ARP entry on your Slackware system, in your case the router GW MAC address, try:
- substitute Router_GW_IP with the router GW IP and xx:xx:xx:xx:xx:xx with the router MAC (LAN/Wifi)

Extra:
Make sure that on the Slackware system you have the networking configured correctly (WiFi iface IP, GW, default route and no conflicting-with-your-actual-new-setup firewall restriction or static ARP records).

Check if your Slackware system / router SW has no other internal ARP unresolved issues, like:
https://www.linuxquestions.org/quest...7/#post5776741

P.S. If unsatisfied with your actual router SW, you might want to take a look at OpenWRT and the newly developed LEDE port/fork and "pour" it into your router ;)
https://wiki.openwrt.org/toh/mikrotik/rb951g_2hnd
https://forum.lede-project.org/t/ins...51ui-2hnd/3751

Personally, I really like OpenWRT, stable, advanced, flexible and fast.

Thanks for the suggestions. I haven't gotten to try them yet, but I wanted to add that apparently this problem is not limited to the server, but also my wife's MacBook. My phone and laptop have no trouble reaching each other, though. Also, all the connected devices show up in the arp table on the router, but the MacBook and the server don't appear when I run arp -a on my laptop. My Android phone does. So yes, it's definitely an arp issue.

You can try to look what's going on at the ARP level and investigate more by using tcpdump on your Slackware system (+ router & other systems where you have the ability):
INTERFACE = wlan0 (or whatever name it has)

On OpenWRT/LEDE, besides a lot of nice features, there are 3 major configuration possibilities that are really helpful and not many of-the-shelf routers support them:
1. you have the possibility to use your own iptables rules sets
2. you can disable the forwarding on the (pseudo)LAN-Bridge, isolating LAN clients and only discretionary forward ports between them
3. you can remove the WiFi from the LAN bridge:
https://wiki.openwrt.org/doc/recipes/routedap

Do you mean instead of using NetworkManager? NetworkManager is already using dhcp to get an IP from the router.

I checked arp -a on the server, and it already lists the correct router gateway and MAC address, so I don't think that's the problem.

This went a little over my head, but the server has nothing other than the default set in iptables:

Here is the output of the route command. I notice that there are two entries for 192.168.88.0. Could that be a problem? On my laptop there is only one (with Metric = 600).

Regarding the thread you linked, are you suggesting I run those ARP flux mitigation commands, or is there something I should check first to know if it's needed? Sorry, I'm still a bit of a n00b when it comes to networking.

Here is some output of tcpdump on the server during the time when I was trying to ping it from my laptop.

Looks like it is only communicating with the router.

I will keep that in mind. On my old router, I installed DD-WRT, but RouterOS (that the MikroTik runs) is obviously way more capable than I am, and I would expect it to work better than anything else on MikroTik hardware. I think this must be a problem with my router setup somewhere. I've posted on the MikroTik forums too, so hopefully I can work this out without switching to a completely different firmware.

- this is wrong and I'm not sure which is to blame - router for providing crap over DHCP or your Slackware Server having maybe a manual leftover wlan0 adapter definition.
But then you stated that you have another MacBook that is experiencing the same behavior like your Slackware server. In this case it's only the router playing crazy.
Check on your router for any potential mistakes in the LAN Network/NetworkMask definition, LAN Default Gateway IP - which should be 192.168.88.1 and the IP for your Slackware System in the DHCP reservation fields.

Try to setup your Slackware box with static IP (disable DHCP) and on the router disable the IP reservation you've made for your Slackware system - the router should accept that the client has a static IP already configured. See if you get a normal routing table and check again the connectivity with ping.

Extra, could you please use instead of the old route command (just cosmetics and a better representation):

- just check the vales of those variables, instead of echo 1 > /proc/sys/something... run: cat /proc/sys/something and see if the returning value is 1/0 (ON/OFF). But that is just for the router (since your Slackware box is only connected through WiFi - doesn't have multiple adapters on the same LAN) and I was just speculating - I hope that the ones that have built your router were knowledgeable enough to get it configured properly.


If I were you, I would edit the post in which you pasted your real MAC addresses and delete / change them, juts for the sake of your privacy ;)

Actually, seems I was wrong about the MacBook. It doesn't appear in arp -a until I ping it, but I think that's normal. I actually don't have a problem pinging it.

Well, I'm having trouble getting a static IP to work with wireless. I will have to try later. Anyway, after restarting NetworkManager, the duplicate line in the routing table is gone. (IP address changed because I decided to try a different static DCHP lease, just to see if changing it made a difference.)

But the problem persists.

Thanks for the tip. I have edited it. I'm afraid I have to give up for today. Hopefully tomorrow will be less frustrating. :(

- 192.168.88.10 is the IP the router assigned to your Slackware host (interface wlan0) over DHCP, which is different from 192.168.88.253 and is obviously not what you expected/configured
- check on the router to see if the DHCP pool (maybe is divided between Ethernet and WiFi) is covering all the address space up to 254 - for example: 192.168.88.10-192.168.88.254 I don't know anything about RouterOS.
- I'm afraid I cannot help you with NetworkManager but only with basic Linux commands (I'm not even installing the NetworkManager package) and I'm also ending my LQ "addiction" for today ... busy


P.S. It's not the best practice to configure a server through DHCP. I'm usually defining the IP Address reservation together with the MAC in the router DHCP table and use static IP definition on the host. The host won't send any DHCP requests and the router will only keep the IP Address reserved and allow the host (IP & MAC match) once is up and communicating. Everybody's happy!

Actually, it is what I configured. I purposely changed it in the router just to see if it would make a difference. Upon disconnecting and reconnecting the server to the network, 192.168.88.10 is the new IP address, but it still can't be pinged from other devices in the LAN (except for the router itself, or if the server first pings the other device).

Yes, it seems to be.

Well, I really appreciate your help. Have a good one.

Always happy to help! You should have a good one (lecture) too:
https://wiki.mikrotik.com/wiki/Manual:IP/ARP

- as a workaround, before you switch to LEDE :) - > check ARP Mode on the router and eventually define a static ARP record for the Slackware server - put that static arp definition in a boot script somewhere (if possible) to survive a router reboot.

Me out! ;)

Thanks. I will try this next. I think from reading the docs that I now know how to set up a static IP on wireless using rc.inet1.conf and wpa_supplicant. I will also try a static ARP.

I wanted to help you with the static IP configuration on your Slackware server, but I've noticed that you are using NetworkManager (I never used it) and then I also don't use the Slackware way - actually I'm always substituting /etc/rc.d/rc.inet1 with my own "manual" network initialization script. At least, just for inspiration, I can help you with the Linux way (that will work under Slackware) to get your WiFi device manually connected and configured with either DHCP / Static IP. I switched to iproute2 some time ago and tried to double the commands (commented) with the old (standard) ifconfig / route ones - just for reference.
Here you go:

If you want to stick with rc.inet1.conf for your wireless, it's pretty straightforward. Just edit your GATEWAY and the wlan0 section (which should be the 4th network section). Obviously replace the GATEWAY, IPADDR, and NETMASK to those of your network.

If your wpa_supplicant requires a specific driver, you can specify that using WLAN_WPADRIVER[4]="wext" further down in that section.

I forgot to mention that maybe you'll find it more useful to dump both ARP and ICMP packets at the same time while investigating your issue. To do that, just run:

Thank you so much. This works flawlessly to connect my router with a static IP. It has also solved my ping problems with this machine, though I still don't really understand why it wasn't working before. I have distilled these commands into the following rc script that runs from /etc/rc.d/rc.M in place of /etc/rc.d/rc.inet1:

The script also sets a static ARP. I will mark this as solved now.

EDIT: Nevermind, I spoke too soon. The ping problems still persist, though this does work to set a static IP.

I tried this, but for some reason it didn't work. It seemed to be connected from what I could tell by looking at the output of iwconfig and ifconfig, but I couldn't connect to the internet or ping the router. I could probably dig deeper and find out why, but abga's solution is working, and I've already spent too much time on this. Thanks for the advice, though!

Okay, here's something new. I found that when pinging from my laptop or phone with a fresh ARP cache, it does eventually find the server. It sometimes needs 16 or more attempts before finding the destination host. So, for those of you who know more about this than me, what does that indicate?

EDIT: I added a static ARP entry for the server in the router, but that didn't help.

EDIT2: Going back to the MacBook, I think now that it actually does have the same issue, but it doesn't require as many tries to successfully ping it. It takes maybe 4 tries instead of 10-20+. This is looking more and more like an issue with the router, IMO. Hopefully just the router firmware, and maybe if I switch to OpenWRT, that will take care of it. I think that may be my next step, unless someone has some idea how this can be fixed. That may have to wait until after my trip next week, though.

I'd like to point out that this IS NOT the way the network configuration should be done under Slackware! The available tools and configuration provided and documented by Slackware should be used instead.

Now that nobody will sue me, back to your issue. The script you created looks OK apart from some duplicates - you either use ip or ifconfig.
Put a hash (or remove it) in front of ifconfig as it does the same thing as the ip command above it:
and
In the line:
make sure that the MAC is the one the router advertises it over WiFi - check on another client (laptop) with arp -a to be sure you're correct.

- How did you add a static ARP entry for the server in the router? Were you finally able to use arp -s IP MAC and execute it? If so, then I start to get out of ideas...
- I've hinted in a previous post to look at the docs for your router and now I've read some myself - check if the ARP Mode is Enabled
https://wiki.mikrotik.com/wiki/Manual:IP/ARP#ARP_Modes
- Your issue is really peculiar, mainly because you said it was working before with the old router and you haven't changed anything on your Slackware system. I might have two more ideas to make it work:
1. Check on your Slackware System if your WiFi interface is not powered down by the motherboard/CPU power management - take the steps from this post:
https://www.linuxquestions.org/quest...1/#post5775413
- or, a more direct approach to check if PowerManagement is enabled:
/sbin/iwconfig wlan0
- and look after the "Power Management:" entry - if it's on, then run
/sbin/iwconfig wlan0 power off

- if that's the case, then amend your newly created script and turn the WiFi PowerManagement off after the interface connection and IP configuration

2. I was about to suggest you a workaround, to ping the router from within your script after the interface connection and IP configuration. In this way you'll force the (lazy?) router to update the ARP table with your Slackware server MAC. But then you stated that you already defined a static entry for the server. Anyways, just test this -> put this line, that will send 1 packet and wait 1 sec for the reply - increase the packet count if you will, in your script after adding the default route & static arp:
...
3. Pour LEDE in your router - OpenWRT is still not patched against the WiFi KRACK attack

Yes, that's what I did.

Yes, ARP=enabled on all the interfaces.

Okay, there's something. WiFi power management was on. Now that I have turned it off, it seems like it may have fixed the pinging problem... I'm not going to claim success yet though until I give it awhile and many tests. Strange that this didn't seem to matter with the old router, though. (Where's the "tentatively solved" option for this thread?)

Thanks for the ideas and info. You have been really helpful with this. I'm hoping that this is really solved. We'll see...

So, the weird thing about this script is that every time the server reboots, ifconfig reports a new MAC address. It doesn't seem to cause a problem, but nonetheless I ended up just switching back to NetworkManager and making the DHCP lease static like I was doing before. The only difference is that now I turn off WiFi power management in my rc.local script. Everything is working fine now, and the MAC address is back to what it always used to be.

Anyway, thanks everyone for the help. I learned a lot!

Glad you made it finally work. I've also learned some stuff from your experience and hopefully also the Slack community.
The script you used was sound but not supported by Slackware. Personally, I'm not using the Slackware stock scripts just because usually my network configuration is more complex, but for your scenario, with only one interface, you should stick with what you "officially" get.
Now, this is the piece of the puzzle that was missing until now and may explain why you are experiencing your issues. The script you made out of my hints shuts down and starst the interface in the beginning, which isn't really necessary, but good practice. But that process won't change your MAC address, unless the driver has this feature, or NetworkManager was still running and did it itself - NetworkManager has this feature and it might have been enabled!
To resolve this, make sure NetworkManager is stopped and you can also enforce a MAC address for your wlan0 in the script just after bringing the interface up and before the IP Address configuration:
As described, NetworkManager has this MAC randomization feature and if enabled it's apparently causing problems in some scenarios:
https://bugs.launchpad.net/ubuntu/+s...r/+bug/1681513
https://bugs.debian.org/cgi-bin/bugr...cgi?bug=836351
..etc

This MAC address randomization on WiFi was also introduced and enabled by default recently in Apple products too (at least in the mobile ones) just to protect the user's privacy.

Having all this said, if MAC randomization is active on your Slackware system (& your wife's MacBook - Apple product) your router might need some time to flush the old MAC entry from it's ARP table and update it with the new one. (the ping sequence automation presented in a post above will help to force the router to do this update).

On the PowerManagement issue, I was about to suggest to put that line in rc.local, but you did it already ;) Now, you might also want to take a look at the power management daemon form Slackware and ad a blacklist for your WiFi card:
https://unix.stackexchange.com/quest...nt-permanently

Finally, it's also not good practice to run a server connected through WiFi but only on wired network. However, it's in your home and I guess you don't want to have wires all over the place ...

Thanks for the additional tip. I will put it in my script in case I go back to using it at some point.

I'm not sure I follow this. The MAC randomization only occurred when NetworkManager was not running (I made sure to stop it first and then make rc.networkmanager non-executable). Now that I am using NetworkManager again, the MAC remains constant. So it doesn't make sense to me that this could somehow be NetworkManager's fault.

I would just put the server near the router and attach it via ethernet, but one of its jobs is to store footage from my security cameras (also wireless). In the worst case scenario where someone breaks in, even if they have the presence of mind to unplug the router or the cameras, I don't want the server with the footage to also be sitting there in plain sight. (That was actually the main reason I got this new router -- it's supposed to be super reliable.) But one day maybe I will run a wire, or, better yet, run a wire for each of the cameras. But that's a lot more time, effort, money, etc.

I just checked (googled) if there were any changes in the latest kernels / network adapter drivers that might have implemented such a MAC changing algorithm and I found none. The only component in your server (a Standard Slackware Installation) that has this capacity is NetworkManager:
https://blogs.gnome.org/thaller/2016...manager-1-4-0/

The commands you distilled in your script are basic Linux networking configuration commands (utilities) that are not able to produce such an effect like the one observed/described. You can take a look at the original /etc/rc.d/rc.inet1 and you'll learn that it also uses ifconfig statements (ip in -current). I guess you got a little confused by rapidly trying a lot of things and accumulating a lot of information :)
If you have time, check with dmesg if you have persistent MAC address between reboots - it should stay consistent.

This thread is already solved and kind of old, but I just wanted to remark that I just discovered powerline adapters. I got a couple of them and so far they are much faster than WiFi, and hopefully more reliable (that remains to be seen). They're definitely dead simple and cheap compared to running cables all over the house. I used the first set for the router and server, and next I will probably get a few more for my IP cameras. I wish I had known this technology existed when I first set this up. :)

Just passing this along in case it helps someone else.

These were pretty common some 15 years ago and very insecure too. I didn't propose them to you because I didn't like your wireless setup in the first place, setting up a security system on insecure infrastructure, although WPA2 is still safe to use. Still..
https://hashcat.net/forum/thread-7717.html
Nowadays you get some AES128 encryption on these powerline adapters, but I strongly advise you not to go for the cheapest ones and always check if the manufacturer is maintaining them, that's releasing firmware updates.
https://security.stackexchange.com/q...erently-secure
https://www.bentasker.co.uk/document...lugav-adapters

I'm surprised that one of the responders in the first link was able to get a strong signal from his neighbor's house. I didn't think that would be possible. I am using encryption and I am in a single house, so it seems like it would be at least as secure as WiFi simply because it's not literally broadcasting the signal.

I get strong signals from some neighbors too but most are encrypted, they're just not hiding their ssid.

Are you talking about wireless or powerline? I get tons of wireless pollution from my neighbors too.

talking about wireless

Transformers Block Signals
 

Over the years various signals have been sent over residential power lines. These included homemade controllers and later commercial ones like "X10" and others.

It was my understanding that the signal range was limited by the step-down transformer (e.g. 10kv to 120v 240v). That is, if two houses were on the same side of a transformer then they could see the same power line signals. Houses using a different transformer could not see signals generated from the other house.

I never tested this so I don't know if my understanding is correct. But if it is, I wonder if the current consumer power line signaling technology is also blocked by the closest step down transformer.

If power lines are on poles one can visually trace the cables and see the transformers in residential suburbs. The trend to move power distribution underground makes it more difficult to analyze now.