- WLUG - wlug.mailman3.com

Re: [Wlug] Wireless mesh network question

by Andy Stewart

HI gang, I setup an experiment with all of the wifi access on one channel. WiCD saw both access points with the same SSID and wifi channel. Connecting to either of them seems to have no ill effects. Andy -- Andy Stewart (KB1OIQ) Founder: Worcester Linux Users' Group Founder: Chelmsford Linux Meetup Group President: PART of Westford, MA (WB1GOF)

Feb. 16, 2015

Wireless mesh network question

by Andy Stewart

HI guys, I am planning to setup a wireless mesh network at a ham radio event in June. Each mesh node will consist of two Linksys WRT54GLs, much like the demo I showed at a recent WLUG meeting. One of the WRT54GLs will be on channel 6 and carry mesh network traffic. The other one will be on channel 1 and allow generic wifi devices access to the mesh network. It seems like there would be an interference problem if every node allowed wifi access on channel 1. Should this be 4 different wifi channels? It is possible for a user to be within radio range of multiple of them simultaneously. Thoughts? I've never setup a wireless network before and could use your advice. These mesh nodes will be placed outside in weatherproof enclosures with battery power. Thanks! Andy -- Andy Stewart (KB1OIQ) Founder: Worcester Linux Users' Group Founder: Chelmsford Linux Meetup Group President: PART of Westford, MA (WB1GOF)

Feb. 16, 2015

Reminder! Meeting tomorrow! Feb. 12th 2015 at 7pm (Mid-Century Room) rm 331!

by Tim Keller

Hey Everybody, This is just a quick reminder that we're having a meeting tomorrow at 7pm in the Mid-Century Room (rm 331) in the student center. Andy is going to be giving a talk about mesh networking! Afterwards we'll do pizza at Tech! Refreshments will be provided at the meeting as well. Later, Tim. -- I am leery of the allegiances of any politician who refers to their constituents as "consumers".

Feb. 11, 2015

Re: [Wlug] sshd_config MaxStartups

by Randall Mason

Maybe it's from a time when servers had fewer resources. If your server would run out of memory with 20 concurrent attempted logins, you may want to have that set to 20, else you should end up with a bigger DOS than if you were just able to prevent ssh logins. The same would be true with bandwidth. If you were on dialup, for example, you may want to make sure that you aren't overwhelming your connection, such that if you can only support 20 concurrent real time logins, you wouldn't end up with a terrible degradation in service. Not that it's too popular to run services on your bandwidth capped 2G internet connection... Sitting at a login prompt on my ARM NAS gives me this: sshd: Virt: 11672 Res: 5280 Shared: 4584 So it seems that I'm wasting 5MB of my 256MB of memory on my NAS when somebody just hangs at the login prompt. I could fairly easily DOS my little NAS by just running `while [ 1 ]; do ssh <box> & done`, couldn't I? Are you really using more than 10 connections sitting at a login prompt? What are they being used for? Is the system powerful enough to handle many concurrent logins? I think that today you should probably have this set up with a combination of dynamic blacklists (BlockHosts or sshguard) and this option, if your server is truly needing more resources. That way all of the failed logins don't eat up your cap for too long. The nice thing about the percent number is that it gives you, as an administrator, at least some chance of logging in before the system is so overloaded that you could never get in and start killing things. It could be that because ssh is becoming more of a transport layer than just a remote tty, this option is less useful. At Github for example, most of the unauthenticated connections that github has should just be dropped quickly because nobody uses password authentication. Randall Mason clashthebunny(a)gmail.com On Wed, Feb 11, 2015 at 9:46 AM, Jamie Guinan <guinan(a)bluebutton.com> wrote: > > Hi Group! > > I'm seeking opinions about an sshd feature. > > I was doing some work on a remote system (I did not set it up) that > seemed to be refusing ssh and scp connections randomly. > > I looked into it, and finally stumbled across this from sshd_config(5), > > MaxStartups > Specifies the maximum number of concurrent unauthenticated > connections to the SSH daemon. > Additional connections will be dropped until authentication > succeeds or the LoginGraceTime > expires for a connection. The default is 10. > > Alternatively, random early drop can be enabled by specifying > the three colon separated val‐ > ues “start:rate:full” (e.g. "10:30:60"). sshd(8) will refuse > connection attempts with a > probability of “rate/100” (30%) if there are currently > “start” (10) unauthenticated connec‐ > tions. The probability increases linearly and all connection > attempts are refused if the > number of unauthenticated connections reaches “full” (60). > > Indeed, the server had this setting, > > MaxStartups 10:50:20 > > This just seems like a terrible option. You can DOS their server just > by making 20 connections and leaving them hanging. And it breaks any > automated scripts relying on ssh or scp (unless you wrap them in a > loop until they succeed, ugh). > > My guess is that the reasoning behind this feature that it will filter > out a number of automated attacks. That seems no better than > security-by-obscurity, and I know how some of you feel about that. :) > > Can you think of any sane reason to enable this feature, or for it to > even exist at all? > > Best regards, > -Jamie > _______________________________________________ > Wlug mailing list > Wlug(a)mail.wlug.org > http://mail.wlug.org/mailman/listinfo/wlug > >

