IPSEC wireless router ?

Page 2 - Seeking answers? Join the Tom's Hardware community: where nearly two million members share solutions and discuss the latest tech.
Archived from groups: comp.sys.ibm.pc.hardware.chips (More info?)

On Sun, 25 Sep 2005 11:30:25 +0200, DEMAINE Benoit-Pierre
<nntp_pipex@demaine.info> wrote:

>learn abit about the french product called 'freebox':
>it natively support wireless routing, and it is REALLY A ROUTER:
>software conf can activate (or not) routing to wireless; by default it is off and
>you can only access wired part.

You still aren't getting my point. 802.11 wireless is bridging.
Where you attach a router and what it does is not part of 802.11.
There's not one word that even mentions routeing or IP addresses in
the IEEE 802.11 specifications.
http://standards.ieee.org/getieee802/802.11.html
Download any of 802.11a/b/g specs and find me where it says "router".

>I mean that in this device, the wireless card is not briged.

All 802.11 wireless cards are bridged. You can attach a router at
both ends and hide the bridging from the client, but the basic
protocol is bridging.

>> Wanna bet? If you ignore the router part of the puzzle and just play
>> with an access point, the IP address of the access point can be
>> literally anything. In fact, that's exactly what I do on wireless
>> systems that I don't want the users to tinker with the access points.
>> I set the management IP address of the access point to something
>> that's out of the usual 192.168.1.0/24 block.
>
>what is your point in this part ?

That with bridging, it's not important that the IP address of the
wireless device be in the same subnet as the wireless LAN.

>>>what happens is that for simplicity, and dummy compliance, all manifacturers do
>>>brige wireless to wired ... BUT on all firewalling tutos, you will find that this
>>>kind of briging DO require to be activated ... aka is NOT available before you
>>>explicitely ask for it.
>>
>> Sorry. I don't understand what you're asking or saying.
>
>hmmm, did you ever try to activate WDS ?


I don't understand your terms "dummy compliance", "tutos", and what
needs to be "activated". What does WPA have to do with anything in
bridging and routeing. WPA encryption is totally transparent to both.

>did you read routing table of a WRT54g ?

> ~ # netstat -r
> Kernel IP routing table
> Destination Gateway Genmask Flags MSS Window irtt Iface
> 192.168.111.0 * 255.255.255.0 U 40 0 0 br0
> 63.198.98.0 * 255.255.255.0 U 40 0 0 vlan1
> 127.0.0.0 * 255.0.0.0 U 40 0 0 lo
> default adsl-63-198-98- 0.0.0.0 UG 40 0 0 vlan1

What should I read in there? That's the router part of the WRT54G.

>if yes, read me again ...

Done. I still don't understand what you're asking or suggesting.

>question is: can ahardware router do it for me ?

Do you want everything in one box? If so, I've listed 3 possible
wireless VPN routers. If you can live with everything in seperate
boxes, then it can be done with a much wider and cheaper variety of
boxes.

>> Good luck. IPsec is no fun to setup. Lots of settings. Lots of
>> potential incompatibilities between servers and clients. Lots of
>> things to go wrong. To the best of my knowledge, nobody has a
>> non-manual IPSec VPN setup.
>
>that why I ask hardware device

Hardware IPSec is about the same complexity as software (FreeSWAN)
especially when dealing with poorly defined features such as replay
protection. I've seen compatibility issues that were not fun to
troubleshoot.

>I have been customer in a network you describe: it was deadly slow and unstable:
>breaking the root switch shotdown whole the network ... for example when you unplug
>the switch the leads to the DHCP server room ...

I'm not suggesting you build a complex network for your home wireless.
I'm simply suggesting that you seperate the modem, VPN router, and
wireless access point into three seperate boxes. I can list the
benifits when you're ready to listen.


--
Jeff Liebermann jeffl@comix.santa-cruz.ca.us
150 Felker St #D http://www.LearnByDestroying.com
Santa Cruz CA 95060 http://802.11junk.com
Skype: JeffLiebermann AE6KS 831-336-2558
 
Archived from groups: comp.sys.ibm.pc.hardware.chips (More info?)

The TZ 170 SP Wireless allows network administrators to create user accounts for
occasional guest users such as consultants and contractors that permit wireless
connections to the Internet without providing access to the corporate network.

