A few issues in V3

[pti-andy]

I have discovered a couple of strange issues in V3. First the simple one… When setting the speed to "auto" the client and AP always shows a 54M connection but in reality it could be anything. I can only know the actual connection rate by speed testing and looking at the signal strength and comparing it to manual speed settings. Also the bandwidth test utility is useless beyond about 10Mbps. The higher the actual speed the more irratic it reports.

Second... and this is the one that has caused me some major grief. The IP address assigned to a bridged interface will not actually be assigned unless the default gateway that is also part of the same subnet is assigned to that interface. I have ether1 <-> wpci1 bridged and ether2 <-> wpci2. There is no way to assign an address to wpci2 unless a separate subnet is used. This causes me to have to switch the IP address from bridge 1 to bridge 2. When doing this the assignment of the default gateway does not move to that interface rendering the entire system with no usable IP address even though one is assigned. I now have no way to reach the radio. Everything I read on this forum is that there is no recovery or reset procedure for a WAR-2. Is this still the case? How do I get back to this radio? It's bad enough that it has to be fetched and replaced but is it now a brick? I think stripping off the serial/power and any other useful ports was a really bad idea!

-Andy
PTI Wireless

[lonnie]

First question -> have you updated to 1.03? Foe the bandwidth test are you using 2.4 GHz or 5 GHz? You cannot have two bridge groups with the same subnet. If you want them all bridged and sharing a subnet then simply make them all have the same bridge group number. If you have messed up the default route you can still get into the unit from another unit on the same subnet. Communications within a subnet are not done with routing, but instead use ARP directly. People were questioned and price was the object and a serial port that rarely gets used was an extra expense that people said could go away. There are no free parts in this business, so if you want a serial port are you prepared to pay an extra $10 per board for it?

[bradg]

There are no free parts in this business, so if you want a serial port are you prepared to pay an extra $10 per board for it?

Then why not just drop the serial port altogether and put a logic-level header (or, even just holes or test pads) on the board so you could make available for sale a logic level <-> RS232 level shifter dongle? For that matter, there are commercial dongle kits already available for such a purpose, all that would be required is the appropriate cable connections and it's ready to go - http://www.compsys1.com/workbench/BenchOrders/bench_orders.html, either P/N A232DBCT or A232DBCT3v depending on wether 3V or 5V logic is involved.

Even so, it would be a relatively cheap dongle to manufacture, even in small quantities, and would be a valuable tool that would allow people to get into the unit to reset it if it became bricked - either by their own doing, or via a software flaw.

Those who didn't want to buy it - fine, they can send the units in. But, those who actually know what they are doing and are comfortable with it should have the ability to rescue their hardware on-site when they need to, not have to send a unit in to be reset to factory default. And, if it's truly a $10 hit, why not go this route and pass the $10 savings on for WAR4 units?

[lonnie]

We will soon have a method that will work without serial ports. The $10 hit is real and was not done for the 4 port because $10 was a small percentage of the total price. As we now have much lower pricing the $10 is a larger percentage and that means we'll be dropping it when we do the next board revision.

[pti-andy]

First question -> have you updated to 1.03? Foe the bandwidth test are you using 2.4 GHz or 5 GHz? You cannot have two bridge groups with the same subnet. If you want them all bridged and sharing a subnet then simply make them all have the same bridge group number. If you have messed up the default route you can still get into the unit from another unit on the same subnet. Communications within a subnet are not done with routing, but instead use ARP directly. People were questioned and price was the object and a serial port that rarely gets used was an extra expense that people said could go away. There are no free parts in this business, so if you want a serial port are you prepared to pay an extra $10 per board for it?
Yes, I am using version 1.0.3 on a 5.8Ghz link with CM9's. I have -45dB signal strength and the link is rock solid. The bandwidth test is useless above about 10Mbps. Try it on the bench. The numbers jump all around and indicate that I’m getting far less than 10Mbps when in reality I can get about 22Mbps from PC to PC through the link.

I am also using a Cisco switch between the two Ethernet ports on the war-2 so I can monitor and graph what is going on through this repeater station. Thus there are two bridge groups with the same subnet. It is a valid configuration but StarV3 only allows one IP assignment.

The problem was not that the default gateway is incorrect but rather the change of IP assignment did not activate on the other port because the gateway address is already assigned to the ether1 bridge group. It leaves the WAR with no IP at all! This is the bug. It should not be this way. I can repeat the problem on the bench. The end result is the radio is unreachable from within the subnet (on the same LAN). I now have an unusable radio and this is why I'm asking about a reset procedure. I have no problem soldering the DB-9 on the board if it will give me a working serial port like the WAR-4. This is much easier than sending boards back!

-Andy
PTI Wireless

[tony]

Can you PM me the steps needed to duplicate your symptom? (eg. which interfaces have what IP, which are part of xx bridge group, etc.)

Thanks!

[lonnie]

Sorry but two separate bridge groups with the same IP subnet is not a valid configuration and would merely create a bridge loop internally.

Be aware that Cisco products in general have trouble with Ethernet from anybody else. We provide service to several schools in the area and the SysAdmin hates them but is forced to use them. They sometimes require auto yet other times he must set them to fixed 100 mbps fdx.

I also wish to know if you are interpreting the bandwidth test properly. It provides a readout in KBytes/sec, so a reading of 1,000 KBytes/sec is actually about 10 mbps.

