I'm preparing to publish a user script, are there any rules I need to follow?

[DDD]

Hello, I'm new

I'm writing a user script that I call BIG MAC that will automatically change the router's wireless MAC address on a regular basis, changing it to a random address, or a user-specified address.

I'm not a professional programmer, so my knowledge of Unix and sh scripts is limited, but I have used many scripts from the community for my router, and I often create modified versions of the community scripts for my personal use, I think it's time to give back to the community.

I have read the wiki, so I know it's best to put the script in the addons directory, I'm going to write an easy-to-use shell UI for the BIG MAC script, like other scripts do, And I'd also like to provide an API for future web GUI usage, but I don't have the ability to write any web code as I'm very new to it.

In addition to that, my script is currently in Alpha testing on my personal devices (with lots of modifications and yet to be perfected), it has tested HND and ARMv7 models, I will go into Beta when it's ready, I'll post a new thread and welcome anyone to try it.

Eventually this script will be hosted on GitHub, but, I'm not a big fan of the GPL license, I'll probably use the MIT license, but if GPL is necessary, I can compromise.

Before entering the Beta, what other rules should I pay attention to in advance?

Any advice is greatly appreciated.

 

[DDD]

RESERVED
　　^ I guess that's another rule

 

[Tech9]

In my experiments, changing wireless MAC makes the router AiMesh incompatible.

 

[dev_null]

When I first published my concept for vnStat-on-Merlin (shameless plug), I was amazed by the positive community reaction and support. I guess the lesson is "folks here want you to succeed, so take every comment in a positive manner". Several of the "furniture" members were incredibly helpful at the start and @Jack Yaz was an incredible partner as the overall effort got more sophisticated and involved.

I tried a couple of different repositories but eventually settled on github because it works and many other script authors are there as well. I guess one more thing: if you don't want everyone to see your alpha work, set up a separate private workspace and then move it to a separate public workspace once you're ready for public testing and evaluation.

Good luck!

 

[dave14305]

Before entering the Beta, what other rules should I pay attention to in advance?

1. Always leave your users with a foolproof uninstall method (do no harm).
2. Don’t interfere with other addons that might also overlap with your own.
3. Assume many users will have setups you never ever would have contemplated. Program acccordingly.
4. Have a pre-defined method for users to share debug info with you.
5. Ask for help when you need it. Do it publicly so other would-be developers can learn from it.
6. Have a thick skin.
7. Have fun!

 

[SomeWhereOverTheRainBow]

1. Always leave your users with a foolproof uninstall method (do no harm).
2. Don’t interfere with other addons that might also overlap with your own.
3. Assume many users will have setups you never ever would have contemplated. Program acccordingly.
4. Have a pre-defined method for users to share debug info with you.
5. Ask for help when you need it. Do it publicly so other would-be developers can learn from it.
6. Have a thick skin.
7. Have fun!

I will also further mention on @dave14305 comment, sometimes users will want to use your script in ways it was not programmatically intended. Be clear on the purpose of your script, and its use. Include what it is able to do and not able to do, and also mention any limitations to the support you may be able to give. For example, you may not have 25 Aimesh routers running, going by what @Tech9 says, you may want a disclaimer of some kind indicating the disposition, especially if you cannot confirm that what @Tech9 says is true. You want to give users an in advance warning of some kind. Basically, define any limitations if there are any.

 

[Maverickcdn]

1. Always leave your users with a foolproof uninstall method (do no harm).

Just to elaborate on this a bit more. Be sure that if your script is creating/writing to any AsusWRT-Merlin user scripts ie. firewall-start, init-start, postconf that you're adding/removing in a way that will not bork any data that may have existed in/been added to those those files as many other scripts use them and many users are likely to have their own code in such files as well.

Majority of contributors here have their code on Github for coding ideas you can implement.

 

[Tech9]

Not very clear for me what the purpose of this script is. Changing of MAC on a mobile device as anti-tracking measure is one thing, but why changing the MAC of a stationary AP? The SSID remains the same and someone can make a script to track the MAC changes, if needed.

 

[SomeWhereOverTheRainBow]

Not very clear for me what the purpose of this script is. Changing of MAC on a mobile device as anti-tracking measure is one thing, but why changing the MAC of a stationary AP? The SSID remains the same and someone can make a script to track the MAC changes, if needed.

AP-randomization is a new fad.... You missed out on that memo?
# Stationary MAC "OUT"
# Randomized MAC "IN"

 

[Tech9]

Possibly. I usually skip unnecessary in my opinion things.

About AiMesh - seems like Asus expects specific MAC for Asus products only. Any other "non-approved" MAC and AiMesh is out. This is what I have discovered when some non-Asus routers in my collection were running Asuswrt for educational purposes.

 