sounds nice ... I need to read again tonight ...

--
DEMAINE Benoit-Pierre (aka DoubleHP ) http://www.demaine.info/
\_o< If computing were an exact science, IT engineers would not have work >o_/
 
Archived from groups: comp.sys.ibm.pc.hardware.chips (More info?)

David Taylor wrote:
> It's not new Duane. All you're doing is blocking traffic by port. I'm
> surprised that it's new to you.
>
> The main advantage of IPSec is the Sec part, i.e. security. Simply
> creating filters and a filter action like you are doing is the very
> simplest start. What the original poster wanted was security which to
> do properly requires a PKI implementation. Then you get mutual
> authentication and encryption, none of which you have right now.

at a 94 IETF meeting in the gateway working group ... a friend
introduced something that has since come to be called VPN. my view was
that it somewhat upset the ipsec people ... since they were working on
end-to-end. the issue with ipsec has been that it required updates to
all the deployed (mostly kernel) tcp/ip protocol stacks. VPN could be
deployed w/o impacting current installed systems. eventually things
were somewhat patched over with the ipsec people labeling VPNs as
light-weight ipsec ... and lots of other people referring to ipsec as
heavy-weight ipsec. there was at least one vendor who announced a
purely vaporware vpn product that dec. ... in response to the uptake of
the concept after the ietf meeting.

to a large degree, the apperance of SSL was because of the same factor
.... the difficulty with doing end-to-end ipsec because of its
impacting, existing deployed systems.

towards the end of 94, my wife and i got called in to cpmsult with the
small client/server company that had come up with ssl ... who wanted to
do payments on their server
http://www.garlic.com/~lynn/aadsm5.htm#asrn2
http://www.garlic.com/~lynn/aadsm5.htm#asrn3

at the time, they had this stuff that was going to use something called
digital certificates issued by these organizations called certification
authorities (as part of something called PKI). as part of doing
payments ... we had to go around and do some end-to-end business audits
on these organizations calling themselves certification authorities ...
some collected postings on the subject off SSL certificates
http://www.garlic.com/~lynn/subpubkey.html#sslcert

SSL implementation at the time was one-way authentication between the
server and the browser. using SSL for the webserver to payment gateway
traffic ... we required an SSL implementation that supported mutual
authentication.

however, as part of that effort, we coined the term "certificate
manufactoring" ... since the majority of the operations weren't
actually doing full-fledge PKIs ... no actual management and
administration of the certified information (contained in the digital
certificates) ... just the straight-forward manufactoring of the
certificates. In fact, numerous certificate-based infrastructures from
the period would rely on existing business operations for
administration of the current validaty of the certified information (as
opposed to actually deploying a full-fledge PKI). The issue then was
that for such operations ... it was quite a trivial proof to show that
the digital certificates were redundant and superfluous (if you were
relying on existing business operations for real-time validity ... then
it was a very short step to having existing business operations also
providing public keys in real time).

there is now even cross-over between the original 94 vpn and the 94 ssl
.... with the apparance of ssl-based VPNs.

the basic technology is asymmetric key cryptography; what one key (of a
key-pair) encodes, the other key decodes (to differentiate from
symmetric key which uses the same key for both encoding and decoding).

there are business process applications of asymmetric key cryptography
called "public key" (where one key is identified as public and made
available, and the other key is identified as private and kept
confidential and never divulated) and "digital signature" (which
involves encoding a hash of a message/document with a private key).

However, there are numerous examples of infrastructures that use public
keys, digital signatures, encrypted channels that don't involve PKI,
certification authorities, and/or digital signatures.

one of the most prevalent authentication infrastructures is RADIUS ...
starting out having been a userid/password implementation. There have
been extensions to RADIUS where public keys are registered in lieu of
passwords and digital signatures used for authentication ... totally
certificateless operation
http://www.garlic.com/~lynn/subpubkey.html#radius

another wide-spread authentication environment is KERBEROS, found as
integral part of a large number of platforms. the original pk-init
specification had public keys being registered in lieu of passwords and
supporting digital signature authentication ... again a certificateless
operation
http://www.garlic.com/~lynn/subpubkey.html#kerberos