A reading of -45 dB might be too high, so try with less power and see if your numbers are more stable. We test all the time PLUS we use these units for our entire WISP and we KNOW the bandwidth test is valid.

Please provide the precise IP scheme that you ended up with (IP assignments, bridge groups and default route) and Tony and I will duplicate it here and see what can be done to get into the box.


Yes, I am using version 1.0.3 on a 5.8Ghz link with CM9's. I have -45dB signal strength and the link is rock solid. The bandwidth test is useless above about 10Mbps. Try it on the bench. The numbers jump all around and indicate that I’m getting far less than 10Mbps when in reality I can get about 22Mbps from PC to PC through the link.

I am also using a Cisco switch between the two Ethernet ports on the war-2 so I can monitor and graph what is going on through this repeater station. Thus there are two bridge groups with the same subnet. It is a valid configuration but StarV3 only allows one IP assignment.

The problem was not that the default gateway is incorrect but rather the change of IP assignment did not activate on the other port because the gateway address is already assigned to the ether1 bridge group. It leaves the WAR with no IP at all! This is the bug. It should not be this way. I can repeat the problem on the bench. The end result is the radio is unreachable from within the subnet (on the same LAN). I now have an unusable radio and this is why I'm asking about a reset procedure. I have no problem soldering the DB-9 on the board if it will give me a working serial port like the WAR-4. This is much easier than sending boards back!

-Andy
PTI Wireless

[pti-andy]

I suppose it may not be valid with StarOS but it is valid network design and very useful. It is no different than if I were to use two different WAR boards on the same subnet. Point is that two different bridge groups should be treated as two completely different radio bridges and they are not.

It is pretty obvious that the bandwidth readout is in KBytes and not bits. This has nothing to do with the fact that the numbers get lower as the throughput gets higher. It is also not related to signal strength. This happens at any signal strength at any distance. I noticed it in the field and then ran tests in the lab and found that in all cases if I push the speed beyond 10Mbps (bits per second) the bandwidth test results in StarOS start to bounce around and the number will get lower instead of higher until they are reading an average of about half of what they should be. It's as if the CPU is to busy to give an accurate result after a certain point. This happens with SuperA/G enabled. It seems to be more stable with it disabled. Also keep in mind that I'm using a bridge and not routing with StarOS. Not sure if that has anything to do with it.

I understand the issues with Cisco Ethernet. The WAR seems to work fine with a Catalyst 2900 switch but will not talk full duplex to any Cisco 7200 PA Ethernet module period! These modules nearly always require a manual full duplex setting on the connected equipment in order to talk. Is there a way to force StarOS to run at full duplex and not negotiate?

I will duplicate the procedure on the IP assignment issue and take note of the exact steps taken. The short version is that I had a 10.0.0.50 on ether2 bridge 2 and a default gateway of 10.0.0.1 (which assigned to ether2). I then removed the IP from ether2 and assigned it to ether1. After activating changes I can't talk to the unit. I put a backup 192.168.1.1 as an additional address on a second test board so I could duplicate the issue without rendering another board useless. In that case the original 10.0.0.50 address became unresponsive and the 192.168.1.1 address was the only way to reach the board. After going back in, I saw that the 10.0.0.50 address was still there but the default gateway address was still saying it was on the other Ethernet. Basically I've noticed that if an IP address is moved from one bridge group to another that had a default gateway associated with it, the new address becomes unusable.

I assure you, I would not be reporting any of this information until after I have duplicated the findings. I am still in need of a way to get back to this board after it has lost IP connectivity. What do you suggest?

-Andy
PTI Wireless

[tkerns]

I am also seeing some strange behavior with the default gateway.

This is a test setup:

dual WAR 1.0.3 in client mode connecting to a Netgear AP that connects to my network via ethernet.

Ether1 192.168.1.1, masq to wpci1 10.1.2.79

I have 2 gateways, one at tower 2 (10.1.2.1) and one at tower 3 (10.1.2.2)
all are WRAPs running 2.10.0-4693