Feb. 11, 2015

sshd_config MaxStartups

by Jamie Guinan

Hi Group! I'm seeking opinions about an sshd feature. I was doing some work on a remote system (I did not set it up) that seemed to be refusing ssh and scp connections randomly. I looked into it, and finally stumbled across this from sshd_config(5), MaxStartups Specifies the maximum number of concurrent unauthenticated connections to the SSH daemon. Additional connections will be dropped until authentication succeeds or the LoginGraceTime expires for a connection. The default is 10. Alternatively, random early drop can be enabled by specifying the three colon separated val‐ ues “start:rate:full” (e.g. "10:30:60"). sshd(8) will refuse connection attempts with a probability of “rate/100” (30%) if there are currently “start” (10) unauthenticated connec‐ tions. The probability increases linearly and all connection attempts are refused if the number of unauthenticated connections reaches “full” (60). Indeed, the server had this setting, MaxStartups 10:50:20 This just seems like a terrible option. You can DOS their server just by making 20 connections and leaving them hanging. And it breaks any automated scripts relying on ssh or scp (unless you wrap them in a loop until they succeed, ugh). My guess is that the reasoning behind this feature that it will filter out a number of automated attacks. That seems no better than security-by-obscurity, and I know how some of you feel about that. :) Can you think of any sane reason to enable this feature, or for it to even exist at all? Best regards, -Jamie

Feb. 11, 2015

Re: [Wlug] linux networking question (reformatted for readability)

by Frank Sweetser

On 2/7/2015 5:14 PM, Brad wrote: > On Sat, Feb 07, 2015 at 04:40:36PM -0500, Frank Sweetser wrote: >> This is just a rough guess, but did you ever check on the state tables >> in your openbsd firewall? >> > I did not check the state tables in the OpenBSD firewall. I figured > since it had just been forcefully reboot the state tables were > coherent. It's not just a simple question of the firewall state table being internally consistent, it also has to be consistent with both the NAT gateway and what the clients are expecting. When one of your internal clients makes an outgoing connection, both the firewall and NAT tables have to have entries added to accommodate the return traffic - a translation rule in the NAT table, and an allow rule in the firewall. If either of those aren't correct, the return traffic won't make it back to the client. >> In your setup you have state distributed >> amongst your clients, your firewall, and you NAT gateway, and unless >> all three are in sync you can easily get the kind of possessed network >> behavior you describe. >> > To properly exorcize should i pour holy-water over the routers? I always > figured some king of black magic was involved in routing. Simple routing, not so much - it's just packet go in, packet go out. It's when you throw state tables in that things start to get fragile. When you have strings of disconnected state tables that require consistency like this, it's not uncommon that you end up having to always reboot them together. > Is a bridged-firewall not a good idea in practice because it adds > another layer between the internat and the intranet, and could get out > of sync? The bridged portion itself isn't inherently much worse than doing a traditional layer 3 visible firewall, so long as you have your rules set up correctly to account for things like passing ARP traffic. Your typical all-in-one box is a little less likely to display this kind of weirdness only because they're combined on a single box, so a reboot will clear both out simultaneously. I would seriously suggest you check out pfSense. It's a FreeBSD based distribution designed to operate as a SOHO class firewall, with all of the usual NAT, DHCP, and other expected goodies. I think it's a pretty safe bet that it'll be a better router and firewall than OSX... -- Frank Sweetser fs at wpi.edu | For every problem, there is a solution that Manager of Network Operations | is simple, elegant, and wrong. Worcester Polytechnic Institute | - HL Mencken