pk-init specification was later upgraded to also include PKI and
certificate-based operation ... supporting the ability for total
strangers to log on to your system ... recent lengthy description
http://www.garlic.com/~lynn/2005q.html#23 Logon with Digital Signature

another public key, non-PKI authentication and confidential
infrastructure with relatively wide deployment is SSH
http://www.openssh.com
http://www.ssh.com

in any case, IPSEC PKI infrastructure can carry with it a much heavier
infrastructure operation than is actually needed for public key
authentication and encryption (and even can be redundant and
superfluous compared to simple upgrades to existing management and
administrative operation).
http://www.garlic.com/~lynn/subpubkey.html#certless
 
Archived from groups: comp.sys.ibm.pc.hardware.chips (More info?)

> The TZ 170 SP Wireless allows network administrators to create user accounts for
> occasional guest users such as consultants and contractors that permit wireless
> connections to the Internet without providing access to the corporate network.
>
> sounds nice ... I need to read again tonight ...

But you can do that with any AP that provides multiple SSID's (or a
couple of AP's) that map to seperate VLAN's, one for employees and one
VLAN going straight out to the internet.

David.
 
Archived from groups: comp.sys.ibm.pc.hardware.chips (More info?)

Can you stop posting to me like a *bitch*. That's all you amount to me is
that and nothing else. And that's what you would be viewed as in the *hood*
or on the *streets* a man acting like a *bitch*.
 
Archived from groups: comp.sys.ibm.pc.hardware.chips (More info?)

> Can you stop posting to me like a *bitch*.

I just want to make a correction here. I don't want you *bitching* about it.
<g>

Can you stop posting to me like a *bitch*?
 
Archived from groups: comp.sys.ibm.pc.hardware.chips (More info?)

On 25 Sep 2005 12:33:53 -0700, lynn@garlic.com wrote:

I'll risk a bit of topic drift here...

>to a large degree, the apperance of SSL was because of the same factor
>... the difficulty with doing end-to-end ipsec because of its
>impacting, existing deployed systems.

Difficulty is an understatement. The AH encapsulation would
effectively prevent re-writing the header on NAT firewalls making that
useless. At least ESP payload only works though NAT. Replay attack
prevention seems to cause some compatibility issues with different
implementations. I lost count of how many different encryption and
authentication protocols were available. Compatibility still seems to
be a problem:
http://nscsysop.hypermart.net/vpnnat.html
I've also lost count of how many bug reports I've submitted to
manufacturers over VPN compatibility issues. My guess(tm) is that SSL
is becoming popular because it offers considerable simplicity and
compatibility.

>however, as part of that effort, we coined the term "certificate
>manufactoring" ... since the majority of the operations weren't
>actually doing full-fledge PKIs

Well, part of the incentive was the Verisign was charging ridiculous
amounts for a server certificate. That might be justifiable with a
big ecommerce site, but not with a small hosted web site that just
wants something better than a password. If Verisign had recognized
the market and priced their PKI services accordingly, there would not
have been any need for the "certificate manufactorys".
| http://www.cacert.org
| http://www.instantssl.com
| http://www.thawte.com


>it was quite a trivial proof to show that
>the digital certificates were redundant and superfluous (if you were
>relying on existing business operations for real-time validity ... then
>it was a very short step to having existing business operations also
>providing public keys in real time).

Well, when the browser now says "Just click here to accept this
certificate as valid" without the slightest authentication, one might
as well pretend that everything is valid. As I recall that was in
response to MS expiring all their certificates issued with Windoze
runtimes in 2000(?) combined with the social engineering of some MS
certificates from Verisign, where MS discovered they had no way to
revoke a certificate.

>there is now even cross-over between the original 94 vpn and the 94 ssl
>... with the apparance of ssl-based VPNs.

Yes, for good reason. The browsers all have SSL capability and an SSL
based VPN can therefore be deployed with a minimum of butchery on the
client side.
| http://www.whalecommunications.com/site/Whale/Corporate/Whale.asp?pi=291
| http://www.cisco.com/en/US/netsol/ns340/ns394/ns171/ns125/networking_solutions_white_paper09186a00801d3583.shtml