Tower 1 (where the netgear AP connect to is bridged using VDS to tower 2, and tower 2 is bridged to tower 3 using VDS.

If I set gateway to 10.1.2.1 it works great. I then change to 10.1.2.2 and problems. can not ping from laptop connected to WAR ether1. From the WAR I can ping the gateway fine. Tried several things, finally rebooted laptop and all is working.

Changed gateway back to 10.1.2.1 and again could not ping from laptop but could from WAR. Tried rebooting WAR, power cycled WAR, rebooted laptop, and power cycled netgear AP. At this point still can not ping, get message in dos window on laptop from 10.1.2.79 destination not available (this is IP on wireless card) (one note... even though I could ping the gateway from the WAR, I could not ping past the gateway and once I powered cycle the WAR, I then get the message from 192.168.1.1 that destination not avilable)

Switched laptop to wireless card (bypassing WAR), connected to the netgear AP and everything works through gateway 10.1.2.1, changed to 10.1.2.2 and everything works.

Is this a v3 issue or a v2 issue? Since the laptop connected to the same netgear AP can change its default gateway and work I would suspect it is a v3 issue.

Also discovered that a reboot is required to make default gateway take affect.

Tim Kerns
CV-Access

[lonnie]

Since you have two towers on the same subnet I assume you are using what you think is a bridged design. If you are using WRAP boards it is in fact a pseudo bridge which was NEVER meant for backhaul use. It is strictly to connect a few customers behind the radio.

Also, you say masq to wpci, when I hope you meant you were masq'ing from the wpci to the Ethernet that connects to your Netgear router.

[tkerns]

Since my laptop connects to the WAR via ethernet and the WAR connects to the Netgear via RF, I do have the ether IP's masq to wpci1.

My understanding as when VDS was released, it was to be able to have the same subnet on the ethernet side of a link between 2 radios, thus creating a transparent bridge. This was released because you said we were incorrectly using the bridge between the ethernet and radio on one WRAP. Now that I have been running this config for almost a year, and running fine, I am incorrectly using it?

My laptop connected wirelessly to the netgear AP works without any issues when I change the default gateway on the laptop. Only now that I am testing a WAR with v3 as a client using nat, it does not like to have the default gateway changed in the WAR.

[lonnie]

Please draw me a diagram. I have no idea what the LAN looks like and a picture will help.

There is no problem with changing a default route in the WAR, since that is very basic to its TCP and routing. If you are using VDS then I assume you have at least two VDS tunnels terminating for the two towers and that is possibly where you are having trouble.

[tkerns]

Here is the setup

Laptop <---ether-->WAR Ether1 - WAR wpci1<------> NG AP <--->ethernet SW <--->WRAP Tower1---->VDS<----WRAP tower2 <--->ethernet SW<---->2nd WRAP Tower2--->VDS< WRAP tower3 <----->ethernet SW


laptop ethernet 192.168.1.22
laptop default gateway 192.168.1.1
WAR ether1 192.168.1.1
WAR wpci1 10.1.2.79
masq from 192.168.1.0/0 to dev wpci1
default route 10.1.2.1

comming off the ethernet switch @ tower 2 is ethernet to WRAP 10.1.2.1 serving as gateway router (no wireless) ... the same @ tower3, WRAP 10.1.2.2 serving as gateway router.

gateway @ tower 2 feeds a T1, gateway @ tower3 feeds 10 meg connection from charter communications.

When I changed default gateway to 10.1.2.2 (tower3), I could ping the gateway from the WAR, but not from the laptop, I could not ping from the WAR or laptop through 10.1.2.2 to a public DNS server. After rebooting and power cycling everything, it started to work.

Switched back gateway to 10.1.2.1 (tower2). I could ping from the WAR to 10.1.2.1 but again not from laptop. Reboots and power cycles did not help (in both cases I did not try rebooting the gateway WRAPS)

changed config, bypassing the WAR

Laptop <---wireless------> NG AP <--->ethernet SW <--->WRAP Tower1---->VDS<----WRAP tower2 <--->ethernet SW<---->2nd WRAP Tower2--->VDS< WRAP tower3 <----->ethernet SW

IP of laptop 10.1.2.23
default gateway 10.1.2.1 Tower2

works as expected....pings from laptop to gateway and public DNS server

IP of laptop 10.1.2.23
default gateway 10.1.2.2 Tower3

works as expected....pings from laptop to gateway and public DNS server

I could also ping 10.1.2.79 the wpci1 radio of the WAR that was still associated to the netgear AP, was able to ssh into WAR via 10.1.2.79

It does sound like an arp issue in the network, but why doesn't it act the same way with the laptop?

[pti-andy]

Lonnie,

Per my previous post... I am still in need of an answer of how to get access to the WAR2 that has stopped responding to it's IP address.

Have you had a chance to review some of the other issues?

[tkerns]

UPDATE:

I have found that when changing gateways, arp seems to work because from the WAR I can ping both gateway..... 10.1.2.1 and 10.1.2.2, I can also ping the WAR wpci from both gateways. I just can not ping from my laptop through the WAR after I make the change.

I also found that by enabling RIP on the WAR and both gateways, all is working. I can switch back and forth and never miss a beat. Also found that a reboot of the WAR is not needed when changing the gateway, only apply changes.

[pti-andy]

Here are the steps to loose IP connectivity permanently to your WAR.

1. Create two bridge groups with ether1 <-> wpci1 and ether2 <-> wpci2.

2. Assign an IP address from the same subnet to both ether1 and ether2.

3. Create a default route that is also in the same subnet (notice that it will be assigned to ether1).

4. Active changes and get back to the interface.

5. Now remove the IP assignment from ether1.

At this point the IP assignment for ether2 is still not valid even though it is in the same subnet as the gateway and ether1 is no longer in conflict. The gateway will not associate to ether2 and there is no way to reach the radio even on the same LAN if you were to activate changes!

6. Edit the IP assignment on ether2 to one that is accessible from your LAN.

This assignment will not take effect and the radio would still be unreachable if you were to activate changes.

The only way to get back to normal is to delete the IP assignments and start over. Editing them will get you nowhere.

The bottom line is that it is pretty easy to turn your radio into a brick even though you have given it a valid IP assignment. This is why it is a bad idea to not have a console port or a reset procedure.

Since there is no console port on a WAR-2 it might be a good idea to not allow changes to be activated unless an IP assignment exists that is actually usable. This would prevent unnecessary customer support.

Speaking of which... What do I do with my WAR/Brick?

-Andy
PTI Wireless

[lonnie]

You still don't get it. It is not proper to have two bridge groups in the system with the same subnet.

If you have two bridge groups it acts like two separate switches and unless you physically connect them they can have the same IP subnets but will not talk to each other. The way to connect devices to the same logical and physical segment is by way of assigning them to a bridge group. The rudimentary IP checks we perform do not allow you to have two interfaces with IP assignments in the same subnet, so that means your assignment to ether2 is disabled. If you then delete the IP from ether1 and activate before you enable the ether2 IP you are sunk, since at that point you do not have an IP on ether1 or ether2. The default route is not material since there are no IP assignments. You seem to be trying to say this is a problem with the software, and I reject that claim, entirely. You have plunked in some numbers and done some activations before you were sure of the effects.

One thing we'll have to check for is to ensure at least one valid IP before allowing an activate, but then that can defeated by putting an IP on a radio with no ESSID. The checks could go on forever, so maybe it is just better if you are certain you have things setup right before you hit activate.

The bottom line is that you have to be careful and make sure you have a plan before you do any editing and especially before you activate.

As for editing the IP on ether2, you must ensure you edit it AND enable it. Simply changing it is no good, since if you look at the IP screen you'll that the IP is still disabled, from when you had an inappropriate IP assigned.

There are any number of ways to use these things inappropriately and have a brick at the end of the exercise. That does not suggest a problem with the hardware nor the software, at least to me. It simply tells me that the person was plugging in numbers without really paying attention and thinking about the effects of the numbers they are plugging in.

Here are the steps to loose IP connectivity permanently to your WAR.

1. Create two bridge groups with ether1 <-> wpci1 and ether2 <-> wpci2.

2. Assign an IP address from the same subnet to both ether1 and ether2.

3. Create a default route that is also in the same subnet (notice that it will be assigned to ether1).

4. Active changes and get back to the interface.

5. Now remove the IP assignment from ether1.

At this point the IP assignment for ether2 is still not valid even though it is in the same subnet as the gateway and ether1 is no longer in conflict. The gateway will not associate to ether2 and there is no way to reach the radio even on the same LAN if you were to activate changes!

6. Edit the IP assignment on ether2 to one that is accessible from your LAN.

This assignment will not take effect and the radio would still be unreachable if you were to activate changes.

The only way to get back to normal is to delete the IP assignments and start over. Editing them will get you nowhere.

The bottom line is that it is pretty easy to turn your radio into a brick even though you have given it a valid IP assignment. This is why it is a bad idea to not have a console port or a reset procedure.

Since there is no console port on a WAR-2 it might be a good idea to not allow changes to be activated unless an IP assignment exists that is actually usable. This would prevent unnecessary customer support.

Speaking of which... What do I do with my WAR/Brick?

-Andy
PTI Wireless

[palmczak]

Sounds like OSI layer issue. I cannot understand why 2 bridges (or bridge groups) cannot occupy the same IP space/ subnet.

Seems the bridge should occupy layer1/2 and IP should have nothing to do with it since it is layer 3. Much the way the awfull cisco 2900 does not care about IP's...

PTI-andy does the WAR pass traffic, is the bridge group functioning? The snag is that the access is gone.

Even if the design is not valid the board should respond to ssh session on the proper ip and subnett. A recovery procedure is necessary.

[pti-andy]

No Lonnie, you still don't get it. If you read my previous post you would have seen that the two Ethernet interfaces are tied together with a switch. The only purpose for having two separate bridge groups is to use them as two separate radios! It doesn’t matter if they are on the same subnet or not! How many networks are made up of only one radio! In your line of thinking you don't want people to use the radios independently unless you are routing. This makes running a backhaul rather difficult if you are using your own routers and want to monitor traffic with a managed switch between the two radios. Other OS’s don’t have this problem.

Further more if you want to assign an IP address to the "Illegal" interface you have to delete it first. Editing it does nothing. How is anyone supposed to know this? It's not as if you have documentation explaining the subtleties of your software! And no, I didn’t just plunk in numbers as you suggested. I assigned the correct numbers to the correct interface and it does not accept it because your previous “rudimentary check” disables the interface even though it has a valid IP!

As for checking for a valid IP before activating changes... This is a very good idea and will keep people from wasting their radios. Suggesting that you would have to check for everything in the configuration is obviously not necessary as anything else that is done wrong doesn't keep you from reaching the radio through the Ethernet port.

None of this would even be an issue at all if you hadn't removed the serial port without having a reset procedure. How many network devices do you know of have no console port or factory reset? You’ve even removed the power connector as if not a singe user would ever use it indoors. You’re just asking for trouble putting out a product like this.

I suggest you get off your high horse and look at this from a customer service perspective. I have purchased many of your products and could purchase many more. I have reported a few bugs or issues that could cause people a lot of headaches, not to mention blowing away their radio, and you want to blame the customer that brings this information to you. Your first assumption is ALWAYS that the user doesn't know what he is doing. If you just read what people are writing maybe you might understand the situation they are trying to convey to you.

Suggesting that I was just plugging in numbers without considering the effects is an insulting and immature statement. The fact is that this radio replaced a previous unit running a different OS. The configuration was duplicated exactly and is correct network design! Maybe you should stop insulting your customers and consider that they might have a valid point!

BTW, you never did answer my question after asking it three times! What am I supposed to do with the brick?

-Andy
PTI Wireless

[pti-andy]

Sounds like OSI layer issue. I cannot understand why 2 bridges (or bridge groups) cannot occupy the same IP space/ subnet.

Seems the bridge should occupy layer1/2 and IP should have nothing to do with it since it is layer 3. Much the way the awfull cisco 2900 does not care about IP's...

PTI-andy does the WAR pass traffic, is the bridge group functioning? The snag is that the access is gone.

Even if the design is not valid the board should respond to ssh session on the proper ip and subnett. A recovery procedure is necessary.


You are absolutely right. The IP address assigned to the unit simply doesn't matter becasue it is only there for managment purposes. There is no reason to reject the IP.

To answer your question... Yes, the WAR does pass traffic and works fine. I just can't manage it because access is gone!

-Andy

[lonnie]

A bridge does not require an IP to function, BUT, it does require an IP if you wish to connect to the instrument that has the bridge.

Why would a device require 2 IP addresses if it was all one big bridge?

With two separate bridge groups how do they connect? The IP has nothing to do with connecting them. They must be connected by putting them in the same bridge group.

As for the contention that the unit should respond to ssh, well, you miss the point that there is NO IP anywhere on the system. He put an invalid IP on ether2, so the system disabled it. Then he moved the default route to ether2 which had no effect whatsoever. The kicker came when he removed the IP from ether1 and then activated before enabling the IP on ether2. This removed the only remaining IP from the system. With no IP assigned to any of the devices it means that it will not respond to ssh. It might pass data but the unit is deaf to ssh.

Sounds like OSI layer issue. I cannot understand why 2 bridges (or bridge groups) cannot occupy the same IP space/ subnet.

Seems the bridge should occupy layer1/2 and IP should have nothing to do with it since it is layer 3. Much the way the awfull cisco 2900 does not care about IP's...

PTI-andy does the WAR pass traffic, is the bridge group functioning? The snag is that the access is gone.

Even if the design is not valid the board should respond to ssh session on the proper ip and subnett. A recovery procedure is necessary.

[lonnie]

There is nothing wrong with having two bridge groups tied to a switch. In fact I bet the system works.

Sorry to insult you, but the feedback that the IP was disabled is right on the IP display. You can also see that you have no IP assignments on the first devices menu. You had lots of feedback and yet you either did not look at it or you ignored it.

I react this way when a customer tries to blame me for their actions or inaction. We do a lot of checking to prevent issues and when someone ignores our output and feedback and then says we are responsible for their problem, it is just not right, and I have no tolerance for that sort of blame.

Sure there should be a recovery mechanism, and we will get something soon, when V3 for x86 is done. But as you already knew there was no recovery you really had to be more careful.

I believe I have said that you must return the unit. With no IP on any device there is nothing you can do. We must reflash it.

I'll PM the mailing address.

No Lonnie, you still don't get it. If you read my previous post you would have seen that the two Ethernet interfaces are tied together with a switch. The only purpose for having two separate bridge groups is to use them as two separate radios! It doesn’t matter if they are on the same subnet or not! How many networks are made up of only one radio! In your line of thinking you don't want people to use the radios independently unless you are routing. This makes running a backhaul rather difficult if you are using your own routers and want to monitor traffic with a managed switch between the two radios. Other OS’s don’t have this problem.

Further more if you want to assign an IP address to the "Illegal" interface you have to delete it first. Editing it does nothing. How is anyone supposed to know this? It's not as if you have documentation explaining the subtleties of your software! And no, I didn’t just plunk in numbers as you suggested. I assigned the correct numbers to the correct interface and it does not accept it because your previous “rudimentary check” disables the interface even though it has a valid IP!

As for checking for a valid IP before activating changes... This is a very good idea and will keep people from wasting their radios. Suggesting that you would have to check for everything in the configuration is obviously not necessary as anything else that is done wrong doesn't keep you from reaching the radio through the Ethernet port.

None of this would even be an issue at all if you hadn't removed the serial port without having a reset procedure. How many network devices do you know of have no console port or factory reset? You’ve even removed the power connector as if not a singe user would ever use it indoors. You’re just asking for trouble putting out a product like this.

I suggest you get off your high horse and look at this from a customer service perspective. I have purchased many of your products and could purchase many more. I have reported a few bugs or issues that could cause people a lot of headaches, not to mention blowing away their radio, and you want to blame the customer that brings this information to you. Your first assumption is ALWAYS that the user doesn't know what he is doing. If you just read what people are writing maybe you might understand the situation they are trying to convey to you.

Suggesting that I was just plugging in numbers without considering the effects is an insulting and immature statement. The fact is that this radio replaced a previous unit running a different OS. The configuration was duplicated exactly and is correct network design! Maybe you should stop insulting your customers and consider that they might have a valid point!

BTW, you never did answer my question after asking it three times! What am I supposed to do with the brick?

-Andy
PTI Wireless

[pti-andy]

Lonnie… You keep mentioning that the IP address entered is invalid. It is NOT. Your software just decided not to use it. Having an IP address on each Ethernet interface is very useful when you are running traffic and speed tests. It also provides a way to reach the radios from each side of the network if something were to go wrong in between. Having only one IP address for two different bridges is a strange limitation and I think anyone would agree with me on this.


It was not obvious that the second IP was useless. When you see an IP address being displayed you assume it is ACTUALLY assigned. The little “*” next to the IP address did not mean anything to me at the time. These things are obvious to you as the programmer of the software but not to an end user who has spent years configuring equipment and knows that when and IP is being displayed it must be real. The kicker came when I edited the IP address, activated changes, and then had no connectivity to the equipment. Believe me, I wasn’t careless! This radio is in service on my network and loosing connectivity means I have to send my tech out to replace it.

I reported this situation to you so that it can be improved and to prevent others from making the same mistake. Just because your software makes sense to you doesn’t mean that others will understand it the same way. The point is not to blame you for anything but to get it fixed and come to an understanding of what can happen. The combination of this software quirk and no recovery procedure led to this. There were no warnings that this would happen. It just did. The only blame that was assigned was by you and put squarely on the end user first as a bad configuration and then as ignorance. How are you ever going to get any feedback on the operation of your software with an attitude like this? You seem to have no concept of customer service and plain good business practice. How much “tolerance”, as you put it, am I suppose to have as a paying customer?

At this point it is water under the bridge. Your can consider this a learning situation, and make improvements, or ignore it and have to re-flash more units. I certainly have learned the hard way.

-Andy
PTI Wireless

[tony]

I have been silently monitoring this thread. I do agree with pti-andy, that the '*' (disabled IP indicator) beside the IP is easy to miss, especially if you are not expecting it.

I will see about improving how the system informs you that a specific IP has been disabled, and also see what can be done in cases where there are no active IPs present in the system at the time of activation.

[palmczak]

First let me state the purpose is for better understanding. Not the least of which is brick prevention. :-)