Feb. 8, 2015

Re: [Wlug] linux networking question (reformatted for readability)

by Brad

On Sat, Feb 07, 2015 at 04:40:36PM -0500, Frank Sweetser wrote: > This is just a rough guess, but did you ever check on the state tables > in your openbsd firewall? > I did not check the state tables in the OpenBSD firewall. I figured since it had just been forcefully reboot the state tables were coherent. > In your setup you have state distributed > amongst your clients, your firewall, and you NAT gateway, and unless > all three are in sync you can easily get the kind of possessed network > behavior you describe. > To properly exorcize should i pour holy-water over the routers? I always figured some king of black magic was involved in routing. Is a bridged-firewall not a good idea in practice because it adds another layer between the internat and the intranet, and could get out of sync? Thanks for the ideas, - brad > On February 7, 2015 3:20:15 PM EST, Brad <bkn(a)ithryn.net> wrote: > >(i appologize for the previous message that i completely unreadable.) > > > >Dear W-LUGgers, > > > >I had some strange network related behavior that left me baffled and i > >wanted > >to hear some theories from more experienced network admins. > > > >The network layout is the following. The network is pretty simple, > >external > >traffic passes through a bridged-firewall (OpenBSD, my choice) into an > >OS X > >server (not my choice) which handles NAT/DHCP/DNS et al., and all the > >office > >computers are dhcp clients to the OS X server. The trouble machines are > >linux > >(ubuntu) desktop clients. > > > >The scenario is the following. I was doing work on the bridged firewall > >(OpenBSD) and somehow caused it to kernel panic, oopsie! So the > >bridged-firewall went down thus no-one had internet access, Dou! i > >quickly > >bounced the machine. It came back on-line and clients were able to > >access the > >internet, huzzah! But, the strange behavior was in two linux machines > >within > >the network that were not able to access some external IPs. My linux > >desktop > >could not access 8.8.8.8, when pinging, i could see an arp who-has > >request > >originating from my machine, i could see the packet come into the OS X > >server. > >But the request always went unanswered. The same behavior happened to > >another > >linux desktop but with 192.48.178.134 (sgi.com) My desktop could ping > >sgi.com. > >So each linux desktop had *different* unreachable IPs. The rest of the > >internet > >was reachable. I tried clearing the arp-cache on the OS X server, then > >clearing > >the NAT state tables, then I rebooted the OS X server, none solved the > >problem. > >I finally renewed the dhcp lease on my linux desktop machine and that > >allowed > >the ping to complete. > > > >What would case this behavior? Could it be stale arp-cache on the linux > >machine? ( I *should* have tried to clear the arp-cache on the linux > >machine > >before i renewed the dhcp lease, but i didn’t think of that until after > >the > >fact.) The linux machine was sending out arp who-has requests so would > >a stale > >cache even matter? Why would no one answer the arp requests? I am not > >an expert > >network admin (its just a side job since the company is only 15 > >people). I > >don’t expect to get a resolution but i’m interested to hear any > >theories. > > > >Thanks and cheers, — brad > > > >PS. As a worcester transplant to boston, i am really jealous i don’t > >live > >closer to attend meetings. The topics of late sound outstanding. > > > >_______________________________________________ > >Wlug mailing list > >Wlug(a)mail.wlug.org > >http://mail.wlug.org/mailman/listinfo/wlug > > -- > Sent from my Android device with K-9 Mail. Please excuse my brevity.

Feb. 7, 2015

Re: [Wlug] linux networking question (reformatted for readability)

by Frank Sweetser

