From: adam@address.invalid
Moe Trin wrote:
> On Sun, 13 Jan 2013, in the Usenet newsgroup alt.os.linux.mandriva,
> in article , Adam wrote:
[Thinkpad T60]
> there is no need for hurry. You don't need it in class yet, right?
Nope, looks like I won't need it at all there. (Although spring-term
classes are a great place to pick up anything contagious, ugh.)
Meanwhile I made other discoveries about the laptop. When I boot
Mandriva on battery power, it's VERY slow (presumably to conserve the
battery charge), even if I then connect it to AC. I'm sure that's
configurable. Also, its built-in dialup modem is a customized Winmodem.
I thought that might be handy for sending and getting faxes away from
home, but then I've never had a need for that. I may play around with
setting some of the numerous BIOS passwords. The 2GB DIMM has been
installed and tested, making 3GB total RAM.
>> Everything else on my home LAN has a fixed address.
>
> I _thought_ they were getting IPs from the router - and the _router_
> was configured to hand out specific IPs to specific MACs. Yes, that
> is static addressing, but it's still using DHCP.
No, everything has a static address specified in
/etc/sysconfig/network-scripts/ifcfg-whatever . That's because (a) it
worked and (b) I don't recall any recommendations to do it any other way.
> Yes, the public hot-spots are DHCP. Because the wireless side of helot
> does indeed go out and about, I'd suggest setting it for DHCP. At home
> if you're using the wireless, I'd suggest setting the router to hand
> out a "fixed" wireless address based on the hardware address associated
> with helot's wireless interface
Same thing as the MAC address?
> If you are also using it on Ethernet, either set that with a
> static address, _OR_ set the router to give out a "fixed" address based
> on the MAC address of the Ethernet interface (what is shown by
> "/sbin/ifconfig eth0"). My understanding of your setup was you are
> using one range on the Ethernet (ex: 192.168.1.0/28), and a separate
> range (ex: 192.168.1.16/28) for the wireless.
No, because nobody ever suggested that. Only suggestion I remember was
moving the router from 192.168.1.1 (and I learned the router has to have
the lowest used address). Would using separate ranges for wired and
wireless make things easier or better? Right now, from /etc/hosts:
127.0.0.1 localhost.localdomain localhost
192.168.1.13 dslrouter.aplomb.invalid dslrouter
192.168.1.23 eris.aplomb.invalid eris
192.168.1.24 eris-wired.aplomb.invalid eris-wired
192.168.1.33 HPCLJ5.aplomb.invalid HPCLJ5 hpclj5
192.168.1.42 stolid-wireless.aplomb.invalid stolid-wireless
192.168.1.43 stolid.aplomb.invalid stolid
192.168.1.53 helot.aplomb.invalid helot
192.168.1.54 helot-wired.aplomb.invalid helot-wired
and the address ending in 3 is the "usual" one for that device.
> Note that if you _do_ run wireless AND Ethernet connections
> at the same time, only one of those can be helot
It looks like I can have lots of devices connected (wired or wireless)
at the same time, as long as each only has one connection.
>> It looks to me that ssh configuration is "one way"
>
> Well... you've got to have a client set up on the one you're coming
> from, and a server set up on the one you're going to - so yes, that is
> effectively one way servers on each independent of each other.
But then I can configure it so each setup will work with both of the
other two machines... right?
> Your router is _probably_
> dropping all "new" connections inbound. Were you to nmap it from an
> outside IP (don't - it may make people unhappy if you try),
I already have an outside IP, my NetZero and Juno dialup accounts, and I
just used them to run 'nmap' on 96.238.n.n (my own WAN) and so far
nobody's complained. All ports from 0-65535 were "filtered" except for
two I already knew about:
PORT STATE SERVICE
2420/tcp open unknown
4567/tcp open tram
This VZ-supplied modem/router won't block these. 2420 is something like
"remote router configuration" and requires the router's ID and password
(the ones I set it to). 4567 is VZ's back door for forcible firmware
updates (and probably Customer Service's reconfiguration when the user's
really screwed up), and my research suggests the UID is the MAC address
without the : (but UC or LC?) and the password is 14 hex characters
probably derived from the MAC, and 256^14 = 5e33.
>> BTW would it be possible for the laptop to ssh into stolid when I'm
>> away from home? My WAN IP is usually 96.238.xxx.xxx (not static)
>
> you've got to tell the router to forward
> this or that port to this or that IP.
I suppose I could log in from "outside" to the router on port 2420 and
configure port forwarding through that, if I knew what I was doing. OTOH
occasionally (seldom) my router reboots and ends up with a new WAN
address, so I can't be 100% sure the WAN address it had when I left home
will be the same several hours later.
>> I ran numerous nmap and netstat commands
>
> Got it - QUICK LOOK data
That's fine -- I'm sure what's unusual stuck out to you. BTW I have no
idea why any of the systems are offering nearly any of the services, as
for the most part they're still all the default configurations.
> 1. stolid nmap:
> Not sure why you're running a DNS server on it.
It's its own DNS server, but shouldn't be acting as one for anything
else. Gotta look into that. (For everything else, to get them up
quickly they're using the VZ DNS for now.)
> The high port looks to be bit-torrent. Not sure why it's open either.
51413 /is/ torrent. I was getting a rescue CD or something at that
moment. I thought that had to be open for torrents to work, but not the
rest of the time.
> Per above, the router isn't forwarding anything to
> stolid, so this is not going to do anything useful.
Not sure what you mean -- that torrent worked.
> 2. helot nmap running Mandriva
> You're running Samba? (139 and 445). No idea why X is visible either,
> or why it's offering printer services.
Agree those aren't needed. All (except ssh) need to be disabled.
> 3. helot nmap running Mageia
Which also took at least 12x longer than any other nmap scan of
anything. I suppose that is a Good Thing.
> Much better - there is a firewall _dropping_ all inbound EXCEPT 113
> which is being rejected. A common firewall setup for a system that
> is intentionally not offering services. The 'reject' of 113 is a
> tradeoff - if the port were being dropped rather than rejected, some
[continued in next message]
--- SoupGate-Win32 v1.05
* Origin: you cannot sedate... all the things you hate (1:229/2)
|