[DDD]

In my experiments, changing wireless MAC makes the router AiMesh incompatible.

Thanks for the reminder, actually I don't like AiMesh because of its lack of control over nodes, I prefer the Router + AP/Aedia bridge combination, so I haven't tested it yet.

Also, I'll give people the choice, there are several random addresses out there with different privacy levels, one of which doesn't change the branding, so it's still an Asus router, just a new one every day.

However, I personally wouldn't recommend using it in AiMesh, although I do now have the ability to sync to the AP after changing the MAC address, but that's based on SSH.

Not very clear for me what the purpose of this script is. Changing of MAC on a mobile device as anti-tracking measure is one thing, but why changing the MAC of a stationary AP? The SSID remains the same and someone can make a script to track the MAC changes, if needed.

Almost all 3rd party firmware can do this, but Merlin doesn't support it, I found it very easy to implement, just need the right commands, that's why I do it.

I used to be very opposed to MAC address randomization, when mainstream systems like iOS, Android, Windows and Linux all adopted randomization of MAC addresses known as improving privacy, This breaks the simple way that administrators rely on to confirm a user's unique identity. later I learned and embraced these and turned into a proponent of random MAC addresses.

Actually you will find that the MAC addresses of routers are more valuable than mobile devices, they can be beacons for indoor positioning on Google Maps and Apple Maps, their databases usually refer to BSSID (MAC address) instead of SSID, because SSID The user can easily change it, the MAC address can't, what I've done is to make this easier.

About AiMesh - seems like Asus expects specific MAC for Asus products only. Any other "non-approved" MAC and AiMesh is out. This is what I have discovered when some non-Asus routers in my collection were running Asuswrt for educational purposes.

I'm not sure if I'll support AiMesh, but I don't think I'll add support for it in the beta release.

However, if there are many needs, I'll see how I can do it in the future, I believe random MAC addresses should be possible without changing the brand information.


Your suggestions are helpful, thank you.

 

[DDD]

When I first published my concept for vnStat-on-Merlin (shameless plug), I was amazed by the positive community reaction and support. I guess the lesson is "folks here want you to succeed, so take every comment in a positive manner". Several of the "furniture" members were incredibly helpful at the start and @Jack Yaz was an incredible partner as the overall effort got more sophisticated and involved.

Yes these people are really kind and every time I have a question, when I use "better search", I can see their answer, they provide a lot of helpful information here, I dare say that without their guidance, I would never have thought of running the script on the router.

I tried a couple of different repositories but eventually settled on github because it works and many other script authors are there as well. I guess one more thing: if you don't want everyone to see your alpha work, set up a separate private workspace and then move it to a separate public workspace once you're ready for public testing and evaluation.

Good suggestion, I have registered a GitHub account a few weeks ago and haven't uploaded any code yet, because there are still many things to be improved, currently only in local development, but thanks for your suggestion.

Thank you.

1. Always leave your users with a foolproof uninstall method (do no harm).
2. Don’t interfere with other addons that might also overlap with your own.
3. Assume many users will have setups you never ever would have contemplated. Program acccordingly.
4. Have a pre-defined method for users to share debug info with you.
5. Ask for help when you need it. Do it publicly so other would-be developers can learn from it.
6. Have a thick skin.
7. Have fun!

Thanks a lot for these suggestions.

I will also further mention on @dave14305 comment, sometimes users will want to use your script in ways it was not programmatically intended. Be clear on the purpose of your script, and its use. Include what it is able to do and not able to do, and also mention any limitations to the support you may be able to give. For example, you may not have 25 Aimesh routers running, going by what @Tech9 says, you may want a disclaimer of some kind indicating the disposition, especially if you cannot confirm that what @Tech9 says is true. You want to give users an in advance warning of some kind. Basically, define any limitations if there are any.

Ok, I'll define the limits, but I'll also be happy to see different usages and try to support that. and user support is going to be a big challenge for me because I'm not sure I have enough time to deal with a lot of feedback, I might define how to provide valuable feedback and then ignore that noise.

thank you for your suggestion.

Just to elaborate on this a bit more. Be sure that if your script is creating/writing to any AsusWRT-Merlin user scripts ie. firewall-start, init-start, postconf that you're adding/removing in a way that will not bork any data that may have existed in/been added to those those files as many other scripts use them and many users are likely to have their own code in such files as well.

Majority of contributors here have their code on Github for coding ideas you can implement.

Yes, I've noticed that many script developers are fine with other scripts, and I currently only add one line of command to my script in these event scripts, I'll learn to see how other scripts can prevent conflicts better, thanks for your suggestions.

 

[SomeWhereOverTheRainBow]

Hello, I'm new