This is just a rough guess, but did you ever check on the state tables in your openbsd firewall? In your setup you have state distributed amongst your clients, your firewall, and you NAT gateway, and unless all three are in sync you can easily get the kind of possessed network behavior you describe. On February 7, 2015 3:20:15 PM EST, Brad <bkn(a)ithryn.net> wrote: >(i appologize for the previous message that i completely unreadable.) > >Dear W-LUGgers, > >I had some strange network related behavior that left me baffled and i >wanted >to hear some theories from more experienced network admins. > >The network layout is the following. The network is pretty simple, >external >traffic passes through a bridged-firewall (OpenBSD, my choice) into an >OS X >server (not my choice) which handles NAT/DHCP/DNS et al., and all the >office >computers are dhcp clients to the OS X server. The trouble machines are >linux >(ubuntu) desktop clients. > >The scenario is the following. I was doing work on the bridged firewall >(OpenBSD) and somehow caused it to kernel panic, oopsie! So the >bridged-firewall went down thus no-one had internet access, Dou! i >quickly >bounced the machine. It came back on-line and clients were able to >access the >internet, huzzah! But, the strange behavior was in two linux machines >within >the network that were not able to access some external IPs. My linux >desktop >could not access 8.8.8.8, when pinging, i could see an arp who-has >request >originating from my machine, i could see the packet come into the OS X >server. >But the request always went unanswered. The same behavior happened to >another >linux desktop but with 192.48.178.134 (sgi.com) My desktop could ping >sgi.com. >So each linux desktop had *different* unreachable IPs. The rest of the >internet >was reachable. I tried clearing the arp-cache on the OS X server, then >clearing >the NAT state tables, then I rebooted the OS X server, none solved the >problem. >I finally renewed the dhcp lease on my linux desktop machine and that >allowed >the ping to complete. > >What would case this behavior? Could it be stale arp-cache on the linux >machine? ( I *should* have tried to clear the arp-cache on the linux >machine >before i renewed the dhcp lease, but i didn’t think of that until after >the >fact.) The linux machine was sending out arp who-has requests so would >a stale >cache even matter? Why would no one answer the arp requests? I am not >an expert >network admin (its just a side job since the company is only 15 >people). I >don’t expect to get a resolution but i’m interested to hear any >theories. > >Thanks and cheers, — brad > >PS. As a worcester transplant to boston, i am really jealous i don’t >live >closer to attend meetings. The topics of late sound outstanding. > >_______________________________________________ >Wlug mailing list >Wlug(a)mail.wlug.org >http://mail.wlug.org/mailman/listinfo/wlug -- Sent from my Android device with K-9 Mail. Please excuse my brevity.

Feb. 7, 2015

linux networking question (reformatted for readability)

by Brad

(i appologize for the previous message that i completely unreadable.) Dear W-LUGgers, I had some strange network related behavior that left me baffled and i wanted to hear some theories from more experienced network admins. The network layout is the following. The network is pretty simple, external traffic passes through a bridged-firewall (OpenBSD, my choice) into an OS X server (not my choice) which handles NAT/DHCP/DNS et al., and all the office computers are dhcp clients to the OS X server. The trouble machines are linux (ubuntu) desktop clients. The scenario is the following. I was doing work on the bridged firewall (OpenBSD) and somehow caused it to kernel panic, oopsie! So the bridged-firewall went down thus no-one had internet access, Dou! i quickly bounced the machine. It came back on-line and clients were able to access the internet, huzzah! But, the strange behavior was in two linux machines within the network that were not able to access some external IPs. My linux desktop could not access 8.8.8.8, when pinging, i could see an arp who-has request originating from my machine, i could see the packet come into the OS X server. But the request always went unanswered. The same behavior happened to another linux desktop but with 192.48.178.134 (sgi.com) My desktop could ping sgi.com. So each linux desktop had *different* unreachable IPs. The rest of the internet was reachable. I tried clearing the arp-cache on the OS X server, then clearing the NAT state tables, then I rebooted the OS X server, none solved the problem. I finally renewed the dhcp lease on my linux desktop machine and that allowed the ping to complete. What would case this behavior? Could it be stale arp-cache on the linux machine? ( I *should* have tried to clear the arp-cache on the linux machine before i renewed the dhcp lease, but i didn’t think of that until after the fact.) The linux machine was sending out arp who-has requests so would a stale cache even matter? Why would no one answer the arp requests? I am not an expert network admin (its just a side job since the company is only 15 people). I don’t expect to get a resolution but i’m interested to hear any theories. Thanks and cheers, — brad PS. As a worcester transplant to boston, i am really jealous i don’t live closer to attend meetings. The topics of late sound outstanding.

Feb. 7, 2015

linux networking question.

by Brad

Feb. 7, 2015