>However, there are numerous examples of infrastructures that use public
>keys, digital signatures, encrypted channels that don't involve PKI,
>certification authorities, and/or digital signatures.

Ummm.... Pre shared keys? (Never mind).

>in any case, IPSEC PKI infrastructure can carry with it a much heavier
>infrastructure operation than is actually needed for public key
>authentication and encryption (and even can be redundant and
>superfluous compared to simple upgrades to existing management and
>administrative operation).

We're talking about a home user with probably a handful of potential
users. The alleged benefit of PKI is that it authenticates the
terminating web pages as being whom they claim to be. I've setup
bogus servers to see how typical clients react. I've found that some
method of authentication is a required as almost all users are
clueless when a counterfeit web page appears. I even got caught in my
own trap when I forgot to turn it off one day. Same with a faked SSID
hot spot running HostAP. One doesn't really "need" PKI and a CA to do
the authentication, but methinks it is generally a good idea.



--
Jeff Liebermann jeffl@comix.santa-cruz.ca.us
150 Felker St #D http://www.LearnByDestroying.com
Santa Cruz CA 95060 http://802.11junk.com
Skype: JeffLiebermann AE6KS 831-336-2558
 
Archived from groups: comp.sys.ibm.pc.hardware.chips (More info?)

Jeff Liebermann wrote:
> On 25 Sep 2005 12:33:53 -0700, lynn@garlic.com wrote:
>
> I'll risk a bit of topic drift here...

u cant be more offtopic that those 2 insulting guys ...

> We're talking about a home user with probably a handful of potential
> users. The alleged benefit of PKI is that it authenticates the
> terminating web pages as being whom they claim to be.

if you consider really secure systems, those where the user is really user, and not
root or admin ...

how could a simple user land browser install a certificate the kernel could use to
establish a new network layer ?

that would require right separation that are planed in GNU/Hurd, and not that stable
in UML, or fuse ...

=> point is: there is no use to tell about SSL support of browser:
root ought to
wget gateway/certificate
then restart a daemon ...

> I've setup
> bogus servers to see how typical clients react. I've found that some
> method of authentication is a required as almost all users are
> clueless when a counterfeit web page appears. I even got caught in my
> own trap when I forgot to turn it off one day. Same with a faked SSID
> hot spot running HostAP. One doesn't really "need" PKI and a CA to do
> the authentication, but methinks it is generally a good idea.

one point for you (regarding most admins thinking ...)

about me:
I am the only admin on all box I install, especially on my familly's computers ...

and that is not enough yet to prevent them doing stupid things ...

the worse things are now impossible to them:
- I hey, I found that free demo CD in supermarket, but it says I have no right to
install it
- I made you not to have this right because I knew you would try to install it !

what happened for real:
- I was given this CD that offers cheap internet access
- you already have cheap internet access for the same price as the one on your new
CD, exept that you attemp to install your stuipd CD broke IE down

by that time, my dad was admin on the box, and the CD broke out all GUI of IE,
including home page, connection params, bookmarks and so on ... after what my
brother (7y more experience in IT than me) founded about 18 troyans on their (live)
box ... I founded 8 more ones using offline scan ...

(hell, a brother who claims to be IT professionnal, and does AV scan on a live box
.... I cant believe it)

--
DEMAINE Benoit-Pierre (aka DoubleHP ) http://www.demaine.info/
\_o< If computing were an exact science, IT engineers would not have work >o_/
 
Archived from groups: comp.sys.ibm.pc.hardware.chips (More info?)

>>did you read routing table of a WRT54g ?
>
>
>>~ # netstat -r
>>Kernel IP routing table
>>Destination Gateway Genmask Flags MSS Window irtt Iface
>>192.168.111.0 * 255.255.255.0 U 40 0 0 br0
>>63.198.98.0 * 255.255.255.0 U 40 0 0 vlan1
>>127.0.0.0 * 255.0.0.0 U 40 0 0 lo
>>default adsl-63-198-98- 0.0.0.0 UG 40 0 0 vlan1
>
>
> What should I read in there? That's the router part of the WRT54G.
>
>
>>if yes, read me again ...
>
>
> Done. I still don't understand what you're asking or suggesting.