I'm writing a user script that I call BIG MAC that will automatically change the router's wireless MAC address on a regular basis, changing it to a random address, or a user-specified address.

I'm not a professional programmer, so my knowledge of Unix and sh scripts is limited, but I have used many scripts from the community for my router, and I often create modified versions of the community scripts for my personal use, I think it's time to give back to the community.

I have read the wiki, so I know it's best to put the script in the addons directory, I'm going to write an easy-to-use shell UI for the BIG MAC script, like other scripts do, And I'd also like to provide an API for future web GUI usage, but I don't have the ability to write any web code as I'm very new to it.

In addition to that, my script is currently in Alpha testing on my personal devices (with lots of modifications and yet to be perfected), it has tested HND and ARMv7 models, I will go into Beta when it's ready, I'll post a new thread and welcome anyone to try it.

Eventually this script will be hosted on GitHub, but, I'm not a big fan of the GPL license, I'll probably use the MIT license, but if GPL is necessary, I can compromise.

Before entering the Beta, what other rules should I pay attention to in advance?

Any advice is greatly appreciated.

One way to see what user experience will be like for your future user base would be to tutorial it first. Let the do it yourselfers try it out and provide you with feedback , that way you have a baseline on how you want the script to run.

 

[Tech9]

Actually you will find that the MAC addresses of routers are more valuable than mobile devices, they can be beacons for indoor positioning on Google Maps and Apple Maps

Okay... and randomized MAC on an AP is a solution to what exactly problem?

 

[SomeWhereOverTheRainBow]

Okay... and randomized MAC on an AP is a solution to what exactly problem?

I think the goal is to limit this aspect.

Actually you will find that the MAC addresses of routers are more valuable than mobile devices, they can be beacons for indoor positioning on Google Maps and Apple Maps, their databases usually refer to BSSID (MAC address) instead of SSID, because SSID The user can easily change it, the MAC address can't, what I've done is to make this easier.

@Tech9

Atleast that is what I gathered from one of the responses that were made in response to your previous post.

 

[Tech9]

I've read it too, but I don't understand the problem for the owner of this AP. If someone can explain, thank you.

 

[SomeWhereOverTheRainBow]

I've read it too, but I don't understand the problem for the owner of this AP. If someone can explain, thank you.

I want to understand in a non-roundabout way, how could an individual actually benefit from a randomized wireless AP mac address? How does the default MAC address pose as a privacy concern for users other than the simple fact it is a fixed MAC address assigned to a piece of hardware. It is not like it is the serial number on a murder weapon and we are trying to hide our tracks?

 

[dazedandlost]

As perhaps the leading candidate for the position of resident privacy nutcase, I would like to offer a few generalized thoughts. I don’t know much about mac addresses beyond their specific hardware identifier origin so ...

1) I am totally thrilled when skilled individuals think about privacy, critically and in depth. When they offer to make their work publicly available and for free (as others here have also done), well, to me that’s icing on the cake. Whether or not this particular effort of yours comes to anything, thank you @DDD.

2) It may or may not be a good thing to vary or spoof mac addresses, I don’t know and everyone’s situation may not be the same. That’s the wonderful thing about having the choice (which we don’t have if the script is not available) we can ignore the script for any reason, or none, if we want to.

3) Aviators know that weather can form around you with potentially catastrophic consequences. In the same sort of possibly sneaky way, things which today are medal worthy may tomorrow bring the harshest punishment. How does it hurt to be a little bit prepared?

 

[Tech9]

What threat we are getting prepared for is the main question.

 

[SomeWhereOverTheRainBow]

As perhaps the leading candidate for the position of resident privacy nutcase, I would like to offer a few generalized thoughts. I don’t know much about mac addresses beyond their specific hardware identifier origin so ...

1) I am totally thrilled when skilled individuals think about privacy, critically and in depth. When they offer to make their work publicly available and for free (as others here have also done), well, to me that’s icing on the cake. Whether or not this particular effort of yours comes to anything, thank you @DDD.

2) It may or may not be a good thing to vary or spoof mac addresses, I don’t know and everyone’s situation may not be the same. That’s the wonderful thing about having the choice (which we don’t have if the script is not available) we can ignore the script for any reason, or none, if we want to.

3) Aviators know that weather can form around you with potentially catastrophic consequences. In the same sort of possibly sneaky way, things which today are medal worthy may tomorrow bring the harshest punishment. How does it hurt to be a little bit prepared?

The questions are not being asked to down play or tarnish the future of the script; however, they are being asked to aid fellow users to understand if they should install the script. While some may simply install a script because it is an option available, simply having a choice doesn't necessarily warrant a need for others when deciding to install. Uninformed users would like to know, what is the true benefit of this script aside from changing a Mac address everyday. How does the user benefit from this? Further more, how does this help the users actual privacy?