I am needing to know what invalidated the IP assigned to the second bridge group. I can think of several firewall scenarios where IP's in the same subnet could be assigned to different bridge groups. That is not to say I think this is the best design however, depending on the network configuration on the ethernet and wireless sides of this I cannot say it is invalid from a pure network standpoint.




As for the contention that the unit should respond to ssh, well, you miss the point that there is NO IP anywhere on the system. He put an invalid IP on ether2, so the system disabled it. Then he moved the default route to ether2 which had no effect whatsoever. The kicker came when he removed the IP from ether1 and then activated before enabling the IP on ether2. This removed the only remaining IP from the system. With no IP assigned to any of the devices it means that it will not respond to ssh. It might pass data but the unit is deaf to ssh.

[tony]

As a general rule of routing, you cannot have two interfaces (virtual, physical or bridge) that share an IP that is part of the same subnet.

If one attempts to do this in the interface, it will silently disable the IP that is in conflict. (by placing a '*' beside the IP in the list). If you try and enable the IP, only then will it actually tell you why it was disabled. (this behaviour will be changed for better feedback).

[lonnie]

The premise is that standard routing uses the subnet mask to determine whether the IP is local, meaning it is available through a device, or if it needs to go out the default route and let another system try and deliver the packet to its local subnet or send it out its default, etc.