YOUR STUPIDITY HIDES YOU THAT BR0 HAD TO BE SET UP MANUALLY !!!

I never had access to any WRT in my life (just touch the plastic box in a shop), BUT
YOU SHOW ME TOURSELF THAT I AM RIGHT IN MY ASSUPMTIONS !!!

go and try set up a WDS gateway, and you will learn from life that there is no such
thing like what you think life is.

some clue to help your mind:
what is br0 ? how to set it up ?
have you ever seen a hardware NIC that the driver makes available as br0 ?
if it's really a linux running around, why arnt there eth0 and eth1 in the routing
tables ???

have you ever seen on the market a hardware NIC that does at the same time wired and
non-wired ?
I never did => where are eth0 and wlan0 ???

===>>> stop writing clueless, and stop insulting and arguing with David, Duane, or
who ever they are.

--
DEMAINE Benoit-Pierre (aka DoubleHP ) http://www.demaine.info/
\_o< If computing were an exact science, IT engineers would not have work >o_/
 
Archived from groups: comp.sys.ibm.pc.hardware.chips (More info?)

On Mon, 26 Sep 2005 22:54:37 +0200, DEMAINE Benoit-Pierre
<nntp_pipex@demaine.info> wrote:

>YOUR STUPIDITY HIDES YOU THAT BR0 HAD TO BE SET UP MANUALLY !!!

The setup is stock Sveasoft Alchemy.
~ # cat /etc/motd
------------------------------------------
Welcome to the Sveasoft WRT54G/GS Firmware
Alchemy-V1.0 build
version v3.37.6.8sv
USE OF THIS FIRMWARE IS AT YOUR OWN RISK
http://www.sveasoft.com

>I never had access to any WRT in my life (just touch the plastic box in a shop), BUT
>YOU SHOW ME TOURSELF THAT I AM RIGHT IN MY ASSUPMTIONS !!!
>
>go and try set up a WDS gateway, and you will learn from life that there is no such
>thing like what you think life is.

WDS is fairly simple to setup.
http://www.linksysinfo.org/modules.php?name=Content&pa=showpage&pid=7

>some clue to help your mind:
>what is br0 ? how to set it up ?
>have you ever seen a hardware NIC that the driver makes available as br0 ?
>if it's really a linux running around, why arnt there eth0 and eth1 in the routing
>tables ???

It's Linux:
~ # uname -a
Linux router 2.4.20 #2 Thu Apr 21 19:40:17 CEST 2005 mips unknown

br0 is the bridge port and can be linked to any of the other bridged
ethernet ports on the switch. I'll guess (not sure) that the routeing
table uses br0 instead of eth0 because br0 is the filtered port name
while eth0 is the unfiltered port name.

Incidentally eth0 and eth1 are there.

~ # ifconfig
br0 Link encap:Ethernet HWaddr 00:0C:41:9C:3D:10
inet addr:192.168.111.33 Bcast:192.168.111.255
Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:87104 errors:0 dropped:0 overruns:0 frame:0
TX packets:111983 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:10605896 (10.1 MiB) TX bytes:47923183 (45.7 MiB)

eth0 Link encap:Ethernet HWaddr 00:0C:41:9C:3D:10
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:268597 errors:0 dropped:0 overruns:0 frame:0
TX packets:274490 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:70588908 (67.3 MiB) TX bytes:64626923 (61.6 MiB)
Interrupt:3 Base address:0x2000

eth1 Link encap:Ethernet HWaddr 00:0C:41:9C:3D:11
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:0 errors:0 dropped:0 overruns:0 frame:0
TX packets:66 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:100
RX bytes:0 (0.0 B) TX bytes:6331 (6.1 KiB)
Interrupt:4 Base address:0x8000

lo Link encap:Local Loopback
inet addr:127.0.0.1 Mask:255.0.0.0
UP LOOPBACK RUNNING MULTICAST MTU:16436 Metric:1
RX packets:1170 errors:0 dropped:0 overruns:0 frame:0
TX packets:1170 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:96923 (94.6 KiB) TX bytes:96923 (94.6 KiB)

vlan0 Link encap:Ethernet HWaddr 00:0C:41:9C:3D:10
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:87085 errors:0 dropped:0 overruns:0 frame:0
TX packets:188737 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:11164196 (10.6 MiB) TX bytes:53280155 (50.8 MiB)

