Good day, Henrik, Jeff,
Many congratulations, Jeff. Nice work on the networking!
On Sun, 27 May 2001, Henrik Nordstrom wrote:
> Some minor issues with uml_router
[snip]
> f) The "router" seems to try to be too smart for it's own good, trying
> to act as a ethernet switch but not knowing how to properly switch a
> ethernet (there are a wide range of broadcast ethernet addresses, not
> only FFFFFFFFFF). Also, it only supports a single ethernet which is a
> big drawback compared to um_eth_serv.
[snip]
> My opinion about F is that the model of um_eth_serv (plain dumb
> broadcast ethernet) is more propriate for the UML networking needs where
> one does not want to involve the host.. but implementing a userspace
> ethernet switch is a cool idea no less. If a switch is the way then it
> should at least do proper ethernet broadcas processing
>
> >From an old Ethenet FAQ:
> 02.13Q: What is a broadcast address?
> A: The unique address that identifies a packet as appropriate to
> all
> receiveing stations. In 802.3 any address in which the second
> byte
> is an odd number. (1,3,...F).
>
> (think it should read nibble above, not byte..)
Henrik, thanks. You're answering my problems before I can report
them. :-)
Using stock 2.4.5 + Jeff's 2.4.5 uml patch:
./linux mem=32M eth0=ethertap,tap1,01:02:03:04:05:06,192.168.1.60
00:24:52.730003 > client.1023 > host.ssh: S 2951267309:2951267309(0) win 5840 <mss 1460,sackOK,timestamp 2961 0,nop,wscale 0> (DF)
00:24:52.730003 M host.ssh > client.1023: S 2938270281:2938270281(0) ack 2951267310 win 5728 <mss 1444,sackOK,timestamp 5830617 2961,nop,wscale 0> (DF)
00:24:55.729705 > client.1023 > host.ssh: S 2951267309:2951267309(0) win 5840 <mss 1460,sackOK,timestamp 3021 0,nop,wscale 0> (DF)
00:24:55.729705 M host.ssh > client.1023: S 2938270281:2938270281(0) ack 2951267310 win 5728 <mss 1444,sackOK,timestamp 5830913 2961,nop,wscale 0> (DF)
00:24:57.129710 M host.ssh > client.1023: S 2938270281:2938270281(0) ack 2951267310 win 5728 <mss 1444,sackOK,timestamp 5831057 2961,nop,wscale 0> (DF)
00:25:01.730325 > client.1023 > host.ssh: S 2951267309:2951267309(0) win 5840 <mss 1460,sackOK,timestamp 3141 0,nop,wscale 0> (DF)
00:25:01.730325 M host.ssh > client.1023: S 2938270281:2938270281(0) ack 2951267310 win 5728 <mss 1444,sackOK,timestamp 5831513 2961,nop,wscale 0> (DF)
00:25:03.129744 M host.ssh > client.1023: S 2938270281:2938270281(0) ack 2951267310 win 5728 <mss 1444,sackOK,timestamp 5831657 2961,nop,wscale 0> (DF)
Note the second column; I believe the "M" stands for multicast.
The packets move back and forth, but the ssh connection never
seems to get beyond the first 2 packets of the tcp handshake; it's as if
the packets are never getting back to the uml client:
client# ssh -v host
SSH Version 1.2.27 [i686-unknown-linux], protocol version 1.5.
Standard version. Does not use RSAREF.
client: Reading configuration data /etc/ssh_config
client: ssh_connect: getuid 0 geteuid 0 anon 0
client: Connecting to host [192.168.1.60] port 22.
client: Allocated local port 1023.
[wait, wait, timeout...]
By simply changing the first byte of the ethernet address to a
"02", the response packets are standard ethernet unicast packets:
./linux mem=32M eth0=ethertap,tap1,02:02:03:04:05:06,192.168.1.60
00:43:10.313063 > client.1023 > host.ssh: S 4108490875:4108490875(0) win 5840 <mss 1460,sackOK,timestamp 994 0,nop,wscale 0> (DF)
00:43:10.313063 < host.ssh > client.1023: S 4106935573:4106935573(0) ack 4108490876 win 5728 <mss 1444,sackOK,timestamp 5940378 994,nop,wscale 0> (DF)
00:43:10.313063 > client.1023 > host.ssh: . 1:1(0) ack 1 win 5840 <nop,nop,timestamp 994 5940378> (DF)
00:43:10.313063 < host.ssh > client.1023: P 1:26(25) ack 1 win 5728 <nop,nop,timestamp 5940380 994> (DF)
00:43:10.313063 > client.1023 > host.ssh: . 1:1(0) ack 26 win 5840 <nop,nop,timestamp 994 5940380> (DF)
00:43:10.313063 > client.1023 > host.ssh: P 1:16(15) ack 26 win 5840 <nop,nop,timestamp 994 5940380> (DF) [tos 0x10]
00:43:10.313063 < host.ssh > client.1023: . 26:26(0) ack 16 win 5728 <nop,nop,timestamp 5940382 994> (DF)
00:43:10.313063 < host.ssh > client.1023: P 26:302(276) ack 16 win 5728 <nop,nop,timestamp 5940382 994> (DF)
00:43:10.469803 > client.1023 > host.ssh: P 16:172(156) ack 302 win 5840 <nop,nop,timestamp 995 5940382> (DF) [tos 0x10]
00:43:10.469803 < host.ssh > client.1023: P 302:314(12) ack 172 win 6432 <nop,nop,timestamp 5940392 995> (DF)
00:43:10.469803 > client.1023 > host.ssh: P 172:192(20) ack 314 win 5840 <nop,nop,timestamp 995 5940392> (DF) [tos 0x10]
00:43:10.469803 < host.ssh > client.1023: P 314:326(12) ack 192 win 6432 <nop,nop,timestamp 5940393 995> (DF)
00:43:10.661988 > client.1023 > host.ssh: . 192:192(0) ack 326 win 5840 <nop,nop,timestamp 999 5940393> (DF) [tos 0x10]
client# ssh -v host
SSH Version 1.2.27 [i686-unknown-linux], protocol version 1.5.
Standard version. Does not use RSAREF.
client: Reading configuration data /etc/ssh_config
client: ssh_connect: getuid 0 geteuid 0 anon 0
client: Connecting to host [192.168.1.60] port 22.
client: Allocated local port 1023.
client: Connection established.
client: Remote protocol version 1.99, remote software version OpenSSH_2.5.2p2
[login proceeds as normal...]
Start the mac address with "03", same failure as with "01". "04"
works just like "02" does. I'll pass on checking them all, but it appears
the "odd/even first byte" rule is actually correct.
In short, perhaps a short note that the first byte of the mac
should be even might save some future networking questions.
BTW, Jeff, even when I specify tap1 on the command line, I still
get the following boot-time message in uml:
eth0 will connect to TUNTAP interface tap0
No biggie. It's just been so _long_ since I've been able to
nitpick. ;-)
Cheers,
- Bill
---------------------------------------------------------------------------
"A computer without a Microsoft operating system is like a dog
without bricks tied to its head."
-- Steve on slashdot
--------------------------------------------------------------------------
William Stearns (wstearns@...). Mason, Buildkernel, named2hosts,
and ipfwadm2ipchains are at: http://www.pobox.com/~wstearns
LinuxMonth; articles for Linux Enthusiasts! http://www.linuxmonth.com
--------------------------------------------------------------------------
|