If you have two IP addresses on different devices but within the same subnet, how is the system supposed to decide which device it will use for the local delivery, and if you have a default in the same subnet as the multiple IP assignments, which device is used for that?

In short, it is a mistake. It might sort of work, but it is not proper. In computers and communications you want it to be correct so that it will always do the right thing. If it is working because of some default action or inaction that could change at some later date then you then have a lot of work trying to figure out why something that always worked suddenly stopped.

We spend a lot of time anlayzing the operation of code and we try and make things always do something that was what we expected, thus something that is random or ambiguous, we treat it as an error.

First let me state the purpose is for better understanding. Not the least of which is brick prevention. :-)

I am needing to know what invalidated the IP assigned to the second bridge group. I can think of several firewall scenarios where IP's in the same subnet could be assigned to different bridge groups. That is not to say I think this is the best design however, depending on the network configuration on the ethernet and wireless sides of this I cannot say it is invalid from a pure network standpoint.

[palmczak]

Thanks Tony.

Also thatks for the change to V3 behavior. My understanding of this problem is that thet are different bridges (AKA bridge groups) this is very different than 2 interfaces that share the same IP space. My analogy is 2 VLANs that share the same IP space.



As a general rule of routing, you cannot have two interfaces (virtual, physical or bridge) that share an IP that is part of the same subnet.