vlan1 Link encap:Ethernet HWaddr 00:0C:41:9C:3D:11
inet addr:63.198.98.51 Bcast:63.198.98.255
Mask:255.255.255.0
UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
RX packets:181414 errors:0 dropped:0 overruns:0 frame:0
TX packets:85673 errors:0 dropped:0 overruns:0 carrier:0
collisions:0 txqueuelen:0
RX bytes:54582227 (52.0 MiB) TX bytes:11338413 (10.8 MiB)


>have you ever seen on the market a hardware NIC that does at the same time wired and
>non-wired ?
>I never did => where are eth0 and wlan0 ???

wlan0 is wl0

~ # cat /proc/net/wl0
wl0: Aug 2 2004 14:32:51 version 3.60.13.0
resets 23681
perm_etheraddr 00:0c:41:9c:3d:12 cur_etheraddr 00:0c:41:9c:3d:12
board 0x1603, board rev 4.5
wsec 1 auth 0 wsec_index 0 wep_algo 1
rate_override 0
antdiv_override 3 txant 3
current_bss.BSSID 00:0c:41:9c:3d:12
current_bss.SSID "LearnByDestroying"
associated 1


>===>>> stop writing clueless, and stop insulting and arguing with David, Duane, or
>who ever they are.

Clueless? Run a Google Groups search for posting with my name. Read
a few. Then come back and call me clueless.


--
# Jeff Liebermann 150 Felker St #D Santa Cruz CA 95060
# 831.336.2558 voice Skype: JeffLiebermann
# http://www.LearnByDestroying.com AE6KS
# http://802.11junk.com
# jeffl@comix.santa-cruz.ca.us
# jeffl@cruzio.com
 
Archived from groups: comp.sys.ibm.pc.hardware.chips (More info?)

David Taylor wrote:
>>The TZ 170 SP Wireless allows network administrators to create user accounts for
>>occasional guest users such as consultants and contractors that permit wireless
>>connections to the Internet without providing access to the corporate network.
>>
>>sounds nice ... I need to read again tonight ...
>
>
> But you can do that with any AP that provides multiple SSID's (or a
> couple of AP's) that map to seperate VLAN's, one for employees and one
> VLAN going straight out to the internet.
>
> David.

I am not tu buy 100 APs for my parents house ... nor spend 1y writing IPSEC conf,
nor buy some 3000e hardware touter ...

if nothings cheap (200 USD), or fast to implement (4 human days), I just give up.

--
DEMAINE Benoit-Pierre (aka DoubleHP ) http://www.demaine.info/
\_o< If computing were an exact science, IT engineers would not have work >o_/
 
Archived from groups: comp.sys.ibm.pc.hardware.chips (More info?)

> I am not tu buy 100 APs for my parents house ... nor spend 1y writing IPSEC conf,
> nor buy some 3000e hardware touter ...

Where did you get 100 from? I said ONE AP that supports multiple SSID's
otherwise use 2 AP's, one for each SSID and use VLAN's to seperate the
networks.
 
Archived from groups: comp.sys.ibm.pc.hardware.chips (More info?)

>>some clue to help your mind:
>>what is br0 ? how to set it up ?
>>have you ever seen a hardware NIC that the driver makes available as br0 ?
>>if it's really a linux running around, why arnt there eth0 and eth1 in the routing
>>tables ???
>
>
> It's Linux:
> ~ # uname -a
> Linux router 2.4.20 #2 Thu Apr 21 19:40:17 CEST 2005 mips unknown
>
> br0 is the bridge port and can be linked to any of the other bridged
> ethernet ports on the switch. I'll guess (not sure) that the routeing
> table uses br0 instead of eth0 because br0 is the filtered port name
> while eth0 is the unfiltered port name.

thats wrong, and your next past confirms it ...

br0 is NOT a brige port

and you can NOT choose the port of the switch you link to.

you OBVIOuSLY dont know how this device is soldered.

And finally, your guess IS WRONG.

br0 IS NOT an alias nor a filter.

I told you to read about wds because tutos tell about this difference. Maybe you
readed words, but your brain did not understood them.