If one attempts to do this in the interface, it will silently disable the IP that is in conflict. (by placing a '*' beside the IP in the list). If you try and enable the IP, only then will it actually tell you why it was disabled. (this behaviour will be changed for better feedback).

[tony]

Not a problem. Regarding the bridge groups; they may be two separate segments to the outside world, however when they are added to the star-v3 system, they are treated as standard interfaces, which must follow the same assignment rules, if you need an IP on the group for management purposes.

[pti-andy]

Thanks Tony for clearing this up. I see now that even though it can be set up as two different bridges, internally the management interface can only choose one of them to operate from. Not sure if there is a way around this with this OS or how the previous system I upgraded from dealt with it but it would be very useful if it is possible.

I'm glad to hear that you will implement a safeguard against this problem in the future. I have no problem with the '*' indication on the disabled IP now that I know what it is. Simply not allowing the “activate” without an IP assignment would fix the issue. It would cause one to go back and figure out what is wrong and notice the IP didn't get assigned. The '*' would then make sense just as it did when I tried to duplicate what went wrong afterwards.

-Andy
PTI Wireless

[Stratolinks]

Let's see anyone try to put IPs that are in the same subnet on 2 interfaces on any OS and have it work correctly all the time. It won't happen. Most OS's won't even allow it.

You could do this if you had used 2 WARs for this, but not by trying to use one. Not only that but when you said that these ethernet ports connect to the same switch, the rationale behind this becomes even more confusing. If they are on the same physical switch, why do you need 2 different IPs on the same subnet to access the same device? You may want to treat it as 2 devices, but it is one device. If you really want 2 devices, then use 2 devices.