> Incidentally eth0 and eth1 are there.
>
> ~ # ifconfig
> br0 Link encap:Ethernet HWaddr 00:0C:41:9C:3D:10
> inet addr:192.168.111.33 Bcast:192.168.111.255
> Mask:255.255.255.0
> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
> RX packets:87104 errors:0 dropped:0 overruns:0 frame:0
> TX packets:111983 errors:0 dropped:0 overruns:0 carrier:0
> collisions:0 txqueuelen:0
> RX bytes:10605896 (10.1 MiB) TX bytes:47923183 (45.7 MiB)
>
> eth0 Link encap:Ethernet HWaddr 00:0C:41:9C:3D:10
> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
> RX packets:268597 errors:0 dropped:0 overruns:0 frame:0
> TX packets:274490 errors:0 dropped:0 overruns:0 carrier:0
> collisions:0 txqueuelen:100
> RX bytes:70588908 (67.3 MiB) TX bytes:64626923 (61.6 MiB)
> Interrupt:3 Base address:0x2000
>
> eth1 Link encap:Ethernet HWaddr 00:0C:41:9C:3D:11
> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
> RX packets:0 errors:0 dropped:0 overruns:0 frame:0
> TX packets:66 errors:0 dropped:0 overruns:0 carrier:0
> collisions:0 txqueuelen:100
> RX bytes:0 (0.0 B) TX bytes:6331 (6.1 KiB)
> Interrupt:4 Base address:0x8000
>
> lo Link encap:Local Loopback
> inet addr:127.0.0.1 Mask:255.0.0.0
> UP LOOPBACK RUNNING MULTICAST MTU:16436 Metric:1
> RX packets:1170 errors:0 dropped:0 overruns:0 frame:0
> TX packets:1170 errors:0 dropped:0 overruns:0 carrier:0
> collisions:0 txqueuelen:0
> RX bytes:96923 (94.6 KiB) TX bytes:96923 (94.6 KiB)
>
> vlan0 Link encap:Ethernet HWaddr 00:0C:41:9C:3D:10
> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
> RX packets:87085 errors:0 dropped:0 overruns:0 frame:0
> TX packets:188737 errors:0 dropped:0 overruns:0 carrier:0
> collisions:0 txqueuelen:0
> RX bytes:11164196 (10.6 MiB) TX bytes:53280155 (50.8 MiB)
>
> vlan1 Link encap:Ethernet HWaddr 00:0C:41:9C:3D:11
> inet addr:63.198.98.51 Bcast:63.198.98.255
> Mask:255.255.255.0
> UP BROADCAST RUNNING MULTICAST MTU:1500 Metric:1
> RX packets:181414 errors:0 dropped:0 overruns:0 frame:0
> TX packets:85673 errors:0 dropped:0 overruns:0 carrier:0
> collisions:0 txqueuelen:0
> RX bytes:54582227 (52.0 MiB) TX bytes:11338413 (10.8 MiB)

without br0, eth0 and wlan0 are just ... independant !

there is NO hardware brige, and there is no default hard link.

briging eth to wlan IS SOFTWARE !!!

wlan0 is NOT an ethernet NIC with an antena, but a NIC dedicated to wireless.

> Clueless? Run a Google Groups search for posting with my name. Read
> a few. Then come back and call me clueless.

the fact you wrote 1000000messages in groups does not mean you know what you write
about.

> All 802.11 wireless cards are bridged. You can attach a router at
> both ends and hide the bridging from the client, but the basic
> protocol is bridging.

NO wireless card is briged. NONE.

Briging IS NOT A PROTOCOL, but asoftware setup.

> 802.11 wireless is bridging by definition.

did you ever set up MANUALLY a wireless card ?
what is wlan0 ?
how is br0 set up un the WRT ?

there is no such protocol as briging !
and 802.11 is only supported by dedicated cards.

> There's no other
> way to connect between wireless and wired devices other than bridging.

there IS, and I do it every morning:
iptables.

*********

the more I read your old posts, the more I see you speak cluelessly.

--
DEMAINE Benoit-Pierre (aka DoubleHP ) http://www.demaine.info/
\_o< If computing were an exact science, IT engineers would not have work >o_/
 

TRENDING THREADS