I never ceases to amaze me how many of the problems that are reported here go back to a lack of basic knowledge of TCP networking. This isn't the place to learn the basics. You can find a wealth of information on the net. Some even decide to bridge so they don't have to learn the stuff.

Yes, I suppose a tweak to the OS that pops up to say why an IP assignment has been disabled by the OS may be beneficial to help protect the user, but not required.

I rant so I'll step down off my soap box now.

[pti-andy]

Let's see anyone try to put IPs that are in the same subnet on 2 interfaces on any OS and have it work correctly all the time. It won't happen. Most OS's won't even allow it.

You could do this if you had used 2 WARs for this, but not by trying to use one. Not only that but when you said that these ethernet ports connect to the same switch, the rationale behind this becomes even more confusing. If they are on the same physical switch, why do you need 2 different IPs on the same subnet to access the same device? You may want to treat it as 2 devices, but it is one device. If you really want 2 devices, then use 2 devices.

I never ceases to amaze me how many of the problems that are reported here go back to a lack of basic knowledge of TCP networking. This isn't the place to learn the basics. You can find a wealth of information on the net. Some even decide to bridge so they don't have to learn the stuff.

Yes, I suppose a tweak to the OS that pops up to say why an IP assignment has been disabled by the OS may be beneficial to help protect the user, but not required.

I rant so I'll step down off my soap box now.
Let’s not rehash the same topic again. If you read all of the previous posts you would see why the second IP is needed and why there is a switch in between the bridges. Secondly having two bridges IS the same thing as having two WAR's. At least it was to the previous OS I was running. Thirdly you are assuming that I am bridging because I don't understand how to route. For your information this is a backhaul between two Cisco 7200 chassis running BGP. A bridge is the single best way to connect these two devices. Not everyone uses StarOS to route their network. So please stop criticizing if you don't have anything constructive to say.


Andy
PTI Wireless

[jeff]

Originally Posted by Stratolinks
Let's see anyone try to put IPs that are in the same subnet on 2 interfaces on any OS and have it work correctly all the time. It won't happen. Most OS's won't even allow it.

The above point is valid and usefull. Having any number of bridge groups is valid, trying to put management ip addresses from the same subnet on each of them is highly questionable.

From the operating systems point of view if it gets a packet on one interface that is destined for the other interface it should just drop it because it knows the address is not for it, but it is on its hardware segment so it is valid to assume that it will be handled by another device on the segment. Many interfaces use hardware to make this choice and it isn't even up to the driver.

[pti-andy]

Originally Posted by Stratolinks
Let's see anyone try to put IPs that are in the same subnet on 2 interfaces on any OS and have it work correctly all the time. It won't happen. Most OS's won't even allow it.

The above point is valid and usefull. Having any number of bridge groups is valid, trying to put management ip addresses from the same subnet on each of them is highly questionable.

From the operating systems point of view if it gets a packet on one interface that is destined for the other interface it should just drop it because it knows the address is not for it, but it is on its hardware segment so it is valid to assume that it will be handled by another device on the segment. Many interfaces use hardware to make this choice and it isn't even up to the driver.
The issue here isn't weather you can have IP's from the same subnet on different bridges or devices, obviously you must or none of the wireless systems on the market today would function. The issue is weather StarOS treats two bridges as two different devices. Other OS's that I have used treat each bridge as a separate device. Each must have an IP if you are to manage or monitor its interface. This goes for Alvaion, Ikarus, you name it.

From the information Tony has given, StarOS internally does not treat the bridge group as an entirely separate device. This is a limitation if you want to monitor traffic with MRTG on a switch and run pings to each interface. Before I upgraded to StarOS each bridge had its own IP. Now it doesn't. This is ok now that it is clear but there was no way of knowing at the time that the IP would be unusable. I now have to use two different boards for my monitoring and testing instead of one even though each board is capable of two different bridges.

The lesson to learn from this is that it IS possible to loose an IP address. It is not necessary to have pop-up messages etc. to this effect. Just a simple check in the activate code that prevents one from loosing IP connectivity.

-Andy
PTI Wireless

[lonnie]

You are mistaking access to the "system" which requires a single IP. The bridges are indeed treated as separate devices but you do not require an IP to configure the bridge, you simply require access, by an IP on any device, to gain access to the system and configure all aspects of the system.

You can do your monitoring, you just have to assign another IP to the second bridge.

You can put an IP on all devices, they just cannot be from the same subnet. Any system that allows that is in error and as the OS gets upgraded you could find its behaviour might change.


The issue here isn't weather you can have IP's from the same subnet on different bridges or devices, obviously you must or none of the wireless systems on the market today would function. The issue is weather StarOS treats two bridges as two different devices. Other OS's that I have used treat each bridge as a separate device. Each must have an IP if you are to manage or monitor its interface. This goes for Alvaion, Ikarus, you name it.

From the information Tony has given, StarOS internally does not treat the bridge group as an entirely separate device. This is a limitation if you want to monitor traffic with MRTG on a switch and run pings to each interface. Before I upgraded to StarOS each bridge had its own IP. Now it doesn't. This is ok now that it is clear but there was no way of knowing at the time that the IP would be unusable. I now have to use two different boards for my monitoring and testing instead of one even though each board is capable of two different bridges.

The lesson to learn from this is that it IS possible to loose an IP address. It is not necessary to have pop-up messages etc. to this effect. Just a simple check in the activate code that prevents one from loosing IP connectivity.

-Andy
PTI Wireless

[jeff]

No the problem "is" that the addresses are on the same subnet. There is no problem with putting an address on each bridge. One way or the other the os now has to make an ambiguous choice about which interface to use if it needs to send a packet to a device on that subnet. Pretend you are the os and you receive a packet or generate one internally that is on the subnet that your two interfaces are on ... which hardware interface do you use to send it out? Depending on the choice made and the upstream topology you could easily convince an upstream device that there is a loop and end up with spanning tree shutting down a port. What your asking for is more of a virtualization scheme where you can define bridge groups and have them act like they are not all on the same machine. I will stick with the answer that just because you got something like this to work for you in the past does not mean it is a good idea.

The statement that putting addresses on two interfaces on the same box that are on the same subnet will break something eventually is valid, which is all I was replying to. Unless there is another point that would be usefull to others maybe this thread can just die now.

[jeff]

Lonnie was editing his reply while I was posting mine and got in first. I just read his and totally agree. Two ways of saying the same thing.

[pti-andy]

Jeff, I understand and agree with your explanation and neither what you or Lonnie is saying is in question. The point that you are making is that there is only one process communicating through two different devices. This is simple and clear and became apparent in Tony’s post.

There are other ways however to handle this issue which is addressed in switches with VLAN segments and other bridge devices. An example is the Alvarion base station we are running requires an IP on each interface to manage it. Since these are only bridges they must be of the same subnet or you wouldn’t be able to reach them. Each interface has its own process that configures it. The Ikarus OS that I was running allows the assignments to two different bridges with no problem however you could only use one IP at a time to manage it thus keeping it local to one interface. This is no problem because each bridge responds to IP requests only through its own interface. The virtualization you spoke of is yet another example. These concepts to handle multiple IP’s are done and are common practice.

I also agree that it would be a bad idea to use two IP’s of the same subnet if the system was not designed that way. This is why any good device including StarOS doesn’t allow it. All of this is basic IP concept and not in question.

The point is that there are many systems that are designed to operate independently. The problem I ran into was making the conversion from one that was to one that wasn’t without a clear indication of this.

All of that being the case is not what did the radio in. When changes were activated there was only one IP assignment. It just wasn’t active. Not knowing that the subtle ‘*’ meant the IP is inactive is what did it. I posted this information so people could see how easy it was to blow away their radio and not to do what I did. I did not intend to start a debate on the finer points of IP design.

I agree that we have beaten this one to death. The silver lining is that some error checking may now be employed in the 'activate' code to prevent this from happening to others.

-Andy
PTI Wireless

[jeff]

There are other ways however to handle this issue which is addressed in switches with VLAN segments and other bridge devices. An example is the Alvarion base station we are running requires an IP on each interface to manage it. Since these are only bridges they must be of the same subnet or you wouldn’t be able to reach them. Each interface has its own process that configures it. The Ikarus OS that I was running allows the assignments to two different bridges with no problem however you could only use one IP at a time to manage it thus keeping it local to one interface. This is no problem because each bridge responds to IP requests only through its own interface. The virtualization you spoke of is yet another example. These concepts to handle multiple IP’s are done and are common practice.

I hate to start this up again, but if they are bridges why would they care if each interface is on the same subnet. A bridge is doing everything at the mac level so as long as each interface replies to a "who has" query it should make no difference which subnet they are on. And just for the benefit of lurkers, I am aware of no exception where multiple ip's on the same subnet on different interfaces controlled by the same routing daemon will not fail in some circumstance. Some type of specialized hardware that uses a different routing process to control different groups of interfaces could work this way but I have yet to deal with it. Vlans could make something like this work if they tagged the traffic on each bridge seperately, but that means in principle no matter what the subnetting they are no longer on the same hw segment.

[pti-andy]

No problem. The bridges don't care what subnet they are on, but must be on the same subnet in order to manage them with a PC on that subnet. Sure you can have each one on a separate routed interface but this is not how they intended it to be used. This is one chassis with multiple radio and Ethernet interfaces all tied to a switch. The software scans each MAC address and displays it’s IP to be managed. This allows them to manage all devices (AU and SU) on the same subnet at once. You can make changes globally or one at a time. The routing is left up to you and is normally placed at the CPE end of the bridge. They are not controlled by the same routing daemon because they are not routers with multiple interfaces. Each bridge is its own device controlled by a separate process. This is how the vast majority of the early wireless systems work and many today that are based on bridging but use a common management tool.

-Andy
PTI Wireless